Eu estou bastante bem informado sobre o TCP Congestion Control, sou das poucas pessoas que alguma vez leu os RFPs que o definem e escreveram código sobre ele.
O RTT apenas influência o débito, se os buffers nas pontas não suportarem o débito*RTT.
Basta que haja perda de pacotes em qualquer ponto do trajecto, para que a recuperação dependa do RTT. E perda de pacotes pode haver muito facilmente.
Um exemplo disso é teres um emissor a 100Mbps e um link de saída a 10Mpbs. O emissor pensa que pode emitir a 100 e vai acelerar até detectar perda de pacotes e depois entra no ciclo de congestion control, onde a velocidade média de emissão é inferior a 10Mbps.
(entretanto com essa brincadeira o emissor vai mantendo cheio o buffer de saída aumentando ainda mais o RTT, mas essa parte com QoS resolve-se)
Errado. O TCP congestion control baseia-se apenas na gestão dos buffers em cada ponto.
Eu percebo perfeitamente o que está em causa. A conclusão que queres tirar do artigo é que não existe. É bastante fácil demonstrar isso. Basta teres 2 PCs ligados por Gb, e fazeres uma tranferência por FTP, de onde obtens 120MB/s, com 1 ligação.
Esta "demonstração" é equivalente a medir a performance do IC19 fazendo voltas de carro no Autódromo do Estoril (é obrigatório fazer analogias com carros quando as pessoas não se entendem :-) )
Isto porque no cenário indicado - 2 PCs ligados por Gb - tem-se:
- latência muitíssimo baixa, RTT próximo de zero
- ausência de botlleneck; não há perda de pacotes nem congestão
Ou seja, as duas condições que originam o fenómeno não estão presentes.
Neste caso, de facto só depende dos buffers suportarem débito*RTT, mas este cenário não representa aquilo de que se está a falar nesta thread.
