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

Mon Jul 31 14:59:01 -03 2017

Oi Roberto,

On 31-07-2017 14:38, Roberto Lima wrote:
> Sem fugir do escopo da conversa. O BBR melhoraria também a latencia no
> tempo de resposta de requisições DNS ou apenas para streaming?

Diretamente não.

Indiretamente, no entanto, é possível que haja melhoras, pois o BBR evita o
bufferbloat que é um dos grandes causadores de latência. Por exemplo, numa
situação em que o usuário esteja fazendo uma transferência grande enquanto
faz uma requisição DNS, pode haver melhora se o servidor enviando os dados dessa
transferência estiver usando BBR. Nesse caso, a transferência não causará
bufferbloat, não haverá aumento de latência devido a esse problema e a
requisição DNS será atendida mais rapidamente. Observa, porém, que o BBR não
necessariamente foi utilizado no servidor DNS, mas sim em um terceiro servidor
qualquer.

Em resumo, BBR poderá ajudar a diminuir a latência de um modo geral na medida em
que mais servidores na Internet como um todo o utilizarem.

> Abs.

Abraço!
Douglas.

> Em 31 de julho de 2017 13:14, Douglas Caetano dos Santos <
> douglascs at taghos.com.br> escreveu:
> 
>> 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