Entendendo a compressão (incluindo cRTP) e a Qualidade de Serviço

Introduction

Este documento analisa problemas comuns com a habilitação dos recursos do software Cisco IOS® de compressão e Qualidade de Serviço (QoS) no mesmo roteador.

O software Cisco IOS oferece muitos recursos que otimizam os links de rede de longa distância (WAN) para facilitar o gargalo da largura de banda da WAN. A compactação é um método de otimização eficaz e inclui dois tipos:

• Compactação de dados - Fornece a cada extremidade um esquema de codificação que permite que os caracteres sejam removidos dos quadros no lado de envio do link e os substitua corretamente no lado de recebimento. Como os quadros condensados ocupam menos largura de banda, maiores números podem ser transmitidos por unidade de tempo. Exemplos de esquemas de compactação de dados incluem STAC, Microsoft Point-to-Point Compression (MPPC) e Frame Relay Forum 9 (FRF.9).

• Compactação de cabeçalho - Compacta um cabeçalho em várias camadas do modelo de referência OSI (Open System Interconnection). Os exemplos incluem a compressão de cabeçalho TCP (Transmission Control Protocol), RTP comprimido (cRTP) e Protocolo Internet/Protocolo de Datagrama de Usuário (IP/UDP) compactado.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Visão geral sobre compactação de dados

A função básica da compactação de dados é reduzir o tamanho de um quadro de dados transmitido por um link de rede. A redução do tamanho do quadro reduz o tempo necessário para transmitir o quadro através da rede.

Os dois algoritmos de compactação de dados mais comumente usados em dispositivos de internetworking são o Stacker e o Predictor.

As seguintes configurações de exemplo mostram duas maneiras de ativar a compactação de payload em uma interface ou subinterface do Frame Relay.

interface Serial0/5
  ip address 10.0.0.1 255.255.255.0
  no ip directed-broadcast
  encapsulation frame-relay IETF
  clockrate 1300000
  frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac

interface Serial0/0.105 point-to-point
  ip address 192.168.162.1 255.255.255.0
  no ip directed-broadcast
  frame-relay interface-dlci 105 IETF
  class 128k
  frame-relay payload-compression FRF9 stac

Hardware de compressão da Cisco

A compactação de dados assistida por hardware alcança a mesma funcionalidade geral da compactação de dados baseada em software, mas acelera as taxas de compactação descarregando isso computacionalmente da CPU principal. Em outras palavras:

• Compactação de software - A compactação é implementada no software Cisco IOS instalado no processador principal do roteador.

• Compactação de hardware - A compactação é implementada no hardware de compactação instalado em um slot do sistema. A compactação de hardware remove as responsabilidades de compactação e descompactação do processador principal instalado no roteador.

  A tabela a seguir lista o hardware de compactação da Cisco e as plataformas suportadas:

Configurar a compactação em uma interface serial com um comando como compress stac ativa automaticamente a compactação de hardware, se disponível. Caso contrário, a compactação de software é ativada. Você pode usar o comando compress stac software para forçar o uso da compactação de software.

Fancy queueing e compressão de hardware

Esta seção discute um problema resolvido com o recurso Cisco Legacy Priority Queueing (PQ) e o hardware de compactação. O hardware de compactação originalmente retirou os pacotes de forma agressiva dos PQs, removendo efetivamente os benefícios do PQ. Em outras palavras, o PQ funcionou corretamente, mas o enfileiramento funcionalmente foi movido para as próprias filas de hardware de compactação (holdq, hw ring e compQ), que são estritamente FIFO (first-in, first-out, primeiro a entrar, primeiro a sair). Os sintomas desse problema estão documentados no bug da Cisco ID CSCdp33759 (marcado como uma duplicata de CSCdm91180).

A resolução modifica o driver do hardware de compactação. Especificamente, ele limita a taxa na qual o hardware de compactação retira pacotes, reduzindo o tamanho das filas de hardware com base na largura de banda da interface. Esse mecanismo de pressão traseira garante que os pacotes permaneçam nas filas extravagantes em vez de serem mantidos nas filas do hardware de compactação. Consulte os seguintes IDs de bug para obter mais informações:

Observação: mais informações sobre esses IDs de bug podem ser encontradas usando o Bug Toolkit (somente clientes registrados) .

• CSCdm91180 - Aplica-se ao encapsulamento Frame Relay e ao Adaptador de Serviço de Compressão (CSA - Compression Service Adapter).

• CSCdp33759 (e CSCdr18251) - Aplica-se ao encapsulamento PPP e ao CSA.

• CSCdr18251 - Aplica-se ao encapsulamento PPP e à compressão do módulo de interface assíncrona (AIM-COMPR).

As filas de nível de hardware da compactação Cisco 3660 podem ser vistas na seguinte saída de exemplo do comando show pas caim stats. Se as filas de compactação de hardware estiverem armazenando muitos pacotes, um pacote removido da fila do PQ espera na extremidade posterior dessa fila e, portanto, sofre atraso.

Router> show pas caim stats 0

CompressionAim0
   ds:0x80F56A44 idb:0x80F50DB8
       422074 uncomp paks in  -->      422076 comp paks out
       422071 comp paks in    -->      422075 uncomp paks out
    633912308 uncomp bytes in -->    22791798 comp bytes out
     27433911 comp bytes in   -->   633911762 uncomp bytes out
          974 uncomp paks/sec in -->      974 comp paks/sec out
          974 comp paks/sec in -->        974 uncomp paks/sec out
     11739116 uncomp bits/sec in -->   422070 comp bits/sec out
       508035 comp bits/sec in -->   11739106 uncomp bits/sec out
   433 seconds since last clear
   holdq: 0  hw_enable: 1  src_limited: 0  num cnxts: 4
   no data: 0  drops: 0  nobuffers: 0 enc adj errs: 0 fallbacks: 0
   no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151
   Bad reqs: 0  Dead cnxts: 0 No Paks: 0 enq errs: 0
   rx pkt drops: 0  tx pkt drops: 0 >dequeues: 0 requeues: 0
   drops disabled: 0 clears: 0 ints: 844314 purges: 0
   no cnxts: 0  bad algos: 0 no crams: 0 bad paks: 0
   # opens: 0 # closes: 0 # hangs: 0

Observação: o CSCdr86700 remove as alterações implementadas no CSCdm91180 de plataformas que não suportam um CSA.

Além disso, ao solucionar esse problema, os problemas de expansão de pacotes com pacotes pequenos (cerca de 4 bytes) e padrões particulares repetitivos, como pings da Cisco com um padrão de 0xABCDABCD, foram resolvidos com o bug ID CSCdm11401. Pacotes pequenos têm menos probabilidade de serem relacionados a outros pacotes no fluxo e tentar compactá-los pode resultar em pacotes expandidos ou causar redefinições de dicionário. A causa raiz é um problema com o chip usado no CSA. O bug da Cisco ID CSCdp64837 resolve esse problema alterando o código de compactação FRF.9 para evitar a compactação de pacotes com menos de 60 bytes de payload.

Enfileiramento simulado e compactação de software

Em contraste com a compactação de hardware, a compactação de software e o enfileiramento sofisticado, incluindo enfileiramento moderado personalizado, prioritário e ponderado, não são suportados em interfaces configuradas com encapsulamento PPP. Essa limitação está documentada nos IDs de bug CSCdj45401 e CSCdk86833.

A razão para a limitação é que a compactação PPP não é stateless e mantém um histórico de compactação no fluxo de dados para otimizar as taxas de compactação. Os pacotes compactados devem ser mantidos para manter o histórico de compactação. Se os pacotes forem compactados antes do enfileiramento, eles deverão ser colocados em uma única fila. Colocá-los em filas diferentes, como o enfileiramento personalizado e prioritário fazem, pode levar a que os pacotes cheguem fora da sequência, o que quebra a compressão. As soluções alternativas não são ótimas e não foram implementadas. Essas alternativas incluem a compactação de pacotes à medida que eles são removidos da fila (inaceitável por motivos de desempenho), a manutenção de um histórico de compactação separado para cada fila (sem suporte e envolvendo uma sobrecarga significativa) e a redefinição do histórico de compactação para cada pacote (afeta substancialmente as taxas de compactação). Como solução alternativa, você pode configurar o encapsulamento HDLC (controle de enlace de dados de alto nível), mas essa configuração pode afetar o desempenho do sistema e não é recomendada. Em vez disso, use a compactação de hardware.

Compressão de cabeçalho de RTP e QoS

O RFC 1889 especifica o RTP, que gerencia o transporte do caminho de áudio para Voz sobre IP (VoIP). O RTP fornece serviços como sequenciamento para identificar pacotes perdidos e valores de 32 bits para identificar e distinguir entre vários remetentes em um fluxo multicast. O importante é que ele não fornece nem garante QoS.

Os pacotes VoIP são compostos por um ou mais exemplos de codec de fala ou quadros encapsulados em 40 bytes de cabeçalhos IP/UDP/RTP. 40 bytes é uma quantidade relativamente grande de sobrecarga para os payloads VoIP típicos de 20 bytes, particularmente sobre links de baixa velocidade. RFC 2508 especifica RTP compactado (cRTP), que é projetado para reduzir os cabeçalhos IP/UDP/RTP para dois bytes para a maioria dos pacotes no caso em que nenhuma soma de verificação UDP está sendo enviada ou quatro bytes com somas de verificação. O algoritmo de compactação definido neste documento baseia-se muito no design da compactação do cabeçalho TCP/IP como descrito em RFC 1144 .

O RFC 2508 especifica na verdade dois formatos de cRTP:

• RTP compactado (CR) - Usado quando os cabeçalhos IP, UDP e RTP permanecem consistentes. Todos os três cabeçalhos estão compactados.

• UDP compactado (CU) - Usado quando há uma grande alteração no timestamp do RTP ou quando o tipo de payload do RTP é alterado. Os cabeçalhos IP e UDP são compactados, mas o cabeçalho RTP não é.

O software Cisco IOS versão 12.1(5)T introduziu várias melhorias para a compactação sobre PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) do Frame Relay nos Cisco 2600, 3600 e 7200 Series Routers. Essas melhorias incluem:

Problemas conhecidos

A tabela a seguir lista problemas conhecidos com os recursos de QoS do cRTP e do Cisco IOS. Essa lista é precisa no momento da publicação. Consulte também as Release Notes da sua versão do software Cisco IOS para obter mais informações.

policy-map test-policer
  class class-default
    police 10000 1500 1500 conform-action
transmit exceed-action transmit
    service-policy inner-police
!
policy-map inner-police
  class prec5
    police 20000 1500 1500 conform-action
transmit exceed-action transmit

Informações Relacionadas

• página de suporte de QoS
• Suporte Técnico - Cisco Systems