Cisconinja’s Blog

TCP Header Compression

Posted by Andy on January 27, 2009

This post will take a look at an example of configuring TCP header compression.  TCP header compression can be used to compress the IP and TCP headers (40 bytes combined) typically down to between 3-5 bytes.  The  topology for the example is shown below:

tcphc-topology

For testing purposes, we will be starting a telnet session and an HTTP download between the 2 routers.  Therefore, we will configure separate MQC classes to match each type of traffic and enable class-based TCP header compression on each of them.  TCP header compression configuration is required on each end of the link.  R1 will also be configured as an HTTP server.  The configuration for this is shown below:

R1:
class-map match-all HTTP
 match protocol http
class-map match-all Telnet
 match protocol telnet
!
policy-map test
 class HTTP
  compress header ip tcp
 class Telnet
  compress header ip tcp
!
interface Serial0/0
 ip address 10.1.12.1 255.255.255.0
 load-interval 30
 service-policy output test
!
ip http server
ip http path flash:

R2:
class-map match-all HTTP
 match protocol http
class-map match-all Telnet
 match protocol telnet
!
policy-map test
 class HTTP
  compress header ip tcp
 class Telnet
  compress header ip tcp
!
interface Serial0/0
 ip address 10.1.12.2 255.255.255.0
 load-interval 30
 service-policy output test

A large file (test.txt) has been placed in R1’s flash for R2 to download.  Now we will start the HTTP download and telnet session:


R1#telnet 10.1.12.2
R2#copy http://10.1.12.1/test.txt null:
 

 

The results with TCP header compression enabled are shown below:

tcphc-r1-pmap3

The efficiency improvement factor is a measure of bytes that would have been sent divided by bytes actually sent.  For each of the classes, this works out to:

HTTP:   (16,397 + 484,998) / 484,998   = 1.03

Telnet:  (5,837 + 2,935) / 2,935   = 2.98

which matches the output shown above.  The reason HTTP is much less efficient is due to it’s much larger packet sizes.  The average packet size for each class in this example is:

HTTP:   (16,397 + 484,998) / 477   = 1051 bytes

Telnet:  (5,837 + 2,935) / 192   = 45 bytes

The IP and TCP headers make up only a small portion of the total HTTP packet, while they make up nearly the entire telnet packet.  In most cases, it probably would not be worthwhile to enable TCP header compression for HTTP traffic.

 

Now let’s look at what would happen if we tried to enable TCP header compression on a link between 2 live routers as TCP traffic was being sent across the link.  First we will remove TCP header compression from both classes on both routers:

R1:
policy-map test
 class HTTP
  no compress header ip tcp
 class Telnet
  no compress header ip tcp

R2:
policy-map test
 class HTTP
  no compress header ip tcp
 class Telnet
  no compress header ip tcp

On R2, we will start an HTTP download from R1 again.  On R1, we will telnet to R2 and enable TCP header compression on both MQC classes on R2:

R2#copy http://10.1.12.1/test.txt null:

R1#telnet 10.1.12.2
Trying 10.1.12.2 ... Open
R2#conf t
 policy-map test
  class HTTP
   compress header ip tcp
  class Telnet
   compress header ip tcp

At this point, the HTTP download has stopped and R2 displays the following error message:

tcphc-r2-error

Meanwhile on R1, R2 no longer responds to the telnet session and we are unable to undo the configuration.  The reason for this is that R2 begins immediately sending compressed headers once the compress header ip tcp is entered, and R1 does not know how to interpret them if it does not have a similar configuration.  We could exit out of the telnet session and configure R1 similarly at this point, but traffic still has been temporarily disrupted and our HTTP download has to be completely restarted.  Another option is to first configure R2 with passive TCP header compression, and then configure R1 for TCP header compression.  Passive TCP header compression only compresses outgoing headers if the incoming headers from that destination are compressed.  Unfortunately, this is only supported at the interface level, so it cannot be used on a subset of TCP traffic like class-based TCP header compression can.  To test this out we will first remove the class-based TCP header compression policy from each router interface:

R1:
interface Serial0/0
 no service-policy output test

R2:
interface Serial0/0
 no service-policy output test

On R2, we will start an HTTP download from R1 again.  On R1, we will telnet to R2 and enable passive TCP header compression:

R2#copy http://10.1.12.1/test.txt null:

R1#telnet 10.1.12.2
Trying 10.1.12.2 ... Open
R2#conf t
 interface Serial0/0
  ip tcp header-compression passive

Now we close the telnet session and configure TCP header compression on R1:

R1:
interface Serial0/0
 ip tcp header-compression

R1 and R2 both begin using TCP header compression at this point, and no traffic was disrupted in between.  The TCP header compression statistics on R1 are shown below:

tcphc-r1-shtcphc

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: