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

Mon Jul 31 15:15:40 -03 2017

On 31-07-2017 14:49, Fabio Ribeiro wrote:
> No que diz o serviço DNS, na wikipédia[1], ou seja, não, só QUIC e TCP.
> Caso o DNS utilizasse um protocolo semelhante ao QUIC/uTP, poderia
> pensar no caso.

Não apenas QUIC ou TCP, mas qualquer protocolo de transporte que funcione de
forma semelhante, como o uTP que citaste.

Quanto ao DNS, este é um protocolo da camada de aplicação, portanto não pode se
beneficiar diretamente do BBR ou outro controle qualquer, uma vez que isso é
responsabilidade do protocolo da camada de transporte. Inclusive, o DNS pode
fazer uso tanto de UDP quanto de TCP como transporte.

Abraço!
Douglas.

> Em 31-07-2017 14:38, Roberto Lima escreveu:
>> 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?
>>
>> Abs.
>>
>> 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