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

[Roberto Lima]

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
>