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

[Douglas Caetano dos Santos]

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