[GTER] Google detalha novo algoritmo de congestão TCP

[Douglas Caetano dos Santos]

Oi Lucas,

On 27-07-2017 16:02, Lucas Willian Bocchi wrote:
> Imagine um protocolo como sendo um carro, e ele é. Carrega coisas. Agora,
> esqueça a noção de carro que temos hoje com 4 rodas. Imagine que o carro
> fosse, sei lá, uma caixa que fosse arrastada com uma esteira. Em toda a
> estrada que você tivesse que passar, teria que ter uma esteira (movida por
> motor, água, sei lá o quê), mas a mecânica teria que ser a mesma: o carro
> pra funcionar precisa de uma esteira. O que o povo fez foi pegar uma caixa
> que precisa de uma esteira pra se mover e colocaram puxador, cavalo pra
> arrastar a caixa, e assim por diante.

Por qual razão tu vê o BBR como apenas um puxador numa caixa? Uma ou outra
característica talvez possa ser considerada meia-boca, mas quase tudo é muito
bem pensado.

Nessa tua analogia, o BBR não seria um puxador, mas apenas um controle mais
esperto de quando colocar mais caixas nessa esteira.

Além disso, o BBR busca resolver uma série de problemas, e não apenas ser "mais
rápido". Exemplos são o bufferbloat (buffers gigantes que causam aumento de
latência), shallow buffers (buffers pequenos demais, que causam perdas de
pacotes esporádicas não devidas a congestionamento, o que causa sinalização
incorreta pros controles de congestionamento com base na perda de pacotes) e
redes sem fio (onde ocorre perda de pacote por causa do meio físico, não por
congestionamento).

Pode-se dizer que o BBR faz um aproveitamento da rede muito melhor que os demais
controles de congestionamento num caso geral. Óbvio que haverá casos específicos
que o BBR não serve, aqui mesmo tivemos problemas com ele, mas no geral tende a
ser um controle muito mais inteligente e robusto. Precisa, sim, de melhorias,
mas é um grande avanço frente ao que vinha sendo utilizado até então.

Abraço!
Douglas.

> 
> Em 27 de julho de 2017 14:50, Douglas Caetano dos Santos <
> douglascs at taghos.com.br> escreveu:
> 
>> Wellington,
>>
>> On 26-07-2017 17:01, Wellington Almeida wrote:
>>> Que adianta protocolo "mias rápido" se há 30 km do centro de são paulo
>> você
>>> mal consegue ter 5 mega de velocidade via rádio ?
>>> 3g e 4g sofríveis e com planos que mais parecem uma piada... como a Tim
>> que
>>> tem planos de 50 megas de franquia... me pergunto o que vc faz com 50
>> megas
>>> hoje em dia.. envia 3 fotos ? Cabos podres, velocidades de 100 mega com
>>> garantia de apenas 3... e por ai vai..
>>
>> Exatamente por causa desse tipo de problema (dentre outros) é que esse novo
>> controle de congestão foi feito. O TCP original não consegue agir
>> corretamente
>> em situações como as que temos hoje, como por exemplo redes sem fio (e não
>> apenas por problemas de equipamentos ruins, mas também porque redes sem
>> fio têm
>> problemas intrínsecos devido à física da propagação de sinais) ou situações
>> "piadas" que tu descreves. (E eu concordo que muito disso tudo só pode ser
>> "piada" mesmo, ainda que eu já não consiga mais rir de nada disso.)
>>
>> Em resumo, a solução de um problema não impede a solução de outro. Ou
>> seja, não
>> adianta criticar a criação de um novo protocolo se essa reclamação não
>> leva à
>> solução do outro problema reclamado. Esse novo protocolo é MUITO bem vindo
>> para
>> solucionar inúmeros problemas existentes atualmente, talvez não
>> observáveis por
>> todos os usuários de Internet.
>>
>> Att.,
>> Douglas.
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>