Exploiting Packet Header Redundancy for Zero Cost Dissemination of Dynamic Resource Information

1
Exploiting Packet Header Redundancy forZero Cost
Dissemination of Dynamic Resource Information

• Peter A. Dinda
• Prescience Lab
• Department of Computer Science
• Northwestern University
• http//www.cs.northwestern.edu/pdinda

2
Overview

• Piggyback information on outgoing packets
• Encode information into redundant or unused TCP,
  IP, and Ethernet fields
• Result Disseminate information with no
  additional packets or increased packet size
• Identified gt86 bits per packet
• Proof-of-concept 17 bits per packet

3
Outline

• Disseminating dynamic resource info
• Theoretical redundancy
• Mechanisms for exploiting redundancy
• Prospects
• Proof-of-concept
• Using the mechanisms
• Conclusion and future work

4
Disseminating Dynamic Resource Information
Consumer
Sensor
Consumer
Consumer
5
Current Model
App
App
Sensor
Consumer
Transport
Transport
Network
Network
Data Link
Data Link
Physical
Physical
Sensor is just another application
6
Problems With Current Model

• Bandwidth consumption
• Can be reduced via adaptive techniques
• Different available BW to different consumers
• Additional packets injected into network
• Consumers must know to ask for data

But packets already flow through the network!
7
Proposed Model
App
App
Sensor
Consumer
Transport
Transport
Network
Network
Header Editing
Data Extraction
Data Link
Data Link
Physical
Physical
Sensor data piggybacked on application packets
8
Header Editing
Sensor Data
Data
TCP
IP
Ethernet
Padding
Overwrite unused or redundant fields with sensor
data
How much redundancy is there and how do we
exploit it?
9
Packet Traces

• NLANR Passive Measurement Network
• All packets at points of presence
• 28 90 second traces
• 4 sites (U. Buffalo, Columbia, Colorado State, U.
  Memphis)
• Late September, 2001
• 68,000 to 3 million packets per trace

10
How Much Redundancy Is There?

• Headers as a sequence of 1 byte symbols
• Shannon entropy
• Number of bits needed per symbol
• Does not capture correlation
• Mutual information
• Bits per byte assuming one-step correlations

Evaluate the theoretical limits to redundancy
11
Redundancy in IP Headers

• Shannon entropy 4.8 bits per byte
• 40 redundant
• 8 extra bytes per header
• Mutual information 1.2 bits per byte
• 85 redundant
• 17 extra bytes per header

Considerable redundancy is available
How does this redundancy manifest in practical
ways?
12
Practical Mechanisms TCP Header
destination port
source port
sequence number
acknowledgement number
flags
hlen
reserved
window size
checksum
urgent pointer
options
Mechanism Bits
Reserved bits 6
Ack field when ACK0 32
Urgent field when URG0 16
NOP option padding varies
Total gt54
13
Prospects TCP Header
destination port
source port
sequence number
acknowledgement number
flags
hlen
reserved
window size
checksum
urgent pointer
options
Mechanism Bits
Reserved bits 6
Ack field when ACK0 32
Urgent field when URG0 16
NOP option padding varies
Total gt54
Always Zero!
Untested
Untested
Options rare
14
Practical Mechanisms IP Header
vers
hlen
TOS
length
identifier
fragment offset
flags
TTL
protocol
checksum
source address
destination address
options
Mechanism Bits
Reserved TOS bits 2
Reserved IP flag 1
Identifier when DF1 16
Fragment offset when DF1 13
NOP option padding varies
Total gt32
15
Prospects IP Header
vers
hlen
TOS
length
identifier
fragment offset
flags
TTL
protocol
checksum
source address
destination address
options
Mechanism Bits
Reserved TOS bits 2
Reserved IP flag 1
Identifier when DF1 16
Fragment offset when DF1 13
NOP option padding varies
Total gt32
95 Zero
Always zero
90 DF1
90 DF1
Options rare
16
Practical Mechanisms Ethernet Padding
Data
TCP
IP
Ethernet
Padding
Ethernet frames data must be at least 46 bytes
long
TCPIPkeystroke 20201 41 bytes
TCP ACK 2020 40 bytes
Prospects Untested
17
Proof-of-concept

• Evaluate IP Header approaches
• Random bit source for data
• Minet user-level stack
• 20 lines of header-editing/data extraction code
• 200 lines of ancillary code (output)
• Study interaction with Linux stack (2.2 kernel)
  and Cisco router

18
Proof-of-concept results
Mechanism Bits Minet to Linux Minet to Router to Minet Minet to Router to Linux Demon-strated bits
Reserved TOS bits 2 OK FAILS OK 0
Reserved IP flag 1 OK OK OK 1
Identifier when DF1 16 OK OK OK 16
Fragment offset when DF1 13 FAILS FAILS FAILS 0
NOP option padding varies untested untested untested 0
Total gt32 17
IP Header can transport 17 extra bits 90 of the
time
What should we use them for?
19
Using the Bits

• 1 sample per packet
• Host load 1.4-15 bits per sample
• Network bandwidth / latency ?
• Sample resolution can be varied
• Timestamps
• Easy for TCP packets use RTT estimate

20
Using the Bits

• Using this channel to transport streams
• Unreliable like IP
• Also cant choose where/when data is sent
• Only goes to friendly hosts
• Or have to wait until someone sends a packet to
  the machine you are targeting
• What are appropriate coding approaches?

21
Diffusion
Random Drop
App
Sensor
Consumer
Transport
Network
Header Editing
Data Extraction
Data Link
Physical
Information diffuses out from a sensor to
friendly hosts
22
Conclusions and Future Work

• Introduced concept of exploiting packet header
  redundancy for zero cost information
  dissemination
• Intentionally extreme approach
• Identified mechanisms and prospects
• Demonstrated proof-of-concept
• Future work Linux kernel implementation

23
For MoreInformation

• Peter Dinda
• http//www.cs.northwestern.edu/pdinda
• Minet
• http//www.cs.northwestern.edu/pdinda/minet/
• Prescience Lab
• http//www.cs.northwestern.edu/plab