Performance Studies of TCP/IPv6 Header Compression Over Point-to-Point Link

Chandan Verma Department of Computer Science and Engineering Indian School of Mines, Dhanbad (Deemed University) Govt. of India E-Mail: [email protected] Mobile: 09334097718

Anshu Gupta Department of Computer Science and Engineering Indian School of Mines, Dhanbad (Deemed University) Govt. of India E-Mail: [email protected] Mobile: 09835341345

ABSTRACT TCP/IP protocol suite is the basis of transmission mechanism of today’s Internet technologies. IP provides the best effort delivery service and TCP provides the reliability to the services offered by IP [1]. Due to significant redundancy in header fields, both within the same packet header and in between consecutive packets belonging to the same packet stream, header compression of a TCP/IP protocol plays an imperative role. Header compression algorithms thus exploit protocol inter-packet header field redundancies to improve overall efficiency. In any network, higher link utilization, lower transport delay and higher reliable transport are desirable [1-3]. In Internet, these are believed to be achieved with TCP/IP packet overhead reduction [4-8]. The research elsewhere reported that compression mechanism even reduces the 60 bytes header (40B of IPv6 and 20B of TCP) to about 5 bytes. Reducing this overhead will increase user throughput and/or the number of users a network can support. Thus the issue of compression needs qualitative and quantitative investigation in particular reference to performance in terms of overhead percentage, processing delay, transfer delay, probability of error in packet etc. A rigorous quantitative performance studies has been done earlier. In the present work we report results of a study based on simulated model. In our work, compression is done on point-to-point basis. Performance analysis carried out in the paper gives an overview of the effect of compression on Probability of error, overhead bits per packet, compression/decompression time that varies with the number of packets sent and the Line Efficiency variation with the size of MTU.

I. INTRODUCTION In TCP/IP Protocol architecture, at sender side, data comes from Application Layer to the TCP Layer and then goes to the IP Layer. At each layer, a header is added to the data. A header is the portion of TCP/IP packet that precedes the actual data. It contains source and destination addresses, error checking, and other information for routing and delivery of data. With header compression technique, we can compress the header of TCP/IP packet. The compression technique given here is loss less compression. Ideally, any header compression scheme will avoid sending redundant data, while protecting the protocol from extra errors caused by maintaining state over a potentially loss-prone link. In doing this, the predictable properties of the underlying protocol need to be identified and exploited. The general principle of header compression is to occasionally send a packet with a full header; subsequent compressed headers, refer to the context established by the full header and may contain incremental changes to the context. For example, VJ TCP header compression identifies enough redundancy in TCP/IPv4 to compress 40-byte headers to as few as three bytes, including a two-byte checksum. As far as any generalized compression scheme is concerned, the efficiency will vary depending on the predictability of the protocol header and how well this predictability can be captured in a specification. Since many useful categorizations for fields have been identified from previous work in header compression, we have chosen to use similar terminology and style. The basic idea is to identify each field in the protocol, which may be located at any bit offset and length in the frame, and then to associate various attributes with the field. While different schemes have been introduced for classifying fields, we found it convenient to use a derivative of some of

the fields used by Degermark. In particular, there are four main types of fields in any IP header. These are constant, delta, inferable, and random. Version

Traffic Class

Flow Label

Payload Length

Next Header

Hop Limit

Source address:

Destination address:

Source Port

Destination Port Sequence Number Acknowledgment Number

H Length

Reserved

U A P RS F R C US Y I G K S T NN

Checksum

Window

Urgent Pointer

Fig. 1 Constant Fields: VER, Traffic Class, Flow Label, Next Header, Hop Limit, Source and Destination IPv6 Address, Source and Destination port. Inferred Field: Payload Length. Delta Fields: Sequence and Acknowledgement No, Window Size. Random Fields: UCK and PUS flags, Checksum, Urgent Pointer.

In the mechanism used to compress the packet we have eliminated all the constant fields except the version field. This is because without the version field the decompressor at the receiver side will not be able to distinguish between compressed and uncompressed packets.

The basic idea behind compression technique used is: •

Do not re-transmit fully static fields, e.g. address fields

•

Transmit dynamic fields, e.g. checksum field

•

For slowly varying fields, e.g. in sequence number transmit only the difference from last known value.

Packet flow in Forward direction

Compressed Packets

Compression

Decompression Feedback

Context

Context

Fig 2

The process of header compression uses the concept of flow context, which is the collection of information about field values and change patterns of field values in the packet header. This context is found on the compressor and the decompressor side of each packet flow. The first packet of a newly identified flow is used to build the context on both sides. This packet is sent without compression. Once the context is established on both sides the compressor compresses the packet as much as possible. When a packet cannot be decompressed correctly, the decompressor will assume the reason is that one or more previous packets are lost. Thus, subsequent packets received by the decompressor may also be dropped even though they are transmitted correctly. This is called as error propagation, which means the packet dropping is caused by errors in previous packets instead of this packet itself. Only a small fraction of time and in case of error recovery, uncompressed packet are sent for synchronization, to reconstruct the context and then revert back to normal operational mode of sending compressed packet .In this paper we are compressing TCP/IPv6 Packet Headers with the proposed technique.

Continuously discarding packet on the forward path, due to error propagation, results in ACK’s not being sent. Similarly, error propagation on the reverse path will prevent the TCP sender from receiving the ACK’s. In the TCP sender, ACK’s are used to indicate network conditions. The sender will even transmit packet at a lower speed if the gap between the ACK’s is too big. This will have two side results:1. The efficiency of compression gets lower or perhaps even more bits need to be sent compared to transmitting without compression. 2. The correct information is received later, may be even later than the transmission without compression. Fig 2 shows the process diagrammatically. II. EXPERIMENTAL METHODOLOGY AND ASSUMPTIONS The compressed packet format is shown in Fig 3. Each packet stream is associated with a small 8 bit context identifier (CID) together with 6 bytes that change, the Decompressor will be able to calculate and fill the other fields. The following figure3 shows the format of a compressed TCP/IPv6 packet.

Fig. 3

The 0th byte is taken as a mask vector to let the decompressor know that which field value have to change and by what amount. There are six flag bits used for this purpose. C: If C bit is set this means the packet is containing the Connection number. Otherwise it is cleared. In our experiment we are considering that each packet will always contain the CID, so C bit will always be kept as 1. P: This flag is used for enabling the push flag of TCP header. In our experiment, we are keeping this bit always cleared. S: This flag is set if we are sending the delta value of sequence number. Otherwise it is cleared. In our experiment we are keeping this bit always 1. A: Flag A is used to validate or invalidate the Acknowledgement field. If it is set then only we can send the delta value of change in ACK field with previous packet. In our experiment we are considering only half duplex communication, so this flag is always cleared. W: As it is already mentioned that the communication we are considering is half duplex, we don’t have to send the available window size. So, in our experiment it is always kept clear. U: This field is used for enabling and disabling the delta value urgent data field. If it is one, the changed value is sent otherwise this field is omitted from the compressed header. The metrics that we have used for the performance study are: 1. Probability of Error 2. Compression Time: - It is the average time taken to compress one packet. 3. Decompression Time: - It is the average time taken to decompress one packet. 4. Average Overhead: - It is number of extra bytes sent per packet. 5. Line Efficiency

Some of these parameters have been evaluated under two conditions: a) When the payload size is kept fixed in each packet. b) When the payload is of variable length in each packet. III. EXPERIMENTAL RESULTS (A) EFFECT OF COMPRESSION ON ERROR: The probability of error depends upon the number of bits in packet and bit error rate of the link. Let

denotes the bit error rate (BER).

Probability of no bit in a packet is in error P1 =(1- )

-----(1)

Probability that no Byte in a packet is in error P8= (1- ) 8

----- (2)

For an uncompressed packet of N1 Bytes Header… Probability of error in the packet header is… Puc=1-(1-P8) N1

----- (3)

The size of a TCP/IPv6 packet header is 60B. So the probability of error in packet header is Ppack=1-(1-P8)60

----- (4)

For a compressed packet of N2 Bytes Header… Probability of error in the packet header is… Pc=1-(1-P8) N2

----- (5)

As we are considering the size of a compressed packet header is 5 B. The probability of error in the packet header will become Pc=1-(1-P8)5

Table 1 shows a comparative study between the compressed and uncompressed packet header error probability for different values of BER. Prob Of Err When Compressed 0 0.000016 0.028365414 0.36192115 0.790702127 0.961429066 0.99607101 0.999846412 0.9999994

ERROR PROBABILITY 1.1 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

P ro b a b ilit y

BER 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Prob Of Err Without Compression 0.059923016 0.399218997 0.743131653 0.918793323 0.980620743 0.996727492 0.999671993 0.9999872 0.99999995

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Bit Error Rate

Prob Of Err Without Compression Prob Of Err With Compression

Table 1

Fig 4

Since N1> N2, from equation 3 and 5, it is clear that Puc > Pc That is the probability of error in a packet decreases due to compression. Fig 4 above supports the conclusion. (B) COMPRESSION AND DECOMPRESSION TIME The following Table (2) and Fig 5 show the Average Time required for compression and decompression for the variable number of packets with fixed packet length.

Results for fixed length packets:

Results for variable length packets:

No. of

Compression

Decompression

Avg Overhead

Packets

Time(ns)

Time(ns)

(Bytes)

500

6.218825

20.043688

5.62

1000

1.5031017

11.009409

5.56

1500

1.068045

6.270847

5.54

2000

0.8004004

4.702726

5.53

2500 3000 3500 4000 4500 5000 5500

0.6002402 1.0335001 0.45727354 0.37509382 0.7111901 0.320124 0.2727769

4.4017606 3.1343782 2.6580331 2.3506875 2.0671263 2.180376 1.7094597

5.52 5.52 5.517 5.515 5.513 5.512 5.510

6000

0.26675278

1.8169278

5.51

6500

0.24622722

1.4309918

5.509

7000

0.44288778

1.3430817

5.508

7500

0.20005512

1.4668338

5.508

8000

0.40002498

1.1626452

5.507

8500

0.1765135

1.2942477

5.507

9000

0.17781605

1.2112272

5.506

9500

0.32633352

0.9895779

5.506

10000

0.160016

0.94010895

5.506

Table 2

No. Of Packets

Compression Time(ns)

Decompression Time(ns)

Avg Overhead (Bytes)

500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500 7000 7500 8000

25.043674 3.1110063 3.070846 3.900775 1.8812482 2.0673559 1.3431185 0.37538767 1.0447507 1.2404361 1.7093488 1.0500861 1.6924543 1.1143489 1.053472 0.97502506

31.268938 9.414012 6.272937 7.052351 4.362001 3.6678896 3.1151757 2.3506877 2.4450617 2.8206882 2.2731407 1.8169695 2.1541421 1.7859062 1.6668605 1.3751704

5.62 5.56 5.54 5.53 5.524 5.52 5.517 5.515 5.513 5.512 5.510 5.51 5.509 5.508 5.508 5.507

Table 3 With Variable Payload

With Fixed Payload

Average Overhead(B) 5.64 5.62 5.58 5.56 5.54 5.52 5.5 5.48 5.46 5.44

500 1000 1500 2000 2500300035004000 4500500055006000 6500700075008000 85009000950010000

Number of packets Sent

A v e ra g e T im e T a k e n /P a c k e t

5.6

Decompression Time(ns)

5.64 5.62 5.6 5.58 5.56 5.54 5.52

10 9 8 7 6 5 4 3 2 1 0

5.5 5.48 5.46 5.44 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500 7000 7500 8000

Number of Packets Sent

Fig 5

Average Overhead(Bytes)

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11

Fig 6

A v g N um be r o f B y te s /P a c k e t

Decompression(ns)

22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

A v g O H b y t e s /p k t

A v g T im e T a k e n /P k t

Compression(ns)

Compression Time(ns)

The following Table 3 and Fig 6 show the Average Time required for compression and decompression for the variable number of packets with variable payload. From the results shown above it is found that: i)

As number of packets per session increase, the average processing time (that is a part of overall delay) as well the % overhead decrease. This is in complete harmony with previous studies and due to fact that with increasingly number of packets as more and more header fields are reduced, the effect of compression increases.

ii)

The average processing time in case of variable length packet is higher than that of the fixed length packet for any session with same number of packets. This is due to the fact that the receiver and the transmitter have to do additional processing for estimation of variable bytes for payload in case of variable length packets.

iii)

From the given sample results, it is found that for packet size (payload) of 38 and 9 bytes, the overheads per packet on average are respectively 5.62 (with compression gain of 90.55%)and 5.56 (with compression gain of 90.73%) bytes. This ensures the better effect of compression with packets with higher payload.

(B) LINK EFFICIENCY AND MTU Header compression is motivated by the need of good interactive response i.e. .the line efficiency which is the ratio of the data to header + data in the datagram of a protocol .For reasonable line efficiency the bulk data packet size needs to be 10 to 20 time the header size i.e. Maximum Packet size (MTU). MTU is a crucial link-level configuration parameter. Table 4 and Fig 7 illustrate the results obtained.

Line Efficiency (uncompressed)%

Line Efficiency (compressed)%

64

6.25

91.4

128

53.125

95.7

256

76.56

97.85

512

88.28

98.9

1024

94.14

99.4

2048

97.07

99.73

LINE EFFICIENCY vs MTU

100 LIN E EFFICIEN C Y

MTU

80 60 40 20 0

64

128

256

512

1024

2048

LE(uncompressed)%MTU LE(compressed)%

Table 4

Fig 7

As shown in Fig 7, efficiency is sensitive to small changes in MTU and good efficiency comes at the expense of good response. After the knee point in the performance curve (which is around a MTU of 512), the efficiency is relatively independent of speed or MTU. IV CONCLUSION & FUTURE RESEARCH We have reported results of performance studies of TCP/IPv6 header Compression based on simulated work. Our results show the benefits of Header Compression in terms of overhead percentage and processing delay. It shows that the effect of compression is higher as number of packets per session increases and as payload is more. We intend to carry out further work with different links with different capacities to make it more practical one. Although the application of header compression in commercial use is rare, many 3rd Generation Projects have specified the Header compression algorithms in Protocol Development. REFERENCES [1]

[2] [3] [4] [5] [6] [7] [8]

C T Bhunia, Information Technology, Network and Internet, New Age International Publishers, New Delhi, 2005J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68–73. C T Bhunia, CSIC, Computer Society of India, Mumbai, Emre Ertekin et al, Internet Protocol Header Compression, Robust Header Compression, and Their Applicabilty in the Global Information Grid, IEEE Com Mag, Vol 42, No 11, Nov’2004, pp 106-116 EFENET LAB, An Introduction to IP header compression, www.EFNET.COM Degermark et al, FRC 2507 IP Header Compression, http://www.chscene.ch/ccc/rfc/rfc2500/rfc2507 Ching Shen Tye et al, A Review of IP Packet Compression Technique, ISBN:1-9025-6009-4@2003 PGNet Nimrod Arbel et al, IP Header compression for satellite (First Report), http://www.opalsoft.net/qos/VoIP.htm C Bormann et al, Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed, RFC 3095, 2001.Caida, Packet Length Distribution, 4 Aug’2004, http://www.caida.org/analysis/AIX/plen_hist/