QoS question

[Ahmede]

We are using LLQ for voice, for low speed links (256k or 512K), is it a good idea to use "compress header ip rtp"?

[vladrac-ccna]

by cisco:

RTP or TCP IP header compression is a mechanism that compresses the IP header in a data packet before the packet is transmitted. Header compression reduces network overhead and speeds up transmission of RTP and TCP packets.

Cisco IOS software provides a related feature called Express RTP/TCP Header Compression. Before this feature was available, if compression of TCP or RTP headers was enabled, compression was performed in the process-switching path. Compression performed in this manner meant that packets traversing interfaces that had TCP or RTP header compression enabled were queued and passed up the process to be switched. This procedure slowed down transmission of the packet, and therefore some users preferred to fast-switch uncompressed TCP and RTP packets.

Now, if TCP or RTP header compression is enabled, it occurs by default in the fast-switched path or the Cisco Express Forwarding-switched (CEF-switched) path, depending on which switching method is enabled on the interface. Furthermore, the number of TCP and RTP header compression connections was increased.

If neither fast-switching nor CEF-switching is enabled, then if TCP or RTP header compression is enabled, it will occur in the process-switched path as before.

The Express RTP and TCP Header Compression feature has the following benefits:

•It reduces network overhead.

•It speeds up transmission of TCP and RTP packets. The faster speed provides a greater benefit on slower links than faster links.

So, why dont you give it a try and let us know?

Vlad

[pkhatri]

Hi,

It's not such a bad idea to use RTP header compression on low-bandwidth links such as the one you have. The use of cRTP will get you:

- more effective throughput across those links

- reduced serialisation delay (the actual compression delay for cRTP is quite small)

Hope that helps - pls rate the post if it does.

Paresh

[Ahmede]

I'll try it and will let you know..

Thanks for your help

[stevep]

You could also enable LFI if you are using a leased line, for frame-relay you would enable FRF.12. I would also recommend tuning your maximum fragment size for 10ms serialization delay for both frame and leased line.

If enabling cRTP on frame-relay you might also want to tune the CIR value to 95% of the pvc size.

i.e. a 256kbps pvc would require a max-fragment delay of 320 bytes and a CIR of 243200bps with a Bc of 2432 bits per Tc.

One final thing, note the CPU load prior/post to enabling cRTP, if it is anywhere near to 75% prior to enabling cRTP I would perhaps be inclined to leave it off.