Questões Práticas em Medições da Internet

1. Questões Práticas em Medições da Internet Capítulo 4 Crovella, M, Krishnamurthy, B. Internet Measurement: infrastructure, traffic & applications. John Wiley & Sons, 2006.

2. Roteiro • Onde podem ser realizadas as medições? • Papel do Tempo • Papel de Diretórios da Internet e Bases de Dados • Medições nas Diversas Camadas de Protocolos

3. Onde Podem ser Realizadas as Medições?

4. Locais de Medições em um ISP

5. Locais das Medições: LAN • Medições em LANs são normalmente efetuadas em redes experimentais (testbeds) e normalmente não têm interesse em medições da Internet. • No entanto, medições de latência local e relacionadas a hardware são tipicamente realizadas em LANs. • Nelas é mais fácil ter controle completo sobre o que está sendo medido. • São realizadas também medições relacionadas às camadas mais altas. • Há interesse crescente sobretudo em medições em redes sem fio.

6. Locais das Medições: Rede Troncal • Normalmente são realizadas medições mesmo que os dados obtidos não sejam disponibilizados. • Objetivo principal: planejamento de capacidade • Técnicas: • SNMP (Mais comum): perda de pacotes, atraso e vazão. • Rastreamento de pacotes (com marcas de tempo de alta precisão)

7. Rede Troncal: Roteiro • Alocação de Largura de Banda • Medições dentro da Rede • Identificação de Ataques • Disponibilidade (Resiliência)

8. Rede Troncal: Alocação de Largura de Banda • Alocação de largura de banda nos links internos (provisionamento) é uma das atividades principais dos ISPs. • Aplicações diferentes têm graus variados de sensibilidade à latência, de modo que a utilização dos links deve ser ajustada de modo a satisfazer requisitos como atraso de modo a limitar o atraso fim-a-fim. • A composição real do tráfego deve ser medida dentro da rede para se fazer o provisionamento adequado. • Mesmo que o ISP use sobreprovisionamento o grau adequado deve ser calculado.

9. Rede Troncal: Medições dentro da Rede • Os ISPs podem usar informações de longo prazo da utilização dos links para identificar PoPs que necessitam de uma maior capacidade. • Diversos monitores de alta velocidade foram construídos para monitorar os enlaces. • Medições dentro da rede troncal provê uma visão em profundidade de todo o tráfego associado a um conjunto de usuários. • Verificação dos SLAs assinados pelo ISP. Requer medição do atraso dos pacotes.

10. Rede Troncal: Medições dentro da Rede • Dado que o tráfego sensível a atrasos pode ocorrer entre qualquer par origem-destino, deve ser monitorado o tráfego entre todos os pares. • A modelagem baseada em medições tem auxiliado no provisionamento adequado de largura de banda.

11. Rede Troncal: Medições dentro da Rede • Podem ainda ser monitorados os diversos links dentro da rede junto com informações de roteamento para se ter uma visão completa. • No nível macro, mudanças de tráfego podem ser observadas através de amostras de medições dentro da rede. • Diversas matrizes de tráfego são criadas para capturar o tráfego entre prefixos, cidades ou usuários arbitrários. • Num nível micro, as medições na rede permitem ajustar os pesos dos protocolos de roteamento internos (IGP) para balancear o tráfego entre diversos links • Necessitam de grande capacidade de armazenamento e devem lidar com uma rede que está mudando constantemente.

12. Rede Troncal: Idenficação de ataques • A monitoração da rede buscando crescimentos repentinos podem ajudar a identificar potenciais ataques. • As técnicas de detecção de anomalias podem ser reforçadas observando mudanças significativas dos padrões de tráfego entre pontos de presença. • Ex.: observação periódica da utilização dos links.

13. Rede Troncal: Disponibilidade (Resiliência) • Podem ocorrer também falhas que não estejam relacionadas a ataques mas que também devem ser monitoradas para garantir a disponibilidade. • Apesar do usuário ter múltiplas conexões IP, se houver compartilhamento de rede física, pode não obter a disponibilidade desejada. • As rotas podem ser recuperadas se houver rotas alternativas pré-computadas. • Para uma recuperação rápida pode ser atribuída uma maior prioridade às mensagens de atualização de rotas.

14. Locais das Medições: Entrada da Rede • Roteador Gateway • Roteador de Peering • Roteador de Acesso

15. Entrada da Rede:Roteador Gateway • Controle de acesso • Estatísticas globais • Exportação de resumos de tráfego por fluxo • Através da ferramenta netflow • Informações sobre os instantes de início e fim do fluxo • Duração • Endereços IP da origem e destino • Número de portas • Sistemas autônomos, • Etc. • Informação suficiente para: • Construir relatórios de agregados de tráfego por usuário. • Aprender que fração do tráfego é destinado a usuários da rede e quanto está apenas transitando através da rede.

16. Entrada da Rede:Roteador de Peering • Roteadores que falam BGP para trocar informação de roteamento. • O peering pode ser público ou privado, em função da disponibilidade dos dados trocados. • Objetivo da medição neste nível: • Conectividade inter-domínio. • Desejo de balancear o tráfego para não gerar dívida. • Dados agregados do netflow são frequentemente uma fonte para a geração de tráfego para estas finalidades.

17. Entrada da Rede:Roteador de Peering • Exame do BGP para examinar convergência de fluxo, anúncios incorretos ou repetidos, etc. • Laços de roteamento em BGP (transiente ou persistente) são causados por anúncios ou saídas incorretas de ASes externos. • Uma forma de identificar estes laços é examinar os traços de pacotes e verificar se o pacote cruza o mesmo ponto de monitoração com a mesma carga, variando apenas o campo do TTL. • Pode ser necessário monitorar também as rotas internas a um AS (iBGP).

18. Entrada da Rede:Roteador de Peering • Podem ser injetadas falhas deliberadamente para examinar seus impactos: • Quanto tempo demora antes que a rota seja reparada, ou que seja encontrada um melhor caminho • Examinar a diferença entre a reação de diversos ISPs. • Medições ativas podem participar de sessões de trocas BGP remotas para examinar: • Taxa de falhas dos roteadores que fazem o peering • Frequência com que ocorrem estas falhas. • A instabilidade de roteamento é frequentemente o resultado de poucos caminhos de rede na Internet.

19. Entrada da Rede:Roteador de Acesso • Roteadores de acesso dos usuários • Para os usuários uma questão chave é a disponibilidade. Portanto, são realizadas medições rotineiras para garantir que a taxa de falhas seja muito baixa ou nula. • Deve ser garantida a SLA com grandes usuários comerciais. • Para aplicações de tempo real os requisitos da SLA podem ir além da disponibilidade, baixo atraso e baixa perda de pacotes. • Pode ser solicitada a filtragem de pacotes a partir apenas de certos endereços, limitação do número de pacotes em um certo intervalo de tempo, marcação de pacotes (QoS), verificação proativa de possíveis ataques, etc.

20. Locais das Medições: PTT • Um ponto de troca de tráfego permite que diversos ISPs troquem tráfego em pontos determinados. • Os custos são divididos em função do tráfego trocado em cada direção. • Este é um ponto privilegiado de observação para o tráfego que é trocado entre os ISPs. • Finalidade principal: Manter o tráfego local – transferir o tráfego entre dois participantes sem ter que roteá-los através de rotas mais longas. • Estas medições permitem ter uma ideia geral das alterações nos padrões de tráfego.

21. Locais das Medições: WAN • Medições em diversos locais da rede: • Pontos mencionados anteriormente em diversos PoPs. • Medições multi-sítios de forma coordenada. • Requer: sincronização de relógios, serialização da execução, mecanismo de comando e controle capaz e lidar com questões de controle de acesso e de recursos. • O potencial de problemas é ampliado devido à diversidade de locais. • Há também questões de segurança no uso dos recursos e dos dados. • Exemplos: NIMI, PlanetLab e perfSONAR

22. Locais das Medições: WAN • Representatividade das medições: • Requer que estejam bem representadas: população de usuários, escolha de clientes, servidores, etc. • Problemas com a relutância por parte dos administradores de rede em compartilhar os seus dados devido a questões de privacidade e competitividade.

23. Papel do Tempo

24. Papel do Tempo • Muitas medições requerem uma medição precisa do tempo: • Medição de tempo de ida e volta dos pacotes • Medição do atraso sofrido pelos pacotes ao passar por roteadores e links • Produção de uma visão ordenada no tempo de medições realizadas em diferentes partes da rede. • Medição do desempenho (tempo de resposta e vazão) de componentes da Internet.

25. Relógios • Terminologia: • tempo verdadeiro em qualquer instante • tempo aparente reportado pelo relógio no instante • Offset: • Diferença entre o tempo verdadeiro e o tempo reportado. • Um relógio preciso seria aquele para o qual o estivesse sempre próximo a zero.

26. Relógios • Taxa e Skew: • Taxa: • Primeira derivada do tempo aparente de um relógio em relação ao tempo verdadeiro. • Um relógio preciso teria um próximo a um. • Skew: • Diferença entre a taxa de um relógio e a taxa correta • Skew • Resolução: • Menor quantia em que o tempo reportado pode mudar. Ele dá um limite inferior na incerteza do relógio.

27. Relógios • A acurácia é um requisito mais exigente do que skew zero e, portanto, é mais difícil de ser atingido. • Um relógio que tenha um grande offset (e, portanto, é inacurado) mas que tenha skew zero ainda é útil para certo tipos de medição. • Exemplos: • Tempos de ida e volta dos pacotes • Intervalos entre chegadas de pacotes • Medições de tempo de resposta de servidor. • Por outro lado, há medições que requerem offset zero: • Atraso de pacotes em um sentido • Ordenação no tempo de eventos ocorridos em diversos locais da rede.

28. Escalas de tempo • Atrasos de pacotes em um sentido têm frequentemente magnitudes na escala de dezenas ou centenas de milissegundos. • São aceitáveis: resoluções e offsets na ordem de milissegundos e um pequeno skew. • Intervalos de tempo entre chegada de pacotes em um link de alta velocidade pode estar na escala de microssegundos. • O relógio pode ter qualquer offset, mas a resolução deve ser da ordem de nanossegundose o skewdeve ser próximo a zero.

29. Requisitos de Resolução • Os requisitos de resolução normalmente diminuem ao subir na pilha de protocolos. • Tempos de resposta típicos: • um quarto de segundo para o DNS • Poucos segundos para o HTTP • Poucos minutos para aplicações P2P

30. Fontes de Informação de Tempo • Fontes de tempo externas: • Serviços de rádio do NIST • GPS: • Constelação de 32 satélites em órbitas de 12 horas • Precisão da ordem de centenas de nanossegundos a microssegundos • As antenas devem ter pelo menos uma visão parcial do céu. • Sistemas CDMA: • GPS indireto (as estações base obtêm o tempo a partir do GPS) • Precisão menor do que 10 microsegundos • Receptor pode ser instalado dentro de prédios • Necessita que a área seja servida por rede CDMA

31. Fontes de Informação de Tempo • Relógios baseados em PCs: • Relógio de hardware: • mantém informação do tempo enquanto o computador está desligado • Relógio de software: • Lido usando gettimeofday() no Linux e GetSistemTime()no Windows • Implementado com uma interrupção de alta prioridade gerada por um oscilador de cristal • Precisão determinada pelo período da interrupção, tipicamente 10 ms. • O skew depende das propriedades do oscilador (50PPM), portanto o relógio precisa ser corrigido de forma regular

32. Fontes de Informação de Tempo • Relógios baseados em PCs (cont.): • Registrador TSC (Time StampCounter): • Disponível em processadores Intel (a partir do Pentium) • Incrementado a cada ciclo do processador • Resolução melhor do que 1s • Em sistemas Linux ele é usado para interpolar entre valores fornecidos pelo relógio de software • O skewpode ser tão baixo como 0,1 PPM

33. Sincronização do Tempo • Relógios sincronizados: • NTP – Network Time Protocol • Organizado em redes de sincronização – conjunto hierárquico de servidores de tempo e clientes • Um nível é chamado de estrato (stratum) • Os servidores stratum 1 são sincronizados por padrões de rádio, satélite, ou modem. • Provê serviço preciso e confiável usando servidores redundantes em diferentes caminhos de rede.

34. Sincronização do Tempo • Relógios sincronizados: • NTP – Network Time Protocol(cont.) • Em intervalos determinados, um cliente envia um pedido para cada servidor configurado e obtém uma resposta • Os pedidos e as respostas recebem um carimbo de tempo na partida e na chegada: 4 carimbos. Usa estes carimbos para estimar o offset do relógio e o atraso de ida e volta para cada servidor. • Abordagem geral: limite superior no erro do offset é metade do tempo de ida e volta • Estimativas do offset são filtradas para remover pontos fora da curva. Constrói estimativas da precisão de cada servidor (dispersão) • Organiza a subrede de sincronização em uma árvore de expansão de caminho mais curto.

35. Sincronização do Tempo • Relógios sincronizados: • NTP – Network Time Protocol(cont.) • Precisão: • Stratum 1: faixa de 10s • Stratum 2 na Ethernet: em torno de 1 ms • Stratum 2 na WAN: 10 a 100 ms • O NTP encontra-se atualmente na sua versão 4 [RFCs 5905 a 5908 de Junho 2010]: • Projetado para precisão da ordem de microsegundos.

36. Sincronização do Tempo • Sincronização Tempos medidos após a medição: • Inferência a partir de uma série de medições do deslocamento relativo e do skew relativo dos dois relógios envolvidos.

37. Papel de Diretórios da Internet e Bases de Dados

38. Papel de Diretórios e Base de Dados • Registros de endereços • Registros regionais: ex.: LACNIC • Registros nacionais: ex.: NIC.br • Servidores DNS • Problemas com bancos de dados desatualizados

39. Distribuição de Endereços P: Como um provedor IP consegue um bloco de endereços? R: ICANN: Internet Corporation for Assigned Names and Numbers (www.icann.org.br) • aloca endereços • gerencia DNS • aloca nomes de domínio, resolve disputas Através da IANA (Internet Assigned Numbers Authority)

40. Distribuição de Endereços • LACNIC é a instituição responsável para a América Latina e o Caribe.

41. Distribuição de Endereços IANA = Internet Assigned Numbers Authority Ex.: Nic.br No Brasil, estas funções foram delegadas ao NIC.br (nic.br) pelo Comitê Gestor da Internet BR – www.cgi.br)

42. Registro de Roteamento Internet (IRR) • Criado em 1995 com o objetivo de ajudar na engenharia de endereçamento e roteamento. • Colaboração de diversas organizações de rede • Objetivo: Mapear e verificar a corretude de questões de roteamento interdomínio. • Mapeamento de um AS para uma lista de redes internas ao AS. • Permite que um operador de rede verifique se a informação que está sendo trocada numa sessão BGP está correta.

43. Banco de Dados de Ativos de Roteamento (RADb) • Registro de informações de roteamento onde políticas e anúncios das redes participantes estão presentes para ajudar a resolver problemas relacionados a roteamento. • Pode estar desatualizado pois as redes podem não submeter as suas atualizações prontamente.

44. Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers Base de Dados Hierárquica e Distribuída Cliente quer IP para www.amazon.com; 1aaprox: • Cliente consulta um servidor raiz para encontrar um servidor DNS .com • Cliente consulta servidor DNS .com para obter o servidor DNS para o domínio amazon.com • Cliente consulta servidor DNS do domínio amazon.com para obter endereço IP de www.amazon.com

45. a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) k RIPE London (also Amsterdam, Frankfurt) i Autonomica, Stockholm (plus 3 other locations) m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA DNS: Servidores raiz • procurado por servidor local que não consegue resolver o nome • servidor raiz: • procura servidor oficial se mapeamento desconhecido • obtém tradução • devolve mapeamento ao servidor local 13 servidores de nome raiz em todo o mundo

46. Servidores TLD e Oficiais • Servidores Top-level domain (TLD) : • servidores DNS responsáveis por domínios com, org, net, edu, etc, e todos os domínios de países como br, uk, fr, ca, jp. • Network Solutions mantém servidores para domínio .com • NIC.br (Registro .br) para domínio .br • Servidores oficiais: • servidores DNS das organizações, provendo mapeamentos oficiais entre nomes de hospedeiros e endereços IP para os servidores da organização (e.x., Web e correio). • Podem ser mantidos pelas organizações ou pelo provedor de acesso

47. Servidor de Nomes Local • Não pertence necessariamente à hierarquia • Cada ISP (ISP residencial, companhia, universidade) possui um. • Também chamada do “servidor de nomes default” • Quanto um hospedeiro faz uma consulta DNS, a mesma é enviada para o seu servidor DNS local • Atua como um intermediário, enviando consultas para a hierarquia.

48. Hospedeiro em cis.poly.edu quer endereço IP para gaia.cs.umass.edu consulta interativa: servidor consultado responde com o nome de um servidor de contato “Não conheço este nome, mas pergunte para esse servidor” servidor local dns.poly.edu Exemplo de resolução de nome pelo DNS servidor raiz 2 3 servidor TLD 4 5 6 7 1 8 servidor oficial dns.cs.umass.edu solicitante cis.poly.edu gaia.cs.umass.edu

49. consulta recursiva: transfere a responsabilidade de resolução do nome para o servidor de nomes contatado carga pesada? servidor DNS raiz 2 3 6 7 servidor TLD 4 servidor DNS local dns.poly.edu 5 1 8 servidor DNS oficial dns.cs.umass.edu solicitante cis.poly.edu gaia.cs.umass.edu Exemplo de resolução de nome pelo DNS

50. DNS: uso de cache, atualização de dados • uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cachelocal • entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo) • Servidores TLD tipicamente armazenados no cache dos servidores de nomes locais • Servidores raiz acabam não sendo visitados com muita frequência • estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados • RFCs 2136, 3007, 4033/4/5 • http://www.ietf.org/html.charters/dnsext-charter.html