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

Mon Aug 7 12:04:07 -03 2017

Quando a mensagem for maior que 512 bytes, o TCP será utilizado.

Geralmente em transferências de zonas entre servidores DNS ou em consultas
de nomes muito grandes.

Abraços,
________________________________
*Alan Tamer Vasques*
alantamer at gmail.com

Em 7 de agosto de 2017 09:08, Douglas Caetano dos Santos <
douglascs at taghos.com.br> escreveu:

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