1. Chapter 3 Transport Layer slides are modified from J. Kurose & K. Ross CPE 400 / 600 Computer Communication Networks Lecture 12

2. Transport Layer 2 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP r 3.6 Principles of congestion control r 3.7 TCP congestion control

3. Transport Layer 3 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control! r manifestations:  lost packets (buffer overflow at routers)  long delays (queueing in router buffers) r a top-10 problem!

4. Transport Layer 4 Causes/costs of congestion: scenario 1 r two senders, two receivers r one router, infinite buffers r no retransmission r large delays when congested r maximum achievable throughput unlimited shared output link buffers Host A in : original data Host B out

5. Transport Layer 5 Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

6. Transport Layer 6 Causes/costs of congestion: scenario 2 r always: (goodput) r “perfect” retransmission only when loss: r retransmission of delayed (not lost) packet makes larger (than perfect case) for same in out = in out > in out “costs” of congestion: r more work (retrans) for given “goodput” r unneeded retransmissions: link carries multiple copies of pkt R/2 in out b. R/2 in out a. R/2 in out c. R/4 R/3

7. Transport Layer 7 Causes/costs of congestion: scenario 3 r four senders r multihop paths r timeout/retransmit in Q: what happens as and increase ? in finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

8. Transport Layer 8 Causes/costs of congestion: scenario 3 Another “cost” of congestion: r when packet dropped, any “upstream transmission capacity used for that packet was wasted! HostAHostA HostBHostB o u t

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

10. Transport Layer 10 Lecture 12 outline r 3.6 Principles of congestion control r 3.7 TCP congestion control

11. Transport Layer 11 TCP congestion control: additive increase, multiplicative decrease r Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs m additive increase: increase CongWin by 1 MSS every RTT until loss detected m multiplicative decrease: cut CongWin in half after loss congestion window size time Saw tooth behavior: probing for bandwidth

12. Transport Layer 12 TCP Congestion Control: details r sender limits transmission: LastByteSent-LastByteAcked  CongWin r Roughly,  CongWin is dynamic, function of perceived network congestion How does sender perceive congestion?  loss event = timeout or 3 duplicate acks  TCP sender reduces rate ( CongWin ) after loss event three mechanisms:  AIMD  slow start  conservative after timeout events rate = CongWin RTT Bytes/sec

13. Transport Layer 13 TCP Slow Start  When connection begins, CongWin = 1 MSS  Example: MSS = 500 bytes & RTT = 200 msec  initial rate = 20 kbps r available bandwidth may be >> MSS/RTT  desirable to quickly ramp up to respectable rate r When connection begins, increase rate exponentially fast until first loss event  double CongWin every RTT  done by incrementing CongWin for every ACK received

14. Transport Layer 14 TCP Slow Start (more) r Summary: initial rate is slow but ramps up exponentially fast Host A one segment RTT Host B time two segments four segments

15. Transport Layer 15 Refinement: inferring loss r After 3 dup ACKs:  CongWin is cut in half  window then grows linearly r But after timeout event:  CongWin instead set to 1 MSS;  window then grows exponentially  to a threshold, then grows linearly  3 dup ACKs indicates network capable of delivering some segments  timeout indicates a “more alarming” congestion scenario Philosophy:

16. Transport Layer 16 Refinement Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: r Variable Threshold r At loss event, Threshold is set to 1/2 of CongWin just before loss event

17. Transport Layer 17 Summary: TCP Congestion Control  When CongWin is below Threshold, sender in slow- start phase, window grows exponentially.  When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.  When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.  When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

18. Transport Layer 18 TCP sender congestion control StateEventTCP Sender ActionCommentary Slow Start (SS) ACK receipt for previously unacked data CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) ACK receipt for previously unacked data CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT SS or CALoss event detected by triple duplicate ACK Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. SS or CATimeoutThreshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” Enter slow start SS or CADuplicate ACK Increment duplicate ACK count for segment being acked CongWin and Threshold not changed

19. Transport Layer 19 TCP throughput r What’s the average throughout of TCP as a function of window size and RTT?  Ignore slow start r Let W be the window size when loss occurs. r When window is W, throughput is W/RTT r Just after loss, window drops to W/2, throughput to W/2RTT. r Average throughout:.75 W/RTT

20. Transport Layer 20 TCP Futures: TCP over “long, fat pipes” r Example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput r Requires window size W = 83,333 in-flight segments r Throughput in terms of loss rate:  ➜ L = 2·10 -10 Wow r New versions of TCP for high-speed

21. Transport Layer 21 Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck router capacity R TCP connection 2 TCP Fairness

22. Transport Layer 22 Why is TCP fair? Two competing sessions: r Additive increase gives slope of 1, as throughout increases r multiplicative decrease decreases throughput proportionally R R equal bandwidth share Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2

23. Transport Layer 23 Fairness (more) Fairness and UDP r Multimedia apps often do not use TCP  do not want rate throttled by congestion control r Instead use UDP:  pump audio/video at constant rate, tolerate packet loss r Research area: TCP friendly Fairness and parallel TCP connections r nothing prevents app from opening parallel connections between 2 hosts. r Web browsers do this r Example: link of rate R supporting 9 connections;  new app asks for 1 TCP, gets rate R/10  new app asks for 11 TCPs, gets R/2 !

24. Transport Layer 24 Chapter 3: Summary r principles behind transport layer services:  multiplexing, demultiplexing  reliable data transfer  flow control  congestion control r instantiation and implementation in the Internet  UDP  TCP Next: r leaving the network “edge” (application, transport layers) r into the network “core”