Guilherme da Silva Sengès

Transcrição

1 DESEMPENHO DE CONEXÕES BANDA LARGA Guilherme da Silva Sengès Projeto de Graduação apresentado ao Curso de Engenharia de Computação e Informação da Escola Politécnica, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Edmundo Albuquerque de Souza e Silva Rio de Janeiro Março de 2014

2 DESEMPENHO DE CONEXÕES BANDA LARGA Guilherme da Silva Sengès PROJETO SUBMETIDO AO CORPO DOCENTE DO CURSO DE ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO. Examinado por: Prof. Edmundo Albuquerque de Souza e Silva, Ph.D. Prof a. Rosa Maria Meri Leão, D.Sc. Prof. Daniel Sadoc Menasche, Ph.D. RIO DE JANEIRO, RJ BRASIL MARÇO DE 2014

3 da Silva Sengès, Guilherme Desempenho de Conexões Banda Larga/Guilherme da Silva Sengès. Rio de Janeiro: UFRJ/POLI, XII, 43 p.: il.; 29, 7cm. Orientador: Edmundo Albuquerque de Souza e Silva Projeto (graduação) UFRJ/ Escola Politécnica/ Curso de Engenharia de Computação e Informação, Referências Bibliográficas: p medição. 2. redes. 3. qualidade. I. Albuquerque de Souza e Silva, Edmundo. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Curso de Engenharia de Computação e Informação. III. Título. iii

4 Dedicado aos meus pais, meu irmão, meus avós, meu grande amor e meu orientador. Eles são a base de todo este trabalho. iv

5 Agradecimentos Gostaria de agradecer a minha família por estar sempre por perto e proporcionar todo o apoio possível e necessário desde meu nascimento. Aos meus pais, especialmente, por participarem ativamente de cada minuto em minha vida, com uma entrega de corpo inteiro em virtude de meu bem-estar. Ao meu irmão, pela parceria e compreensão únicas, tornando nossa convivência sempre prazerosa. Aos meus avós e tios por possibilitarem todos os momentos bons que uma família grande pode oferecer. Ao meu amor que esteve ao meu lado antes, durante e sempre, desde os meus primeiros passos nesta grande empreitada. Aos meus amigos de infância, pré e pós adolescência que estiveram comigo em todas as superações que foram incumbidas a mim. Aos amigos da computação e do laboratório LAND, por me ajudarem nas dificuldades e dúvidas que todo aluno saudável deve passar. E ao meu orientador, por mostrar o caminho do conhecimento e o gosto pelos estudos, ensinando os assuntos que me despertam enorme interesse. v

6 Resumo do Projeto de Graduação apresentado à Escola Politécnica/UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação DESEMPENHO DE CONEXÕES BANDA LARGA Guilherme da Silva Sengès Março/2014 Orientador: Edmundo Albuquerque de Souza e Silva Curso: Engenharia de Computação e Informação Medições ativas em redes constituem um conjunto de técnicas que se utilizam de pacotes especiais (chamados sondas) enviados de um nó transmissor a um coletor (possivelmente o mesmo computador) com o objetivo de se obter métricas capazes de fornecer ao analista informações relevantes sobre o estado da rede por onde trafegam essas sondas. Nos últimos dez anos, essas técnicas têm sido aperfeiçoadas e usadas na Internet, principalmente em redes de longa distância, com o propósito de descobrir gargalos de capacidade, detetar congestionamentos e outros problemas que afetam o desempenho das aplicações. Recentemente, tem havido um grande interesse em determinar a qualidade dos serviços oferecidos pelas operadoras de banda larga aos seus clientes. Por exemplo, os EUA lançaram o programa Measuring Broadband America em 2010 e, em 2011, a Anatel publicou um regulamento que estabelece metas de qualidade sobre a prestação de serviços de comunicação multimídia. Esse trabalho visa o desenvolvimento de um software de medição que permita a realização de estudos em larga escala sobre a qualidade do acesso à Internet. O alicerce desta ferramenta foi o software TANGRAM-II, desenvolvido anteriormente pelo laboratório LAND/COPPE/UFRJ. O objetivo é o desenvolvimento de uma metodologia adequada para a realização de medições ativas de forma a obter estatísticas confiáveis que permitam a realização de um estudo abrangente em parceria com uma importante provedora de serviço. Descreveremos os desafios do trabalho e algumas das soluções concebidas. Além disso, apresentaremos estudos preliminares com um pequeno número de usuários em um ambiente real. vi

7 Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of the requirements for the degree of Engineer PERFORMANCE OF BROADBAND CONNECTIONS Guilherme da Silva Sengès March/2014 Advisor: Edmundo Albuquerque de Souza e Silva Course: Computer and Information Engineering Active measurements on computer networks combine a group of techniques that make use of special packets (known as probes) sent from a transmission node to a receiver (possibly the same computer) with the purpose of obtaining metrics for providing the analyst with relevant information about the network state related to the path where probes travel. Over the past ten years these techniques have been improved and used on the Internet, mainly on long distance networks, with the purpose of finding capacity bottlenecks, detecting network congestions and other problems that affect the performance of applications. Recently, there has been a significant concern about establishing the quality of services offered by broadband ISP s to its clients. For example, the USA started a program called Measuring Broadband America on 2010 and, on 2011, the brazillian telecommunications agency (Anatel) published a regulation that establishes baselines of quality about broadband services offered in Brazil. This work aims at developing a measurement software that allows the execution of large-scale studies to assess the quality of Internet access. The foundation of this tool was TANGRAM- II software previously developed by the LAND/COPPE laboratory. Our goal is to develop a suitable methodology for performing active measurements to obtain reliable statistics needed for performing a comprehensive study in partnership with a leading service provider. We describe the challenges of this work and some of the solutions devised. Furthermore, we present preliminary studies with a small number of users in a real environment setup. vii

8 Sumário Lista de Figuras Lista de Tabelas Lista de Abreviaturas ix xi xii 1 Introdução Contribuição Organização do texto Trabalhos relacionados 4 3 Metodologia proposta e funcionamento da ferramenta Definições sobre as métricas de interesse observadas Tempo de ida e volta Jitter Vazão Perda de pacotes Configuração da ferramenta Funcionamento da ferramenta Resultados Comparativo entre diferentes perfis de resultados Captura na mudança do plano de banda larga Influência do tráfego concorrente nas medições Conclusão e trabalhos futuros Conclusão Trabalhos futuros Referências Bibliográficas 35 A Funcionamento dos módulos 38 viii

9 Lista de Figuras 3.1 Envio de rajadas para medição de vazão utilizando UDP Esquema básico entre o cliente e o servidor Processo principal Gráfico exemplificando resultados de latência (RTT) Gráfico com as médias dos RTT s de um dos usuários observados. Boa parte dos valores obtidos manteve-se abaixo de 30 ms Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.2) colorida em vermelho Grande variabilidade nas médias dos RTT s de um dos usuários. Impressionantes valores acima de 100 ms foram capturados para usuário localizado em São Paulo Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.4) colorida em vermelho Gráfico com as médias do jitter de um dos usuários observados. Boa parte dos valores obtidos manteve-se abaixo de 3 ms Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.6) colorida em vermelho Gráfico exemplificando usuário com quantidades significativas de jitter acima de 5 ms Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.8) colorida em vermelho Gráfico com as medições de vazão por TCP para download de usuário pouco afetado pela faixa de horário entre 18 e 23 horas Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.10) colorida em vermelho ix

10 4.12 Gráfico de usuário com valor máximo de vazão por TCP para download consideravelmente reduzido na faixa de horário entre 18 e 23 horas Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.12) colorida em vermelho Dados de vazão por UDP para upload relativos ao mesmo usuário da Figura Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.14) colorida em vermelho Dados de vazão por UDP para upload relativos ao mesmo usuário da Figura Não há redução da vazão medida na faixa de horário entre 18 e 23 horas Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.16) colorida em vermelho Gráfico com resultados de vazão por TCP para upload. Usuário localizado no Rio de Janeiro Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.18) colorida em vermelho Gráfico relativo a usuário com porcentagens significativas da vazão por TCP para upload abaixo de 70% Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.20) colorida em vermelho Gráfico com as medições de vazão por TCP para download representando bons indicadores da banda larga contratada O gráfico da direita apresenta os dados coletados somente na ausência de tráfego concorrente. O gráfico apresenta os dados coletados unindo ambas as ocorrências de presença de tráfego concorrente e ausência de tráfego concorrente A.1 Processo de medição de Vazão por TCP para download A.2 Processo de medição de RTT e jitter A.3 Processo de medição de Vazão por TCP para upload A.4 Processo de medição de Vazão por UDP para upload A.5 Processo de medição de Vazão por UDP para download x

11 Lista de Tabelas 3.1 Fatores de perturbação e as respectivas soluções proporcionadas Quantidade de usuários analisados em diferentes estados brasileiros.. 15 xi

12 Lista de Abreviaturas ADSL Asymmetric Digital Subscriber Line, p. 5 Anatel Agência Nacional de Telecomunicações, p. 2 DNS Domain Name System, p. 5 FCC Federal Communications Comission, p. 2 GeorgiaTech Georgia Institute of Technology, p. 4 ICMP Internet Control Message Protocol, p. 6 ISP s Internet Service Providers, p. 1 MIT Massachusetts Institute of Technology, p. 4 MSS Maximum Segment Size, p. 9 NTP Network Time Protocol, p. 7 Ofcom Office of Communications, p. 4 QoE Quality of Experience, p. 2 QoS Quality of Service, p. 2 RTT Round Trip Time, p. 6 TCP Transmission Control Protocol, p. 5 TRAI Telecom Regulatory Authority of India, p. 5 UDP User Datagram Protocol, p. 6 WAN Wide Area Network, p. 34 xii

13 Capítulo 1 Introdução A oferta de de banda larga tem crescido muito nos últimos anos. Com cada vez mais pessoas acessando a Internet através de conexões velozes, a incidência de aplicações e serviços presentes neste meio multiplicou-se na diversidade e quantidade. Como consequência desses produtos, os usuários que antes utilizavam pontualmente o conteúdo disponível, passaram a intensificar essas atividades; potencializando a percepção de lacunas na banda larga que é ofertada. Em virtude deste fato, a preocupação com a qualidade de serviço e, mais recentemente, com a qualidade de experiência do usuário tem ganho força nestes últimos dez anos. É essencial entender os múltiplos significados que a palavra qualidade pode significar no contexto da banda larga. A existência de diferentes perfis de uso de cada usuário da Internet exemplifica a grande diversidade atrelada ao conceito. Como exemplo, aplicações que necessitam de uma resposta rápida na comunicação - e.g. jogos eletrônicos pela Internet - estarão sujeitos a uma sensibilidade maior em relação a latência na comunicação dos dados. Já aplicações como o Netflix enviam uma grande quantidade de dados em uma pequena janela temporal, refletindo em uma importância maior sobre a vazão da conexão do usuário final. Estas duas aplicações são um claro exemplo de diferentes métricas de qualidade que terão relevância para diferentes perfis de usuário. Os estudos sobre esse assunto visam beneficiar as três partes envolvidas no serviço de banda larga: O consumidor final, os Internet Service Providers (ISP s) e as agências reguladoras governamentais. Para o consumidor final, os indicadores de qualidade apresentados nesses estudos, ajudam na escolha consciente de um serviço de banda larga que melhor atenda suas necessidades. Por sua vez, os ISP s podem fazer uso dessas informações para identificar pontos deficientes a serem melhorados em suas redes, tornando-os mais atrativos e competitivos. Por último, as agências reguladoras podem utilizar os mesmos estudos para estabelecer patamares que ajudem a proteger os consumidores. Uma das formas de prover o diagnóstico da banda larga provida é através do 1

14 diagnóstico da infraestrutura que interconecta a rede doméstica a rede do ISP, utilizando técnicas de medição que adicionem tráfego a esses caminhos. Essa abordagem tem sido utilizada intensamente por pesquisas que fazem uso da parceria entre agências regulatórias, centros de pesquisa em universidades e ISP s interessados em auto diagnosticar-se. O projeto Measuring Broadband America criado pelo Federal Communications Comission (FCC), agência regulatória norte-americana, é um exemplo o qual relatórios anuais tem refletido na melhora de indicadores como o cumprimento do serviço ofertado [1], além da contribuição de identificar quais fatores são determinantes para a qualidade do serviço - Quality of Service (QoS) - e investigar quais seriam os possíveis indicadores para a melhora da qualidade de experiência do usuário - Quality of Experience (QoE) - ao utilizar diferentes serviços e aplicações na Internet. Com essa crescente preocupação sobre a qualidade do serviço ofertado, a Agência Nacional de Telecomunicações (Anatel) formulou no mês de outubro do ano de 2011, novos indicadores para avaliar a qualidade de serviços de banda larga, presentes na Resolução n o 574 da Anatel [2]. Desde então, ISP s brasileiros tem sido regulados por políticas mais rígidas, podendo ocasionar na emissão de multas para os ISP s caso haja deficiência em um desses indicadores observados. O estabelecimento desta política de punição, estimulou o questionamento por parte das provedoras, se os indicadores avaliados são idealmente a melhor forma de avaliar a qualidade do serviço ofertado. Este questionamento culminou no interesse de uma grande provedora de serviços de Internet em colaborar com este trabalho e formar uma parceria para desenvolver uma metodologia que ajude a entender quais as melhores práticas para oferecer um panorama da banda larga ofertada. Esse trabalho visa o desenvolvimento de um software de medição que permita a realização de estudos em larga escala sobre a qualidade do acesso à Internet. O alicerce desta ferramenta foi o software TANGRAM-II [3], desenvolvido anteriormente pelo laboratório LAND [4]. Nosso objetivo é o desenvolvimento de uma metodologia adequada para a realização de medições ativas de forma a obter estatísticas confiáveis que permitam a realização de um estudo abrangente. Além disso, serão apresentados estudos preliminares com um pequeno número de usuários em um ambiente real, observando três diferentes provedoras de banda larga. 1.1 Contribuição A principal contribuição deste trabalho é o desenvolvimento de um software de medição talhado para medições ativas em banda larga. Para a obtenção das métricas de medição, é necessário: 2

15 1. O desenvolvimento de uma metodologia adequada para cada métrica. 2. Uma implementação criteriosa do algoritmo desenvolvido para evitar que atrasos na execução das rotinas e/ou o próprio algoritmo tenha influência na métrica a ser obtida. 3. Levar em consideração o tráfego concorrente nos canais por onde passam as sondas. Considere como exemplo o item (3) acima. Sabendo-se da interferência que dados oriundos do tráfego concorrente dos usuários podem ocorrer sobre os dados de medição coletados [5], este trabalho visa considerar a coleta e apresentação de tais ocorrências sobre as métricas de medição observadas. Tentaremos fazer uma breve avaliação do impacto desse tráfego concorrente sobre o resultado final. Ao observar os trabalhos relacionados, percebeu-se que há pouca incidência de ferramentas de elaboração própria para coletar os dados desejados, e quando há algum processo de implementação, este consiste no agrupamento de uma série de ferramentas já existentes. O trabalho aqui apresentado, coleta dados com o auxílio de uma ferramenta desenvolvida por completo para este propósito. Utilizando algumas práticas observadas por pesquisadores sobre o assunto, a ferramenta visa mitigar os diversos fatores de perturbação que não estão relacionados com a qualidade da banda larga que se deseja medir. Todas as técnicas utilizadas para coletar as métricas desejadas, além de um mecanismo de sincronização e manutenção da infraestrutura montada, foram implementadas visando a minimização de falhas na implementação, utilizando a base do módulo de monitoramento de tráfego do software TANGRAM-II. A ferramenta elaborada neste trabalho tem como objetivo formar o alicerce de uma base de dados capaz de contribuir com estudos mais avançados, envolvendo futuras análises através de modelos estatísticos e técnicas de aprendizado de máquina. 1.2 Organização do texto O restante deste texto está organizado da seguinte forma: O capítulo 2 apresenta uma revisão dos trabalhos relacionados. O capítulo 3 apresenta a metodologia formulada neste trabalho, descrevendo os desafios no desenvolvimento de diferentes métricas empregadas. Além disso, é apresentado o funcionamento e organização da ferramenta desenvolvida. O capítulo 4 apresenta os resultados encontrados através dos dados coletados de um pequeno número de usuários em ambiente real. Por fim, o capítulo 5 apresenta algumas conclusões relacionando a metodologia proposta com os resultados encontrados, além de apresentar os trabalhos futuros. 3

16 Capítulo 2 Trabalhos relacionados Diferentes agências regulatórias de vários países vêm empregando estudos sobre esse assunto. Na Inglaterra, a agência Office of Communications (Ofcom) realiza estudos e relatórios anuais desde No primeiro relatório [6], uma companhia de marketing foi contratada para entrevistar usuários de banda larga, respondendo a perguntas como o plano de banda larga contratado, o perfil de uso e a satisfação quanto ao serviço contratado. Nessa pesquisa, 28% dos entrevistados não souberam informar qual o plano de banda larga havia sido contratado. Além disso, dados sobre a banda larga coletada de cerca de 1600 usuários que colaboraram com a pesquisa foram usados para divulgar os primeiros indicadores. Os resultados só levaram em conta os dados obtidos em intervalos os quais não havia tráfego concorrente do colaborador. Nos Estados Unidos, a FCC coordena o projeto intitulado de Measuring Broadband America [7]. Este projeto, iniciado em 2009, realiza estudos para o melhor entendimento da qualidade da banda larga oferecida para os norte-americanos, estabelecendo um trabalho em conjunto com o Massachusetts Institute of Technology (MIT), Georgia Institute of Technology (GeorgiaTech) e diversos ISP s americanos. No relatório publicado no ano de 2011 [1], o constante acompanhamento dos indicadores de qualidade, revelou que os valores mensurados para velocidade de download se aproximaram daqueles anunciados pelas companhias, após a publicação do primeiro relatório em Através dos mesmos relatórios norte-americanos de 2010 e 2011, estudos complementares foram realizados a partir dos dados disponibilizados. Ressalta-se os trabalhos com a ferramenta BISmark [5] [8] criada para complementar as métricas observadas pelo FCC. Parte das recomendações destes trabalhos foram aplicadas neste trabalho. O uso de dispositivos conectados diretamente ao modem dos usuários participantes dos experimentos e as recomendações sobre a robustez ao usar múltiplas conexões TCP são os principais exemplos. A principal contribuição destes artigos é mostrar como componentes como os buffers em roteadores de uso doméstico, redes 4

17 sem fio, além de efeitos causados por protocolos, podem afetar consideravelmente o desempenho no acesso feito pelos usuários. Além disso, os autores tratam de um ponto muito importante, no qual a existência de serviços que atendam a velocidade contratada, não implica em usuários satisfeitos ao utilizar serviços na Internet - pois essas podem demandar mais do que simples velocidades elevadas. No Brasil, o trabalho realizado por Madruga et al.[9] coletou dados de 48 usuários de diferentes ISP s brasileiros para averiguar métricas como a relação entre a Capacidade de Transferência de Massa aferida e a anunciada pelos ISP s para conexões de banda larga - popularmente conhecido com o uso do termo velocidade. Outro métrica interessante consiste na avaliação do tempo de resolução de Domain Name System (DNS) para uma página fixa na Internet. Os resultados das métricas observadas revelaram deficiências como diferenças percentuais de até 80% entre a velocidade anunciada pelos ISP s e a aferida pelos experimentos. Com base nos indicadores apresentados, a Anatel publicou uma nova regulamentação (n o 574), estabelecendo novos patamares de qualidade no serviço de banda larga regente. Na Índia, a agência de governamental responsável - Telecom Regulatory Authority of India (TRAI) - estabeleceu em 2006 [10] uma regulamentação responsável por acompanhar uma série de indicadores de qualidade, tais como a perda de pacotes, vazão e latência, além de acompanhar serviços relacionados ao provisionamento de banda larga aos usuários - tais como o tempo de resposta no serviço de atendimento dos ISP s ao consumidor. Como consequência dessa regulamentação, empresas responsáveis por aferir os indicadores preestabelecidos, mantém relatórios técnicos disponíveis para consulta[11]. Existem trabalhos que tratam da dificudade na obtenção de métricas de desempenho em determinados ambientes. No artigo de Ma et. al. [12], o problema da existência de enlaces que não respondem a sondas para diagnóstico é tratado. O trabalho caracteriza em quais condições é possível obter um diagnóstico desses enlaces, além de explicar como e quantos enlaces monitores - que respondem a sondas para diagnóstico - são utilizados na abordagem. Um algortimo eficiente, em relação a uma abordagem padrão, é proposto e testado tanto em ambiente simulado quanto em um ambiente real. Há artigos que realizam estudos sem a cooperação entre ambas as pontas. Em Croce et. al. [13], estimativas sobre a capacidade de conexões utilizando Asymmetric Digital Subscriber Line (ADSL) são feitas por envio de sondas contendo ACKs do protocolo Transmission Control Protocol (TCP). Utilizando as características do ADSL, técnicas são usadas para mitigar o efeito que o tráfego concorrente pode causar, além de utilizar uma quantidade de sondas inferior quando comparado às técnicas empregadas com comperação em ambas as pontas. A validação da ferramenta elaborada é feita com casos reais em ISP s. 5

18 Capítulo 3 Metodologia proposta e funcionamento da ferramenta Os métodos empregados na metodologia elaborada para as medições neste trabalho, fazem uso de um conjunto de técnicas chamadas de medições ativas. Medições ativas significam que todas as métricas observadas são obtidas através do envio de sondas entre os fins comunicantes. Para cada tipo de métrica a ser observada, atributos relevantes são adicionados no conteúdo da sonda. Assim, diferentes tipos de sondas são enviadas e recebidas entre o nó transmissor e o coletor para cada métrica observada. 3.1 Definições sobre as métricas de interesse observadas Tempo de ida e volta O tempo de ida e volta ou Round Trip Time (RTT), consiste no cálculo do tempo decorrido para uma sonda ser enviada a partir do nó transmissor, percorrer um caminho existente entre o nó transmissor e o coletor, ser recebida pelo coletor e então reenviada de volta para o nó transmissor. O protocolo User Datagram Protocol (UDP) foi propositalmente escolhido para o envio das sondas. Enquanto ferramentas como o ping e traceroute fazem o uso do protocolo Internet Control Message Protocol (ICMP) e podem ser usadas para medir o RTT, estas mesmas podem causar uma variabilidade dos resultados não desejada e causada por mecanismos de balanceamento de carga que podem estar presentes no caminho percorrido [14]. A utilização de pacotes UDP elimina a multiplicidade de caminhos causados pelo balanceamento, tanto no envio quanto na recepção das sondas. Para efeitos de análise, os resultados obtidos são registrados como uma média 6

19 de uma sequência de sondas enviadas. É importante notar que o tempo decorrido tem como referencial o relógio do nó transmissor. Portanto, o cálculo do tempo decorrido é obtido através da subtração entre o tempo registrado na chegada após o coletor reenviar a sonda, e o tempo registrado no envio da sonda a partir do nó transmissor. Esta escolha foi feita por sua simplicidade e habilidade de mitigar o risco de erro no cálculo do tempo decorrido devido a uma possível dessincronização entre os nós. A utilização de ambos os relógios do transmissor e do coletor implicaria em uma desnecessária sincronização entre eles através do protocolo Network Time Protocol (NTP). Procedimento empregado Neste trabalho, a técnica utilizada consistiu no envio de uma quantidade de sondas que ponderassem entre um tempo total de medição curto e um resultado que pudesse ser estatisticamente confiável. Por isso, visando essa ponderação, 30 sondas são enviadas, a partir do nó transmissor, até o coletor. Estas sondas, quando retransmitidas pelo coletor, são recebidas pelo nó transmissor e seus respectivos tempos decorridos são gravados. Logo após, o tempo médio de ida e volta é calculado a partir de uma média simples dos tempos de ida e volta gravados para cada sonda recebida de volta. O número escolhido de sondas para envio foi decidido afim de obter uma média representativa do atraso no caminho percorrido como um todo Jitter Consiste na medição dos intervalos entre as sondas recebidas pelo nó transmissor após serem enviadas pelo mesmo e retransmitidas pelo coletor. Os intervalos de envio entre uma sonda e outra são perturbados por atrasos presentes na rede - principalmente pela flutuação das filas nos roteadores. O envio é novamente realizado utilizando o protocolo UDP por motivos semelhantes aos expostos anteriormente no RTT. O uso exclusivo do relógio do nó transmissor é novamente empregado devido ao risco de dessincronização anteriormente relatado. Procedimento empregado Para este projeto, as mesmas sondas enviadas para calcular o RTT médio são usadas para calcular o jitter médio. Calcula-se o tempo de intervalo entre cada sonda recebida de volta no nó transmissor, e através de uma média simples, o jitter médio é calculado. O tempo de intervalo entre cada sonda é obtido pela diferença dos tempos de pares de sondas que foram recebidos com sucesso. Caso uma sonda seja perdida, o tempo de intervalo entre esta e a sonda seguinte e a sonda anterior não é calculado, e portanto não é considerado para o cálculo do jitter médio. 7

20 3.1.3 Vazão A definição de medição de vazão é diversa. Segundo a seção sobre medições de banda larga do livro Internet Measurement [15], pode-se considerar a vazão de três formas diferentes: A medição da capacidade, representando a quantidade total de bits por segundo que um enlace ou caminho comporta. A medição da largura de banda disponível, significando a porção da capacidade que não está em uso durante um determinado período de tempo. E a medição da capacidade de transferência em massa, a qual é utilizada neste trabalho. A capacidade de transferência em massa consiste no cálculo da quantidade de bits por segundo que saem de um nó transmissor e chegam com sucesso até o nó coletor, utilizando um protocolo capaz de detectar e gerir congestionamentos - como o TCP. Além desta técnica, foi desenvolvida outra abordagem bastante experimental utilizando o protocolo UDP. Como medida de avaliação dos usuários participantes deste trabalho, é considerado somente a capacidade de transferência em massa. Para fins somente ilustrativos serão apresentados os resultados para a técnica utilizando UDP. A partir deste ponto por questões de praticidade, a capacidade de transferência em massa será referida somente como vazão utilizando TCP e a outra técnica como vazão utilizando UDP. Vazão utilizando o protocolo TCP Uma das maiores preocupações desta técnica é superar possíveis problemas relacionados ao ambiente o qual o usuário participante do experimento está configurado. Fatores como a má configuração dos parâmetros de conexões TCP, a existência de perdas pontuais ao executar uma medição, ou até a competição de demais conexões TCP existentes, podem limitar o valor máximo a ser atingido e ofuscar resultados que realmente reflitam o estado da infraestrutura observada. Muitos destes fatores são minimizados pela configuração do ambiente real da ferramenta que será mostrada na seção 3.2. Contudo, alguns dos trabalhos sobre este assunto [8][16][17], revelam que o uso de múltiplas conexões TCP reduzem a perda agregada, minimizam as consequências de parâmetros configurados por padrões de sistemas operacionais e aumentam a robustez contra a perda de pacotes. Procedimento empregado A técnica empregada é bastante simples: Um arquivo com tamanho configurável é dividido em partes iguais e enviado do nó transmissor para o coletor através de uma quantidade configurável de conexões TCP. Após a correta inicialização de cada conexão TCP aberta, os bits começam a ser enviados em um mesmo instante. O coletor recebe os bits do arquivo e grava o instante recebido de cada pedaço do arquivo recebido. É importante notar que uma conexão TCP possui o período 8

21 chamado de Slow-Start, no qual o protocolo tenta estabelecer qual o máximo de segmentos TCP suportados sem que haja perda pelo receptor. Este período não é considerado no cálculo da vazão, já que o máximo de uma conexão ainda não foi atingido. Ao final da transmissão, os bits recebidos de cada segmento são somados e então o tempo de recebimento do último segmento é subtraído do primeiro segmento recebido - desconsiderando o período de Slow-Start. Através de uma divisão simples, o número de bits recebidos é dividido pelo tempo total e o resultado é a vazão. Calculando o tempo de Slow-Start Para encontrar o tempo necessário de Slow-Start a ser descartado pelo coletor são feitos os seguintes cálculos: 1) Determinação do número de segmentos TCP para que o limiar da janela de recepção máxima de segmentos seja alcançado. O limiar corresponde ao número de segmentos máximo que poderiam ser enviados sem que uma confirmação de recepção fosse recebida. Limitado aos 16 bits reservados no cabeçalho TCP para a identificação da janela de recepção, o limiar será correspondente ao valor de bytes. O tamanho máximo de segmento - Maximum Segment Size (MSS) - corresponde a quantidade de bytes máximo que podem ser transferidos em um único segmento TCP, não considerando o cabeçalho. Utiliza-se o valor máximo aceito pelos enlaces intermediários de 1440 bytes. NSegmentos = Limiar Janela de Recepção MSS (3.1) 2) Cálculo do tempo de transmissão de uma janela TCP: TJanela = (Limiar Janela Capacidade Máxima Contratada) RTT (3.2) Na Equação 3.2, considera-se a capacidade máxima contratada do usuário, pois representa o enlace com a menor capacidade entre o transmissor e o receptor. Se o resultado for menor que zero, então o tempo de transmissão de uma janela é irrelevante e assume-se o valor zero. 3) Cálculo do tempo decorrido de Slow-Start: TSlowStart = log 2 (NSegmentos) RTT + TJanela (3.3) O RTT utilizado corresponde a média dos valores de RTT obtidos nas medições, e assume-se um valor comum entre as médias. A explicação da Equação 3.3 é bastante simples e intuitiva: O tempo de Slow-Start é dado pelo número de RTT s 9

22 necessários para alcançar o limiar máximo de segmentos. Como o número de segmentos enviados é dobrado a cada ACK recebido na etapa de Slow-Start, temos que o crescimento é quadrático. Portanto, para calcularmos a quantidade de RTT s necessários, extraímos o log na base 2 do número de segmentos que calculamos na Equação 3.1. O adicional do tempo de transmissão de uma janela TCP é apenas relevante para conexões de menor velocidade. Vazão utilizando o protocolo UDP Ao contrário do TCP, o protocolo UDP não possui qualquer controle de congestionamento e de transmissão, portanto maiores cuidados são necessários para este tipo de medição. A vazão que se calcula nessa técnica leva em consideração as perdas de datagramas ocorridas no percurso (por filas cheias nos roteadores usados no caminho, por exemplo). Portanto, a técnica empregada calculará a vazão efetiva através do protocolo UDP, o qual julga-se uma métrica mais próxima do observado através do uso de aplicações que utilizam o UDP (e.g. Skype [18]). Por não possuir nenhum controle de transmissão, o número de datagramas enviados para o coletor de uma só vez precisa ser calculado a partir da fila de transmissão e de recepção. Caso transmita-se mais do que a capacidade destas filas, haverá perda dos pacotes nos próprios nós nas pontas, acarretando em um cálculo da vazão não relacionado com o atual estado da rede a ser diagnosticada. Procedimento empregado Consiste no envio de rajadas de datagramas igualmente espaçados entre eles e também entre cada rajada. Um número configurável de rajadas são enviadas, contendo cada uma, um número configurável de datagramas. Observe a Figura 3.1. Ao final do processo, o tempo de recepção de cada rajada é calculado através da subtração entre o tempo do último datagrama recebido e do primeiro recebido de uma mesma rajada, subtraindo-se o intervalo entre datagramas na transmissão. O tamanho em bits de uma rajada recebida é então dividida pelo tempo da rajada respectiva, sendo a vazão calculada por rajada. Ao final, a vazão calculada será dada pela média simples de cada vazão de rajada calculada. Para a configuração do número de rajadas transmitidas e do número de datagramas por rajada, é considerado o valor contratado da banda larga do usuário. O número de rajadas e datagramas transmitidos em um único segundo deve ser capaz de preencher o canal de transmissão sem que haja a perda nas filas de transmissão e de recepção. 10

23 Figura 3.1: Envio de rajadas para medição de vazão utilizando UDP Perda de pacotes As sondas trafegadas durante o processo de medição - assim como todo e qualquer pacote que trafega pela Internet - estão sujeitas a perdas provocadas por diversos fatores, sendo o principal deles o crescimento das filas nos roteadores presentes na rede. O rápido crescimento em um curto intervalo de tempo provoca a perda de pacotes pelo estouro dessas filas. A perda de pacotes consiste então na contagem das sondas que não foram recebidas pelo nó receptor na camada de aplicação. É importante lembrar que as sondas transmitidas utilizando o protocolo de transporte TCP não acusam perdas para a camada de aplicação, já que são retransmitidas no nível da própria camada de transporte. A perda que medimos, portanto, trata das sondas transmitidas através do protocolo de transporte UDP. Procedimento empregado Através da ferramenta desenvolvida, qualquer quantidade de pacotes UDP enviados de um nó transmissor é previamente conhecida através de uma conexão de controle aberta entre o nó transmissor e o coletor. Dessa forma, qualquer quantidade recebida abaixo do número de pacotes esperado é contabilizada como perda. O cálculo desta perda é feito através da subtração do número de pacotes esperado pelo número de pacotes recebidos. O resultado desta diferença é posto em porcentagem através da simples divisão pelo número de pacotes esperado. 3.2 Configuração da ferramenta Com o objetivo de mitigar os fatores de perturbação não relacionados a infraestrutura de um ISP, optou-se por utilizar dispositivos conectados diretamente aos modens de acesso à Internet [8]. Dessa forma, problemas existentes por medições 11

24 realizadas dentro da rede local do usuário são resolvidos conforme mostrado na Tabela 3.1. Tabela 3.1: Fatores de perturbação e as respectivas soluções proporcionadas. Fator Solução Perturbação por comunicação Uso de dispositivo conectado por sem fio cabo ao modem Presença de tráfego concorrente Dispositivo capaz de detectar tráfego concorrente do usuário Configuração de parâmetros Dispositivo pode ser configurado para a medição remotamente Tais dispositivos utilizados para gerar as medições foram escolhidos como roteadores de baixo custo. Através de um sistema operacional Linux voltado para roteadores de uso residencial [19], foi possível instalar a ferramenta desenvolvida nos dispositivos. A ferramenta, instalada no dispositivo, é capaz de detectar a presença de tráfego concorrente - ocasionado pelo usuário - e contabilizá-la através da observação dos dados trafegados em cada interface local do dispositivo. Esta detecção de tráfego concorrente só é possível se todos os computadores pessoais do usuário estiverem conectados ao dispositivo - já que este é um roteador de baixo custo. A ilustração na Figura 3.2, fornece uma representação simplificada entre o cliente e o servidor do software piloto criado. Figura 3.2: Esquema básico entre o cliente e o servidor. 12

25 3.3 Funcionamento da ferramenta A Figura 3.3 representa o processo principal do procedimento de medição da ferramenta. A presença de etapas como as de Autenticação e de Envio de Parâmetros garantem a comunicação de dados de controle de forma segura e de configuração correta do dispositivo para banda larga contratada pelo usuário. Os detalhes de cada etapa deste processo podem ser verificadas no Apêndice A deste trabalho, exceto pelas etapas de Autenticação e de Envio de Parâmetros que não apresentam relevância para o entendimento deste trabalho. Vale ressaltar que as etapas relacionadas a diferentes métricas observadas podem ser executadas em diferentes combinações. A métrica da cálculo das perdas no envio de datagramas UDP está inserido nas demais métricas que fazem o uso do UDP. 13

26 Figura 3.3: Processo principal. 14

27 Capítulo 4 Resultados Os dados coletados e expostos a seguir, refletem diferentes períodos de observação em relação a 24 roteadores, contendo a ferramenta desenvolvida, que foram distribuídos para usuários reais de banda larga e alocados para estes experimentos. No total, 3 ISP s brasileiros foram observados, sendo 19 dos usuários observados pertencentes ao ISP denominado A, 3 outros pertencentes ao ISP denominado B e 2 restantes pertencentes ao ISP denominado C. Os estados brasileiros que fizeram parte deste trabalho, além da quantidade de usuários em cada um deles, está apresentado na Tabela 4.1. Tabela 4.1: Quantidade de usuários analisados em diferentes estados brasileiros. Estado Quantidade de usuários observados Rio de Janeiro 12 São Paulo 9 Rio Grande do Sul 2 Distrito Federal 1 É importante atentar para a localização do servidor de medições utilizado nos diferentes períodos de medição realizados. Um único servidor foi alocado no laboratório LAND, situado no estado do Rio de Janeiro, e a rede de acesso ao qual estava localizado, difere da rede dos demais ISP s A, B e C. Considera-se que diferenças possam existir entre os resultados aqui expostos e possíveis resultados que considerem apenas a rede de acesso de cada ISP isoladamente. Sobre a leitura dos gráficos a seguir Os gráficos de barras em três dimensões a seguir representam o conjunto de amostras respectivas a uma métrica observada durante um período específico de medição. Esse período de medição estará explicitado na legenda de cada gráfico. Os eixos são lidos da seguinte forma: O eixo intitulado de hora do dia está dividido em 24 faixas correspondentes às 24 horas do dia. No eixo X do gráfico, há faixas de 15

28 valores com os possíveis resultados esperados de acordo com a métrica observada. Por fim, o eixo intitulado de porcentagem das medições representa a quantidade de amostras em uma determinada hora do dia, sendo dividida percentualmente de acordo com as faixas de valores do eixo X - respectivo aos valores da métrica observada. Não há distinção entre as cores usadas na barras de cada gráfico, exceto quando explicitado no texto. Exemplo: Suponhamos que 50 amostras relativas a métrica de RTT observada foram coletadas às 20 horas durante 10 dias de medição. Dessas 50 amostras, 10 apresentaram valores entre 90 e 100 milissegundos, outras 10 apresentaram valores entre 40 e 50 milissegundos, e o restante apresentou valores entre 20 e 30 milissegundos. Dessa forma, o seguinte gráfico da Figura 4.1 seria obtido. Figura 4.1: Gráfico exemplificando resultados de latência (RTT). 4.1 Comparativo entre diferentes perfis de resultados Nesta seção, mostraremos resultados dos gráficos para cada métrica observada separadamente. Após a análise dos resultados dos 24 clientes, serão expostos dois casos contrastantes para cada métrica. É importante ressaltar que todos os resultados a seguir foram coletados sem a interferência de tráfego concorrente dos usuários. O período de medição estará explicitado nos trechos a seguir. 16

29 Média do RTT observado As medições coletadas durante o mês de Janeiro de 2014 revelaram que a maioria dos usuários observados possuem boa parte dos tempos de resposta abaixo de 30 milissegundos, exemplificado pelo usuário observado no gráfico das Figuras 4.2 e 4.3. Isso foi observado tanto para usuário presentes no Rio de Janeiro, quanto para os localizados em São Paulo. Porém, 2 dos usuários observados obtiveram tempos de resposta com grande variação, superando valores de 100 milissegundos, conforme ilustrado nas Figuras 4.4 e 4.5, mesmo localizados na cidade de São Paulo. Figura 4.2: Gráfico com as médias dos RTT s de um dos usuários observados. Boa parte dos valores obtidos manteve-se abaixo de 30 ms. 17

30 Figura 4.3: Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.2) colorida em vermelho. Figura 4.4: Grande variabilidade nas médias dos RTT s de um dos usuários. Valores acima de 100 ms foram capturados para um usuário localizado em São Paulo. 18

31 Figura 4.5: Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.4) colorida em vermelho. Média do jitter observado Boa parte dos usuários observados obtiveram valores de jitter inferiores a 3 milissegundos 4.6 e 4.7. Em contraste, 3 dos usuários observados apresentaram quantidades significativas acima de 5 milissegundos 4.8 e 4.9. As medições foram coletadas no mês de Janeiro de

32 Figura 4.6: Gráfico com as médias do jitter de um dos usuários observados. Boa parte dos valores obtidos manteve-se abaixo de 3 ms. Figura 4.7: Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.6) colorida em vermelho. 20

33 Figura 4.8: Gráfico exemplificando usuário com quantidades significativas de jitter acima de 5 ms. Figura 4.9: Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.8) colorida em vermelho. 21

34 Vazão por TCP para download Dentre os diferentes valores de banda larga contratada, variando entre 1 Mb/s e 35 Mb/s para o grupo de usuários observado, não houve diferenças significativas no perfil das medições coletadas. A diferença capturada está explicitada nos gráficos das Figuras 4.10 e Observando-os, percebe-se que há um grupo de 20 usuários pouco afetado pela faixa de horário entre 18 e 23 horas - grande número de usuários conectados e utilizando o serviço ao mesmo tempo. Já um outro grupo de 4 usuários apresenta um perfil semelhante ao gráfico da Figura 4.12, que possui considerável redução da vazão máxima observada na faixa de horário entre 18 e 23 horas. O período de observação abrange o mês de Janeiro de Figura 4.10: Gráfico com as medições de vazão por TCP para download de usuário pouco afetado pela faixa de horário entre 18 e 23 horas. 22

35 Figura 4.11: Gráfico exibindo somente as porcentagens para o horário de 21 horas respectivas a região do gráfico anterior (Figura 4.10). Figura 4.12: Gráfico de usuário com valor máximo de vazão por TCP para download consideravelmente reduzido na faixa de horário entre 18 e 23 horas. 23