Cisco Class-Based Header Compression

We now begin our conversation on QoS mechanisms employed in slow link speed situations. Cisco categorizes a link speed of 768kbps as a slow speed link which may need the following link efficiency mechanisms: • Header Compression • Link Fragmentation and Interleaving (LFI) Let’s begin our discussion with header compression. Every voice over IP packet from an IP phone must be packetized for delivery over the IP network. The packetizing consists of an layer 3 IP header (20 bytes), layer 4 UDP header (8 bytes) and a layer 4 RTP header (12 bytes). The IP|UDP|RTP header represents 40 bytes of every Voice over IP transmission. A G.711 audio sample consists of a 160 bytes when the default 20ms (50pps) sampling interval is used. The IP|UDP|RTP headers are added to the G.711 audio sample which results in a 200 byte packet (160 + 40). The resultant header overhead is 20% of the entire packet (40 / 200). I cannot think of an instance where I would recommend a customer run the processor intensive task of header compression when the header information only represents 20% of the entire packet. I would recommend compressing voice to G.729 or iLBC before compressing RTP header information. G.729 compressed voice samples are only 20 bytes in length, while the IP|UDP|RTP header information is static at 40bytes (20ms sample). G.729 based voice over IP phone calls have approximately 67% header overhead. RTP header compression compresses the IP|UDP|RTP headers to 4 bytes by default. UDP checksums are not removed by default. If UDP checksums are turned off, the RTP header compression mechanism can get the RTP header down to 2 bytes of overhead information. Turning UDP checksums can be dangerous and is normally not recommended. We will consider the results of header compression with the expectation that UDP checksums are turned on. 4 bytes out of a total of 24 bytes represents approximately 17% overhead. RTP header compression (cRTP) will save 40% of the total bandwidth (67% - 17%). G.729 with cRTP result in an approximate bandwidth requirement of 10kbps per phone call. Header compression is a processor intensive task and should be used sparingly. When possible, header compression should be offloaded to a dedicated math co-processor (CSA, AIM, VSA). Header compression and IPSEC site to site encryption cannot co-exist in hardware. IPSEC encryption occurs in hardware before compression and the resulting encrypted traffic cannot be compressed. Compression algorithms remove redundancy, while encryption algorithms create random patterns that much match at the opposite end of the tunnel. This discussion of header compression has excluded layer 2 header information because layer 2 header information cannot be compressed in any way. Layer 2 overhead values are as follows: 802.1Q (trunked) Ethernet • 13kbps Point to Point Protocol (PPP) • 4kbps Multi-Link PPP (ML-PPP • 6kbps Frame Relay • 4kbps ATM • 26kbps RTP header compression is turned on in the following example which provides a priority queue (PQ) sized for 10 G.729 phone calls: Policy-map llq-policy Class voice Priority 100 Compression header ip rtp Call Admission Control (CAC) mechanisms do not take cRTP mechanisms into consideration. An H.323 gatekeeper would be configured at 160kbps to accommodate 10 phone calls. Cisco Unified Communications Manager’s locations would be configured at 240kbps to accommodate 10 phone calls. More detail on CAC can be found in my previous blog posts. TCP header compression can also be enabled in individual classes, but it’s only recommended in interactive classes that have very small payloads. Auto QoS will turn header compression on when an interface is configured with a bandwidth parameter of 768kbps or lower. Most serial interfaces default to a bandwidth parameter of 1544kbps regardless of the actual speed of the interface. REFERENCES Global Knowledge – Cisco Quality of Service class Cisco QoS SRND


Copyright © 2009 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022