Che cos'è Laminar?
Laminar è un nuovo framework per il controllo della congestione TCP che separa la pianificazione della trasmissione, che determina con precisione quando vengono inviati i dati, dal puro controllo della congestione, che determina la quantità totale di dati inviati durante ogni RTT.
L'algoritmo predefinito per la pianificazione della trasmissione è un'implementazione rigorosa del principio di conservazione dei pacchetti di Van Jacobson [Jacobson88]. I dati che arrivano al destinatario causano errori ACK, che a loro volta portano il mittente a ritrasmettere alla rete una quantità equivalente di dati. La variabile dello stato principale è implicita nella quantità di dati e di ACK che circolano nella rete. Questo stato viene osservato tramite un stimatore migliorato tcp_packets_in_flight() (noto anche come total_pipe). Il total_pipe si basa su una "pipe" come descritto in RFC 3517, ma include anche la quantità di dati riportata dall'ACK attuale e le trasmissioni in attesa che hanno superato il controllo della congestione ma sono in attesa di altri eventi come il TSO.
Una nuova variabile, CCwin, è la principale variabile dello stato del controllo della congestione. Gli algoritmi di controllo della congestione regolano CCwin per regolare il livello complessivo di congestione lungo il percorso. Sebbene CCwin assomiglia a cwnd, cwnd è sovraccarico e utilizzato da più algoritmi (come la soppressione dei burst) con obiettivi diversi e a volte contrastanti.
Ogni volta che total_pipe è diverso da CCwin, l'algoritmo di pianificazione della trasmissione modifica leggermente il numero di segmenti inviati in risposta a ogni ACK. Avvio lento e riduzione della tariffa proporzionale [PRR] (sostituzione del dimezzamento della tariffa) sono entrambi integrati nell'algoritmo di pianificazione della trasmissione.
Il vantaggio principale del framework Laminar è che, dividendo il controllo della congestione e la pianificazione della trasmissione in sottosistemi separati, ognuno è soggetto a vincoli di progettazione molto più semplici, semplificando lo sviluppo di molti nuovi algoritmi che non sono fattibili con la precedente organizzazione del codice.
Il framework Laminar cambia la filosofia di progettazione sottostante del controllo della congestione di TCP e ha potenzialmente ampie implicazioni, oltre alla patch stessa. Lo scopo di questa patch è consentire agli utenti di sperimentare il codice, aggiungere commenti e aiutare a scoprire eventuali casi limite che potrebbero essere stati trascurati. Inoltre, la patch è incompleta, nel senso che mancano ancora alcuni algoritmi, nello specifico: algoritmi di controllo della congestione diversi da CUBI e Reno; convalida basata sui dati, metriche di destinazione e così via. Sarebbe davvero bello se le persone potessero aiutare a eseguire il refactoring di alcuni di questi altri algoritmi.
Il framework Laminar e la sua motivazione sono descritti in modo più approfondito in una bozza di Internet, draft-mathis-tcpm-tcp-laminar.
Invia commenti e suggerimenti all'indirizzo mattmathis@google.com.
Questo progetto fa parte dell'impegno di Google per rendere il web più veloce attraverso i miglioramenti del protocollo.
Note di implementazione
Laminar viene implementato principalmente in 3 funzioni (tcp_input.c):
Tcp_cong_avoid() e tcp_mult_decr() eseguono il controllo della congestione AIMD utilizzando la variabile di stato CCwin. Fatta eccezione per l'annullamento, queste due funzioni sono le uniche in cui CCwin apporta modifiche. (Entrambe le funzioni richiamano gestori specifici dei moduli di congestione).
Tcp_laminar_schedule() determina la quantità di dati da inviare in risposta a ogni ACK. Implementa la conservazione dei pacchetti di Van Jacobson, regolata leggermente verso l'alto o verso il basso per far convergere tcp_packets_in_flight() in CCwin.
Sono state apportate modifiche importanti allo strumento di stima tcp_packets_in_flight() per renderlo invariante nella maggior parte degli eventi di protocollo. L'applicazione si blocca, gli aggiustamenti in tcp_laminar_schedule() e le perdite di pacchetti effettive cambiano tcp_packets_in_flight(), come devono. l'elaborazione ACK, i TSO e la maggior parte degli altri eventi non lo fanno. Tieni presente che, in caso di perdite, il numero effettivo di pacchetti in fase di volo cambia immediatamente, ma non viene indicato nello strumento di stima tcp_packets_in_flight() finché il macchinario di ritrasmissione li contrassegna come persi e incrementa lost_out.
Scarica la patch
Questa patch è contro net-next di Dave Miller e si applica in modo pulito alla versione 3.5-rc2.
Nota: i moduli di controllo della congestione diversi da Reno e CUBI non sono stati aggiornati e non verranno compilati. Se la tua configurazione crea altri moduli di controllo della congestione, ad esempio vegas, scalabili, ad alta velocità e così via, questi devono essere prima disabilitati.