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

[Fabio Ribeiro]

Me chegou em mente uma questão muito elementar e besta ao mesmo tempo,
O QUIC ou UDP consegue tirar proveito do BBR?

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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>