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

[Fabio Ribeiro]

Olá, bom dia

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.

Abraços.

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