1. 10/7/2003-10/9/2003 TCP and Congestion Control October 7-9, 2003

2. 10/7/2003-10/9/2003 Assignments Finish chapter 3 Finish up your project!

3. 10/7/2003-10/9/2003 TCP: Overview Point-to-Point –one sender, one receiver Connection-oriented –handshaking (exchange of control msgs) Reliable, in order data delivery Pipelined Full duplex data Flow controlled –sender will not overwhelm receiver

4. 10/7/2003-10/9/2003 TCP Example Application data placed in send buffer Data taken from send buffer and placed in segment (data + header) –Max amount of data is MSS Data placed in receive buffer App reads from receiver buffer Applet

5. 10/7/2003-10/9/2003 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

6. 10/7/2003-10/9/2003 Seq #’s and ACKs Seq #’s –Byte stream “number” of first byte in segment’s data –First is randomly chosen ACKs –Seq # of next byte expected from other side –Cumulative ACK –Piggybacking Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

7. 10/7/2003-10/9/2003 Round Trip Time and Timeout TCP uses timeout mechanism How can we determine the timeout value? –Must be longer than RTT –Too short? –Too long? Take SampleRTT – but RTT varies

8. 10/7/2003-10/9/2003 Round Trip Time and Timeout EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT Exponential weighted moving average Influence of past sample decreases exponentially fast Typical value:  = 0.125

9. 10/7/2003-10/9/2003 Example RTT Estimation

10. 10/7/2003-10/9/2003 Round Trip Time and Timeout Timeout also takes into account how much the EstimatedRTT deviates from the SampleRTT TimeoutInterval = EstimatedRTT + 4*DevRTT

11. 10/7/2003-10/9/2003 TCP Reliable Data Transfer TCP creates rdt service on top of IP’s unreliable service –Reliable, in order delivery Pipelined segments Cumulative acks TCP uses single retransmission timer –Retransmit triggered by timeout and duplicate ACK Consider simplified design –No duplicate ACKs, flow control, or congestion control

12. 10/7/2003-10/9/2003 TCP Sender Events Data received from app –Create segment with seq # –seq # is byte-stream number of first data byte in segment –Start timer if not already running (think of timer as for oldest unacked segment) –Expiration interval: TimeOutInterval Timeout –Retransmit segment that caused timeout –Restart timer Ack rcvd –If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments

13. 10/7/2003-10/9/2003 Retransmit Scenarios Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

14. 10/7/2003-10/9/2003 Retransmit Scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120

15. 10/7/2003-10/9/2003 TCP ACK Generation Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

16. 10/7/2003-10/9/2003 Fast Retransmit Time-out period often relatively long –long delay before resending lost packet Detect lost segments via duplicate ACKs –Sender often sends many segments back-to-back –If segment is lost, there will likely be many duplicate ACKs If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost –fast retransmit: resend segment before timer expires

17. 10/7/2003-10/9/2003 TCP Flow Control Need to keep sender from sending too fast for receiver Match sending rate with receiver “drain” rate

18. 10/7/2003-10/9/2003 Operation RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow –guarantees receive buffer doesn’t overflow Sender actually continues to send 1-byte pkts after receiver window is full – WHY?

19. 10/7/2003-10/9/2003 TCP Connection Management Sender and receiver establish “connection” before exchanging data segments Initialize TCP variables –seq. #s –buffers, flow control info (e.g. RcvWindow) Client initiates connection –Socket clientSocket = new Socket("hostname","port number"); Server accepts connection –Socket connectionSocket = welcomeSocket.accept();

20. 10/7/2003-10/9/2003 TCP Connection Management Three way handshake –Step 1: client host sends TCP SYN segment to server specifies initial seq # no data –Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server initial seq. # –Step 3: client receives SYNACK, replies with ACK segment, which may contain data

21. 10/7/2003-10/9/2003 Three-way Handshake client SYN=1, seq=12345 server SYN=1, seq=98765, ack=12346 SYN=0, seq=12346, ack=98766 Connection Request Connection Granted ACK

22. 10/7/2003-10/9/2003 TCP Connection Management Closing a connection –client closes socket: clientSocket.close(); –Step 1: client end system sends TCP FIN control segment to server –Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. –Step 3: client receives FIN, replies with ACK. –Enters “timed wait” - will respond with ACK to received FINs –Step 4: server, receives ACK. Connection closed.

23. 10/7/2003-10/9/2003 Teardown client FIN server ACK FIN close closed timed wait

24. 10/7/2003-10/9/2003 Principles of Congestion Control 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)

25. 10/7/2003-10/9/2003 Scenario 1: Queuing Delays two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput unlimited shared output link buffers Host A in : original data Host B out

26. 10/7/2003-10/9/2003 Scenario 2: Retransmits One router, finite buffers Sender retransmission of lost packet –Original packet dropped –Original packet delayed finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

27. 10/7/2003-10/9/2003 Scenario 3: Congestion Near Receiver four senders multihop paths timeout/retransmit finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

28. 10/7/2003-10/9/2003 Approaches 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

29. 10/7/2003-10/9/2003 TCP Congestion Control End-end control (no network assistance) Sender limits transmission LastByteSent-LastByteAcked  CongWin CongWin is dynamic, function of perceived network congestion Different than the RcvWindow

30. 10/7/2003-10/9/2003 TCP Congestion Control How does sender perceive congestion? –loss event = timeout or 3 duplicate acks –Is this always a good measure? –TCP sender reduces rate (CongWin) after loss event Three components of CC algorithm –AIMD –slow start –conservative after timeout events

31. 10/7/2003-10/9/2003 TCP AIMD – Congestion Avoidance Multiplicative Decrease –cut CongWin in half after loss event Additive Increase –increase CongWin by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection

32. 10/7/2003-10/9/2003 TCP Slow Start When connection begins, CongWin = 1 MSS –Example: MSS = 500 bytes & RTT = 200 msec –initial rate = 20 kbps Available bandwidth may be >> MSS/RTT –desirable to quickly ramp up to respectable rate When connection begins, increase rate exponentially fast until first loss event –Double CongWin every RTT until a loss –After loss – reduce CongWin by ½ and increase linerarly

33. 10/7/2003-10/9/2003 Slow Start Example Double CongWin every RTT –done by incrementing CongWin for every ACK received Host A one segment RTT Host B time two segments four segments

34. 10/7/2003-10/9/2003 Timeout Events After 3 dup ACKs –CongWin is cut in half –window then grows linearly But, after timeout event –CongWin instead set to 1 MSS –window then grows exponentially to a threshold (1/2 previous CongWin size), then grows linearly Idea – 3 dup ACKs indicates network capable of delivering some segments –timeout before 3 dup ACKs is “more alarming ”

35. 10/7/2003-10/9/2003 Threshold –Starts at 65K –Set to ½ CongWin when loss event occurs TCP Tahoe vs TCP Reno 0 2 4 6 8 10 12 14 123456789101112131415 Transmission round congestion window size (segments) Series1Series2

36. 10/7/2003-10/9/2003 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