TCP/IP Header

Compression for
Satellite Environment

Ittay Eyal
Dmitry Batenkov
Itai Ravid
Vladislav Zolotarov
Doris Fischer
Part I
Satellite Environment

Dmitry Batenkov
Vladislav Zolotarov
 Topology (5 stations case)

Server Client

Satellite
Compressor Channel Decompressor
Simulator
Topology (3 stations case)

Server Client

Compressor SATSIM Decompressor

 Compression station

Compression
module

Compression
thread

From Receiving Sending To

Server module module SatSim
 Decompression station
Decompression
module

Receiving Decompression Sending

module thread module

SatSim Client

Sending Forwarding thread Receiving

module module
 Satellite channel simulator
(5 stations case)

Compressor SATSIM
Receiving Module
Sending
module module
Decompressor

Server Sending Forwarding thread Receiving

module module
 Satellite channel simulator
(3 stations case)

Compression Decompression
module module
SATSIM Module
Receiving Sending
Server module module Client

Sending Forwarding thread Receiving

module module
 Sending module
Access synchronization

SendPacket()

Sending thread

APC callback
Recycling
WinDis
NDIS Adapter
 Receiving module
Access synchronization

GetNextPacket()

Receiving thread
Posting
initial reads

Posting
additional
WinDis reads
NDIS Adapter
APC callback
Sending Decompression Due time
module module arrived? TS

Second thread
TS

SATSIM

Synchronizaton
Delay = 0 TS

TS
Main thread
TS

Receiving Compression TS
module module BER
Part II
TCP/IP Header Compression

Ittay Eyal
Doris Fischer
Itai Ravid
TCP/IP Header Compression
Protocol for compressing the TCP/IP header
part of the packet
Based on RFC1144 created by Van Jacobson
in 1990, during his research work at Cisco Ltd.
Compression can get up to 1/8 the size of the
original header (from 40 bytes into 5 bytes)
Originally meant to speed up Low-Speed Serial
Links
TCP/IP Header Compression – Cont.
In TCP/IP packet the header size is 40 bytes
Though in low speed connections the
overhead of an error in the header part of the
packet takes a high percentage of the
communication
In some modern technology (like satellite
communication) we find this overhead, crucial
because of the long delay time while crossing
the atmosphere
 Protocol Main Ideas
High percentage of the packet header stay
constant during a connection
Therefore if we knew what were the fields in
the previous packet header, we can omit fields
that stay constant in the current packet header
We can decrease size of fields that change in a
small amount by passing only the difference in
the fields content (difference relative to the
previous packet header)
 Protocol Details
V. Jacobson suggests we keep an
uncompressed copy of the previous packet
header, on each side of the connection
That way we will update its changed fields
each time we get a packet
A full packet header will be passed only in the
first packet of a connection (passing also
constant fields of the header) or after an error
Afterwards we will pass only the changed fields
in the packet header
Protocol Details – Cont.
Since not all the fields change in the same
time, we will pass a bit mask field in each
beginning of a compressed packet
The bit mask field will indicate which fields
have changed from the previous packet
header
The bit mask will have a constant order,
though only the 1’s bits will indicate a
changed field
Protocol Details – Cont.
In V. Jacobson suggestion he indicates
the packet compression kind:
 TYPE_IP - header content wasn’t touched
 UNCOMPRESSED_TCP – if the connection
number is stamped into the header (in the
IPPROTO_TCP field), but the content of the
other fields didn’t change
 COMPRESSED_TCP – the packet header is
fully compressed
Protocol Details – Cont.
According to the packet type the
decompressing computer can determine how
it should handle the packet
Decompression is done easily because we
know what was the previous packet header
content
The reversed process is done in order to
decompress the packet headers
Protocol Details – Cont.
The changed fields (in which we send the
difference values) are added to the previous
packet header stored in the decompression
computer
Checksum is recalculated according to the
updated fields content
Assurance of the protocol
Fields content is always recoverable,
because in all times we know what content
was in the previous packet
We can calculate the current full packet
header, in each new packet that arrives
Lost packets (during the communication
process) are recovered using the regular
TCP/IP protocol. Regardless to the
compression process
Benefit of Header Compression
Header benefit of compressed packet
(without noise)
Compression benefit (%)

0.04

0.03

0.02 Poly.

0.01

0
13906 44544 489971 6726428 3.5E+07 8.7E+07
File size (Bytes)
Benefit of Header Compression

Header benefit of compressed packet (with noise)

0.4
Compression benefit (%)

0.3
0.2
0.1
0
-0.1 13906 44544 38965 489971
-0.2
-0.3
-0.4
-0.5
File size (Bytes)