Home Artigos técnicos Avaliação BBR em uma grande CDN
Applications

About The Author

Outline

Largura de banda de gargalo e Tempo de Propagação de ida e volta (BBR) é um algoritmo de controle de congestionamento TCP que ganhou atenção significativa no mercado devido à sua capacidade de oferecer maior throughput, conforme relatado por muitos provedores de conteúdo. Neste post, avaliamos a BBR (versão 1) no contexto das cargas de trabalho da Verizon Media, agora da Edgio, Content Delivery Network (CDN), que fornece volumes significativos (vários Tbps) de atualizações de software e streaming de vídeo, e quantificamos os benefícios e impactos no tráfego. Esperamos que essa avaliação em uma grande CDN ajude outros provedores de conteúdo a escolher o protocolo de controle de congestionamento certo para seu tráfego.

Fundo

Muitos provedores de conteúdo e pesquisadores acadêmicos descobriram que o BBR oferece maior taxa de transferência do que outros protocolos como o TCP-Cubic. Ao contrário dos algoritmos de controle de congestionamento baseados em perdas, como o ubíquo TCP-Cubic, o BBR tem um paradigma de operação diferente: Ele 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 buferbloat. Para obter mais informações sobre o funcionamento do BBR, consulte a publicação original do Google aqui.

Medições e Análise

Para entender o potencial da BBR em nossa CDN, avaliamos a BBR em vários estágios, medindo o impactos nos fluxos 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, realizamos um teste de BBR em pequena escala em um pop e também realizamos um teste de pop completo, com todos os fluxos para clientes executando BBR. Para identificar os benefícios que os clientes experimentariam, medimos a taxa de transferência de nossos logs internos do servidor web proxy durante o teste, bem como a análise de nível de soquete.

Métricas a avaliar

Nosso 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-gigabyte muito maiores. Portanto, é crucial identificar métricas de sucesso que capturem ganhos reais de desempenho em diferentes padrões de tráfego. Em particular, para essa avaliação, identificamos os tempos de throughput e de conclusão do fluxo TCP como parâmetros de sucesso. Na Figura 1, mostramos um mapa de calor de tamanhos de objetos comuns solicitados a partir da CDN vs. Tempo necessário para servi-los. O gradiente de cor indica o número de solicitações 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 de calor mostrando tamanhos de objetos comuns.

O mapa de calor nos dá uma compreensão de diferentes padrões de solicitação. 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 em uma avaliação separada de quais tamanhos fornecem a avaliação mais confiável de throughput, usamos apenas o tamanho de objeto maior que 3MB para avaliações de throughput. Para tamanhos de objetos inferiores a 3MB, o acompanhamento dos tempos de conclusão do fluxo é uma métrica melhor.

Como o primeiro passo em nossa avaliação, ativamos o BBR em alguns servidores em um pop em Los Angeles e monitoramos o throughput e os tempos de conclusão de fluxo para todos os fluxos TCP. Os resultados a seguir examinam alguns estudos de caso específicos do provedor de serviços de Internet.

Um grande provedor sem fio

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 provedor sem fio quando o BBR foi ligado (teste) em comparação com fluxos cúbicos (controle). Esquerda: Medições de produtividade durante dois dias. A linha azul vertical indica quando a BBR foi ativada. Aqui vemos uma melhoria geral de cerca de 6-8% com a BBR. Direita: Um CDF do quinto percentil throughput. Os fluxos de BBR mostram uma melhoria significativa.

Para esse provedor de rede sem fio, assim que ativamos a BBR, em média, vimos uma melhoria de 6-8% no throughput. Também vimos tempos de conclusão de fluxo TCP mais baixos em geral. Essa 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 provedor de linha fixa

Em seguida, examinamos o desempenho de um grande provedor de telefonia fixa. Aqui também vimos a taxa de transferência (para objetos grandes) e o tempo de conclusão do fluxo (mostrado na Figura 3). Melhorias usando BBR.

Figura 3. O tempo médio necessário para concluir um fluxo para um grande provedor de linha fixa. Os fluxos BBR (teste) mostram menos jitter e levaram menos tempo para concluir a transferência de dados. Os benefícios são mais impactantes para objetos maiores. Nós, no entanto, vemos jitter semelhante para grandes tamanhos de arquivo para ambos cúbico e BBR.

Os ganhos relatados a partir desses testes mostram resultados muito promissores para o tráfego do lado do cliente.

Como esses ganhos estão em uma visão agregada, decidimos nos aprofundar um pouco para verificar se todos os fluxos TCP no pop viram o benefício de usar BBR; ou se alguns fluxos TCP sofreram, e quais?

Na borda da CDN, realizamos quatro tipos diferentes de sessões TCP:

  • Pop-to-Client (como mostrado acima)
  • Pop-to-pop (entre datacenters)
  • Comunicação intra-pop (entre as caches do mesmo pop)
  • Pop-to-Origin (pop para o data center 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 alto quanto os outros três.

Tráfego pop-to-pop e intra-pop

É importante avaliar também o impactos nesses fluxos TCP, já que em muitos casos esses fluxos são bloqueadores para a entrega do cliente, como para 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 (controle). Medições de rendimento durante dois dias. A linha azul vertical indica quando a BBR foi ativada. A taxa de transferência diminuiu cerca da metade com a BBR.

Tais diferenças claras de desempenho entre fluxos para usuários finais e entre datacenters não foram relatadas em descobertas anteriores. Precisamos avaliar por que esses fluxos TCP em particular sofreram; se este é um artefato de hardware ou configurações em nossa CDN; e, em caso afirmativo, 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 soquete 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. Foram avaliados casos em que menos de 0,5KB de dados foram transferidos e constatamos que, na maioria dos casos, a BBR teve desempenho semelhante ao cúbico.

Com base nesses resultados, concluímos que para nossos padrões de tráfego, é melhor usar 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 de pop completo

Para avaliar o benefício de desempenho do BBR em grande escala, realizamos um teste pop completo em um pop no Rio de Janeiro para todo o tráfego voltado para o cliente de nossa rede nesse pop. Este pop fez um interessante estudo de caso, uma vez que as restrições de localização e peering na região resultam em RTTs medianas mais elevadas experimentadas pelos clientes do que em outras regiões.

Figura 5. Melhoria da taxa de transferência usando BBR para o cliente COMO que mostra retransmissões altas (ASN1).

Implantamos a mudança no algoritmo de controle de congestionamento e monitoramos o desempenho. Uma CDF de rendimento observada usando BBR vs. Cúbico para os dois maiores ases (Sistemas Autônomos) no Rio é mostrada. 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 dele, procuramos outras métricas TCP coletadas durante o teste usando o utilitário ss. Uma distinção clara é vista na taxa de retransmissão entre estes dois ases. Mesmo para os ases com RTTs mais elevados, o BBR funciona bem 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 desempenho melhor do que o BBR. É, no entanto, importante notar que muitos dos parâmetros do TCP Cubic foram cuidadosamente ajustados em nossa CDN.

Em seguida, investigamos se todas as conexões do ASN1 mostradas na Figura 5 apresentaram melhora no rendimento. A Figura 6 é um gráfico de tempo tomado (menor implica melhor throughput) por BBR e conexões cúbicas para diferentes tamanhos de objeto. Aqui vemos que a BBR só começou a mostrar benefícios visí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 específico.

Figura 6. Para ases que mostram melhorias, o benefício do BBR é visto para fluxos de longa duração com arquivos grandes.

Por que isso acontece?

Existem duas dimensões para estes resultados – Cubic 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 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, em outras palavras, o tráfego estilo pop-to-pop, e portanto o Cubic alcança maior throughput. No caso de pequenos buffers, como clientes sem fio, o buffer preenche 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 mais alto. Assim, esse fluxo aumenta seus dados em voo a uma taxa muito mais rápida do que o fluxo que tem um RTT menor. Isso leva à realocação da largura de banda para os fluxos em ordem decrescente de RTTs e fluxos com RTTs mais altos preenchem buffers mais rapidamente do que os fluxos com RTTs pequenos.

Reproduzir resultados numa definição de laboratório

Para desenvolver uma maior compreensão das interações entre fluxos, criamos um ambiente de teste em máquinas virtuais que capturam o comportamento que vimos na produção. Identificamos maneiras de simular diferentes classes de tráfego em um servidor de borda da seguinte forma:

O atraso de 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 aproximadamente 15 ms e 0,0001 para 0,01. Para tráfego intra-pop, deixamos que as VMs maximorem a capacidade disponível. Finalmente, simulações foram executadas usando vários tamanhos de objeto 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 foi 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 do laboratório usando utilitários KVM, iperf, netem e tc.

Usando essa configuração, executamos a simulação centenas de vezes com tráfego de fundo simulado, tanto cúbico quanto BBR, e medimos o tempo necessário para completar os fluxos. O objetivo do tráfego em segundo plano é simular um ambiente semelhante à produção. Muitos estudos existentes focaram em executar alguns fluxos de cúbico e BBR e avaliar 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, já que para tamanhos de arquivo pequenos a taxa de transferência pode ser ruidosa.

Figura 8. Time take por iperf Flows. Esquerda: Fluxos do cliente. Direita: Fluxos pop-to-pop. Tamanho do objeto: 3MB. O BBR apresentou melhor desempenho do que o CUBIC para fluxos de clientes simulados.

Vimos o padrão reaparecendo em nosso testbed também. Na Figura 8, mostramos um CDF de tempo tomado pelos fluxos BBR e Cubic iperf em dois cenários: Tráfego de cliente e tráfego pop-to-pop para arquivos de 3MB (tamanho médio). Os fluxos BBR não conseguem alcançar até cúbico em uma configuração de alta largura de banda de baixa perda. O tráfego do cliente (baixa largura de banda) viu uma melhoria, ou seja, o tempo gasto pelos fluxos BBR foi menor. No entanto, a melhoria para arquivos pequenos é marginal. Reproduzir esses comportamentos no ambiente de teste nos dá 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 de nossa avaliação, observamos que os fluxos de BBR não apresentam bom desempenho em todos os cenários. Especificamente, o tráfego dentro de um datacenter/ponto de presença (pop) e o tráfego entre datacenters (pop-to-pop) sofreu ao usar o BBR. Em alguns casos extremos, a taxa de transferência é reduzida pela metade. No entanto, vimos uma melhoria de 6-8% no throughput de tráfego pop-to-Client.

Neste post, delineamos a avaliação do BBR (versão 1) no contexto da nossa CDN. Começamos com um pequeno teste de alguns servidores em um único pop e avaliamos diferentes variáveis que são de interesse para nós como um grande provedor de conteúdo. Em uma grande escala, teste pop completo, percebemos que o BBR ajudaria a maioria nos casos para ases onde retransmissões são altas e sugere que vale a pena usar o BBR para arquivos grandes.

Para onde vamos daqui?

Se ativarmos a BBR ao nível do sistema (todos os fluxos), arriscamos o tráfego intra-pop e pop-to-pop sofrer diminuições na taxa de transferência.

No entanto, o BBR tem mostrado potencial e está funcionando bem para o tráfego do lado do cliente. Isso nos motiva a habilitar seletivamente o BBR para clientes, potencialmente começando com provedores sem fio. Além disso, esses caminhos têm buffers rasos e perda sem fio, uma situação ideal para o BBR ter um desempenho melhor do que outros fluxos cúbicos.

Esperamos que este esboço traga alguma clareza sobre o uso da BBR em grandes provedores de conteúdo e suas implicações em diferentes tipos de tráfego que podem compartilhar gargalos. A versão alfa do BBRv2 já está disponível, o que deve abordar alguns desses problemas. Planejamos continuar avaliando versões mais recentes do BBR e usar um controlador de transporte inteligente que escolha o controle de congestionamento certo para o tipo certo de fluxo. Vamos compartilhar mais detalhes sobre isso no futuro.

Graças à contribuição de várias equipes de toda a organização que tornaram esta análise possível!