Chapter 4 Transport Text Walrand amp Parakh 2010 Steven Low CMS EE Caltech Agenda Internetworking Routing across LANs layer2layer3 DHCP NAT Transport layer Connection setup ID: 1044757
Download Presentation The PPT/PDF document "cs / ee /ids 143 Communication Networks" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. cs/ee/ids 143 Communication NetworksChapter 4 TransportText: Walrand & Parakh, 2010Steven LowCMS, EE, Caltech
2. AgendaInternetworkingRouting across LANs, layer2-layer3DHCPNAT Transport layerConnection setupError recovery: retransmissionCongestion control
3.
4. Transport servicesUDP Datagram service No congestion control No error/loss recovery LightweightTCP Connection oriented service Congestion control Error/loss recovery Heavyweight
5. UDPUDP header1 ~ 65535 (216-1)≤ 65535 Bytes – 8 Bytes (UDP header) – 20 Bytes (IP header)Usually smaller to avoid IP fragmentation (e.g., Ethernet MTU 1500 Bytes)
6. TCPTCP header
7. Example TCP states3-way handshake4-way handshakePossible issue: SYN flood attackResult in large numbers of half-open connections and no new connections can be made.
8. Window Flow Control~ W packets per RTTLost packet detected by missing ACKRTTtimetimeSourceDestination12W12W12WdataACKs12W
9. ARQ (Automatic Repeat Request)Go-back-NSelective repeatTCP Sender & receiver negotiate whether or not to use Selective Repeat (SACK) Can ack up to 4 blocks of contiguous bytes that receiver got correctly e.g. [3; 10, 14; 16, 20; 25, 33]
10. Window controlLimit the number of packets in the network to window WSource rate = bpsIf W too small then rate « capacity If W too big then rate > capacity => congestionAdapt W to network (and conditions)
11. TCP window controlReceiver flow controlAvoid overloading receiverSet by receiverawnd: receiver (advertised) window Network congestion controlAvoid overloading networkSet by senderInfer available network capacitycwnd: congestion windowSet W = min (cwnd, awnd)
12. TCP congestion controlSource calculates cwnd from indication of network congestionCongestion indicationsLosses DelayMarks Algorithms to calculate cwndTahoe, Reno, Vegas, …
13. TCP Congestion ControlsTahoe (Jacobson 1988)Slow StartCongestion AvoidanceFast RetransmitReno (Jacobson 1990)Fast RecoveryVegas (Brakmo & Peterson 1994)New Congestion Avoidance
14. TCP Tahoe (Jacobson 1988)SStimewindowCA : Slow Start : Congestion Avoidance : Threshold
15. Slow Start Start with cwnd := 1 (slow start)On each successful ACK increment cwnd cwnd := cnwd + 1Exponential growth of cwnd each RTT: cwnd := 2 x cwndEnter CA when cwnd >= ssthresh
16. Congestion AvoidanceStarts when cwnd >= ssthreshOn each successful ACK: cwnd := cwnd + 1/cwndLinear growth of cwnd each RTT: cwnd := cwnd + 1
17. Packet LossAssumption: loss indicates congestionPacket loss detected byRetransmission TimeOuts (RTO timer)Duplicate ACKs (at least 3)123456123PacketsAcknowledgements3373(Fast Retransmit)
18. Fast RetransmitWait for a timeout is quite longImmediately retransmits after 3 dupACKs without waiting for timeoutAdjusts ssthresh flightsize := min(awnd, cwnd) ssthresh := max(flightsize/2, 2)Enter Slow Start (cwnd := 1)
19. Summary: TahoeBasic ideasGently probe network for spare capacityDrastically reduce rate on congestionWindowing: self-clocking for every ACK { if (W < ssthresh) then W++ (SS) else W += 1/W (CA) } for every loss { ssthresh := W/2 W := 1 }Seems a little too conservative?
20. TCP Reno (Jacobson 1990)CASS for every ACK { W += 1/W (AI) } for every loss { W := W/2 (MD) }How to halve W without emptying the pipe?Fast Recovery
21. Fast recoveryIdea: each dupACK represents a packet having left the pipe (successfully received)Enter FR/FR after 3 dupACKsSet ssthresh := max(flightsize/2, 2)Retransmit lost packetSet cwnd := ssthresh + ndup (window inflation)Wait till W := min(awnd, cwnd) is large enough; transmit new packet(s)On non-dup ACK, set cwnd := ssthresh (window deflation)Enter CA
22. 99400Example: FR/FRFast retransmitRetransmit on 3 dupACKsFast recoveryInflate window while repairing loss to fill pipetimeStimeR123456878cwnd8ssthresh174000Exit FR/FR44411001011
23. Summary: RenoBasic ideasdupACKs: halve W and avoid slow startdupACKs: fast retransmit + fast recoveryTimeout: slow startslow startretransmitcongestion avoidance FR/FR dupACKstimeout
24. Multiple loss in Reno?On 3 dupACKs, receiver has packets 2, 4, 6, 8, cwnd=8, retransmits pkt 1, enter FR/FRNext dupACK increment cwnd to 9After a RTT, ACK arrives for pkts 1 & 2, exit FR/FR, cwnd=5, 8 unack’ed pktsNo more ACK, sender must wait for timeout12timeStimeD34568718FR/FR090000098 unack’d pkts253timeout
25. New Reno Fall & Floyd ‘96, (RFC 2583)Motivation: multiple losses within a windowPartial ACK takes Reno out of FR, deflates windowSender may have to wait for timeout before proceedingIdea: partial ACK indicates lost packetsStays in FR/FR and retransmits immediatelyRetransmits 1 lost packet per RTT until all lost packets from that window are retransmittedEliminates timeout
26. Delay-based TCP: Vegas (Brakmo & Peterson 1994)Reno with a new congestion avoidance algorithmConverges (provided buffer is large) !SStimewindowCA
27. for every RTT{ if W/RTTmin – W/RTT < a / RTTmin then W ++ if W/RTTmin – W/RTT > b / RTTmin then W -- }for every loss W := W/2Congestion avoidanceEach source estimates number of its own packets in pipe from RTTAdjusts window to maintain estimate # of packets in queues between a and b
28. ImplicationsCongestion measure = end-to-end queueing delayAt equilibriumZero lossStable window at full utilizationNonzero queue, larger for more sourcesConvergence to equilibriumConverges if sufficient network bufferOscillates like Reno otherwise
29. Theory-guided design: FASTWe will study them further in TCP modeling in the following weeks
30. SummaryUDP header/TCP headerTCP 3-way/4-way handshakeARQ: Go-back-N/selective repeatTahoe/Reno/New Reno/Vegas/FAST -- useful details for your project
31. 31Why both TCP and UDP?Most applications use TCP, as this avoids re-inventing error recovery in every applicationBut some applications do not need TCPFor example: Voice applicationsSome packet loss is fine. Packet retransmission introduces too much delay. For example: an application that sends just one message, like DNS/SNMP/RIP. TCP sends several packets before the useful one. We may add reliability at application layer instead.
32. Mathematical model
33. TCP/AQMCongestion control is a distributed asynchronous algorithm to share bandwidthIt has two componentsTCP: adapts sending rate (window) to congestionAQM: adjusts & feeds back congestion informationThey form a distributed feedback control systemEquilibrium & stability depends on both TCP and AQMAnd on delay, capacity, routing, #connectionspl(t)xi(t)TCP: RenoVegasFASTAQM: DropTail RED REM/PI AVQ
34. Network modelp1(t)p2(t)NetworkLinks l of capacities cl and congestion measure pl(t) Sources iSource rates xi(t)Routing matrix R x1(t)x2(t)x3(t)
35. F1FNG1GL R RT TCPNetworkAQMxyqpReno, VegasDroptail, RED IP routing Network modelTCP CC model consists ofspecs for Fi and Gl
36. ExamplesDerive (Fi, Gl) model forReno/REDVegas/DroptailFAST/DroptailFocus on Congestion Avoidance
37. Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 }
38. Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 }link loss probabilityround-trip loss probabilitywindow sizethroughput
39. Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 }
40. Model: REDqueue lengthmarking prob1sourcerateaggregatelink rate
41. Model: Reno/RED
42. F1FNG1GL R RT TCPNetworkAQMxyqpDecentralization structureqy
43. Validation – Reno/REM30 sources, 3 groups with RTT = 3, 5, 7 msLink capacity = 64 Mbps, buffer = 50 kBSmaller window due to small RTT (~0 queueing delay)
44. queue sizefor every RTT{ if W/RTTmin – W/RTT < a then W ++ if W/RTTmin – W/RTT > a then W -- }for every loss W := W/2Model: Vegas/DroptailFi:pl(t+1) = [pl(t) + yl (t)/cl - 1]+Gl:
45. periodically { } Model: FAST/Droptail
46. L., Peterson, Wang, JACM 2002
47. Validation: matching transientsSame RTT, no cross trafficSame RTT, cross trafficDifferent RTTs, no cross traffic[Jacobsson et al 2009]
48. RecapProtocol (Reno, Vegas, FAST, Droptail, RED…)EquilibriumPerformance Throughput, loss, delayFairnessUtilityDynamicsLocal stabilityGlobal stability