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

[Vicente Luca]

Uma das aplicações desse novo algoritmo é melhorar a performance de gRPC — ou qualquer framework que use HTTP/2 e connection multiplex — em caminhos com eventual perda de pacote.  

Uma das vantagens de gRPC + HTTP/2 é a multiplexação de vários requests em apenas 1 stream TCP, o que salva bastante tempo em não ter que fazer TCP handshake + SSL handshake, e também recursos, fora outras vantagens mais. Porém uma grande desvantagem é quando se multiplexa sobre caminhos com perda de pacote, ainda que baixa ( tipo 1% — Internet),  devido aos controles de congestion do TCP serem bastante agressivos em diminuir a janela pela metade quando detectam uma perda.

Como a idéia é não se retroceder utilizando várias conexões TCP para minimizar o impacto do window resizing em caso de packet loss, a alternativa foi criar um algoritmo de congestion mais inteligente.  Outras frentes, como o protocolo QUIC (http over UDP), também tentam resolver esse e outros problemas, mas demanda uma mudança completa do client (chrome já suporta) e do server.   Já o TCP BBR pode ser ativado no lado do server e os clientes já terão benefícios, sem necessidade de alterarem o seu TCP stack ou browser. 

Os benefícios são reais, mas não se aplicam pra todos os casos.  Por outro lado, não detectei nenhum downfall ao ativar o algoritmo, então na dúvida melhor usar :) 

Abs,

—vicente

   




> On Jul 21, 2017, at 11:24 AM, Fábio Rodrigues Ribeiro <listas at farribeiro.com.br> wrote:
> 
> 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