Existe um algoritmo para fingerprinting o algoritmo de controle de congestionamento TCP usado em uma sessão capturado?

Question

Eu gostaria de um programa para determinar a controle de congestionamento algoritmo TCP usado em uma sessão TCP capturado .

Os referenciados artigo afirma Wikipédia:

TCP New Reno é o mais comumente implementado algoritmo, suporte SACO é muito comum e é uma extensão Reno / New Reno. A maioria dos outros são propostas concorrentes que ainda precisam avaliação. Começando com 2.6.8 do Linux kernel do comutada padrão implementação de Reno a BIC. o implementação padrão foi novamente mudado para CUBIC no 2.6.19 versão.

Além disso:

Compound TCP é um Microsoft implementação de TCP, que mantém duas janelas de congestionamento diferentes simultaneamente, com o objectivo de alcançar um bom desempenho em LFNs enquanto não prejudicar justiça. Tem sido amplamente implantado com Microsoft Windows Vista e Windows Server 2008 e foi portado para mais velhos Microsoft Do Windows versões, bem como Linux.

O que seria algumas estratégias para determinar qual algoritmo CC está em uso (de um terceiro capturar a sessão)?

Atualizar

Este projecto construiu uma ferramenta para fazer isso:

A Internet tem sido recentemente evoluindo de congestionamento homogénea controlo de congestão heterogénea ao controle. Vários anos atrás, Internet tráfego foi controlado principalmente pela algoritmo padrão TCP AIMD, enquanto tráfego da Internet é agora controlada por muitos controle de congestionamento TCP diferente algoritmos, tais como AIMD, BIC, cúbica, CTCP, HSTCP, HTCP, Hybla, Illinois, LP, STCP, VEGAS, veno, WESTWOOD +, e SIM. No entanto, há muito pouco trabalho sobre o desempenho e estabilidade estudar da Internet com controlo do congestionamento heterogénea. 1 razão fundamental é a falta de informações de implantação de diferente algoritmos TCP. Os objectivos desta projeto são:

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

Answer 1

Existem muitos algoritmos de controle mais congestionamento do que você mencionar aqui, em cima da minha cabeça a lista inclui:. RÁPIDO, Scalable, HSTCP, HTCP, Bic, Cubic, Veno, Vegas

Há também pequenas variações delas devido a correções de bugs em implementações reais e eu acho que as implementações em diferentes sistemas operacionais também se comportam ligeiramente diferentes um do outro.

Mas se eu precisar para tentar chegar a uma idéia que seria para estimar o RTT da ligação, você pode tentar olhar para o tempo que levou entre o terceiro eo quarto pacotes, como o primeiro e segundo pacotes pode ser infectado por ARPs e outros algoritmos de identificação ao longo do percurso.

Depois de ter uma estimativa para RTT você poderia tentar refiná-lo ao longo do caminho, eu não sei exatamente como você pode fazer isso, porém. Mas você não precisa de uma especificação completa para o programa, apenas idéias: -)

Com o RTT descobri que você pode tentar colocar os pacotes em caixas RTT e contar o número de em pacotes de dados de voo em cada bin. Desta forma, você vai ser capaz de "complô" Estima-cwnd (# de pacotes no bin) ao tempo e tentar alguma correspondência de padrão lá.

Uma alternativa seria a de ir ao longo do traço e tentar "executar" na sua cabeça as diferentes algoritmos de controle de congestionamento e ver se a decisão em todas as correspondências pontos com a decisão que você teria feito. Ele vai exigir alguns intervalos de leniência e precisão.

Isso definitivamente soa como uma tarefa interessante e desafiador!