A Unified Header Compression Framework for Low-Bandwidth Links Jeremy Lilley Jason Yang Hari...
-
Upload
elizabeth-miller -
Category
Documents
-
view
225 -
download
0
Transcript of A Unified Header Compression Framework for Low-Bandwidth Links Jeremy Lilley Jason Yang Hari...
A Unified Header Compression Framework for Low-Bandwidth
Links
Jeremy Lilley • Jason YangHari Balakrishnan • Srinivasan
Seshan
MIT Laboratory for Computer ScienceNetworks and Mobile Systems Group
http://nms.lcs.mit.edu/
Motivation
• Low bandwidth on many wireless links• Protocol headers are often large• Header compression is attractive and
beneficial in many cases• But…
– Many, many protocols in practice- compressing them is where the real gains are– Treating each as a separate problem: tedious!
• Wanted: A general approach!
The Problem:Painful Implementation Path
• Standardization (packet format, RFCs)• Implementation hassles
– Requires detailed knowledge of kernel internals
– Needs understanding of link error characteristics
• Each protocol treated as a new problem• Result: Header-compressed protocols
lag way behind!
Solution:Unified approach to the problem
Source code implementati
on for different platforms
High-level protocol description
Protocol designer writes
Code Generation
Toolkit runs
Goal: to make header compression absurdly simple
Previous Work
• 1984 – Thinwire• 1990 – V.
Jacobson– TCP/IP
• 1996 – Degermark– UDP/TCP/IPv6
• 1999 – Casner– RTP
Contributions
• Unified header compression scheme • High-level description language• Header compression software toolkit• Error-tolerance analysis• Comparison to conventional header
compression
Compression Scheme: An Example
Source IP Address
Destination IP Address
ChecksumProtocolTTL
Length
Flags
HLenVer TOS
ID Fragment Offset
Constant Inferrable Delta Random
Unified Compression Scheme
• Goal: To send original packets with minimal amount of bandwidth
• Reference packets– Send complete header
• Compressed packets (common case)– Send only changes
Base StationMobile Host
Internet
Reference Packets
• Fields sent unchanged– Initializes decompressor state– Keeps state synchronized
• Contexts– Want to allow many packet streams
concurrently– Provide different “contexts” for them– Context ID to identify the stream
Compressed Headers
• Only delta and random fields sent• Send only non-zero delta values
– Encoded in change bit-vector
• Field ordering must be consistent
0 0 0 0 1 0 1 0 Payload
Delta flags RandomDelta values
Corresponding flagand delta values
Context ID
Specification Language
• Set of header fields– Size in bits– Compression category (CONSTANT,
INFERRED, DELTA, RANDOM)– Category-specific parameters: inference formula, encoding method…
PField sourceIP, fsize=32, ptype=CONSTANT;PField length, fsize=16, ptype=INFERRED, formula=[framelength];
Rules and Actions
• Rules can:– Bypass routines altogetherPRule SendAsIP, ruletext=[protover]!=4;
– Force a reference packet to be sentPRule SendReference,
ruletext=[curTime]<{expireTime};
• Actions can keep state, write logs {expiretime}=[curTime]
+5*[tickspersecond]
Complete Sample Description
class IPcompressor {NiceName IP_Compression_Protocol;Compressed_ID 0x0081;UnCompressed_ID 0x0083;
PField protover, fsize=4, ptype=NOCHANGE;PField hdrlen, fsize=4, ptype=NOCHANGE; PField tos, fsize=8, ptype=NOCHANGE;PField totlen, fsize=16, ptype=INFERRED, formula=[length];PField packetid, fsize=16, ptype=DELTA, encoding=VARONETHREE, negatives=DISALLOWED;PField fragments, fsize=16, ptype=NOCHANGE;PField ttl, fsize=8, ptype=NOCHANGE;PField protocol, fsize=8, ptype=NOCHANGE;PField checksum, fsize= 16, ptype=RANDOM;PField sourceIP, fsize=32, ptype=NOCHANGE;PField destIP, fsize=32, ptype=NOCHANGE;
PRule SendAsIP, ruletext=[protover]!=4; # want IP version 4}
class IPcompressor {NiceName IP_Compression_Protocol;Compressed_ID 0x0081;UnCompressed_ID 0x0083;
PField protover, fsize=4, ptype=NOCHANGE;PField hdrlen, fsize=4, ptype=NOCHANGE; PField tos, fsize=8, ptype=NOCHANGE;PField totlen, fsize=16, ptype=INFERRED, formula=[length];PField packetid, fsize=16, ptype=DELTA, encoding=VARONETHREE, negatives=DISALLOWED;PField fragments, fsize=16, ptype=NOCHANGE;PField ttl, fsize=8, ptype=NOCHANGE;PField protocol, fsize=8, ptype=NOCHANGE;PField checksum, fsize= 16, ptype=RANDOM;PField sourceIP, fsize=32, ptype=NOCHANGE;PField destIP, fsize=32, ptype=NOCHANGE;
PRule SendAsIP, ruletext=[protover]!=4; # want IP version 4}
Errors
• Errors desynchronize compressor and decompressor– State changes missing, corrupted– As errors increase, header compression can
be a losing proposition
• Need to keep synchronized, preferably with implicit semantics/in-band signaling
Base StationMobile Host
Internet
Impact of Link Errors TCP/IP over a 28.8 kbps link
0
1
2
3
4
5
6
7
1.0E-08 1.0E-07 1.0E-06 1.0E-05 1.0E-04
Bit Error Rate
Thro
ughp
ut R
atio
0-byte
1-byte
10-byte
100-byte
1460-byte
Break-even at 1.0
Errors Decrease Effectiveness
Error handling
• Subject of ongoing research, we implement basic techniques– Connection-oriented protocols: implicit
signaling– Connectionless protocols: periodic refresh
• TCP effectiveness analysis in paper• Flexible framework enables other
techniques to be incorporated
Compression Comparisons
Generated TCP/IP vs. VJ TCP/IP,based on original packet length
0
0.2
0.4
0.6
0.8
1
Bulk ACKs Interactive
Traffic Type
Com
pres
sion
Rat
io
TCP/IPSemanticsVJ TCP/IP
Compression vs. SpecificityHow much does extra information help?
0
0.2
0.4
0.6
0.8
1
Bulk ACKs Interactive
Traffic Type
Com
pres
sion
Rat
io
Naïve IP
IP Semantics
TCP/IP Semantics
Low-overhead ImplementationCPU time for compressing outgoing packet
0
5
10
15
20
25
Bulk ACKs Interactive
Traff ic Type
Mic
rose
cond
s
Naïve IP
IP Semantics
TCP/IP Semantics
VJ TCP
Further Directions
• String protocol compression– E.g., HTTP transfers
• Advanced error recovery• Handling IPSec
All <250k
<50k <10k
6.3%
9.3% 11.1% 19.3%
Fraction of transfer as http header