1 Ch. 7 : Internet Transport Protocols

3-2 TCP reliable data transfer r TCP creates reliable service on top of IP’s unreliable service r pipelined segments r cumulative acks r single retransmission timer r receiver accepts out of order segments but does not acknowledge them r Retransmissions are triggered by timeout events r Initially consider simplified TCP sender: m ignore flow control, congestion control

3-3 TCP sender events: data rcvd from app: r create segment with seq # r seq # is byte-stream number of first data byte in segment r start timer if not already running (think of timer as for oldest unACKed segment)  expiration interval: TimeOutInterval timeout: r retransmit segment that caused timeout r restart timer ACK rcvd: r if acknowledges previously unACKed segments m update what is known to be ACKed m start timer if there are outstanding segments

Transp ort Layer 3-4 TCP sender (simplified) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ Comment: SendBase-1: last cumulatively ACKed byte Example: SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is ACKed

3-5 TCP actions on receiver events: application takes data: r free the room in buffer r give the freed cells new numbers m circular numbering r WIN increases by the number of bytes taken data rcvd from IP: r if Checksum fails, ignore segment r If checksum OK, then : if data came in order: r update AN+WIN r AN grows by the number of new in-order bytes r WIN decreases by same # if data out of order: r Put in buffer, but don’t count it for AN/ WIN

3-6 TCP: retransmission scenarios stop timer start timer for SN 100 Host A AN=100 time A. normal scenario Host B AN=120 SN=100, 20 bytes data SN=92, 8 bytes data start timer for SN 92 NO timer start timer for new SN 92 AN=100 Host A SN=92, 8 bytes data X loss B. lost ACK + retransmission Host B SN=92, 8 bytes data AN=100 time start timer for SN 92 TIMEOUT NO timer stop timer timer setting actual timer run

3-7 אפקה תשע"א ס"ב Transport Layer 3-7 TCP retransmission scenarios (more) see also slide 47 AN=100 Host A SN=92, 8 bytes data X loss C. lost ACK, NO retransmission Host B SN=100, 20 bytes data AN=120 time start timer for SN 92 stop timer NO timer Host A time D. premature timeout Host B SN=92, 8 bytes data AN=120 start timer for SN 92 TIMEOUT NO timer star fort 92 stop start for 100 stop SN=100, 20 bytes data AN=100 AN=120 SN=92, 8 bytes data redundant ACK

Transport Layer 3-8 TCP ACK generation [RFC 1122, RFC 2581] 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 with 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 This Ack carries no data Immediate send ACK, provided that segment starts at lower end of gap

Transport Layer 3-9 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate ACKs. m sender often sends many segments back-to- back m if segment is lost, there will likely be many duplicate ACKs for that segment r If sender receives 3 ACKs for same data, it assumes that segment after ACKed data was lost: m fast retransmit: resend segment before timer expires

Transport Layer 3-10 Host A timeout Host B time X resend seq X2 seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 ACK x1 triple duplicate ACKs

Transport Layer 3-11 event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } Fast retransmit algorithm: a duplicate ACK for already ACKed segment fast retransmit

12 TCP: Flow Control

3-13 TCP Flow Control for A’s data r receive side of TCP connection at B has a receive buffer: r flow control matches the send rate of A to the receiving application’s drain rate at B r Receive buffer size set by OS at connection init r WIN = window size = number bytes A may send starting at AN r application process at B may be slow at reading from buffer sender won’t overflow receiver’s buffer by transmitting too much, too fast flow control node B : Receive process Receive Buffer data taken by application TCP data in buffer spare room WIN data from IP (sent by TCP at A) AN

3-14 אפקה תשע"א ס"ב TCP Flow control: how it works Formulas :  AN = first byte not received yet m sent to A in TCP header  AckedRange = = AN – FirstByteNotReadByAppl = = # bytes rcvd in sequence & not taken  WIN = RcvBuffer – AckedRange = SpareRoom r AN and WIN sent to A in TCP header r Data rcvd out of sequence is considered part of ‘spare room’ range Procedure:  Rcvr advertises “spare room” by including value of WIN in his segments  Sender A is allowed to send at most WIN bytes in the range starting with AN m guarantees that receive buffer doesn’t overflow node B : Receive process ACKed data in buffer Rcv Buffer data from IP data taken by application WIN (sent by TCP at A) s p a r e r o o m non-ACKed data in buffer (arrived out of order) ignored AN

3-15 אפקה תשע"א ס"ב בקרת זרימה של TCP – דוגמה 1

3-16 אפקה תשע"א ס"ב בקרת זרימה של TCP – דוגמה 2

17 TCP: setting timeouts

18 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT m note: RTT will vary r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions, cumulatively ACKed segments  SampleRTT will vary, want estimated RTT “smoother”  use several recent measurements, not just current SampleRTT

19 High-level Idea Set timeout = average + safe margin

20 Estimating Round Trip Time EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT r Exponential weighted moving average r influence of past sample decreases exponentially fast  typical value:  =  SampleRTT : measured time from segment transmission until ACK receipt  SampleRTT will vary, want a “smoother” estimated RTT use several recent measurements, not just current SampleRTT

21 Setting Timeout Problem:  using the average of SampleRTT will generate many timeouts due to network variations Solution:  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: RTT freq.

22 An Example TCP Session

23 TCP Round Trip Time and Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT r Exponential weighted moving average r influence of given sample decreases exponentially fast r typical value of x: 0.1 Setting the timeout  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

24 TCP: Congestion Control

25 TCP Congestion Control r Closed-loop, end-to-end, window-based congestion control r Designed by Van Jacobson in late 1980s, based on the AIMD alg. of Dah-Ming Chu and Raj Jain r Works well so far: the bandwidth of the Internet has increased by more than 200,000 times r Many versions m TCP/Tahoe: this is a less optimized version m TCP/Reno: many OSs today implement Reno type congestion control m TCP/Vegas: not currently used For more details: see TCP/IP illustrated; or read for linux implementation

26 TCP & AIMD: congestion r Dynamic window size [Van Jacobson] m Initialization: MI Slow start m Steady state: AIMD Congestion Avoidance r Congestion = timeout m TCP Tahoe r Congestion = timeout || 3 duplicate ACK m TCP Reno & TCP new Reno r Congestion = higher latency m TCP Vegas

27 Visualization of the Two Phases threshold Congwing Slow start Congestion avoidance

28 TCP Slowstart: MI r exponential increase (per RTT) in window size (not so slow!) r In case of timeout: m Threshold=CongWin/2 initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (congestion event OR CongWin > threshold) Slowstart algorithm Host A one segment RTT Host B time two segments four segments

29 TCP Tahoe Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (timeout) { /* loss event */ every ACK: Congwin += 1/Congwin } threshold = Congwin/2 Congwin = 1 perform slowstart Congestion avoidance TCP Taheo

30 TCP Reno r Fast retransmit: m Try to avoid waiting for timeout r Fast recovery: m Try to avoid slowstart. m used only on triple duplicate even m Single packet drop: not too bad

31 TCP Reno cwnd Trace

Transport Layer3-32 TCP congestion control: bandwidth probing r “probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate m continue to increase on ACK, decrease on loss (since available bandwidth is changing, depending on other connections in network) ACKs being received, so increase rate X X X X X loss, so decrease rate sending rate time r Q: how fast to increase/decrease? m details to follow TCP’s “sawtooth” behavior

Transport Layer3-33 TCP Congestion Control: details r sender limits rate by limiting number of unACKed bytes “in pipeline”:  cwnd: differs from rwnd (how, why?)  sender limited by min(cwnd,rwnd) r roughly,  cwnd is dynamic, function of perceived network congestion rate = cwnd RTT bytes/sec LastByteSent-LastByteAcked  cwnd cwnd bytes RTT ACK(s)

Transport Layer3-34 TCP Congestion Control: more details segment loss event: reducing cwnd r timeout: no response from receiver  cut cwnd to 1 r 3 duplicate ACKs: at least some segments getting through (recall fast retransmit)  cut cwnd in half, less aggressively than on timeout ACK received: increase cwnd r slowstart phase: m start low (cwnd=MSS) m increase cwnd exponentially fast (despite name) m used: at connection start, or following timeout r congestion avoidance: m increase cwnd linearly

Transport Layer3-35 TCP Slow Start  when connection begins, cwnd = 1 MSS m example: MSS = 500 bytes & RTT = 200 msec m initial rate = 20 kbps r available bandwidth may be >> MSS/RTT m desirable to quickly ramp up to respectable rate r increase rate exponentially until first loss event or when threshold reached  double cwnd every RTT  done by incrementing cwnd by 1 for every ACK received Host A one segment RTT Host B time two segments four segments

Transport Layer3-36 Transitioning into/out of slowstart ssthresh: cwnd threshold maintained by TCP  on loss event: set ssthresh to cwnd/2 ; gp to slowstart  remember (half of) TCP rate when congestion last occurred  when cwnd >= ssthresh : transition from slowstart to congestion avoidance phase slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s),as allowed new ACK dupACKcount++ if dupACKcount=3 set cwind=1MSS duplicate ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0 congestion avoidance

Transport Layer3-37 TCP: congestion avoidance  when cwnd > ssthresh grow cwnd linearly  increase cwnd by 1 MSS per RTT m approach possible congestion slower than in slowstart  implementation: cwnd = cwnd + MSS^2/cwnd for each ACK received  ACKs: increase cwnd by 1 MSS per RTT: additive increase  loss: cut cwnd in half (non-timeout-detected loss ): multiplicative decrease m true in macro picture m may require Slow Start first to grow up to this AIMD AIMD: Additive Increase Multiplicative Decrease

Transport Layer3-38 TCP congestion control FSM: overview slow start congestion avoidance fast recovery cwnd > ssthresh loss: timeout loss: timeout new ACK loss: 3dupACK loss: 3dupACK loss: timeout

Transport Layer3-39 TCP congestion control FSM: details slow start congestion avoidance fast recovery timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s),as allowed new ACK cwnd = cwnd + MSS (MSS/cwnd) dupACKcount = 0 transmit new segment(s),as allowed new ACK. dupACKcount++ duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 dupACKcount++ duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 timeout ssthresh = cwnd/2 cwnd = 1 dupACKcount = 0 retransmit missing segment cwnd = cwnd + MSS transmit new segment(s), as allowed duplicate ACK cwnd = ssthresh dupACKcount = 0 New ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0

Transport Layer3-40 Popular “flavors” of TCP ssthresh TCP Tahoe TCP Reno Transmission round cwnd window size (in segments)

Transport Layer3-41 Summary: TCP Congestion Control  when cwnd < ssthresh, sender in slow-start phase, window grows exponentially.  when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly.  when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh  when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.

Transport Layer3-42 TCP throughput r Q: what’s average throughout of TCP as function of window size, RTT? m ignoring slow start r let W be window size when loss occurs. m when window is W, throughput is W/RTT m just after loss, window drops to W/2, throughput to W/2RTT. m average throughout:.75 W/RTT

Transport Layer3-43 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

Transport Layer3-44 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

Transport Layer3-45 Fairness (more) Fairness and UDP r multimedia apps often do not use TCP m do not want rate throttled by congestion control r instead use UDP: m pump audio/video at constant rate, tolerate packet loss 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 already 9 connections; m new app asks for 1 TCP, gets rate R/10 m new app asks for 11 TCPs, gets R/2 !