Experimental evaluation of TCP-L

1
Experimental evaluation of TCP-L

• June 5, 2003
• Stefan Alfredsson
• Karlstad University

2
Outline

• Motivation
• TCP-L
• Experiment environment
• Experiment results
• Future work

3
Motivation (I)

• We want to improve the performance of TCP over
  unreliable wireless networks
• Unreliability is due to the nature of radio
  communication (i.e. fading, interference, path
  loss), and causes bit errors
• Bit errors are reduced with modulation, coding,
  link level retransmissions
• TCP was designed for wired links, so losses due
  to bit errors are interpreted as sign of
  congestion, leading to bad performance

4
Van Jacobson's Congestion Control

• "Packets get lost for two reasons they are
  damaged in transit, or the network is congested
  and somewhere on the path there was insufficient
  buffer capacity. On most network paths, loss due
  to damage is rare (ltlt 1) so it is probable that
  a packet loss is due to congestion in the
  network."
• Jacobson88, Congestion Avoidance and Control

5
Motivation (II)

• Idea from the PRTP protocol Some applications do
  not need full reliability, and may tolerate
  errors to an extent
• Make use of damaged data instead of doing
  retransmissions
• Improves performance by avoiding falsely
  triggered congestion control
• Improve spectral efficiency by avoiding
  retransmissions of mostly identical data
• Receiver will accept and acknowledge data as if
  it was received correctly

6
TCP-L (I)

• Receiver-only modification of TCP to accept
  segments with bit errors
• Application knows if it can accept errors, and
  informs the TCP-L stack accordingly
• Experiments have been performed which show large
  gains in throughput performance compared to
  regular TCP

7
TCP-L (II) - recovery overview
8
TCP-L (III)

• TCP checksum is used to detect errors, but
  location is unknown (hdr vs payload)
• By examining the TCP header and making some
  assumptions, the sensitive part is narrowed from
  20 byte to 4
• After header recovery, data is delivered to
  application which then has to deal with potential
  errors in the datastream

9
(No Transcript)
10
Improving the recovery

• "Soft information" means feedback from link layer
  about decoding process
• Use soft info to get a hint of where errors are
  located, how severe they are
• How hard should we try to recover?
• Can give a hint of how badly a packet is damaged
  appl could then set levels of acceptable damage

11
Experiment Environment

• sender ltgt gateway ltgt receiver
• Gateway emulates last hop of wireless link
• Limits bandwidth, increases delay
• Creates errors in packets

12
Error Creation

• Gateway uses a modified version of
  FreeBSD/dummynet
• It is configured with a "loss pattern", which is
  XOR'ed with the packets
• Loss pattern is generated offline and fed to
  dummynet at setup time.

13
Experiment parameters (I)

• Parameters set to emulate generic wireless
  links
• Link is defined by bandwidth and delay parameters
  (link profile)
• Bit error distribution depends on coding and
  interleaving for these experiments, independent
  and random bit errors are used (loss profile)
• Different TCP MTUs have been used to see if/how
  this affects throughput

14
Experiment parameters (II)

• Two link profiles were used
• 384kbit/s, 70ms delay
• 2Mbit/s, 30ms delay
• Five loss profiles were used
• Bit error rates ranging from 10-7 10-5
• gt 0-10 percent packet errors
• Two MTU sizes were used
• 576 and 1500 bytes

15
Results 384kbit/s, MTU 576
2.0
2.9
4.5
10
16
Results 384kbit/s, MTU 1500
17
Results 2Mbit/s, MTU 576
18
Results 2Mbit/s, MTU 1500
19
Future Work short term

• Present TCP-L paper at IST Mobile Summit 2003
  next week
• Examine why some experiments performed very
  poorly (120 sec timeout?)
• Determine the impact of burstiness factor

20
Future Work longer term

• Integrating soft information to improve decoding
• Experiment with a real applications JPEG2000?
• Compare to other TCP versions (Westwood?)
• Handle IP header as well?
• Persuade link manufacturer to export soft info
  and pass damaged data )
• Run with scheduler/emulator from Uppsala

21
Questions?