1 / 30

Transport Protocols: UDP vs. TCP, Congestion Control, and Error Recovery

Understand the key differences between UDP and TCP in terms of service, lightweight vs. heavyweight protocols, and the importance of congestion control and error recovery mechanisms in modern networks. Explore TCP states, flow control, Selective Repeat vs. Go-back-N, and different TCP congestion control algorithms like Tahoe, Reno, and Vegas. Learn about Fast Retransmit, Slow Start, and the adaptations introduced in New Reno TCP for handling multiple losses within a window.

angelo
Download Presentation

Transport Protocols: UDP vs. TCP, Congestion Control, and Error Recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. cs/ee 143 Communication NetworksChapter 7 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech

  2. Transport services • UDP • Datagram service • No congestion control • No error/loss recovery • Lightweight • TCP • Connection oriented service • Congestion control • Error/loss recovery • Heavyweight

  3. UDP 1 ~ 65535 (216-1) UDP header ≤ 65535 Bytes – 8 Bytes (UDP header) – 20 Bytes (IP header) Usually smaller to avoid IP fragmentation (e.g., Ethernet MTU 1500 Bytes)

  4. TCP TCP header

  5. Example TCP states 3-way handshake 4-way handshake Possible issue: SYN flood attack Result in large numbers of half-open connections and no new connections can be made.

  6. RTT 1 2 W 1 2 W data ACKs 1 2 W 1 2 W Window Flow Control • ~ W packets per RTT • Lost packet detected by missing ACK Source time Destination time

  7. ARQ (Automatic Repeat Request) Go-back-N • TCP • 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] Selective repeat

  8. Window control • Limit the number of packets in the network to window W • Source rate = bps • If W too small then rate « capacity If W too big then rate > capacity => congestion • Adapt W to network (and conditions)

  9. TCP window control • Receiver flow control • Avoid overloading receiver • Set by receiver • awnd: receiver (advertised) window • Network congestion control • Avoid overloading network • Set by sender • Infer available network capacity • cwnd: congestion window • Set W = min (cwnd, awnd)

  10. TCP congestion control • Source calculates cwnd from indication of network congestion • Congestion indications • Losses • Delay • Marks • Algorithms to calculate cwnd • Tahoe, Reno, Vegas, …

  11. TCP Congestion Controls • Tahoe (Jacobson 1988) • Slow Start • Congestion Avoidance • Fast Retransmit • Reno (Jacobson 1990) • Fast Recovery • Vegas (Brakmo & Peterson 1994) • New Congestion Avoidance

  12. TCP Tahoe (Jacobson 1988) window time CA SS : Slow Start : Congestion Avoidance : Threshold

  13. Slow Start • Start with cwnd = 1 (slow start) • On each successful ACK increment cwnd cwndcnwd + 1 • Exponential growth of cwnd each RTT: cwnd 2 x cwnd • Enter CA when cwnd >= ssthresh

  14. Congestion Avoidance • Starts when cwndssthresh • On each successful ACK: cwndcwnd + 1/cwnd • Linear growth of cwnd each RTT: cwndcwnd + 1

  15. Packets 1 7 2 3 4 5 6 Acknowledgements 1 2 3 3 3 3 Packet Loss • Assumption: loss indicates congestion • Packet loss detected by • Retransmission TimeOuts (RTO timer) • Duplicate ACKs (at least 3) (Fast Retransmit)

  16. Fast Retransmit • Wait for a timeout is quite long • Immediately retransmits after 3 dupACKs without waiting for timeout • Adjusts ssthresh flightsize = min(awnd, cwnd) ssthresh max(flightsize/2, 2) • Enter Slow Start (cwnd = 1)

  17. Summary: Tahoe • Basic ideas • Gently probe network for spare capacity • Drastically reduce rate on congestion • Windowing: 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?

  18. TCP Reno (Jacobson 1990) SS CA for every ACK { W += 1/W(AI) } for every loss { W = W/2 (MD) } How to halve W without emptying the pipe? Fast Recovery

  19. Fast recovery • Idea: each dupACK represents a packet having left the pipe (successfully received) • Enter FR/FR after 3 dupACKs • Setssthresh max(flightsize/2, 2) • Retransmit lost packet • Set 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

  20. 1 2 3 4 5 6 7 8 1 9 10 11 0 0 0 0 0 0 0 Exit FR/FR 11 7 9 4 4 4 4 4 Example: FR/FR • Fast retransmit • Retransmit on 3 dupACKs • Fast recovery • Inflate window while repairing loss to fill pipe S time time R 8 cwnd 8 ssthresh

  21. Summary: Reno • Basic ideas • dupACKs: halve W and avoid slow start • dupACKs: fast retransmit + fast recovery • Timeout: slow start dupACKs congestion avoidance FR/FR timeout retransmit slow start

  22. FR/FR 1 3 0 0 0 0 2 0 timeout 8 unack’d pkts 5 8 9 Multiple loss in Reno? • On 3 dupACKs, receiver has packets 2, 4, 6, 8, cwnd=8, retransmits pkt 1, enter FR/FR • Next dupACK increment cwnd to 9 • After a RTT, ACK arrives for pkts 1 & 2, exit FR/FR, cwnd=5, 8 unack’edpkts • No more ACK, sender must wait for timeout 2 3 4 5 6 7 8 9 0 1 S time D time

  23. New RenoFall & Floyd ‘96, (RFC 2583) • Motivation: multiple losses within a window • Partial ACK takes Reno out of FR, deflates window • Sender may have to wait for timeout before proceeding • Idea: partial ACK indicates lost packets • Stays in FR/FR and retransmits immediately • Retransmits 1 lost packet per RTT until all lost packets from that window are retransmitted • Eliminates timeout

  24. Delay-based TCP: Vegas (Brakmo & Peterson 1994) • Reno with a new congestion avoidance algorithm • Converges (provided buffer is large) ! window time CA SS

  25. Congestion avoidance • Each source estimates number of its own packets in pipe from RTT • Adjusts window to maintain estimate # of packets in queues between aand b for every RTT { • if W/RTTmin – W/RTT< a / RTTmin then W++ • if W/RTTmin – W/RTT> b / RTTminthen W-- } for every loss W := W/2

  26. Implications • Congestion measure = end-to-endqueueing delay • At equilibrium • Zero loss • Stable window at full utilization • Nonzero queue, larger for more sources • Convergence to equilibrium • Converges if sufficient network buffer • Oscillates like Reno otherwise

  27. Theory-guided design: FAST We will study them further in TCP modeling in the following weeks A simple model of AIMD (Reno) for example…

  28. Summary • UDP header/TCP header • TCP 3-way/4-way handshake • ARQ: Go-back-N/selective repeat • Tahoe/Reno/New Reno/Vegas/FAST -- useful details for your project • Simply model of AIMD

  29. 33 Why both TCP and UDP? Most applications use TCP, as this avoids re-inventing error recovery in every application But some applications do not need TCP For 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.

More Related