© 2002 – RNP GT-QoS RNP2 José Augusto Suruagy Monteiro Leobino Sampaio Mércia E. B. Figueredo Setembro de 2002 © 2002 – RNP

© 2002 – RNP

GT-QoSRNP2

José Augusto Suruagy MonteiroLeobino SampaioMércia E. B. Figueredo

Setembro de 2002

© 2002 – RNP

GT-QoS: Workshop de Redes Avançadas – IMPA, 25 de Setembro de 2002

Roteiro

• Objetivos do GT-QoS

• Proposta de Trabalho

• Qualidade de Serviço– Arquiteturas de Serviços

• Melhor Esforço

• Serviços Integrados

• Serviços Diferenciados

– Implementações em Redes Acadêmicas– Propostas de Projetos Piloto

• Infra-estrutura de Medições– Métricas de Interesse– Projetos relacionados– Propostas de Projetos Piloto

GT-QoS


Objetivos

Definição/detalhamento de uma Arquitetura de Serviços com Diferenciação de QoS para a RNP2

Implementação de uma Infra-estrutura de Medições com a finalidade de monitorar a QoS que está sendo oferecida para as diversas classes de serviços

GT-QoS


Proposta de Trabalho

Formação do GT:

• base: coordenadores de projetos relacionados

Articulação com os Projetos de Redes Avançadas:

• atividades/objetivos comuns

• necessidades de QoS: definição de uma arquitetura mínima de serviços

GT-QoS


Projetos de Redes Avançadas Relacionados:

Projeto IQoM (UNIFACS, UFPR, UFSC, UFRGS e CPqD): prevê a definição de métricas, implantação de uma infra-estrutura de medições (ativas e passivas) e implementação de serviços diferenciados.

· Projeto InfraVIDA (UFPE, UFRN, UFBA, UNIFACS e Real Hospital Português): infra-estrutura de suporte a telemedicina, envolve também a transmissão de vídeo fazendo uso de serviços diferenciados no backbone da RNP2.

· Projeto MAPPED (UFRJ, UFF, UFMG e CEDERJ): Desenvolvimento e incorporação de novas técnicas de adaptação fim-a-fim para dar maior eficiência e flexibilidade às aplicações multimídia aplicada ao ensino à distância.



Projetos de Redes Avançadas Relacionados:

Projeto QoSWare (UFPE, UFMG e Telemar): Middleware para gerenciamento de QoS para suporte a aplicações interativas (jogos, simulação interativa distribuída, aplicações de voz, aplicações de vídeo e realidade virtual compartilhada)

· Projeto QUARESMA (UFRJ, UNICAMP, UFF, LIP6 e Netcenter): QUAlidade de Serviço em Redes – Segurança, Mobilidade e Aplicações. Aborda diversos aspectos relacionados a QoS, desde a caracterização de tráfego até a incorporação de QoS nas aplicações, passando também por corretores de banda na plataforma CORBA.


© 2002 – RNP

Qualidade de Serviço


Conceito Básico

• Recomendação E.800: Efeito coletivo do desempenho do serviço e que determina o grau de satisfação do usuário deste serviço.

• Novidade das redes integradas e mais recentemente da Internet: oferecimento de serviços que atendam os diferentes requisitos de QoS das aplicações.

• Quantitativamente, a QoS para uma dada aplicação pode ser expressa através de um conjunto de parâmetros mensuráveis tais como retardo máximo, variação máxima do retardo, percentual máximo de perdas, etc.



Necessidades das Aplicações – Pesquisa SEQUIN


QoS service One-way-delay ipdv packet loss bandwidth Best effort wide wide medium wide Very good ( Premium IP )

medium very small very small according to

SLA Prioritised Bandwidth (IP+)

medium medium medium according to

SLA Guaranteed bandwidth

medium medium very small single value

One-way-delay IPDV Packet loss bandwidth

Best effort Unspecified Unspecified < 5% Unspecified

Premium IP distance delay

+ 50 ms < 25 ms negligible

according to SLA

IP+ distance delay

+100 ms <25-50 ms < 2%

according to SLA


Tipos Principais

• Melhor Esforço (Best Effort)

• Serviços Integrados (IntServ)

• Serviços Diferenciados (DiffServ)

Arquiteturas de Serviços


Serviços Integrados

• Arquitetura de serviços idealizada para disponibilizar funções de reserva de banda fim-a-fim para aplicações de tempo real.

• Tipos de Serviço:

• Serviço Garantido: Este serviço foi concebido para aplicações de tempo real. Para isso o retardo é controlado e o tráfego condicionado por um token bucket.

• Serviço de carga controlada: Este serviço foi criado para aplicações elásticas e está próximo do serviço melhor esforço quando em leve sobrecarga. É garantida a entrega de pacotes (baixa perda) e o retardo não irá exceder o máximo retardo suportado pela aplicação.




• RSVP (Reservation Protocol): Protocolo de sinalização para reserva de recursos.




• Limitações:

– Não escalável

– Alta exigência nos roteadores.



Serviços Diferenciados

• Arquitetura de serviços baseada no controle de QoS para fluxos agregados que são identificados através do DSCP (Differentiated Service Code Point):


DSCP NãoEspec.

0 1 2 3 4 5 6 7

- Byte TOS IPV4- Byte Classe de Tráfego IPV6



• Comportamento por salto (PHB):

– Descrição do tratamento de encaminhamento que cada pacote recebe em cada nó.

– O Valor do DSCP é utilizado para selecionar o PHB

– Os roteadores devem possuir funções de programação/gerenciamento de filas para priorização de pacotes e controle do tamanho das filas.

– O roteador de um domínio DiffServ deve ser capaz de oferecer o PHB para cada classe de serviço.

• Comportamento por domínio (PDB):

– O tratamento que um grupo de pacotes marcado receberá, a partir do nó de entrada até o nó de saída (borda-a-borda) em um domínio.



Tipos de Serviços

• Encaminhamento Assegurado (AF):– O serviço AF é composto por várias sub-classes de serviço, que possuem

diferentes níveis de precedência em relação ao descarte de pacotes. É indicado para as aplicações que não são sensíveis ao atraso, mas não suportam perda.

• Encaminhamento Expresso (EF): – O encaminhamento expresso oferece um serviço de redes com baixa perda,

pequeno atraso, baixo jitter e banda garantida. É indicado para aplicações de tempo real.




• Maior escalabilidade

• Número limitado de classes de serviços

• Menor exigência nos roteadores.



Alternativas de Serviços

• Nobres (Elevated)

• Premium (QPS e SEQUIN)

• Olympic

• Best Effort

• Plebeus (Non-Elevated)

• Scavenger (QBSS)

• Alternative Best Effort (ABE)

• Best-Effort Differentiated Service (BEDS)



Implementações em Redes Acadêmicas

• QBone Premium Service (QPS)

• Projeto SEQUIN

• Projeto Piloto de QoS IP da RNP

• QBone Scavenger Service (QBSS)

• Proposta de Projetos Piloto do GT-QoS



QBone Premium Service (QPS)

• Definido pelo QoS-WG da Internet2 (http://qbone.internet2.edu/premium/)

• A sua implantação encontra-se suspensa indefinidamente.

• Motivos principais:

• falta de suporte dos roteadores,

• custo de atualização dos equipamentos em cada rede (cada domínio QPS deve efetuar policiamento em cada porta de entrada),

• ausência de demanda por parte das aplicações,

• preocupações com o custo e complexidade operacionais.



Projeto SEQUIN

• Objetivo:

• Implantação de um serviço Premium IP extensível e flexível sobre a rede GÉANT, baseado nas tecnologias de QoS disponíveis .

• Oferecer um serviço fim-a-fim, modular, escalável, operando entre múltiplos domínios de gerenciamento.

• Um Serviço independente das tecnologias de rede existentes

• O Serviço implementado não deve interferir com outros serviços existentes.

• Conformidade com o padrão IETF.



Projeto SEQUIN

• Decisões principais:

• O Serviço Premium deve ter uma adição mínima de processamento por nó, a fim de se que tenha uma implementação abrangente com o hardware existente.

• O Serviço será implementado passo a passo. Na primeira fase (durante o projeto) foi implantado um pequeno domínio DiffServ.

• Somente uma fração de cada link foi destinada ao serviço Premium (entre 5 a 10%), como forma de garantir que os outros serviços não fossem prejudicados.

• Inicialmente (na primeira fase), a configuração é estática e nenhum protocolo de sinalização foi utilizado.



Projeto SEQUIN

• Decisões principais:

• Uma especificação de interface entre domínios é obrigatória para se manter o comportamento por domínio de acordo com o EF PHB. Ex: a interface pode conter valores de DSCP, regras de policiamento e todos os parâmetros necessários para assegurar a correta propagação do serviço.

• O serviço tem destino especificado (destination aware): é obrigatório o conhecimento da origem e destino (no nó de ingresso) na fase inicial do serviço.



Projeto SEQUIN

• SLA (Service Level Agreements) composto de duas partes:– Administrativa– Especificação do Nível de Serviço (SLS):

• Especifica o grupo de parâmetros que definem o serviço oferecido.



Projeto SEQUIN

• Parte Administrativa (alguns campos):

– Contatos Técnico e Administrativo envolvidos (Escopo)

– Duração (Escopo)

– Garantias de disponibilidade (Escopo, Processo, Solução)

– Monitoração (Escopo, Processo):

• Parte SLS:

– Escopo

– Descrição do fluxo :

• Atributo da marca de QoS: O valor do DSCP

• Atributo da origem: Um valor único que representa a NREN X.

• Atributo do destino: Um conjunto de valores que representa as NRENS destino.

– Garantias de desempenho



Fonte:SEQUIN Deliverable D2.1

Projeto SEQUIN



Projeto SEQUIN

• Corrente de SLAs:



Projeto SEQUIN

• Funcionalidade dos roteadores fim-a-fim:


Fonte: QoS and SLA aspects across multiple management domains: The SEQUIN approach


Projeto SEQUIN

• Topologia de testes para o serviço Premium:


Fonte: QoS and SLA aspects across multiple management domains: The SEQUIN approach


Projeto SEQUIN

• Resultados:

• Tiveram êxito na realização do serviço na rede de produção

• Resultados demonstraram que é possível a implementação do serviço em maior escala

• Os testes continuarão a ser feitos de forma a se evoluir o sistema de provisão do serviço.



Projeto Piloto de QoS da RNP

• Serviços

Serviço Premium (Virtual Leased Line)

Serviço Assegurado

Serviço Best Effort




• Mecanismos testados:

– O mecanismo de fila LLQ (Low Latency Queueing)

– Sua implementação se vale de uma fila com prioridade para o serviço Premium e filas usando a política CBWFQ (Class-based Weighted Fair Queueing) para as demais classes;

– É obrigatório alocar um mínimo de 25% da banda para a classe Best Effort;

– A Cisco recomenda o uso de, no máximo, 5 classes de tráfego.




• Utilização de geradores de tráfego

• Os parâmetros de desempenho avaliados nos testes objetivos foram: perda, atraso e jitter;

• As ferramentas escolhidas: MGEN/DREC, TANGRAM II e o RUDE/CRUDE.




• Usando o serviço Premium:

• Geração de 4 Mbits/seg entre RS/SP com e sem QoS;

• Geração de 2,2 Mbits/seg entre

• http://corcovado.ceo.rnp.br/Testes_QoS/




• Problemas com IOS:

• Alguns reloads, fora deste padrão, também foram registrados;

• Devido ao fato dos testes estarem atrapalhando o serviço de produção, estes foram suspensos.

• Problemas com sincronização:

• NTP não fornece precisão suficiente para esta medida;




• Resultados:

• Apesar da interrupção dos testes, foi possível verificar a priorização de serviço para os tráfegos gerados ao se habilitar as políticas de QoS;

• Redução acentuada da perda e redução de jitter.



QBone Scavenger Service (QBSS)

• Definido pelo QoS-WG da Internet2 (http://qbone.internet2.edu/qbss/)

• Objetivo: – O descongestionamento do serviço BE, principalmente nos "gargalos" da

rede.

• Indicação :– aplicações que suportem bem, perdas, atraso, variação de atraso:

• Aplicações para transferência de grandes volumes de dados com TCP ou aplicações “TCP-friendly”.

• Novas aplicações distribuídas destinadas a usar banda subutilizada da rede.




Funcionamento geral:

• É uma classe adicional ao serviço BE, com baixa probabilidade de atendimento e pouca banda alocada.

• Funciona como uma rede virtual paralela com baixos recursos, mas que podem ser aumentados à medida que a classe default (BE) é subutilizada.

• O DSCP padrão para o tráfego QBSS é o 001000 (QBSS codepoint)

Política de marcação dos pacotes:

– O usuário deve indicar que aplicações devem ser marcadas para o serviço.– A marcação dos pacotes pode ser feita pela aplicação ou no roteador de

borda mais próximo do host origem.




Patches disponibilizados pelo Qbone:

• wu-ftpd-qbss.diff :

Altera o servidor de FTP wuftpd-2.6.1, para marcar pacotes com o QBSS codepoint quando o usuário usa o serviço como anonymous.

• apache-qbss.diff:

O servidor WEB apache_1.3.20 também marca os pacotes com o QBSS codepoint, só que é possível configurar a partir de que tamanho de arquivo o serviço marca os pacotes.



Propostas de Projetos Piloto

• Levantamento da Demanda por QoS:– Projetos de redes avançadas– Questionário.

• Definição de uma arquitetura de QoS para a RNP– Quais serviços atendem melhor a demanda por QoS (Premium, Scavenger,

etc.)?– Dimensionar o serviço:

• Capacidade dos links a ser reservada, 5%?

– Descobrir uma solução para SLA :• CiscoWorks2000 Service Management Solution ?

• Retomada dos testes no backbone da RNP com Serviços Diferenciados.• Pilotos com os Serviços escolhidos• Medições específicas para avaliar o benefício e o impacto da

implementação destes serviços

GT-QoS

© 2002 – RNP

Infra-Estrutura de Medições


Roteiro

• Motivação

• Objetivos

• Métricas de Interesse

• Tipos de medições

• Projetos de medições

• Projetos relacionados

• Propostas de projetos piloto do GT-Qos



Motivação

• Necessidade de monitorar o tráfego para checar se os objetivos de QoS estão sendo atendidos.

• Falta de um diagnóstico rico e preciso sobre informações específicas do tráfego e sua tendência.

• Necessidade de visualização permanente das características do tráfego.

• Necessidade de visualização dos fluxos de tráfegos entre os diversos POPs da rede.



Objetivos

• Avaliar os recursos oferecidos pelas ferramentas existentes no mercado, levando em consideração o tipos de medição e as métricas de desempenho.

• Desenvolver um ambiente de coleta, acompanhamento e apresentação de resultados sobre as características da rede.

• Obter um ambiente que permita uma análise mais precisa da rede para definir a prioridade dos serviços.

• Responder às seguintes questões:

– Qual é a composição do tráfego?

– O que priorizar?

– Quais são as origens e destinos do tráfego?



Métricas de Interesse

• Largura de banda

• Atraso

• Jitter

• Perda de pacotes

• Utilização

• Caracterização do tráfego



Tipos de Medições

• Ativas – São gerados pacotes de teste e monitorado o desempenho para os mesmos através da rede.

• Problemas: falta de sincronização dos relógios e tráfego extra na rede.

• Ideais para medições de Jitter, atraso, perda e latência.

• Passivas – são coletadas informações sobre todos os pacotes que trafegam na rede sem fazer nenhuma interferência.

• Requer maior investimento na infra-estrutura de equipamentos.

• Ideais para medições de caracterização de tráfego, utilização.



Projetos de Medições

• Caida (Cooperative Association for Internet Data Analysis)– http://www.caida.org

• Surveyor http://www.advanced.org/surveyor/

• IEPM (Internet end-to-end performance monitoring)– http://www-iepm.slac.stanford.edu/

• RIPE (Réseaux IP Européens)– http://www.ripe.net/test-traffic/index.html

• NLANR (MOAT)– http://moat.nlanr.net/

• E2Epi (End-to-End Performance Initiative) – http://e2epi.internet2.edu



Projetos Relacionados

• IQoM (Redes Avançadas)

• LAND/UFRJ

• GT-VOIP

• Experiência da RNP



Projeto IQoM

• Levantamento de um conjunto de equipamentos e ferramentas que visam coletar dados sobre as métricas de interesse relacionadas à QoS das aplicações.

• Manter um estrutura permanente de coleta e visualização das medidas.

• Implantação de um piloto de infra-estrutura de medições (passiva e ativa) a ser posteriormente ampliado para todos os demais pontos de interesse.



Ferramentas do LAND

• Objetivos– Desenvolver modelos para permitir a análise de mecanismos e algoritmos.– Medições e testes.

• Tangram II

• Viva Voz

• Whiteboard distribuído

• Servidor Multimídia RIO



GT-VOIP

• Piloto VOIP– Telefonia IP sobre a RNP2

• Fases do Piloto– Fase 0

• Medições fim-a-fim sobre estrutura existente

– Fase 1• Implantação de gateways e operação da telefonia IP

– Fase 2• Implantação de gatekeepers, criação de diretórios de usuários, ampliação do uso

peer-to-peer



Experiência da RNP

As estatísticas atuais são baseadas no MRTG




• Num primeiro momento, os esforços serão direcionados para a caracterização do tráfego.

• Determinar:

– Quanto do tráfego está sendo destinado para cada serviço;

– A origem e destino de um tráfego;

– Maior diagnóstico da rede.

GT-QoS



• Utilização do Netflow/NetraMet/Flow-tools

• Experimentos iniciais no PoP-BA (UFBa) e UNIFACS

• Exemplos de resultados:

• http://netflow.internet2.edu

GT-QoS


Referências

http://qbone.internet2.edu/premium

http://www.caida.org

http://www.internet2.edu/e2epi/

http://www.cisco.com/warp/public/732/Tech/netflow/

http://www.nlanr.net

http://www.advanced.org/surveyor/

http://watt.nlanr.net/

http://www.ietf.org/html.charters/ippm-charter.html

Documents

© 2002 – RNP GT-QoS RNP2 José Augusto Suruagy Monteiro Leobino Sampaio Mércia E. B. Figueredo Setembro de 2002 © 2002 – RNP