Home Blogs Medição do meio com relação de retransmissão
Applications

Medição do meio com relação de retransmissão

About The Author

Outline

Ao operar uma grande rede global, garantir uma boa conetividade e desempenho entre sistemas que se comunicam através da Internet pública é fundamental para garantir uma experiência positiva do usuário. Dada a natureza complexa e de melhor esforço da Internet, até mesmo os links mais bem provisionados nos provedores mais confiáveis às vezes têm problemas.

Há uma série de estratégias para monitorar esses links, incluindo medição ativa, que gera tráfego especificamente para medição e medição passiva, que monitora o tráfego existente. neste artigo, descrevemos uma abordagem passiva que faz uso do nosso sistema de amostragem de soquete xTCP para monitorar passivamente muitos desses links que nossa rede depende.

Para aproveitar ao máximo os dados do xTCP, desenvolvemos ainda mais uma abordagem para processar esses dados que aborda alguns dos desafios associados ao monitoramento da Internet. Em particular, introduzimos um conceito que chamamos de Ratio de retransmissão, que fornece uma medida relativa da gravidade das retransmissões observadas entre sites de rede de distribuição de conteúdo (CDN) . Demonstramos que a relação de retransmissão acima de certos níveis corresponde a degradações na taxa de transferência, impactando diretamente o desempenho percebido pelo usuário, tornando-a uma excelente base para a automação de rede que nos permite trabalhar em torno das degradações de desempenho da rede.

Fundo

Um fluxo de trabalho comum na CDN, envolve um ponto de presença (pop) que está chegando a outro para algum conteúdo, por exemplo, para buscar um pedaço de conteúdo para cache. Frequentemente, essas interações são feitas em resposta direta a uma solicitação do cliente, o que significa que a solicitação downstream pode estar aguardando a conclusão dessa transferência. Geralmente, os pedidos em si podem ser bastante pequenos, na ordem de alguns kilobytes. As respostas podem ser altamente variáveis em tamanho, de kilobytes a muitos megabytes.

Fig 1: O fluxo de solicitação envia solicitações pequenas (KBs de pedido) e recebe respostas potencialmente grandes (potencialmente megabytes).

Para monitorar a integridade das conexões entre pontos de presença, podemos usar nossa ferramenta de monitoramento de soquete, xTCP, para provar o estado atual de todos os soquetes abertos em nossos servidores de borda. Embora isso forneça visibilidade crítica em nossos soquetes voltados para o cliente, esses dados de soquete também nos dão uma visão dos dados entre os POPs.

No entanto, medir esses dados não é sem alguns desafios. Primeiro, o xTCP fornece uma amostra pontual de diferentes conexões. Isso significa que podemos pegar muitas conexões em muitos pontos diferentes da transmissão. Portanto, qualquer avaliação que fizermos terá que considerar a distribuição mais ampla de comportamentos, em vez de quaisquer valores únicos.

Em seguida, precisamos garantir que estamos monitorando a direção correta. Enquanto tanto o pop que gerou a solicitação (Pop A no diagrama acima) quanto o pop que recebeu a solicitação e deve responder a ela (pop B acima) têm informações de soquete, suas cargas de trabalho assimétricas significam que esperamos ver comportamento diferente: a maioria dos pacotes enviados pelo cliente serão pacotes de controle (a solicitação inicial, pacotes de confirmação subsequentes), enquanto a maioria dos pacotes enviados pelo servidor serão pacotes de dados, que são mais propensos a conter volumes significativos de dados.

Como resultado, se houver congestionamento ou outros problemas ao longo do caminho, os pacotes que transportam dados e, portanto, ocupam mais espaço na fila, são mais propensos a encontrar perda de pacotes e sofrer retransmissões, por exemplo, como resultado de quedas de fila em um roteador ocupado. Para demonstrar isso, consideramos a distribuição de taxas de retransmissão de pacotes (computadas como a proporção de pacotes retransmitidos totais divididos pelo número total de segmentos de dados enviados, menos retransmissões) vistas nos fluxos de solicitação e resposta entre um par de POPs por um período de 10 minutos.

Fig 2: O tráfego de resposta encontra mais retransmissões, provavelmente devido ao seu tamanho maior.

Aqui, vemos que os sockets de solicitação do cliente não experimentam quase nenhuma retransmissão durante este período de tempo. Por outro lado, as respostas mostram quase 85% dos soquetes com retransmissões não zero, no entanto, observamos que a taxa de retransmissão está bem abaixo de 1% para a grande maioria das conexões. Sem surpresa, observamos comportamento semelhante em quase todos os pares de pops com retransmissões não zero durante o período de teste. Por isso, concentramo-nos nos fluxos de resposta carregados de dados. Como estamos preocupados em atender as solicitações aos PoPs originais, nos referimos a esses fluxos como “inbound”.

Nosso desafio final vem de algumas complexidades gerais em torno de retransmissões, e a dificuldade de usá-las como um sinal para a degradação do desempenho. De fato, retransmissões podem ocorrer regularmente sem indicar um problema específico, pois elas simplesmente refletem o estado do remetente e o número de vezes que um pacote foi reenviado. Estes podem, em última análise, ser o resultado de outro comportamento complexo do protocolo além da perda (por exemplo, teste de perda de cauda). Somando-se à complexidade, observamos que muitos soquetes nunca observam retransmissões. Isso significa que resumos ingênuos (por exemplo, considerando a mediana) podem resultar em resumos muito conservadores da taxa de retransmissão, e resumos distorcidos (por exemplo, percentil 95 ou 99) podem capturar em grande parte comportamentos que não são prejudiciais à população em geral.

Relação de retransmissão

A fim de ajudar a simplificar os impactos desses desafios, consideramos uma métrica composta que chamamos de taxa de retransmissão. Inspirada na relação HD do Meta , que visa quantificar a fração de clientes que são capazes de transmitir vídeo HD, esta medida se esforça para descrever a fração de soquetes que estão experimentando um nível insalubre de retransmissões. Uma vez que retransmissões não zero são, por vezes, esperadas, definimos a relação de retransmissão da seguinte forma:

Criticamente, esse valor é particularmente fácil de calcular com dados disponibilizados via xTCP. Em nossa experiência operacional, descobrimos que os valores da relação de retransmissão são geralmente pequenos em links saudáveis, evitando os desafios quase sempre zero presentes nas medições de taxa de retransmissão bruta.

Também descobrimos que a medição é sensível, muitas vezes gerando alertas antes de outros sistemas de monitoramento de desempenho. Isso o torna especialmente valioso ao diagnosticar rapidamente degradações de rede, que muitas vezes começam com pequenos problemas que eventualmente se tornam em problemas maiores.

Validando a métrica

Para demonstrar que a relação de retransmissão está diretamente correlacionada com o desempenho da aplicação, demonstramos sua eficácia considerando duas medidas. Primeiro, mostramos que durante tempos de alta taxa de retransmissão, o aplicativo cliente (o solicitante) experimenta uma taxa de transferência menor do que durante tempos com baixa ou zero taxa de retransmissão. Em segundo lugar, mostramos que a alta taxa de retransmissão muitas vezes corresponde a degradações em outros sinais de rede, em particular, sondas ICMP entre POPs.

Para explorar os impactos no desempenho do aplicativo, retomamos medidas tomadas explicitamente da camada do aplicativo. Em particular, consideramos os rendimentos medidos no pop do cliente, uma vez que estes representam a taxa de entrega funcional alcançada no processo de envio de dados. Para entender o impactos dos eventos de retransmissão, realizamos o seguinte estudo sobre um par de POPs ao longo de uma semana, durante o qual ocorreu um problema significativo no provedor.

Primeiro, consideramos todos os períodos em que ocorreu um evento de retransmissão . Definimos um evento de retransmissão como qualquer período de tempo em que a relação de retransmissão entre um par de pops se encontra dentro de um determinado intervalo por pelo menos dez minutos consecutivos. Embora notemos que isso exclui eventos de curta duração, ele fornece uma visão sobre o comportamento de eventos mais longos. Para cada evento de retransmissão, coletamos os valores de throughput correspondentes durante o evento. Como controle, coletamos dados pelo mesmo período de tempo que o evento, mas três horas antes. Isso nos dá dois conjuntos de medições de taxa de transferência: Os eventos de retransmissão “durante” e “normal”, realizados durante períodos sem retransmissão. Em seguida, normalizamos as medições “durante” pela taxa de transferência média alcançada entre os POPs durante o tempo normal. Para os nossos limiares, consideramos quatro intervalos: Superior a 0, mas inferior a 25%, superior a 25, mas inferior a 50%, superior a 50, mas inferior a 75% e, finalmente, superior a 75%.

Fig. 3: A taxa de transferência relativa em relação aos períodos de não retransmissão, observados durante cada evento de retransmissão.

A figura acima mostra a distribuição dos rendimentos relativos observados durante o período de medição. Primeiro, vemos que, mesmo no intervalo mais baixo, 60% das transações alcançaram um rendimento inferior ao da mediana. À medida que consideramos maiores taxas de retransmissão, a taxa de transferência continua a cair, com maior taxa de retransmissão correspondente a menor taxa de transferência, e o pior caso resulta em uma diminuição mediana relativa de mais de uma ordem de magnitude. Estas medições deixam claro que a relação de retransmissão capta com sucesso o fraco desempenho dos fluxos afetados.

Em seguida, voltamos para como esses eventos se correlacionam com nossas medidas ICMP ativas entre POPs. Aqui, consideramos o comportamento de alguns de nossos monitoramentos ativos, que realizam testes regulares de ICMP entre POPs, para medir qualquer perda ou alteração nos padrões de atraso. Para essa análise, usamos novamente os eventos extraídos de nossa comparação de throughput. Desta vez, porém, observamos a perda medida do ICMP por períodos de tempo de cada limiar, onde o normal neste caso não observou perda. Observamos que as limitações em nossa sondagem de ICMP resultam em uma granularidade de perda de 2% para essas medidas específicas.

Fig 4: A perda observada de ICMP durante cada período de tempo. A maior relação de retransmissão corresponde a uma maior perda.

Aqui, vemos que os limiares mais baixos raramente mostram qualquer perda, com 90% das medições não detetando qualquer. Em contraste, no limiar de .75, 80% das medidas observaram perda, e observaram perda mediana relativamente alta de 4%. Criticamente, observamos níveis em que a taxa de retransmissão correspondeu a impactos significativos de throughput (por exemplo, 0,25) resultam em pouca perda nas métricas do ICMP. Esses achados reiteram a importância de medir o desempenho do caminho para além das simples sondas ICMP, e destaca a capacidade da relação de retransmissão de oferecer uma visão diferenciada do desempenho dos fluxos reais na Internet.

Conclusões e além

Neste post, demonstramos o valor da relação de retransmissão, uma métrica de resumo conveniente que pode ser prontamente computada com dados disponíveis a partir dos dados do soquete xTCP também. Mostramos ainda que ele fornece uma visão clara dos casos em que o desempenho do aplicativo é impactado e as intervenções de rede são necessárias.

A relação de retransmissão tornou-se uma parte fundamental do nosso processo de monitoramento, fornecendo uma visão clara do desempenho do sistema, sem a necessidade de processar logs de aplicativos maiores e mais pesados ou depender de sondas ICMP que não conseguem capturar alguns impactos.

Nosso trabalho contínuo é explorar como a métrica pode ser feita o mais sensível possível para fornecer alerta antecipado às degradações, ao mesmo tempo em que fornece uma entrada adequada para sistemas de automação mais complexos.

Agradecimentos especiais às equipes de Engenharia de Arquitetura e Confiabilidade de Rede no seu apoio a este trabalho!

Para pesquisadores interessados em aprender mais sobre o Edgio Labs & Advanced Projects, ou interessados em explorar trabalhos colaborativos em qualquer um dos tópicos descritos acima, entre em contato com a equipe em research@edg.io.