IIP Wireless. Presentation Outline

Transcription

1 IIP Wireless Improving Internet Protocols for Wireless Links Markku Kojo Department of Computer Science cs.helsinki.fi/research/.fi/research/iwtcp/ 1 Presentation Outline Project Project Summary Environment of Interest Problem Problem Areas SeawindSeawind Network Emulator TCP TCP Enhancements Experiments and Example Results Conclusions 2

2 Project Summary Follow-up of IIP Mobile Partners: Partners: UHelsinki,, Nokia Hungary, NRC, Sonera TopicsTopics Empirical examination of TCP behaviour TCP enhancements (implementations on Linux) Development of a network emulator Contributions to standardization Research Research continues in IIP Mixture? 3 Environment of Interest Mobile Host uplink downlink Fixed Host Last-hop Router Wireless link Internet 4

3 Problem Areas congestion losses, queuing delay corruption losses, variable and constant delays Mobile Host Fixed Host Last-hop Router Wireless link congestion losses, latency, reordering Internet 5 Software Emulator for Analyzing WIreless Network Data Transfers IIP Wireless Research Group Department of Computer Science 6

4 Performance Measurements over a Real Network Client Network Server 7 Performance Measurements using Network Emulator Client Network Emulator Server 8

5 Objective of Seawind To implement a network emulator that allows performance measurements over an emulated network with specific characteristics using data traffic generated by a real-life application Enable studying and testing the behavior of higher layer protocols (transport/application) with real workload generated by a single user (e.g., a user as seen by a GPRS or GSM network) Enable studying possible interactions between the underlying network behavior and higher layer protocols Software implementation of a network emulator for Linux platform (extendable) Graphical User Interface and automated test run control Allow use of existing analysis tools, develop new analysis tools 9 Wireless Network Characteristics of Interest Relatively low bandwidth ( ~4800bits/sec ~2 Mbits/sec) High High latency (long round-trip time) Long, Long, variable delays possible Data Data buffering along the wireless path Different Different error characteristics error free, bit errors possible, data losses Link Link outages, intermittent connectivity Effects Effects of background traffic 10

6 Network Emulation Model: A Single Network Subsystem Emulated by a Seawind Simulation Process (SP( SP) Low Bandwidth Propagation Delay Bit errors Packet drops Error Delay Recv Pkts Send Out Input Buffer (router queue) Link Send Buffer Emulated Link Link Recv Buffer 11 Structure of Seawind Mobile End Remote End Workload Generator (Application) Seawind Emulator Workload Generator (Application) TCP IP (Link Layer) Virtual Network Interface Buffer size Low Bandwidth Network Protocol Adaptor (NPA) Bit errors SP Delays SP Packet drops Background load Network Protocol Adaptor (NPA) TCP IP (Link Layer) Virtual Network Interface Emulated Network 12

7 Structure of Seawind (serial line version) Mobile End Workload Generator (Application) TCP IP PPP Network Interface Buffer size Low Bandwidth Serial line (null modem cable) Seawind Emulator Bit errors Delays Packet drops SP SP Emulated Network Background load Remote End Workload Generator (Application) TCP IP PPP Network Interface Serial line (null modem cable) 13 Software Components of Seawind Output logs Test params GUI & Ctrl tool tcpdump log Seawind log Ctrld ctrl flow Ctrld Ctrld WLG TCP IP L2 Virtual Net Interface Mobile End NPA data flow Simulation Prosess Emulator Simulation Prosess NPA WLG TCP IP L2 Virtual Net Interface Remote 14 End

8 TCP Enhancements Baseline: Baseline: NewReno,, SACK Increasing the initial window Limited Limited Transmit Random Random Early Detection (RED) Explicit Explicit Congestion Notification (ECN) TCP TCP Eifel Forward Forward RTO-Recovery Recovery 15 Spurious RTOs on Regular TCP Delay spikes occur on wireless networks handoffs link link-layer layer error recovery bandwidth variation Delay spike may trigger TCP retransmission timer Regular TCP sender retransmits all unacknowledged segments Eventually whole window is unnecessarily retransmitted in slow start Network resources are wasted Throughput gets worse Delay spike Spurious RTO Unnecessary retransmissions 16

9 Delays and F-RTOF When delay spike causes RTO to expire, the first unacknowledged segment is retransmitted 1 st ACK acknowledges the retransmission: send 2 new segments 2 nd ACK acknowledges data that was not retransmitted: RTO is declared spurious It is possible that second ACK does not advance window if Packet following RTO was dropped There was reordering following the RTO or a segment was duplicated Continue transmitting new data Spurious RTO Delay spike 17 When data is lost and RTO expires, F-RTO F sender retransmits the first unacknowledged segment 1 st ACK acknowledges the retransmission, so two new segments are transmitted 2 nd ACK does not acknowledge new data, so the sender starts to retransmit unacknowledged segments in slow start When RTO is not spurious (i.e. it is caused by data loss), F-RTO F is not worse than regular RTO recovery in any situation Any combination of data and ACK losses should lead to slow start RTO recovery F-RTO and Data Loss Lost segments RTO 18

10 Performance on Delay Spikes Tests with Linux implementation on emulated slow wireless link Link speed: 28.8 kbps RTT: ~500 ms MTU: 296 bytes Delay spikes on random basis Both Eifel and F-RTO F improve performance compared to regular TCP Both avoid unnecessary retransmissions Eifel is not as good as F-F RTO, because TCP timestamps are additional overhead There are more congestion- related losses 19 Performance on Data Loss Tests with Linux implementation on emulated slow wireless link Link speed: 28.8 kbps RTT: ~500 ms MTU: 296 bytes Link occasionally goes to loss state dropping all packets F-RTO performs about as well as regular TCP Eifel has problems If first lost ACK corresponds to successfully transmitted data packet, sender continues by transmitting new data 20

11 Other Experiments Congestion on slow link with Traffic Mixes Active Queue Management (RED) Differentiated packet treatment Web-transfer performance Typical Web-page sizes Traffic Traffic mixes on wireless link TCP flows competing with UDP flows 21 Conclusions Wireless Wireless links are a challenge for TCP Significant improvements are possible Some Some of the proposed improvements work well but further enhancements are needed Empirical evaluation is necessary Seawind Seawind allows us to use real protocol implementations 22

12 More Information