E no caso geral não se tem qualquer tipo de controle sobre os buffers, os quais são partilhados para todo o tráfego que lá passa. E a experiência mostra que com uma única stream TCP obténs um determinado débito, mas com várias ligadas streams ao mesmo servidor o débito cresce. Bummer. Não percebeste o que está em causa. A agregação de tráfego num link é uma coisa. Uma stream TCP isolada nesse mesmo link, é outra. De qq modo, o artigo fala por si.
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.
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) 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.
É o suficiente para provar que os teus cálculos do upstream mínimo estão errados, e carecem de verificação experimental.