Largura de banda de gargalo e Tempo de Propagação de ida e volta (BBR) é um algoritmo de controlo de congestionamento do TCP que ganhou atenção significativa no mercado devido à sua capacidade de fornecer maior rendimento, conforme relatado por muitos fornecedores de conteúdo. Neste post, avaliamos a BBR (versão 1) no contexto das cargas de trabalho da Verizon Media, agora da Edgio, de rede de distribuição de conteúdo (CDN), que fornece volumes significativos (múltiplos Tbps) de atualizações de software e streaming de vídeo, e quantificamos os benefícios e o impactos no tráfego. Esperamos que essa avaliação em uma grande CDN ajude outros fornecedores de conteúdo a escolher o protocolo de controle de congestionamento certo para o seu tráfego.
Fundo
Muitos fornecedores de conteúdo e investigadores académicos descobriram que o BBR proporciona maior rendimento do que outros protocolos como o tcp-cubic. Ao contrário dos algoritmos de controlo de congestionamento baseados em perdas, como o ubíquo TCP-Cubic, o BBR tem um paradigma de operação diferente: Atualiza continuamente a quantidade de dados que podem estar em voo com base no RTT mínimo que a sessão viu até agora para evitar o efeito de bufferbloat. Para mais informações sobre o funcionamento do BBR, dê uma olhada na publicação original do Google aqui.
Medições e Análise
Para compreender o potencial da BBR na nossa CDN, avaliamos a BBR em vários estágios, medindo o impactos nos fluxos de TCP a partir de alguns pontos de presença (POPs). Os POPs representam uma concentração de servidores em cache localizados em grandes áreas metropolitanas. Inicialmente, realizámos um teste BBR de pequena escala num Pop e também realizámos um teste de pop completo, com todos os fluxos para clientes a executar o BBR. Para identificar os benefícios que os clientes experimentariam, medimos a taxa de transferência dos logs do nosso servidor web de proxy interno durante o teste, bem como a análise do nível do soquete.
Métricas para avaliar
A nossa CDN de vários inquilinos vê uma grande variedade de tráfego de clientes. Muitos clientes têm muitos objetos pequenos, enquanto outros têm objetos multi-gigabytes muito maiores. Portanto, é crucial identificar métricas de sucesso que captem ganhos reais de desempenho em diferentes padrões de tráfego. Em particular, para esta avaliação, identificamos os tempos de throughput e de conclusão do fluxo de TCP como parâmetros de sucesso. Na Figura 1, mostramos um mapa térmico de tamanhos de objetos comuns solicitados à CDN vs. Tempo necessário para os servir. O gradiente de cores indica o número de pedidos em cada categoria. Estes são números representativos de um pequeno conjunto de servidores, o suficiente para capturar apenas o comportamento comum.
Figura 1. Mapa térmico mostrando tamanhos de objetos comuns.
O mapa térmico dá-nos uma compreensão de diferentes padrões de pedidos. Em geral, ganhar maior rendimento é o melhor indicador de ganho de desempenho. No entanto, a taxa de transferência como medida pode ser muito ruidosa, especialmente para casos em que o tamanho do objeto é pequeno (menos de alguns MBs). Portanto, com base numa avaliação separada de quais tamanhos fornecem a avaliação mais confiável da taxa de transferência, usamos apenas o tamanho de objeto maior que 3MB para avaliações de taxa de transferência. Para tamanhos de objetos inferiores a 3MB, o acompanhamento dos tempos de conclusão do fluxo é uma métrica melhor.
Como o primeiro passo na nossa avaliação, ativámos o BBR em alguns servidores num instante em Los Angeles e monitorizámos a taxa de transferência e os tempos de conclusão do fluxo para todos os fluxos de TCP. Os resultados a seguir examinam alguns estudos de caso específicos do provedor de serviços de Internet.
Um grande fornecedor sem fios
A figura 2 mostra a diferença quando a BBR foi ligada.
Figura 2. Impacto da taxa de transferência para os clientes de um grande fornecedor de serviços sem fios quando a BBR foi ligada (teste) em comparação com fluxos cúbicos (controlo). Esquerda: Medições de rendimento durante dois dias. A linha azul vertical indica quando a BBR foi ativada. Aqui vemos uma melhoria global de cerca de 6-8% com a BBR. Direita: Uma CDF do rendimento do 5º percentil. Os fluxos de BBR mostram uma melhoria significativa.
Para este fornecedor sem fios, assim que ativámos a BBR, em média, vimos uma melhoria de 6-8% na taxa de transferência. Também vimos tempos de conclusão de fluxo de TCP mais baixos em geral. Esta descoberta está de acordo com outros relatórios do Spotify, Dropbox e YouTube, onde um ganho claro na taxa de transferência é visto em redes sem fio onde a perda de pacotes é comum, mas isso não é necessariamente um indicador de congestionamento.
Um grande fornecedor de cabo
Em seguida, examinámos o desempenho de um grande fornecedor de linha fixa. Aqui também vimos melhorias na taxa de transferência (para objetos grandes) e no tempo de conclusão do fluxo (mostrado na figura 3.) usando o BBR.
Figura 3. O tempo médio necessário para completar um fluxo para um grande provedor de linha fixa. Os fluxos BBR (teste) mostram menos trepidação e levaram menos tempo para concluir a transferência de dados. Os benefícios são mais impactantes para objetos maiores. No entanto, vemos um jitter semelhante para ficheiros grandes, tanto para cúbico como para BBR.
Os ganhos relatados destes testes mostram resultados muito promissores para o tráfego do lado do cliente.
Como esses ganhos estão em uma visão agregada, decidimos aprofundar um pouco mais para verificar se todos os fluxos de TCP no Pop viram o benefício de usar o BBR; ou se alguns fluxos de TCP sofreram, e quais?
Na borda da CDN, realizamos quatro tipos diferentes de sessões de TCP:
- Pop-to-Client (como mostrado acima)
- Pop-to-pop (entre centros de dados)
- Comunicação intra-pop (entre as caches do mesmo pop)
- Pop-to-origin (pop para o centro de dados de origem do cliente)
Para este estudo, consideramos os fluxos Pop-To-Client, Pop-Pop e Intra-Pop, uma vez que a borda à origem não é tão grande volume quanto os outros três.
Tráfego pop-to-pop e intra-pop
Também é importante avaliar o impactos nesses fluxos de TCP, já que em muitos casos esses fluxos são bloqueadores para a entrega do cliente, como para o conteúdo dinâmico.
Para a taxa de transferência de tráfego pop-to-pop e intra-pop, vimos uma grande regressão no desempenho. A figura 4 mostra o impactos no tráfego intra-pop e pop-to-pop durante o mesmo período de tempo:
Figura 4. Impacto da taxa de transferência para tráfego intra-pop e pop-to-pop quando a BBR foi ligada (teste) em comparação com fluxos cúbicos (controlo). Medições de rendimento durante dois dias. A linha azul vertical indica quando a BBR foi ativada. A taxa de transferência diminuiu cerca de metade com a BBR.
Diferenças tão claras de desempenho entre fluxos para utilizadores finais e entre centros de dados não foram reportadas em descobertas anteriores. Precisamos avaliar por que esses fluxos de TCP em particular sofreram; se isso é um artefato de hardware ou configurações em nossa CDN; e se sim, quais afinações teriam que ser alteradas.
A partir de mais investigações usando logs de acesso ao servidor web e avaliações de dados de socket do lado do servidor, verificou-se que, na presença de fluxos de RTT altos e baixos, os fluxos de TCP que têm RTTs muito baixos sofreram com o uso de BBR. Avaliamos ainda os casos em que foram transferidos menos de 0,5KB de dados e descobrimos que, na maioria dos casos, a BBR teve um desempenho semelhante ao cúbico.
Com base nestes resultados, concluímos que, para os nossos padrões de tráfego, é melhor usar o Cubic para comunicações intra-pop e pop-to-pop onde RTTs e perda são baixos. Para o tráfego do lado do cliente, vale a pena usar o BBR.
Teste Pop completo
Para avaliar o benefício de desempenho do BBR em larga escala, fizemos um teste pop completo em um Pop no Rio de Janeiro para todo o tráfego voltado para o cliente da nossa rede nesse Pop. Este Pop fez um interessante estudo de caso, uma vez que as restrições de localização e de peering na região resultam em RTTs medianas mais elevadas experimentadas pelos clientes do que noutras regiões.
Figura 5. Melhoria da taxa de transferência usando BBR para o cliente COMO que mostra altas retransmissões (ASN1).
Implantamos a mudança no algoritmo de controle de congestionamento e monitoramos o desempenho. Mostra-se uma CDF de rendimento observada usando BBR vs. Cúbico para as duas maiores ases (Sistemas Autônomos) no Rio. Como visto na Figura 5, um COMO, no geral, viu o benefício da BBR enquanto outro não.
Para investigar o raciocínio por trás disso, procurámos outras métricas de TCP recolhidas durante o teste utilizando o utilitário ss. Uma distinção clara é observada na taxa de retransmissão entre estes dois ases. Mesmo para os Ases com RTTs mais elevados, o BBR tem um bom desempenho apenas para casos que têm um elevado número de retransmissões, ou seja, para ases com menos perda cúbica não tem razão para recuar e tem um melhor desempenho do que o BBR. É, no entanto, importante notar que muitos dos parâmetros do tcp cúbico foram cuidadosamente sintonizados na nossa CDN.
Em seguida, investigamos se todas as conexões do ASN1 mostradas na Figura 5, mostraram uma melhoria na taxa de transferência. A figura 6 é um gráfico de tempo gasto (menor implica melhor rendimento) por conexões BBR e cúbicas para diferentes tamanhos de objetos. Aqui vemos que a BBR só começou a mostrar benefícios notáveis para objetos maiores, na ordem das MBs. Nós vimos uma instância anômala usando BBR, mas não conseguimos atribuí-la a qualquer problema relacionado ao protocolo de controle de congestionamento.
Figura 6. Para ases que mostram melhorias, o benefício da BBR é visto para fluxos de longa duração com arquivos grandes.
Porque é que isto acontece?
Há duas dimensões para estes resultados – cúbico vs. BBR e BBR vs. BBR.
Cúbico vs. BBR
O BBR é altamente reativo aos tamanhos de buffer e RTT quando estima a largura de banda do gargalo. No caso de buffers grandes, onde os middleboxes podem construir uma fila, o RTT estimado do BBR aumenta. Como não há perda de pacotes, o Cubic não recua nesses casos, ou seja, o tráfego pop-to-pop, e portanto o Cubic atinge um rendimento mais alto. No caso de pequenos buffers, como clientes sem fios, o buffer enche-se rapidamente e resulta em uma perda – assim, fluxos cúbicos de volta, e os fluxos BBR têm um melhor desempenho.
BBR vs. BBR
Neste cenário, nenhum fluxo recua quando há uma perda. No entanto, quando dois fluxos com RTTs diferentes competem por uma parte da largura de banda, o fluxo que tem um RTT maior também tem um RTT mínimo maior e, portanto, um produto de atraso de largura de banda maior. Assim, esse fluxo aumenta os seus dados em voo a uma taxa muito mais rápida do que o fluxo que tem um RTT mais baixo. Isso leva à realocação da largura de banda para os fluxos em ordem descendente de RTTs e fluxos com RTTs mais altos preenchem buffers mais rapidamente do que fluxos com RTTs pequenos.
Reproduzir resultados num ambiente de laboratório
Para desenvolver uma maior compreensão das interações entre fluxos, criámos um ambiente de teste em máquinas virtuais que captam o comportamento que vimos na produção. Identificámos formas de simular diferentes classes de tráfego num servidor de borda da seguinte forma:
O atraso no tráfego do cliente foi definido para cerca de 50 ms com perdas que variam de 0,001 a 0,1 e largura de banda de gargalo de 50 Mbps. Da mesma forma, para pop-to-pop apenas a perda e atraso foram definidos em cerca de 15 ms e 0,0001 a 0,01. Para o tráfego intra-pop, deixamos que as máquinas virtuais maximorem a capacidade disponível. Finalmente, foram realizadas simulações usando vários tamanhos de objetos para capturar a natureza multi-tenant do nosso tráfego. Executamos todos os três padrões de tráfego em paralelo com uma chegada exponencial de fluxos para capturar uma distribuição de chegada de fluxo no estilo poisson. A figura 7 mostra a configuração do leito de teste.
O objetivo deste teste era reproduzir os problemas que vemos no teste de produção, especificamente a queda na taxa de transferência para pequenos fluxos de RTT para tráfego intra-pop e pop-to-pop.
Figura 7. Configuração de laboratório usando os utilitários KVM, iperf, Netem e tc.
Usando esta configuração, fizemos a simulação centenas de vezes com tráfego de fundo simulado, tanto cúbico como BBR, e medimos o tempo necessário para completar os fluxos. O objetivo do tráfego de fundo é simular um ambiente semelhante à produção. Muitos estudos existentes concentraram-se em gerir alguns fluxos de cúbico e BBR e avaliar os seus comportamentos. Embora nesses casos seja útil entender o comportamento por fluxo, ele representa mal as complexidades de uma CDN de grande volume. Usamos o tempo de conclusão do fluxo do lado do cliente como um indicador confiável, uma vez que para arquivos pequenos a taxa de transferência pode ser ruidosa.
Figura 8. Time take por iperf Flows. Esquerda: O cliente flui. Direita: Fluxos pop-to-pop. Tamanho do objeto: 3MB. O BBR teve melhor desempenho do que o cúbico para fluxos simulados de clientes.
Vimos o padrão reaparecendo também no nosso banco de testes. Na Figura 8, mostramos um CDF de tempo gasto pelos fluxos BBR e Cubic iperf em dois cenários: Tráfego de clientes e tráfego pop-to-pop para arquivos de 3MB (tamanho médio). Os fluxos BBR não conseguem alcançar cúbicos numa configuração de banda larga de baixa perda. O tráfego de clientes (largura de banda baixa) melhorou, ou seja, o tempo gasto pelos fluxos BBR foi menor. No entanto, a melhoria para ficheiros pequenos é marginal. Reproduzir estes comportamentos no ambiente de teste dá-nos a confiança de que eles são o resultado da interação entre diferentes tipos de fluxo. Como resultado, qualquer implantação do BBR na CDN deve estar ciente do impactos mais amplo que pode ter em uma mistura de tipos de fluxo.
Conclusão
A partir da nossa avaliação, observamos que os fluxos de RBR não têm um bom desempenho em todos os cenários. Especificamente, o tráfego dentro de um centro de dados/ponto de presença (pop) e o tráfego entre centros de dados (pop-to-pop) sofreu ao usar o BBR. Em alguns casos extremos, a taxa de transferência é reduzida para metade. No entanto, vimos uma melhoria de 6-8% na taxa de transferência de tráfego pop-to-cliente.
Neste post, descrevemos a avaliação do BBR (versão 1) no contexto da nossa CDN. Começámos com um pequeno teste de alguns servidores num único pop e avaliamos diferentes variáveis que nos interessam como um grande fornecedor de conteúdos. Em grande escala, teste de pop completo, notámos que a BBR ajudaria a maioria nos casos para ases onde as retransmissões são altas e sugere que vale a pena usar BBR para arquivos grandes.
Para onde vamos daqui?
Se ativarmos a BBR ao nível do sistema (todos os fluxos), corremos o risco de o tráfego intra-pop e pop-to-pop sofrer diminuições na taxa de transferência.
No entanto, a BBR tem mostrado potencial e está a ter um bom desempenho para o tráfego do lado do cliente. Isso nos motiva a habilitar seletivamente o BBR para clientes, potencialmente começando com provedores de rede sem fio. Além disso, estes caminhos têm buffers rasos e perda sem fios, uma situação ideal para a BBR ter um melhor desempenho do que outros fluxos cúbicos.
Esperamos que este esboço traga alguma clareza sobre o uso do BBR em grandes fornecedores de conteúdo e suas implicações em diferentes tipos de tráfego que podem compartilhar gargalos. A versão alfa do BBRv2 está agora disponível, o que deve abordar alguns destes problemas. Planeamos continuar a avaliar versões mais recentes do BBR e usar um controlador de transporte inteligente que escolha o controlo de congestionamento certo para o tipo certo de fluxo. Vamos partilhar mais detalhes sobre isto no futuro.
Graças à contribuição de várias equipas de toda a organização que tornaram esta análise possível!
