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

[Douglas Caetano dos Santos]

On 31-07-2017 12:00, Fabio Ribeiro wrote:
> Me chegou em mente uma questão muito elementar e besta ao mesmo tempo,
> O QUIC ou UDP consegue tirar proveito do BBR?

UDP não, porque não tem controle de congestionamento (nem qualquer outro tipo de
controle). QUIC, no entanto, é um protocolo de transporte com
garantia de recepção tal qual o TCP e, por isso, tem os respectivos controles
necessários (incluindo o de congestionamento). Portanto, sim, QUIC tira proveito
do BBR quando esse controle é usado, tanto que já foi implementado para QUIC,
conforme link que eu indiquei no e-mail anterior. A implementação do BBR, no
entanto, é separada; existe uma para o TCP e outra para o QUIC.

Abraço!
Douglas.

> Em 31-07-2017 11:48, Douglas Caetano dos Santos escreveu:
>> On 31-07-2017 11:22, Fabio Ribeiro wrote:
>>> Douglas,
>>>
>>> Perguntar uma coisa, se a maioria utiliza UDP+QUIC, no sentido que há
>>> muito marketshare está nos APPs do Youtube e o Chrome para isso não foi
>>> perda de tempo... Será?
>>
>> QUIC foi um experimento da Google pra testar alguns conceitos que não se
>> poderiam testar no TCP que temos hoje. O uso do UDP foi porque criar um
>> protocolo sobre IP diretamente seria impraticável devido ao engessamento das
>> redes IP que apenas preveem os protocolos sobre IP que conhecemos hoje (TCP,
>> UDP, ICMP, etc.) Como UDP é extremamente simples, sem previsão de qualquer
>> tentativa de controle sobre o tráfego, foi a escolha natural para implementar o
>> QUIC. Nesse sentido, temos outros protocolos que seguiram caminho semelhante,
>> como o uTP (uTorrent Protocol).
>>
>> Não foi perda de tempo porque o conceito por trás do BBR não está atrelado
>> ao TCP, mas sim à ideia de transporte de dados. Tanto é que o BBR foi
>> implementado para o QUIC também [1]. Lembrando que o QUIC é um substituto do
>> TCP do ponto de vista do transporte de dados, ou seja, muitos problemas
>> existentes no TCP também existem no QUIC, dentre os quais aqueles que o BBR
>> procura solucionar.
>>
>> Ao menos pelo que a Google diz, os experimentos com o QUIC buscam testar
>> hipóteses de melhorias que posteriormente serão (ou talvez já foram) portados
>> para o TCP.
>>
>>> E que o Google não quer mexer diretamente nos protocolos, só ao entorno,
>>> isso por que para manter compatibilidade e não quebrar "a internet"?
>>
>> Mais ou menos por aí. Mexer no TCP é uma grande dificuldade porque exige que
>> muitos usuários tenham de fazer alteração em seus softwares, além de que um TCP
>> não pode ser incompatível com outro. Imagina esse cenário: a Google (ou qualquer
>> servidor na Internet) passa a usar um TCP com alterações incompatíveis com o TCP
>> dos usuários. O resultado seria que a maioria dos usuários (pra não dizer todos)
>> não conseguiriam mais acessar tal servidor. Além disso, há inúmeras outras
>> questões, como a competição entre diversos fluxos TCP com protocolos diferentes
>> e o compartilhamento justo da banda disponível entre esses fluxos.
>>
>>> O remendo é tanto, será que está na hora de abandonarmos o principalmente
>>> o TCP?
>>
>> Eu, pessoalmente, acho que o TCP poderia ser, num futuro próximo, substituído
>> por um protocolo que contemple as necessidades atuais. O QUIC experimenta
>> diversas coisas que o TCP não consegue fazer e que talvez nunca conseguirá por
>> causa das premissas que o protocolo assume como ponto de partida. Não estou, no
>> entanto, advogando em favor do QUIC, até porque não tenho experiência com ele.
>>
>> De outro lado, no entanto, tem que se ver que o TCP já é um protocolo conhecido
>> e entendido por todos e muito robusto. Ele funciona e funciona bem. É difícil
>> fazer uma troca de algo que está funcionando bem, apesar de a "guerra" IPv4 vs
>> IPv6 estar aí para mostrar que é necessário pensar com bastante antecedência
>> nesse tipo de mudança.
>>
>>> Enquanto ao QUIC, se é para fazer gambita em cima do UDP, que se faça
>>> logo um novo protocolo. A partir de agora considero uma variante do UDP.
>>
>> O QUIC é um novo protocolo. Apenas usa o UDP como o UDP ou o TCP usam o IP, que
>> por sua vez usa Ethernet, por exemplo. O QUIC não é um substituto do UDP, mas um
>> protocolo que roda por cima dele, fazendo uso de suas propriedades.
>>
>>> Abraços.
>>
>> Abraço!
>> Douglas.
>>
>> [1] https://chromium.googlesource.com/chromium/src/net/+/master/quic/core/congestion_control/bbr_sender.cc
>>
>>
>>>
>>> Em 31-07-2017 10:33, Douglas Caetano dos Santos escreveu:
>>>> Oi Fábio,
>>>>
>>>> On 31-07-2017 10:00, Fabio Ribeiro wrote:
>>>>> Um detalhe que fico imaginando o Google em fazer esta empreitada é
>>>>> performance em streaming de video, arquivos grandes. O que não é o caso
>>>>> de comunicações mais peculiares como WhatsApp, que tem quadros muitos
>>>>> pequenos e por fim não tem grande vantagem.
>>>>>
>>>>> Confere?
>>>>
>>>> No meu ponto de vista, e pelo que li, confere sim. Uma das razões para a criação
>>>> do BBR foi a existência do Bufferbloat [1], que gera principalmente um grande
>>>> aumento geral de latência na entrega de pacotes. O BBR procura controlar o envio
>>>> de forma a evitar o acúmulo de pacotes em buffer no caminho entre as pontas. As
>>>> pequenas transferências também têm vantagens porque o BBR consegue alcançar mais
>>>> rapidamente a banda máxima do caminho (a depender de diversos fatores, claro),
>>>> mas, como tu disseste, não é lá uma grande vantagem para essas transferências em
>>>> si. A vantagem será a redução/eliminação da latência provocada pelas grandes
>>>> transferências. Outro objetivo do BBR é a estabilidade na transferência em
>>>> caminhos com grandes perdas ou com grande latência natural (distâncias
>>>> continentais, por exemplo).
>>>>
>>>> [1] https://en.wikipedia.org/wiki/Bufferbloat
>>>>
>>>> Abraço!
>>>> Douglas.
>>>>
>>>>> Em 21-07-2017 15:24, Fábio Rodrigues Ribeiro escreveu:
>>>>>> Boa tarde a todos.
>>>>>>
>>>>>> Fique sabendo via mídia secular[1]. Mais detalhes no link da matéria, ou
>>>>>> diretamente no blog do Google, que a caixas da GCP já tem esse novo
>>>>>> recurso[2].
>>>>>>
>>>>>> [1]
>>>>>> https://olhardigital.com.br/noticia/novo-algoritmo-do-google-promete-tornar-toda-a-internet-mais-rapida/69888
>>>>>>
>>>>>> [2]
>>>>>> https://cloudplatform.googleblog.com/2017/07/TCP-BBR-congestion-control-comes-to-GCP-your-Internet-just-got-faster.html