5

Desidero un programma per determinare lo TCP congestion control algorithm utilizzato in una sessione TCP acquisita.Esiste un algoritmo per l'impronta digitale dell'algoritmo di controllo della congestione TCP utilizzato in una sessione acquisita?

Le fa riferimento Wikipedia articolo afferma:

TCP New Reno è il più comunemente algoritmo implementato, il supporto sacco è molto comune ed è un'estensione Reno/New Reno. La maggior parte degli altri sono proposte concorrenti che hanno ancora bisogno di valutazione . A partire dal 2.6.8 il kernel Linux ha cambiato l'implementazione di default da da reno a BIC. L'implementazione predefinita era nuovamente modificata in CUBIC nella versione 2.6.19 .

anche:

Compound TCP è un Microsoft implementazione di TCP che mantiene due diverse finestre di congestione contemporaneamente, con l'obiettivo di raggiungere buone prestazioni su LFNs pur non pregiudicare l'equità. Dispone di Microsoft Windows Vista e Windows Server 2008 ed è stato convertito in versioni precedenti di Microsoft Windows e Linux.

Quali sarebbero alcune strategie per determinare quale algoritmo CC è in uso (da una terza parte che cattura la sessione)?

Aggiornamento

This project ha costruito uno strumento per fare questo:

Internet è stato recentemente evolvendo da congestione omogenea controllo per eterogeneo di congestione controllo. Diversi anni fa, Internet il traffico era controllato principalmente con l'algoritmo TCP AIMD serie , mentre traffico Internet è ora controllata da molti di controllo della congestione TCP diversa algoritmi, come AIMD, BIC, cubi, CTCP, HSTCP, HTCP, HYBLA, ILLINOIS, LP, STCP, VEGAS, VENO, WESTWOOD + e YEAH. Tuttavia, ci sono pochissimo studio su Internet con controllo di congestione eterogeneo. Una ragione fondamentale di è la mancanza delle informazioni di distribuzione di diversi algoritmi TCP . Gli obiettivi di questo progetto sono:

1) develop tools for identifying the TCP algorithms in the Internet, 
2) conduct large-scale TCP-algorithm measurements in the Internet. 

risposta

4

Ci sono molti algoritmi più di controllo della congestione che si parla qui, la parte superiore della mia testa l'elenco comprende: veloce, scalabile, HSTCP, HTCP, Bic, Cubico, Veno, Vegas.

Esistono anche piccole variazioni a causa di correzioni di bug nelle implementazioni effettive e suppongo che le implementazioni in diversi sistemi operativi si comportino anche in modo leggermente diverso l'una dall'altra.

Ma se ho bisogno di provare a farmi un'idea sarebbe di stimare l'RTT della connessione, puoi provare a guardare il tempo impiegato tra il terzo e il quarto pacchetto, come il primo e il secondo i pacchetti possono essere contaminati da ARP e altri algoritmi di rilevamento lungo il percorso.

Dopo aver stimato per RTT, potresti provare a perfezionarlo lungo il percorso, ma non sono esattamente sicuro di come potresti farlo. Ma non hai bisogno di una specifica completa per il programma, solo idee :-)

Con RTT capito puoi provare a mettere i pacchetti in bidoni RTT e contare il numero di pacchetti di dati in volo in ciascun cestino. In questo modo sarete in grado di "tracciare" stime-cwnd (numero di pacchetti in bin) al tempo e provare alcuni pattern matching in quel punto.

Un'alternativa sarebbe quella di percorrere la traccia e provare a "correre" nella testa i diversi algoritmi di controllo della congestione e vedere se la decisione in qualsiasi punto corrisponde alla decisione che avresti fatto. Richiederà alcuni intervalli di clemenza e precisione.

Questo sicuramente sembra un compito interessante e stimolante!