Resumo do Artigo Comparison of Public End-to-End Bandwidth Estimation Tools on High-Speed Links Janeiro de 2005

Transcrição

1 Resumo do Artigo Comparison of Public End-to-End Bandwidth Estimation Tools on High-Speed Links Alok Shriram1, Margaret Murray2, Young Hyun1, Nevil Brownlee1, Andre Broido1, Marina Fomenkov1, and kc claffy1 1 CAIDA, San Diego Supercomputer Center, University of California, San Diego {alok,youngh,nevil,broido,marina,kc}@caida.org 2 Texas Advanced Computing Center marg@tacc.utexas.edu Alok Shriram1, Margaret Murray2, Young Hyun1, Nevil Brownlee1, Andre Broido1, Marina Fomenkov1, and kc claffy1 1 CAIDA, San Diego Supercomputer Center, University of California, San Diego {alok,youngh,nevil,broido,marina,kc}@caida.org 2 Texas Advanced Computing Center marg@tacc.utexas.edu Janeiro de 2005

2 Introdução Os usuários de redes de alta velocidade necessitam de ferramentas de medição e metodologias para monitorar as condições da rede, para uma melhor utilização e otimização da rede. As características da rede relacionadas ao desempenho são, capacidade, largura de banda disponível, maior capacidade de transferência, e vazão alcançável do TCP, estas características são medidas em bits por segundos. O objetivo deste artigo é testar e comparar as ferramentas que afirmam medir largura de banda disponível fim a fim de um trajeto, esta métrica é determinada pelo link com a menor capacidade não utilizada. Medir a largura de banda disponível em links de alta velocidade tem se tornado um grande desafio para as ferramentas de medição. Vários fatores dificultam a precisão de medidas fim a fim, como, a precisão do relógio, interrupção de coalescência, dispositivos de camada 2, a combinação mal sucedida do MTU, mecanismos de QoS. Enquanto esta precisão for difícil, é importante que as ferramentas de estimação da largura de banda sejam rápidas e pouco intrusivas, evitando assim, resultados errados e atrasados, e que os testes de medição não interfiram nos recursos da rede do usuário que tenta medi-la e explorá-la. Metodologias Testadas As ferramentas selecionadas para o estudo foram: abing, pathchirp, pathload e Spruce. Para comparação o Iperf também foi incluída, esta ferramenta mede a vazão TCP alcançável. Laboratórios de estimação de largura de banda Os testes foram realizados no laboratório CalNGI Network Performance Reference Lab, que pode ser usado como centro de referência para testar ferramentas de estimação de largura de banda. A configuração utilizada foi, todos os hosts das extremidades foram conectados a switches capazes de manipular MTU jumbo (9000B). Havia três roteadores, cada um com dois domínios diferentes, e todos roteando os pacotes através de um único backbone. Uma link OC48 conectando um roteador Juniper M20 com um roteador Cisco GSR 12008, e link GigE conectando este Cisco a um roteador Foundry BigIron 10. Foram usados MTUs jumbo (9000 B) por toda a configuração de OC48/GigE a fim suportar o fluxo de tráfego com linha velocidade cheia. As ferramentas de estimação da largura de banda foram executadas em dois hosts finais, cada um equipado com processador Xeon com 1.8 gigahertz, com 512MB de memória, e uma placa NIC da Intel PRO/1000 GigE instalado em um 64b PCI-X barra-ônibus de 133 megahertz. O sistema operacional é a versão 4.8 do FreeBSD que é referência do CAIDA. O laboratório também inclui hosts dedicados que rodam CoralReef e NetraMet software de monitoração passiva. CoralReef analisa as características do fluxo e pacotes IATs

3 em tempo real e captura cabeçalho de dados para a análise subseqüente. O NeTraMet pode coletar o tamanho do pacote e as distribuições do tempo de chegada entre pacotes (interarrive time- IAT ) em tempo real, separando o tráfego da ferramenta do tráfego cruzado. Método de geração de tráfego cruzado Os algoritmos usados pelas ferramentas estimação da largura de banda supõem características de tráfego cruzado. Quando estas características não são aplicadas, as ferramentas não poderão executar corretamente. Neste estudo foram usadas duas séries de testes de ferramenta de laboratório usando dois métodos diferentes de geração de tráfego cruzado. Estes métodos são descritos abaixo: O tráfego cruzado sintético Spirent Communications SmartBits é um sistema de hardware para teste. Usa a aplicação Spirent SmartFlow que permite gerar tráfego controlado para testar laboratório de L2/L3 e de QoS. Usando SmartBits e SmartFlow nós podemos gerar o tráfego pseudo-random, contudo reproduz tráfego com níveis de carga e distribuições do tamanho de pacotes precisamente controlados. O tráfego sintético resultante emula cabeçalhos de protocolos realísticos. Entretanto, não copia o controle do congestionamento do TCP e não previne congestionamento. Reconstrução de uma parte do tráfego real. Para este método foi usada a ferramenta tcpreplay. Este método de geração de tráfego cruzado reproduz o IAT real (tempo entre pacotes) e a distribuições do tamanho dos pacotes, mas não previne congestionamento. Comparação da precisão das ferramentas Experimentos com tráfego cruzado sintetizado. Foi usado o dispositivo de SmartBits 6000B com a aplicação de SmartFlow para gerar cargas bidirecionais de tráfego cruzado variando de 10% a 90%. Todas as ferramentas de medição foram executadas uma a uma em um trajeto de 1Gb. O trajeto fim a fim inclui três roteadores diferentes com diferentes ajustes. Para verificar se a seqüência dos roteadores no trajeto afeta as medidas das ferramentas, foram executados testes com tráfego cruzado sintético em ambos os sentidos. Foram observadas somente as menores diferenças entre os sentidos. As variações estão dentro da escala de precisão das ferramentas e foi suspeitado que é devido aos tamanhos diferentes de buffer dos roteadores. As ferramentas abing e Spruce forneceram os resultados mais imprecisos. Os resultados com estas ferramentas nos links de alta velocidade advertem que as ferramentas que utilizam técnicas de pares de pacotes devem estar cientes de possíveis variações do atraso na rede estudada. Também, os frames 1500-byte e a definição do timestamp de microssegundo não são sensíveis o suficiente para examinar trajetos de alta velocidade.

4 As estimativas de largura de banda disponível pelo pathchirp são 10-20% mais elevado do que o valor real determinado pelos ajustes de SmartBits. Esta superestimação persiste mesmo quando não há nenhum tráfego cruzado. Em um trajeto vazio de 1Gb/s esta ferramenta fornece valores até 1100 Mb/s. Os resultados do pathload foram os mais precisos. A diferença entre suas leituras e a largura de banda disponível real foi menor que 10% na maioria dos casos. A última ferramenta testada, o Iperf, não estima largura de banda disponível, mas o throughput alcançável do TCP. Nós executamos o Iperf com o tamanho de buffer máximo de 227 KB e percebemos uma precisão de igual, ou melhor, que 15%. Note que ajustando o buffer para um tamanho menor significativamente reduz o throughput do Iperf. Esta observação parece contradizer o princípio básico que o tamanho do buffer mais adequado é o produto da largura de banda pelo atraso, que neste caso seria (109 b/s) x (10 4 s) = 12.5 KB. Experimentos de traços de playback. A segunda série de testes de laboratório usou traços previamente gravados do tráfego real. Para estas experiências foi extraído uma amostras de seis minutos de tráfego para usar como fonte do tcpreplay. Nos testes com playback de traços reais, abing e o spruce mostraram os mesmos problemas que interferiram seu desempenho nas experiências com tráfego cruzado sintético. As medidas do pathchirp tiveram um período de ativação próximo de 70s quando a ferramenta retornou somente um valor constante. Após a fase de ativação, os valores do pathchirp alternam dentro de 15-20% da largura de banda disponível real. A escala relatada pelo pathload subestima ligeiramente a largura de faixa disponível, ou seja menor que 16%. Iperf relata resultados surpreendentemente baixos quando executado de encontro ao tráfego tcpreplay. Dois fatores causam este valor subestimado: os pacotes perdidos requerem a retransmissão e um longo timeout de retransmissão de 1,2s (default). Na experiência mostrada, o host que executa o Iperf e o host executando o tcpreplay foram conectados em um trajeto fim a fim através de um switch. Foi verificado a MIB do switch para ver se há pacotes rejeitados e foi encontrada uma perda de pacotes de aproximadamente 1% quando a ferramenta e o tráfego cruzado se encontravam. Embora a perda pareça pequena, isto causa ao Iperf a divisão de sua janela de congestionamento e dispara um número significativo de retransmissões. O timeout de retransmissão default é que consome grande tempo execução do Iperf até 75%. Diminuir o timeout de retransmissão para 20ms ou conectar o host tcpreplay diretamente ao trajeto que contorne o switch, isto melhora consideravelmente o desempenho do Iperf. Note que era possível reproduzir o baixo desempenho do Iperf nas experiências com tráfego sintético de SmartBits, colocando um grande número de pacotes pequenos (64B) no trajeto. Estas experiências confirmam que no fim das contas o desempenho do TCP diante da perda de pacotes depende fortemente do temporizador de retransmissão do SO.

5 Comparação de características operacionais da ferramenta Os parâmetros considerados foram os que podem afetar a decisão de um usuário a respeito de que ferramenta se deve usar: tempo, intrusão, e overhead. Todas estas características foram medidas nas experiências com tráfego sintético de SmartBits onde foi possível estabilizar e controlar a carga. O tempo de medição da ferramenta foi definido para ser o tempo médio de medição em relação ao nível particular de carga. A topologia era composta de 4-hops de OC-48/GigE, o tempo de duração observadas de medição eram: 1,3s para abing, 11s Spruce, 5,5s para o pathchirp, e 10s para Iperf independente da carga. O tempo de medição do pathload geralmente aumentava quando a largura de banda disponível diminuía, e variou entre 7s e 22s. A intrusão das ferramentas foi definida pela relação da taxa média de tráfego da ferramenta com largura de banda disponível, e o overhead da ferramenta pela relação da taxa de tráfego da ferramenta com taxa de tráfego cruzado. pathchirp, abing, e spruce tiveram baixos overflow, praticamente não introduziram nenhum tráfego adicional na rede que foi medida. A intrusão do pathload ficou entre 3 e 7%. Seu overhead aumentou ligeiramente com a largura de banda disponível e alcançou 30% para a carga de 10%. Como esperado, o Iperf é a ferramenta a mais intrusiva (74-79%) e de custos de overhead. Já que tenta ocupar toda a largura de banda disponível, seu tráfego pode facilmente exceder o tráfego cruzado existente. Validação no mundo real As comparações de ferramentas da estimação da largura de banda foram criticadas pela sua falta de validation no mundo real. Muitos fatores impedem se não proíbem testar detalhadamente as ferramentas em redes de produção. Primeiramente, as condições da rede e os níveis de tráfego são variáveis e geralmente vão além do controle dos experimentadores. Esta incerteza impede a interpretação não ambigua de resultados experimentais e rende medidas não imreproduzíveis. Em segundo, o perigo dos testes perturbarem ou mesmo interromperem o curso normal de operação da rede faz com que operadores de rede se tornem relutantes em participar de qualquer experiência. Somente a cooperação próxima entre experimentadores e operadores pode superar ambos os obstáculos. Os testes de laboratórios forma com duas séries de experiências no mundo real. Em ambas as instalações, os trajetos foram medidos redes exclusivamente academicas, de pesquisas e do governo. Experiências na rede Abilene. As medidas realizadas da largura de banda disponível em um trajeto fim a fim de 6 hop de Sunnyvale a Atlanta na rede de Abilene. Ambas as máquinas da extremidade tiveram uma 1 conexão de Gb/s à rede e não originaram nenhum tráfego exceto de executar as ferramentas. O restante dos links no trajeto tem capacidade de 2,5Gb/s e 10Gb/s. O spruce não foi testado na rede de Abilene, já que esta ferramenta teve um baixo desempenho nos testes de laboratório. As ferramentas executadas foram pathload, pathchirp, abing, e Iperf durante 5 minutos cada uma.

6 As medições com pathload, pathchirp, e Iperf são razoavelmente precisas, enquanto as leituras abing flutuaram significativamente em uma escala inteira de 0 e 1000 Mb/s. A diferença entre medições do Iperf e valores derivados do SNMP refletem o propósito da ferramenta: Iperf gera grandes overheads maior de 70%, porque tenta intencionalmente encher o link apertado. As leituras conseqüentes dos contadores do SNMP indicam quantos bytes atravessaram uma interface de um roteador durante este intervalo do tempo. Relatam o número total de bytes sem distinguir o tráfego da ferramenta de tráfego cruzado. Se o overhead de uma ferramenta for elevado, então a largura de banda disponível derivada dos dados do SNMP durante a execução da ferramenta é baixa. Ao mesmo tempo, que as ferramentas tentam medir a largura de banda disponível ignorando seu próprio tráfego, uma ferramenta de alto overhead relatará uma largura de banda disponível maior do que SNMP. Conseqüentemente, o Iperf mostra um valor correto do throughput alcançável do TCP de ~950 Mb/s quando os contadores concorrentes do SNMP calculam o tráfego gerado do Iperf, produzindo menos de 200 Mb/s de largura de banda disponível. Uma diferença menor entre o pathload e os resultados do SNMP reflete o overhead do pathload (~10% nos testes de laboratório). Experiências nos trajetos de SDSC-ORNL. Na segunda série de experiências no mundo real, as ferramentas testadas foram, abing, pathchirp, pathload, e spruce nos hosts SDSC e um host no laboratório nacional do Oak Ridge National Lab. Estas experiências são de valor limitado já que não foram usados dados simultâneos do SNMP para a comparação dos resultados. Entretanto, as informações obtidas sobre as capacidades dos links ao longo dos trajetos permitiram ao menos distinguir resultados razoáveis dos impossíveis. Cada ferramenta foi executada usando pacotes de 1500 bytes ou 9000 bytes. abing, pathchirp, e pathload suportam grandes tamanhos de pacotes de testes como opção. O spruce usa um pacote de tamanho de 1500 bytes; no entanto o código foi modificado para que o tamanho do pacote fosse igual a 9000B. O comportamento da abing mudou quando as posições do transmissor e do receptor foram trocadas, em um sentido os pacotes de 9000B não retornaram os resultados e no sentido oposto, o abing com os pacotes de 9000B superestimavam a largura de banda disponível do trajeto OC12 e em trajetos GigE com pacotes 1500B a diferença é foi de aproximadamente 3 vezes. Isto pode ter ocorrido devido às condições diferentes da rede, já que os testes ocorreram em dias diferentes. O pathchirp produziu resultados em ambos os trajetos quando executado com pacotes de 1500B e 9000B no trajeto de GigE, mas falhou no trajeto OC12 com pacotes grandes. As variações entre as medições com o mesmo tamanho de pacote às vezes apresentam mais diferenças do que usar pacotes grandes e pequenos. Nos testes com os pacotes de 1500B, no pathload em ambos os trajetos, relataram resultados limitados pelo host que emite a taxa máximo. Com os pacotes de 9000B, esta ferramenta produziu estimativas da largura de banda disponível para

7 ambos os trajetos, mas publicou uma advertência para o trajeto OC12 "taxa atual de teste não é igual à taxa de teste desejada". O Spruce executou as experiências sem êxito com os pacotes pequenos de SDSC a ORNL, relatou os valores de largura de banda disponível flutuando significativamente. Os testes com os pacotes de 9000B neste sentido produziram sempre 0 Mb/s. Entretanto, no sentido ORNL ao SDSC, suas leituras eram mais consistentes e comparada com outras ferramentas. As suspeitas de que a fragmentação foi a responsável pela a maioria dos problemas ao testar o tamanho do pacote e a má combinação do MTU do trajeto. Os benefícios de utilizar grandes pacotes para medir links de alta velocidade, trazem mais trabalho para suportar consistentemente os grandes pacotes e para reduzir as falhas e as imprecisões que originam da fragmentação. Conclusão e futuros trabalhos Nosso estudo é a primeira avaliação detalhada de ferramentas publicamente disponíveis para a estimação da largura de banda disponível nos links de alta velocidade. Os testes foram conduzidos em laboratórios e em redes de pesquisa. As ferramentas pathload e o pathchirp foram as mais precisas sob as condições destas experiências. Iperf executa bem em links de altada velocidade se executado com seu tamanho máximo de buffer da janela. As pequenas quantidades(~1%) mas persistentes uniformes de perda de pacotes degradam seriamente seu desempenho. Os ajustes do temporizador de retransmissão do SO demasiadamente breves aumentam este problema. Os resultados destas experiências em relação a abing e a spruce que utilizam de técnicas de pares do pacotes devem estar cientes do atraso da atual rede estudada. Também, os frames 1500 bytes e a definição do timestamp em microssegundo não são sensíveis o bastante para testar trajetos de alta velocidade. Apesar dos problemas revelados, experimentos com as ferramentas para estimar largura de banda disponível que usam grandes pacotes são as melhores, considerando a importância de usar-los em links de alta velocidade. Foi demonstrado como o laboratório pode ser usado para avaliar e comparar ferramentas do estimação da largura de banda em oposição ao tráfego cruzado reproduzível em ambientes inteiramente controlados.