Quali sono gli svantaggi possibili nell'impostare un initcwnd (molto) grande per connessioni ad alta larghezza di banda?

Ho sperimentato i parametri TCP in Linux (con un kernel 3.5). Fondamentalmente riguardo a questa connessione:

Server: uplink Gigabit nel datacenter, la larghezza di banda effettiva (dovuta alla condivisione degli uplink) è di circa 70 MB / s quando viene testato da un altro datacenter.

Client: LAN locale Gigabit collegata a fibra a 200 mbit. Il recupero di un file di test raggiunge effettivamente 20 MB / s.

Latenza: circa 50ms andata e ritorno.

Il server remoto viene utilizzato come file server per i file nell'intervallo da 10 a 100 MB. Ho notato che usando un initcwnd di 10 il tempo di trasferimento per questi file è fortemente influenzato dall'avvio lento del TCP, impiegando 3,5 secondi per caricare 10 MB (velocità massima raggiunta: 3,3 MB / s) perché si avvia lentamente e poi accelera comunque è terminato prima che sia raggiunta la velocità massima. Il mio obiettivo è ottimizzare i tempi di caricamento minimi di quei file (quindi non la massima velocità raw o la più bassa latenza di andata e ritorno, sono disposto a sacrificare entrambi se ciò diminuisce il tempo effettivo necessario per caricare un file)

Quindi ho provato un semplice calcolo per determinare quale dovrebbe essere l'ideale initcwnd, ignorando qualsiasi altra connessione e possibile impatto sugli altri. Il prodotto con ritardo di larghezza di banda è di 200 Mbit / s * 50ms = 10 Mbit o 1.310.720 byte. Considerando che initcwnd è impostato in unità di MSS e supponendo che l'MSS sia di circa 1400 byte, ciò richiederà un'impostazione di: 1.310.720 / 1400 = 936

Questo valore è molto lontano dal valore predefinito (10 * MSS in Linux, 64kb in Windows), quindi non è una buona idea impostarlo in questo modo. Quali sono gli aspetti negativi attesi della configurazione in questo modo? Per esempio:

• Interesserà gli altri utenti della stessa rete?
• Potrebbe creare una congestione inaccettabile per altre connessioni?
• Inondare i buffer del router da qualche parte sul percorso?
• Aumentare l'impatto di piccole quantità di perdita di pacchetti?

Quali sono gli aspetti negativi attesi della configurazione in questo modo? Per esempio:

Will it affect other users of the same network?

La modifica di initcwnd influenzerà:

• Gli utenti del server con le impostazioni cambiano
• SE quegli utenti corrispondono al percorso su cui è configurata la modifica delle impostazioni.

Could it create unacceptable congestion for other connections?

Sicuro.

Flood router-buffers somewhere on the path?

Non irrilevante, ma a meno che non siano i tuoi router, mi concentrerei sulle questioni più vicine a te.

Increase the impact of small amounts of packet-loss?

Certo, può farlo.

Il risultato è che ciò aumenterà il costo della perdita di pacchetti, sia intenzionale che non intenzionale. Il tuo server è più semplice per DOS da chiunque sia in grado di completare l'handshake a 3 vie (quantità significative di dati in uscita per un basso investimento (quantità di dati) in).

Aumenterà anche le possibilità che un gruppo di quei pacchetti debba essere ritrasmesso perché uno dei primi pacchetti nel burst andrà perso.

Non credo di aver compreso appieno ciò che stai chiedendo, quindi ecco un tentativo di rispondere:

Prima di tutto, ciò che stai cercando di fare ha senso solo sul lato mittente e non sul lato ricevente. Cioè devi cambiare il file server e non il ricevitore. Supponendo che sia quello che stai facendo:

Cambiando initcwnd in (es.) 10 significa che 10 pacchetti spariranno immediatamente. Se tutti raggiungono il loro obiettivo, si potrebbe finire con una finestra molto più grande nel primo RTT a causa dell'avvio lento (l'aumento esponenziale del cwnd). Tuttavia, in caso di perdita dei pacchetti, la cwnd sarà dimezzata e poiché stai esplodendo con 10 pacchetti avrai una notevole quantità di ritrasmissioni, quindi potresti finire con più problemi di quanto pensi.

Se vuoi provare qualcosa di più aggressivo ed essere in qualche modo "maleducato" con altri utenti di Internet di quanto puoi invece modificare l'algoritmo di controllo della congestione sul lato server. Algoritmi diversi gestiscono cwnd in modo diverso. Tieni presente che ciò interesserà tutti gli utenti a meno che il tuo software lato server non modifichi questa connessione (che dubito fortemente). Il vantaggio qui è che l'algoritmo sarà attivo anche dopo la perdita di pacchetti mentre initcwnd non avrà molto ruolo.

/ proc / sys / net / ipv4 / tcp_congestion_control è dove si modifica l'algoritmo di controllo della congestione.

FWIW per RTT così piccoli (50ms) e per file medi o grandi, initcwnd non dovrebbe influire molto sulla velocità media. Se non ci sono perdite di pacchetti, allora (ad es. Fat pipe) la cwnd raddoppierà ad ogni RTT. Con RTT = 50ms su un tubo grasso inserirai 20 RTT nel primo secondo, il che significa che con initcwnd = 2 finirai con cwnd = 2 * 2 ^ 20 dopo 1 secondo, che scommetto è più che puoi maniglia ;-)