Transport Layer - II

1. Transport Layer - II Michalis Faloutsos Many slides from Kurose-Ross Srikanth Krishnamurthy S. Kalyanaraman

2. In this set of slides • TCP variants • Router assisted congestion control

3. Current TCP Versions • TCP specs can be implemented in different ways • TCP versions: • Tahoe (basic as described) • Reno • Las Vegas

4. TCP Reno • Most popular TCP implementation • Fast retransmit on 3 duplicate ACKs • Fast recovery: cancel slow start after fast retransmission • Half the congestion window threshold, but start with congestion window equal to threshold • Go to congestion avoidance phase • Optimistic Rationale: • I hope there was only one packet lost • Since I sent it, I hope it arrives this time

5. Fast Retransmit • Coarse grained TCP time-outs sometimes lead to long periods wherein a connection goes dead waiting for a timer to expire. • Fast Retransmit -- a heuristic that sometimes “triggers” the retransmission of a packet faster than permissible by the regular time-out. • Every time a data packet arrives at a receiver, the receiver ACKs even though the particular sequence number has been ACKed. • Thus, when a packet is received in out of order, resend the ACK sent last time -- a duplicate ACK!

6. Duplicate ACKs • When a duplicate ACK is seen by the sender, it infers that the other side must have received a packet out of order. • Delays on different paths could be different -- thus, the missing packets may be delivered. • So wait for “some” number of duplicate ACKs before resending data. • This number is usually 3.

7. Fast Recovery • When the fast retransmit mechanism signals congestion, the sender, instead of returning to Slow Start uses a pure AIMD. • Simply reduces the congestion window by half and resumes additive increase. • Thus, recovery is faster -- this is called Fast Recovery.

8. TCP Vegas • What is a “sign” of congestion: • When RTT increases a lot • Thruput = bytes sent / time • Idea: use sending rate (thruput) to finetune window • If sending rate increases, increase window linearly • If sending rate flat, leave window as is • If sending rate decreases, decrease window linearly • Issues: • Estimate RTT, Set appropriate threshold

9. 1100 900 700 Sending KBps 500 300 100 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 10 Queue size in router 5 0.5 1.0 1.5 4.0 4.5 6.5 8.0 Time (seconds) Intuition 70 60 50 40 KB 30 20 10 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) Congestion Window Time (seconds) Average send rate at source 2.0 2.5 3.0 3.5 5.0 5.5 6.0 7.0 7.5 8.5 Driving on Ice Average Q length in router

10. Considering RTT variations • Intuition: • When RTT increases “a lot”, decrease the window • How much does the RTT increase with each packet sent ? • Note that with each additional packet, we are adding load. • One way -- compute for every two round trip delays (with an increase in a segment) to see if observed RTT > avg of min and maximum RTT. • If yes, reduce congestion window.

11. A second possibility • Every RTT time, increase congestion window by a segment. • Compute current throughput: • number of outstanding bytes divided by RTT. • Compute throughput with window = 1: • Keep the value of the throughput that was achieved when only one packet was in transit (at the beginning of the connection). • If the difference between current throughput and this above tagged throughput is less than 1/2 decrease congestion window by 1.

12. TCP Vegas’ approach • Source tries to match the available bandwidth exactly. • TCP source maintains what is known as BaseRTT • the RTT when the flow is not congested • typically the minimum of all RTTs observed. • It uses this value to determine if or not congestion is being experienced.

13. The TCP Vegas: Algorithm • Let BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet) • If not overflowing the connection, then • ExpectedRate = CongestionWindow / BaseRTT • Source calculates current sending rate (ActualRate) once per RTT • Source compares ActualRate with ExpectedRate • Diff = ExpectedRate – ActualRate • if Diff <  • -->increase CongestionWindow linearly • else if Diff > • -->decrease CongestionWindow linearly • else • -->leave CongestionWindow unchanged

14. Vegas Behavior • Green Line -- Expected throughput • Black Line -- Actual throughput • Shaded area -- region between a and b thresholds

15. Vegas Parameters • Parameters • : 1 packet • : 3 packets • Even faster retransmit • keep fine-grained timestamps for each packet • check for timeout on first duplicate ACK

16. Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) Major research issue Principles of Congestion Control

17. Consequences of Congestion • Large delays: throughput vs delay trade-off • We don’t want to operate near capacity • Finite buffers: lost packets • Resending of packets causes • More packets for the same goodput • Wasted bandwidth of the packet that gets dropped

18. two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput Causes/costs of congestion: scenario 1

19. one router, finite buffers sender retransmission of lost packet Causes/costs of congestion: scenario 2

20. Always: (goodput) If packets are dropped: l’ l = > l l in in out out Causes/costs of congestion: scenario 2

21. Four senders, multihop paths, timeout/retransmit Congestion in one link -> retransmits -> congestion in other links Causes/costs of congestion: scenario 3

22. Causes/costs of congestion: scenario 3 Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted!

23. End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at Approaches towards congestion control Two broad approaches towards congestion control:

24. Router Assisted Congestion Control • Random Early Detection • Explicit Congestion Notification Note: often this is referred to as Active Networking: ie routers are involved in perfomance. Active Nets is a much more general idea

25. RED: Random Early Detection • Idea: routers start dropping packets before they are congested • Benefits: make behavior smoother • How: • When queue is above a thres-1: drop packets with probability p • Issues: • setting the parameters • Estimating the queue size

26. Thresholds • two queue length thresholds • if AvgLen  MinThreshold then • enqueue the packet • if MinThreshold < AvgLen < MaxThreshold • calculate probability P • drop arriving packet with probability P • if MaxThreshold  AvgLen • drop arriving packet

27. RED: probability P • Not fixed • Function of AvgLen and how long since last drop (count) keeps track of new packets that have been queued while AvgLen has been between the two thresholds • TempP = MaxP * (AvgLen - MinThreshold) /(MaxThreshold - MinThreshold) • P = TempP/(1 - count * TempP) • MaxP is often set to 0.02, meaning that the gateway drops 1 out of 50 packets when queue size is halfway between MinThreshold and MaxThreshold

28. Comments on RED • Probability of dropping a particular flow's packet(s) is roughly proportional to the share of the bandwidth that flow is currently getting • MaxP is typically set to 0.02, meaning that when the average queue size is halfway between the two thresholds, the gateway drops roughly one out of 50 packets.

29. RED: Dropping probability P(drop) 1.0 MaxP A vgLen MinThresh MaxThresh

30. Selecting Parameters • if traffic is bursty, then MinThreshold should be sufficiently large to allow link utilization to be maintained at an acceptably high level • The difference between two thresholds should be larger than the typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is reasonable for traffic on today's Internet

31. Explicit Congestion Notification • Dropping packets = Warn of congestion • Idea: mark packets to notify congestion • How: • Congested router marks packet (sets a bit) • Receiver “copies” bit in the ACK • Sender reduces its window • Benefit: proactive without losing packets • Problem: sender can ignore it

32. Current Beliefs • RED + ECN are considered to be good • RED alone has problems

33. principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control instantiation and implementation in the Internet UDP TCP Summary

34. Unused Slides

35. receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow flow control TCP Flow Control sender won’t overrun receiver’s buffers by transmitting too much, too fast RcvBuffer= size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver buffering

36. TCP Vegas Details • Value of throughput with no congestion is compared to current throughput • If current difference is small, increase window size linearly • If current difference is large, decrease window size linearly • The change in the Slow Start Mechanism consists of doubling the window every other RTT, rather than every RTT and of using a boundary in the difference between throughputs to exit the Slow Start phase, rather than a window size value.

37. Expected and Actual Rates • The source computes an Expected Rate -- Expected Rate = CongestionWindow/BaseRTT • Actual Rate is also computed -- number of bytes transmitted during the RTT of a tagged packet. • Diff = Expected Rate - Actual Rate. • Note that the Diff is always greater than or equal to zero (BaseRTT is the lowest !).

38. Vegas Rules • Define two thresholds a and b. • If Diff < a, TCP vegas increases congestion window linearly during next RTT. • If Diff > b, it decreases the congestion window linearly. • If a < Diff < b, TCP vegas leaves the congestion window as is.

39. A Visit to Vegas • Having routers participate in congestion control requires changes to core routers -difficult. • It is better to do this end-to-end. • However, we want to still have source based control -- now, it would be source-based congestion avoidance. • We need a TCP that watches out for signs of congestion --TCP Vegas.