IIP Wireless Improving Internet Protocols for Wireless Links

1

Page 1

1University of Helsinki

IIP WirelessIIP WirelessImproving Internet Protocols for Wireless Improving Internet Protocols for Wireless

LinksLinks

MarkkuMarkku KojoKojoUniversity of HelsinkiUniversity of Helsinki

Department of Computer ScienceDepartment of Computer Science

www.www.cscs..helsinkihelsinki.fi/research/.fi/research/iwtcpiwtcp//

2University of Helsinki© IIP Wireless project/MK

Presentation OutlinePresentation Outline

♦♦Project SummaryProject Summary♦♦Environment of InterestEnvironment of Interest♦♦Problem AreasProblem Areas♦♦SeawindSeawind Network EmulatorNetwork Emulator♦♦TCP EnhancementsTCP Enhancements♦♦Experiments and Example ResultsExperiments and Example Results♦♦ConclusionsConclusions

2

Page 2


Project SummaryProject Summary

♦♦FollowFollow--up of IIP Mobileup of IIP Mobile♦♦Partners: Partners: UHelsinkiUHelsinki, Nokia Hungary, NRC, , Nokia Hungary, NRC, SoneraSonera♦♦TopicsTopics

–– Empirical examination of TCP Empirical examination of TCP behaviourbehaviour–– TCP enhancements (implementations on Linux)TCP enhancements (implementations on Linux)–– Development of a network emulatorDevelopment of a network emulator–– Contributions to standardizationContributions to standardization

♦♦Research continues in IIP Mixture?Research continues in IIP Mixture?


Environment of InterestEnvironment of Interest

Mobile Host Fixed Host

InternetWireless link

Last-hop Router

uplink

downlink

3

Page 3


Problem AreasProblem Areas

Mobile Host Fixed Host

InternetWireless link

Last-hop Router

congestion losses,queuing delay

congestion losses, latency, reordering

corruption losses, variable and constant delays

6University of Helsinki

SSoftware oftware EEmulator for mulator for AAnalyzing nalyzing WIWIreless reless

NNetwork etwork DData Transfersata TransfersIIP Wireless Research Group

Department of Computer ScienceDepartment of Computer ScienceUniversity of HelsinkiUniversity of Helsinki

4

Page 4


Performance Measurements over a Performance Measurements over a Real NetworkReal Network

Client

ServerNetwork


Performance Measurements using Performance Measurements using Network EmulatorNetwork Emulator

Client

Server

Network Emulator

5

Page 5


Objective of Objective of Seawind 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 protocoEnable studying and testing the behavior of higher layer protocols ls (transport/application) with real workload generated by a single(transport/application) with real workload generated by a single user user (e.g., a user as seen by a GPRS or GSM network)(e.g., a user as seen by a GPRS or GSM network)

–– Enable studying possible interactions between the underlying netEnable studying possible interactions between the underlying network work behavior and higher layer protocolsbehavior and higher layer protocols

–– Software implementation of a network emulator for Linux platformSoftware implementation of a network emulator for Linux platform(extendable)(extendable)

–– Graphical User Interface and automated test run controlGraphical User Interface and automated test run control–– Allow use of existing analysis tools, develop new analysis toolsAllow use of existing analysis tools, develop new analysis tools


Wireless Network Characteristics of Wireless Network Characteristics of InterestInterest

♦♦Relatively low bandwidth Relatively low bandwidth ( ~4800bits/sec ~2 ( ~4800bits/sec ~2 MbitsMbits/sec)/sec)

♦♦High latency (long roundHigh latency (long round--trip time)trip time)♦♦Long, variable delays possibleLong, variable delays possible♦♦Data buffering along the “wireless path”Data buffering along the “wireless path”♦♦Different error characteristicsDifferent error characteristics

–– error free, bit errors possible, data losseserror free, bit errors possible, data losses

♦♦Link outages, intermittent connectivityLink outages, intermittent connectivity♦♦Effects of background trafficEffects of background traffic

6

Page 6


Network Emulation Model:Network Emulation Model:A Single Network Subsystem Emulated by a A Single Network Subsystem Emulated by a

Seawind Simulation Process (Seawind Simulation Process (SPSP))

Input Buffer(router queue)

Packet drops

Low BandwidthPropagation Delay

Bit errors

Error Delay

Recv Pkts Send Out

Emulated Link LinkRecv Buffer

LinkSend Buffer


Structure ofStructure of SeawindSeawind

Virtual NetworkInterface

Mobile End

IP

TCP

Workload Generator(Application)

(Link Layer)Virtual Network

Interface

Remote End

IP

TCP


(Link Layer)

Network ProtocolAdaptor (NPA)

Network ProtocolAdaptor (NPA)

Seawind EmulatorDelaysBuffer size Packet drops

Low Bandwidth

Emulated Network

Background load

Bit errors

SP SP

7

Page 7


Structure ofStructure of Seawind Seawind (serial line version)(serial line version)

NetworkInterface

Mobile End

IP

TCP


PPPNetworkInterface

Remote End

IP

TCP


PPP

Serial line (null modem cable) Serial line (null modem cable)

Seawind EmulatorDelaysBuffer size Packet drops

Background load

Bit errors

Emulated Network

Low Bandwidth

SP SP


SimulationProsess

GUI &

Ctrl tool

Software Components ofSoftware Components of SeawindSeawind

WLG

Mobile EndVirtual NetInterface

IP

TCP

L2

WLG

Remote EndVirtual NetInterface

IP

TCP

L2

NPA NPA

Ctrld CtrldCtrld

SimulationProsess

Emulator

dataflow

Testparams

tcpdumplog

ctrlflow

Seawindlog

Output logs

8

Page 8


TCP EnhancementsTCP Enhancements

♦♦Baseline: Baseline: NewRenoNewReno, SACK, SACK♦♦Increasing the initial windowIncreasing the initial window♦♦Limited TransmitLimited Transmit♦♦Random Early Detection (RED)Random Early Detection (RED)♦♦Explicit Congestion Notification (ECN)Explicit Congestion Notification (ECN)♦♦TCP TCP EifelEifel♦♦Forward RTOForward RTO--RecoveryRecovery


Spurious RTOs on Regular TCPSpurious RTOs on Regular TCP

♦♦ Delay spikes occur on Delay spikes occur on wireless networkswireless networks

–– handoffshandoffs–– linklink--layer error recoverylayer error recovery–– bandwidth variationbandwidth variation

♦♦ Delay spike may trigger TCP Delay spike may trigger TCP retransmission timerretransmission timer

♦♦ Regular TCP sender Regular TCP sender retransmits all retransmits all unacknowledged segmentsunacknowledged segments

♦♦ Eventually whole window is Eventually whole window is unnecessarily retransmitted unnecessarily retransmitted in slow startin slow start

–– Network resources are wastedNetwork resources are wasted–– Throughput gets worseThroughput gets worse

Delay spikeUnnecessaryretransmissions

Spurious RTO

9

Page 9


Delays and FDelays and F--RTORTO

♦♦ When delay spike causes When delay spike causes RTO to expire, the first RTO to expire, the first unacknowledged segment unacknowledged segment is retransmittedis retransmitted

♦♦ 11stst ACK acknowledges the ACK acknowledges the retransmission: send 2 retransmission: send 2 new segmentsnew segments

♦♦ 22ndnd ACK acknowledges ACK acknowledges data that was not data that was not retransmitted: RTO is retransmitted: RTO is declared spuriousdeclared spurious

♦♦ It is possible that second It is possible that second ACK does not advance ACK does not advance window ifwindow if

–– Packet following RTO was Packet following RTO was droppeddropped

–– There was reordering There was reordering following the RTO or a following the RTO or a segment was duplicatedsegment was duplicated

Delay spike

Continue transmittingnew data

Spurious RTO


FF--RTO and Data LossRTO and Data Loss♦♦ When data is lost and When data is lost and

RTO expires, FRTO expires, F--RTO RTO sender retransmits the sender retransmits the first unacknowledged first unacknowledged segmentsegment

♦♦ 11stst ACK acknowledges ACK acknowledges the retransmission, so the retransmission, so two new segments are two new segments are transmittedtransmitted

♦♦ 22ndnd ACK does not ACK does not acknowledge new data, acknowledge new data, so the sender starts to so the sender starts to retransmit retransmit unacknowledged unacknowledged segments in slow startsegments in slow start

♦♦ When RTO is not When RTO is not spurious (i.e. it is caused spurious (i.e. it is caused by data loss), Fby data loss), F--RTO is RTO is not worse than regular not worse than regular RTO recovery in any RTO recovery in any situationsituation

–– Any combination of data and Any combination of data and ACK losses should lead to slow ACK losses should lead to slow start RTO recoverystart RTO recovery

Lost segments

RTO

10

Page 10


Performance on Delay SpikesPerformance on Delay Spikes

♦♦ Tests with Linux Tests with Linux implementation on implementation on emulated slow wireless emulated slow wireless linklink

–– Link speed: 28.8 kbpsLink speed: 28.8 kbps–– RTT: ~500 msRTT: ~500 ms–– MTU: 296 bytesMTU: 296 bytes–– Delay spikes on random basisDelay spikes on random basis

♦♦ Both Eifel and FBoth Eifel and F--RTO RTO improve performance improve performance compared to regular TCPcompared to regular TCP

–– Both avoid unnecessary Both avoid unnecessary retransmissionsretransmissions

♦♦ Eifel is not as good as FEifel is not as good as F--RTO, becauseRTO, because

–– TCP timestamps are TCP timestamps are additional overheadadditional overhead

–– There are more congestionThere are more congestion--related lossesrelated losses


Performance on Data LossPerformance on Data Loss

♦♦ Tests with Linux Tests with Linux implementation on implementation on emulated slow wireless linkemulated slow wireless link

–– Link speed: 28.8 kbpsLink speed: 28.8 kbps–– RTT: ~500 msRTT: ~500 ms–– MTU: 296 bytesMTU: 296 bytes–– Link occasionally goes to loss Link occasionally goes to loss

state dropping all packetsstate dropping all packets

♦♦ FF--RTO performs about as RTO performs about as well as regular TCPwell as regular TCP

♦♦ Eifel has problemsEifel has problems–– If first lost ACK corresponds to If first lost ACK corresponds to

successfully transmitted data successfully transmitted data packet, sender continues by packet, sender continues by transmitting new datatransmitting new data

11

Page 11


Other ExperimentsOther Experiments

♦♦Congestion on slow link with Traffic MixesCongestion on slow link with Traffic Mixes–– Active Queue Management (RED)Active Queue Management (RED)–– Differentiated packet treatmentDifferentiated packet treatment

♦♦WebWeb--transfer performancetransfer performance–– Typical WebTypical Web--page sizespage sizes

♦♦Traffic mixes on wireless linkTraffic mixes on wireless link–– TCP flows competing with UDP flowsTCP flows competing with UDP flows


ConclusionsConclusions

♦♦Wireless links are a challenge for TCPWireless links are a challenge for TCP♦♦Significant improvements are possibleSignificant improvements are possible♦♦Some of the proposed improvements work well Some of the proposed improvements work well

but further enhancements are neededbut further enhancements are needed♦♦Empirical evaluation is necessaryEmpirical evaluation is necessary♦♦Seawind Seawind allows us to use real protocol allows us to use real protocol

implementationsimplementations

12

Page 12


More InformationMore Information

HTTP://WWW.CS.HELSINKI.FI/RESEARCH/IWTCP/

EMail: [email protected]@cs.Helsinki.FI

Documents

IIP Wireless Improving Internet Protocols for Wireless Links