tcp for wireless networks

Download TCP for wireless networks

Post on 04-Feb-2016




0 download

Embed Size (px)


TCP for wireless networks. CS 444N, Spring 2002 Instructor: Mary Baker Computer Science Department Stanford University. Problem overview. Packet loss in wireless networks may be due to Bit errors Handoffs Congestion (rarely) Reordering (rarely, except for certain types of wireless nets) - PowerPoint PPT Presentation


  • TCP for wireless networksCS 444N, Spring 2002Instructor: Mary Baker

    Computer Science DepartmentStanford University

  • Problem overviewPacket loss in wireless networks may be due toBit errors HandoffsCongestion (rarely)Reordering (rarely, except for certain types of wireless nets)TCP assumes packet loss is due toCongestionReordering (rarely)TCPs congestion responses are triggered by wireless packet loss but interact poorly with wireless nets

  • TCP congestion detectionTCP assumes timeouts and duplicate acks indicate congestion or (rarely) packet reorderingTimeout indicates packet or ack was lostDuplicate acks may indicate packet reorderingAcks up through last successful in-order packet receivedCalled a cumulative ackAfter three duplicate acks, assume packet loss, not reorderingReceipt of duplicate acks means some data is still flowing

  • Responses to congestionBasic timeout and retransmissionIf sender receives no ack for data sent, timeout and retransmitExponential back-offTimeout value is sum of smoothed RT delay and 4 X mean deviation(Timeout value based on mean and variance of RTT)Congestion avoidance (really congestion control)Uses congestion window (cwnd) for more flow controlCwnd set to 1/2 of its value when congestion loss occurredSender can send up to minimum of advertised window and cwndUse additive increase of cwnd (at most 1 segment each RT)Careful way to approach limit of network

  • Responses to congestion, continuedSlow start used to initiate a connectionIn slow start, set cwnd to 1 segmentWith each ack, increase cwnd by a segment (exponential increase)Aggressive way of building up bandwidth for flowAlso do this after a timeout aggressive drop in offered loadSwitch to regular congestion control once cwnd is one half of what it was when congestion occurredFast retransmit and fast recoveryAfter three duplicate acks, assume packet loss, data still flowingSender resends missing segmentSet cwnd to of current cwnd plus 3 segmentsFor each duplicate ack, increment cwnd by 1 (keep flow going)When new data acked, do regular congestion avoidance

  • Other problems in a wireless environmentThere are often bursts of errors due to poor signal strength in an area or duration of noiseMore than one packet lost in TCP windowDelay is often very high, although you usually only hear about low bandwidthRTT quite longWant to avoid request/response behavior

  • Poor interaction with TCPPacket loss due to noise or hand-offsEnter congestion controlSlow increase of cwndBursts of packet loss and hand-offsTimeoutEnter slow start (very painful!)Cumulative ack scheme not good with bursty lossesMissing data detected one segment at a timeDuplicate acks take a while to cause retransmissionTCP Reno may suffer coarse time-out and enter slow start!Partial ack still causes it to leave fast recoveryTCP New Reno still only retransmits one packet per RTTStay in fast recovery until all losses acked

  • Multiple losses in windowAssume cwnd of 102nd and 5th packets lost 3rd duplicate ack causes retransmit of 2nd packetAlso sets cwnd to 5 + 3 = 8Further duplicate acks increment cwnd by 1Ack of retransmit is partial ack since packet 5 lostIn TCP Reno this causes us to leave fast retransmitDeflate congestion window to 5, but weve sent 11!

  • Coarse-grain timeout exampleack1ack1ack1ack1167910ack42ack4ack4Cwnd=8Cwnd=9Cwnd=52345Cwnd = 10Treatment of partial ack determines whether we timeout8ack1Cwnd=1011

  • Solution categoriesEntirely new transport protocolHard to deploy widelyEnd-to-end protocol needs to be efficient on wired networks tooMust implement much of TCPs flow controlModifications to TCPMaintain end-to-end semanticsMay or may not be backwards compatibleSplit-connection TCPBreaks end-to-end nature of protocolMay be backwards compatible with end-hostsState on basestation may make handoffs slowExtra TCP processing at basestation

  • Solution categories, continuedLink-layer protocolsInvisible to higher-level protocolsDoes not break higher-level end-to-end semanticsMay not shield sender completely from packet lossMay adversely interact with higher-level mechanismsMay adversely affect delay-sensitive applicationsSnoop protocolDoes not break end-to-end semanticsLike a LL protocol, does not completely shield senderOnly soft state at base station not essential for correctness

  • Overall pointsKey performance improvements:Knowledge of multiple losses in windowKeeping congestion window from shrinkingMaybe even avoiding unnecessary retransmissionsTwo basic approachesShield sender from wireless nature of link so it doesnt react poorlyMake sender aware of wireless problems so it can do something about it

  • Link layer protocols investigatedLL: TCP-ish one with cumulative acks and retransmit granularity faster than TCPsLL-SMART: addition of selective retransmissionsCumulative ack with sequence # of of packet causing ackLL-TCP-AWARE: snoop protocolAt base station cache segmentsDetect and suppress duplicate acksRetransmit lost segments locallyLL-SMART-TCP-AWARE: Combination of selective acks and duplicate ack suppression

  • Link layer resultsSimple retransmission at link layer helps, but not totallyCombination of selective acks and duplicate suppression is bestDuplicate suppression by itself is goodReal problem is link layers that allow out-of-order packet delivery, triggering duplicate acks, fast retransmission and congestion avoidance in TCPOverall, want to avoid triggering TCP congestion handling techniques

  • End-to-end protocols investigatedE2E (Reno): no support for partial acksE2E-NewReno: partial acks allow further packet retransmissionsE2E-SACK: ack describes 3 received non-contiguous rangesE2E-SMART: cumulative ack with sequence # of packet causing ackSender uses info for bitmask of okay packetsIgnores possibility that holes are due to reorderingAlso problems with lost acksEasier to generate and transmit acks

  • E2E protocols, continuedE2E-ELN: explicit loss notificationFuture cumulative acks for packet marked to show non-congestion lossSender gets duplicate acks and retransmits, but does not invoke congestion-related proceduresE2E-ELN-RXMT: retransmit on first duplicate ack

  • End-to-end resultsE2E (Reno): coarse-grained timeouts really hurtThroughput less than 50% of maximum in local areaThroughput of less than 25% in wide areaE2E-New Reno: avoiding timeouts helpsThroughput 10-25% better in LANThroughput twice as good in WANELN techniques avoid shrinking congestion windowOver two times better than E2EE2E-ELN-RXMT only a little better than E2E-ELNEnough data in pipe usually to get fast retransmit from ELNBigger difference with smaller buffer sizeNot as much data in pipe (harder to get 3 duplicate acks)

  • E2E results continuedE2E selective acks:Over twice as good as E2ENot as good as best LL schemes (10% worse on LAN, 35% worse in WAN)Problem is still shrinkage of congestion windowHavent tried combo of ELN techniques with selective acksELN implementation in paper still allows timeoutsNo information about multiple losses in window

  • Split connection protocolsAttempt to isolate TCP source from wireless lossesLossy link looks like robust but slower BW linkTCP sender over wireless link performs all retransmissions in response to losses

    Base station performs all retransmissionsWhat if wireless device is the sender?SPLIT: uses TCP Reno over wireless linkSPLIT-SMART: uses SMART-based selective acks

  • Split connection resultsSPLIT:Wired goodput 100% since no retransmissions thereEventually stalls when wireless link times outBuffer space limited at base stationSPLIT-SMART:Throughput better than SPLIT (at least twice as good)Better performance of wireless link avoids holding up wired links as muchSplit connections not as effective as TCP-aware LL protocol, which also avoids splitting the connection

  • Error bursts2-6 packets lost in a burstLL-SMART-TCP-AWARE up to 30% better than LL-TCP-AWARESelective acks help in face of error bursts

  • Error rate effectAt low error rates (1 error every 256 Kbytes) all protocols do about the sameAt 16 KB error rate, TCP-aware LL schemes about 2 times better than E2E-SMART and about 9 times better than TCP RenoE2E-SACK and SMART at high error rates:Small cwndSACK wont retransmit until 3 duplicate acksSo no retransmits if window < 4 or 5Senders window often less than this, so timeoutsSMART assumes no reordering of packets and retransmits with first duplicate ack

  • Overall resultsGood TCP-aware LL shields sender from duplicate acksAvoids redundant retransmissions by sender and base stationAdding selective acks helps a lot with bursty errorsSplit connection with standard TCP shields sender from losses, but poor wireless link still causes sender to stallAdding selective acks over wireless link helps a lotStill not as good as local LL improvementE2E schemes with selective acks help a lotStill not as good as best LL schemesExplicit loss E2E schemes help (avoid shrinking congestion window) but should be combined with SACK for multiple packet losses

  • Fast handoff proposalsMulticast to old and new stationsAssumes extra support in networkSome concern about load on base stationsHierarchical foreign agentsMobile host moves within an organizationNotifies only top-level foreign agent, rather than home agentHome agent talks to top-level foreign agent, which doesnt change oftenRequires foreign agents, extra support in network10-30ms handoffs possible with buffering / retransmission at base stations

  • Explicit loss notification issuesReceiver gets corrupted packetInstead of dropping it, TCP gets it, generates ELN message with duplicate ackWhat if header corrupted? Which TCP gets it?Use FEC?Entire packet dropped?Base sta

View more >