DiffServ

Este artigo não cita fontes confiáveis. Ajude a inserir referências. Conteúdo não verificável pode ser removido.—Encontre fontes: ABW  • CAPES  • Google (N • L • A) (Fevereiro de 2013)

Este artigo resulta, no todo ou em parte, de uma tradução do artigo «Differentiated_services» na Wikipédia em inglês, na versão original. Você pode incluir conceitos culturais lusófonos de fontes em português com referências e inseri-las corretamente no texto ou no rodapé. Também pode continuar traduzindo ou colaborar em outras traduções. (Data da tradução: 16 de dezembro de 2004) —Encontre fontes: ABW  • CAPES  • Google (N • L • A)

DiffServ ou serviços diferenciados é um método utilizado na tentativa de conseguir qualidade de serviço em grandes redes, como a Internet.

O método DiffServ opera sobre grandes volumes de dados em oposição a fluxos ou reservas individuais. Isto implica uma negociação para todos os pacotes de, por exemplo, um ISP ou uma universidade. Os acordos resultantes destas negociações são designados de "acordos de nível de serviço" (Service Level Agreements), e envolvem geralmente um valor por parte das operadoras de telecomunicações. Estes acordos especificam que classes de tráfego serão servidas, que garantias são necessárias para cada classe, e qual o volume de dados para cada classe.

Uma "nuvem DiffServ" é um grupo de routers DiffServ. Para os pacotes entrarem numa nuvem DiffServ terão que ser previamente classificados pelo emissor. O emissor preenche o campo de "tipo de serviço" (TOS, de Type of Service, posteriormente designado de DiffServ Code Point ou DSCP) no cabeçalho IP consoante a classe dos dados; as melhores classes são identificadas com os números menores (a escala varia de 0 a 15, contudo deve-se evitar o uso do 0).

Assim que o pacote entra na nuvem DiffServ, as políticas são aplicadas pelo receptor. Se o tráfego ultrapassar o estabelecido no service level agreement, podem ser cobradas taxas ao emissor, consoante os detalhes do contrato. Dentro da nuvem, basta a cada um dos routers dar prioridade máxima aos pacotes com o menor valor no campo Type Of Service, o que é simples de implementar. Pode estabelecer-se também uma política que descarte (drop) os pacotes com base na frequência de drop caso o router se encontre sem espaço no buffer.

Existem muitas formas de dividir o tráfego em classes, cada uma provavelmente adaptada às necessidades especiais da situação. Por exemplo, o tráfego pode ser dividido nas classes Ouro, Prata e Bronze. Em cada router, o tráfego de Ouro tem precedência sobre o de Prata, que por sua vez tem precedência sobre o de Bronze.

O tratamento especial pode ser elaborado em duas maneiras:

• reencaminhamento preferencial, onde os pacotes mais recentes de maior precedência podem ultrapassar (na lista de espera) os de menor precedência;
• descarte preferencial, onde o espaço do buffer para os pacotes de maior precedência está habilitado a aumentar sob prejuízo dos pacotes de menor precedência, que serão descartados.

Existem também outros esquemas híbridos, envolvendo combinações destas e outras estratégias de Qualidade de Serviço.

Exemplo: Dar prioridade a dados específicos em redes de comunicação.

• Tipicamente, isto é conseguido pelo router que liga uma rede local à Internet. O router decide, por exemplo, dar máxima prioridade ao tráfego interativo como shells remotas ou jogos online, para reduzir a latência. O outro tráfego, como HTTP ou correio eletrônico é classificado com uma prioridade menor, enquanto que o tráfego típico de transferências de ficheiros, como FTP ou redes peer-to-peer é classificado como o de menor prioridade.
• A decisão sobre qual o tráfego que deverá ser classificado como prioritário depende geralmente das necessidades em relação à rede. Outra abordagem para decidir qual o tráfego importante é utilizando o campo TOS/DiffServ no cabeçalho Protocolo IP.

Uma vantagem do DiffServ é que a imposição da política (e classificação dos pacotes) é realizada nos limites da nuvem DiffServ. Isto significa que, no núcleo da Internet, os routers operam normalmente, sem a preocupação das complexidades de contabilização dos pagamentos e imposição dos acordos..

A classificação do tráfego é necessária especialmente onde existam estrangulamentos. Na decisão sobre como classificar o tráfego pode surgir a pergunta "Quem tem uma ligação gigabit WAN (ADSL, modem) ou gigabit wireless?" — certamente, não muitos. O protocolo TCP/IP irá usar toda a largura de banda disponível até se verificarem perdas de pacotes ou latência exagerada — mas não tem a noção do delicado tráfego interactivo! Isto é uma consequência da especificação do TCP, e é um protocolo bem sucedido. No entanto, são os protocolos interactivos os mais penalizados. Aqui ficam algumas implementações práticas de políticas de tráfego:

• lartc.org: The Wonder ShaperComentário: Traffic shaping é utilizado com classes de largura de banda garantida e classificação de tráfego (um bom candidato ao DiffServ).

Citação: "…

Resultados

Antes, sem wondershaper, durante um upload:

round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

Depois, com wondershaper, durante um upload limitado a 220kbit/s [traffic shaped]:

round-trip min/avg/max = 15.7/51.8/79.9 ms

Objectivos

Tentativa utópica:

• Manter latência reduzida para tráfego interactivo em qualquer circunstância;

Isto implica que durante downloads e uploads o tráfego SSH ou telnet não seja afectado. Estes são requisitos fundamentais, já que com uma latência de uns meros 200ms se torna difícil de trabalhar.

• Possibilitar a navegação na web a velocidades aceitáveis durante downloads e uploads.

Ainda que o HTTP seja também tráfego interactivo, o tráfego anterior não irá afectar este, dadas as suas características de baixo volume.

• Garantir que os uploads não interferem com os downloads, e vice-versa.

Este é um fenómeno muito corrente, em que o tráfego upstream destrói, pura e simplesmente, a velocidade de download.

Na prática, tudo isto é possível, com um minúsculo acréscimo no consumo de largura de banda...."

• ADSL Bandwidth Management HOWTOCitação: "…Se se iniciar um upload por FTP suficiente grande para saturar a largura de banda, apenas deverá verificar-se um ligeiro aumento na latência para o gateway (na outra extremidade da ligação DSL), comparado ao que seria esperado sem prioritização de tráfego…"
• cbq.init
• descrição: activa o controlo de tráfego baseado em CBQCitação: "…Primeiro que tudo - este é apenas um SIMPLES EXEMPLO das potencialidades do CBQ…" (outro bom candidato para o modelo DiffServ).

Uma desvantagem é a dos detalhes da maneira de operar de cada router em relação ao campo TOS — um pouco arbitrária —, o que torna difícil de prever o comportamento sob a perspectiva ponto-a-ponto. Este facto pode ser agravado se um pacote atravessar duas ou mais nuvens DiffServ para atingir o destino.

Do ponto de vista comercial esta é uma falha grave, já que implica a impossibilidade de vender diferente classes de ligação ponto-a-ponto para o utilizador final, dado que um pacote classificado como de Ouro por um ISP por ser classificado como de Bronze por outro. Os operadores de Internet poderiam resolver esta situação estabelecendo políticas standard entre redes, mas não parecem muito interessados em aumentar a complexidade aos seus já complexos acordos. Segue-se um dos motivos porque tal não se verifica.

A maior desvantagem do DiffServ é que, ao seu mais alto nível, pode ser considerada como uma solução técnica para um problema técnico que não existe.

Uma vez que o DiffServ é um mecanismo simples de decisão sobre que pacotes atrasar ou descartar (sob prejuízo de outrem) numa situação de capacidade de rede insuficiente, considere-se que para o DiffServ descartar (seletivamente) os pacotes, o tráfego na ligação em questão já estará num estado próximo de saturação. Os aumentos subsequentes no tráfego resultarão numa quebra dos serviços Bronze (o menos privilegiado). Dadas as características do tráfego Internet, muito inconstante, esta situação tende a verificar-se regularmente se o tráfego na ligação se encontrar perto do limite em que o DiffServ se torna necessário.

Por esta razão, muitos pensam que o DiffServ será sempre inferior a aumentar a capacidade da rede a fim de evitar perda de pacotes em todas as classes de tráfego.

Em 2003, estava já instalado um excesso de capacidade (fibra) na maioria dos mercados de telecomunicações, já que é notavelmente mais simples e barato adicioná-la, do que empregar políticas DiffServ elaboradas com a finalidade de aumentar a satisfação do cliente. De facto, este é o comportamento normal no núcleo da Internet, que é geralmente rápido e ignorante com "grandes canais" entre routers.

• IntServ
• Qualidade de serviço
• Traffic shaping

• Portal das tecnologias de informação