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

Mon Aug 7 09:08:10 -03 2017

Bom dia, Fabio.

On 06-08-2017 10:52, Fabio Ribeiro wrote:
> batendo o olho aqui estou notando alguma coisa interessante nos seus
> argumentos. Você disse que *PODE* mas isso depende muito do mercado em
> aceitar outro transporte para tal? Então aí nem tem jeito, é continuar
> usando UDP.

Te referes ao DNS usar UDP ou TCP? Se sim, eu não tenho o devido conhecimento
pra afirmar quando é usado um ou outro, mas sei que ambos são usados e que não é
necessariamente uma escolha ou configuração e sim parte do protocolo.

Abraço!
Douglas.

> Em 31-07-2017 15:15, Douglas Caetano dos Santos escreveu:
>> 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