Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Experimental evaluation of TCP-L June 5, 2003 Stefan Alfredsson Karlstad University."— Presentation transcript:

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 (<< 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 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

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

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

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?

Download ppt "Experimental evaluation of TCP-L June 5, 2003 Stefan Alfredsson Karlstad University."

Similar presentations

Ads by Google