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

[Douglas Caetano dos Santos]

Lucas,

On 28-07-2017 14:19, Lucas Willian Bocchi wrote:
> Douglas
> Na verdade me refiro aos modelos de camada 1 e 2 que às vezes não estão
> muito aí pensando o que vai nas camadas acima delas. Logicamente, não é
> obrigação dessas camadas saber o que vai trafegar acima delas, e elas não
> estão nem aí, as camadas de cima que precisam saber "caminhar" sobre as
> duas primeiras, mas é que eles poderiam pensar um pouco melhor na hora de
> implementar isso pra dar uma "ajudinha" pro que já existe.

Mas aí tu corre o risco de uma camada inferior limitar uma superior. O que,
especificamente, se poderia fazer no protocolo Ethernet, por exemplo, pra
melhorar o protocolo IP? E no IP, pro TCP? A grande vantagem desse modelo de
camadas é exatamente a independência entre elas.

E se, no meio do caminho, a camada física mudar? Isso é extremamente comum. Uma
hora o pacote IP está trafegando sobre Ethernet, outra sobre ADSL, outra em uma
rede celular... Se essa "ajudinha" que tu mencionas fosse implementada, tornaria
cada camada dependente de todas as demais, engessando os protocolos utilizados.

Quanto ao BBR, as considerações a respeito do meio físico são feitas apenas para
determinação de comportamento do ponto de vista do próprio TCP. O BBR não faz
distinção internamente do meio físico, ou seja, o BBR não sabe se os dados
estão trafegando em uma rede Ethernet cabeada ou em uma rede celular, ou se os
roteadores intermediários têm buffers gigantes ou minúsculos. Internamente ele
apenas analisa o comportamento do próprio TCP em função do tempo de confirmação
dos dados enviados, da velocidade que são enviados, entre outros. Não há uma
análise do tipo "ah, acho que essa é uma rede sem fio, então vou me comportar
dessa maneira."

Abraço!
Douglas.


> Em 28 de julho de 2017 11:23, Douglas Caetano dos Santos <
> douglascs at taghos.com.br> escreveu:
> 
>> 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
>>>
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>