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

[Douglas Caetano dos Santos]

On 28-07-2017 17:14, Lucas Willian Bocchi wrote:
> Douglas, concordo com tudo o que você disse, porém pra mim, o ônus acaba
> saindo de um lado e indo pro outro: assim como você diz que as camadas de
> baixo se engessam pra atender as de cima, as de cima também se engessam
> (que é o exemplo do BBR) pra se ajustar melhor a de baixo. É a história do
> cobertor: quando você puxa pra cobrir a cabeça, descobre os pés, e quando
> cobre os pés descobre a cabeça.

Nisso concordo plenamente contigo, Lucas. Mas aí faz sentido a camada de
cima se adaptar à de baixo, afinal é a de cima que utiliza a de baixo, e não o
contrário. Claro que, havendo necessidade de adaptação, as camadas de baixo
passam por uma evolução. Vide jumbo frames em Ethernet, seria uma adaptação da
esteira para passar caixas maiores. É melhor engessar as camadas de cima, que
se podem substituir facilmente, do que as de baixo, que quando implementadas
precisam permanecer lá por um bom tempo - vide IPv4 vs IPv6, cuja batalha para
mudança já dura décadas, e os diversos controles de TCP que foram criados e
utilizados ao longo desse mesmo período com facilidade.

Inclusive, na sexta passada foi enviado para o kernel Linux um novo controle de
congestionamento chamado TCP Wave que parece muito interessante por propor uma
solução bem diferente da do BBR.

Abraço!
Douglas.


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