Experimental evaluation of TCP-L June 5, 2003 Stefan Alfredsson Karlstad University

Outline ● Motivation ● TCP-L ● Experiment environment ● Experiment results ● Future work

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

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 (<< 1%) so it is probable that a packet loss is due to congestion in the network." [Jacobson88, Congestion Avoidance and Control]

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

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

TCP-L (II) - recovery overview

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

Legend: blue fields are constant, orange fields "dont care" Assumptions: ● Options are not used (contant header length) ● Only packets with data are handled (affects RST, SYN) ● Traffic is assumed to flow mainly to the receiver ● Ack seq is cumulative – reset to the last correctly received ack no. ● URG must be handled by appl, and is mostly used for terminal traffic ● Adv. Window can be "calculated". PSH + FIN is safe to reset to zero

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

Experiment Environment sender gateway receiver ● Gateway emulates last hop of wireless link – Limits bandwidth, increases delay – Creates errors in packets

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.

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 MTU’s have been used to see if/how this affects throughput

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 … – => 0-10 percent packet errors ● Two MTU sizes were used – 576 and 1500 bytes

Results; 384kbit/s, MTU 576 ~10% ~4.5% ~2.9% ~2.0%

Results; 384kbit/s, MTU 1500

Results; 2Mbit/s, MTU 576

Results; 2Mbit/s, MTU 1500

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

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

Questions?