O algoritmo de controlo de congestionamento (CCA) do Transmission Control Protocol (Protocolo de controlo de congestionamento) regula a quantidade de dados que devem ser enviados entre clientes e servidores para maximizar a utilização da largura de banda disponível e evitar o congestionamento. Desde a sua criação, outros CCAs têm sido desenvolvidos desde a sua criação, como largura de banda de gargalo, Tempo de Propagação de ida e volta (TCP BBR) e CUBIC. Embora o TCP BBR e O CUB tenham como objetivo evitar congestionamentos, compreender a sua eficácia tem sido uma missão contínua para as nossas equipas de engenharia e investigação.
O BBR do TCP visa alcançar uma taxa de transferência mais elevada usando o atraso de pacotes como um indicador em vez da perda de pacotes. No entanto, nossa pesquisa anterior relatou que o BBR tem um desempenho ruim em todos os casos. Especificamente, a nossa avaliação concluiu que havia pouco ou nenhum benefício na taxa de transferência para arquivos pequenos (<100KB). Além disso, observamos que o desempenho da BBR para fluxos com baixo tempo de ida e volta (TTR) e baixa retransmissão foi pior que A CÚBICA. Finalmente, os benefícios da BBR só foram vistos para o tráfego voltado para o cliente, enquanto as conexões de back-office (baixa RTT e retransmissões desprezíveis) tiveram um melhor desempenho com O CUBIC.
A Edgecast, agora Edgio, é uma CDN global de vários inquilinos que fornece tráfego na web para muitos grandes clientes de streaming de vídeo (VOD e ao vivo). Dado que as afinações de controlo de congestionamento usando o BBR para um cliente podem afetar negativamente o desempenho de outro cliente, e uma habilitação geral pode resultar na degradação do desempenho em alguns cenários, implementámos um mecanismo para detetar casos em que o BBR proporciona um desempenho melhorado e pode activá-lo dinamicamente para todos os clientes de CDN. O resultado é uma nova funcionalidade de ajuste dinâmico do controlo de congestionamento que disponibilizamos a todos os nossos clientes.
Insights sobre a metodologia
Talvez a entrada mais importante para um sistema tão dinâmico seja os dados que o alimenta. O nosso mecanismo de ajuste dinâmico de controlo de congestionamento está no topo da nossa coleção de dados de tomadas em grande escala, que exporta dados de desempenho de tomadas TCP (xTCP) de todos os caches de borda. Especificamente, ele extrai informações da estrutura tcp_info do Kernel do Linux via NetLink e transmite-as via Kafka para um cluster do ClickHouse. Ter estes dados de desempenho de socket em escala permite-nos monitorizar o desempenho das ligações aos nossos servidores de cache com granularidade muito elevada. O xTCP provou ser uma ferramenta poderosa para muitas otimizações de CDN. Por exemplo, recentemente viramos a janela de congestionamento inicial do IPv6 e monitoramos o desempenho dos ganhos usando o xTCP.
O xTCP é semelhante ao trabalho feito pela ferramenta de informação de tcp do laboratório de medição do Google (M-Lab) com diferenças significativas provenientes das otimizações necessárias para gerir o grande número de tomadas vistas pelos nossos caches de borda (em comparação com os servidores M-Lab) e a capacidade de exportar os dados em formato de protobuf. Fiquem atentos, planeamos abrir o xtcp em breve.
Na figura a seguir, mostramos a visão geral do nosso sistema. Os dados xTCP são recolhidos em escala a partir de todos os nossos caches de borda transmitidos para o Kafka. Os dados xTCP são então recolhidos num cluster do ClickHouse, que alimenta a nossa análise de dados de rede, incluindo o controlador BBR, que deteta os prefixos de baixo desempenho em cada pop de borda.
Figura 1. Visão geral da coleta de dados usando um push de configuração xTCP e BBR.
Enquanto queremos manter a natureza dinâmica do nosso fluxo de trabalho, também precisamos de selecionar prefixos consistentemente com baixo desempenho em cada ponto de presença (pop) para evitar o flip-flops entre CÚBICO e BBR durante curtos períodos de tempo. E, como mencionado anteriormente, ativamos seletivamente o BBR para pedidos em que o tamanho do ficheiro é superior a 100 KB. Um FLUXO CÚBICO afinado tem um melhor desempenho para pequenos ficheiros.
O controlador BBR usa duas métricas para avaliar a integridade de cada prefixo de cliente observado:
- Ciclo de trabalho: Quanto tempo foi um prefixo (/24 ou /56) no grupo de desempenho do percentil 20 inferior?
- Taxa de aba: Com que frequência o prefixo aparece e desaparece do grupo de desempenho do percentil 20 inferior, ou seja, mudança de estado?
O algoritmo deteta consistentemente prefixos de pior desempenho nas últimas horas. Esta deteção é executada a cada 5 minutos. Embora o número total de prefixos selecionados por pop de borda possa ser nas centenas, observamos que o desempenho do prefixo permanece relativamente consistente. Os mesmos prefixos são regularmente selecionados, e novas adições em cada rodada (como mostrado na figura a seguir do Chicago Pop) são muito poucas.
Figura 2. O número de novos prefixos selecionados por rodada de geração de configuração é baixo.
Se houver, novos prefixos são selecionados para habilitar o BBR, e uma configuração é gerada, passada através de uma etapa de validação e empurrada para os nossos caches de borda globalmente.
Ganhos de desempenho
Temos o prazer de informar que habilitar o BBR em todo o mundo tem mostrado melhorias consideráveis no desempenho. Uma métrica chave que rastreamos a partir dos dados do socket xtcp é a taxa de entrega relatada em tcp_info. Uma vez que ativamos dinamicamente a BBR para os prefixos com maior desempenho, esperamos que a nossa taxa de entrega do percentil mais baixo (pior caso) melhore.
A figura a seguir mostra a melhoria na taxa de entrega dos percentis 5 e 10 no nosso Pop de Los Angeles assim que a mudança BBR foi ativada.
Figura 3. Foram observadas melhorias nas taxas de entrega dos percentis 5 e 10 após a mudança da BBR.
Da mesma forma, na figura a seguir, mostramos uma melhoria considerável (cerca de 2 vezes) na taxa de entrega do percentil inferior para um grande ISP residencial nos EUA assim que ativamos dinamicamente a BBR em todos os nossos POPs norte-americanos.
Figura 4. Foram observadas melhorias para um grande ISP residencial depois de habilitar dinamicamente o BBR.
A taxa de entrega extraída do tcp-info fornece uma boa estimativa do desempenho visto pelo cliente. No entanto, o indicador de desempenho mais preciso é a taxa de transferência observada nos logs de acesso de HTTP para a conexão do cliente, ou seja, goodput.
Medimos o adeus de um servidor de cache de borda. Como mostrado na figura a seguir, a mudança resultou em um aumento de despedidas. No geral, o percentil 10 aumentou em 12%.
Figura 5. O percentil 10 aumentou em 12%.
Um agradecimento especial à equipa de desenvolvimento da BBR no Google pelo seu trabalho incrível no BBRv1 e pelo seu esforço contínuo no BBRv2. Estamos ansiosos pelo BBRv2 e continuaremos a empurrar mudanças relevantes para a nossa plataforma em breve. Parabéns a Sergio Ruiz, Joseph Korkames, Joe Lahoud, Juan Bran, Daniel Lockhart, Ben Lovett, Colin Rapor apoiar esta mudança durante o desenvolvimento, testes e implementação. A equipa de engenharia Edgio gostaria de agradecer especialmente a Dave Seddon por ter contribuído para o desenvolvimento da ferramenta xTCP que impulsionou grande parte da análise.
Com o ajuste dinâmico do controle de congestionamento, os clientes Edgio agora obtêm automaticamente melhorias de desempenho para seus clientes com baixo desempenho e melhoram seu desempenho de resultados, resultando em uma entrega mais rápida da web e uma redução nos buffers para streaming de vídeo .
