Ch 7 Internet Transport Protocols 1 TCP reliable

Ch. 7 : Internet Transport Protocols 1

TCP reliable data transfer r TCP creates reliable r r service on top of IP’s unreliable service pipelined segments cumulative acks single retransmission timer 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 -2

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 un. ACKed segment) r expiration interval: Time. Out. Interval timeout: r retransmit segment that caused timeout r restart timer ACK rcvd: r if acknowledges previously un. ACKed segments m m update what is known to be ACKed start timer if there are outstanding segments 3 -3

Next. Seq. Num = Initial. Seq. Num Send. Base = Initial. Seq. Num loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number Next. Seq. Num if (timer currently not running) start timer pass segment to IP Next. Seq. Num = Next. Seq. Num + 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 > Send. Base) { Send. Base = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP sender (simplified) Comment: • Send. Base-1: last cumulatively ACKed byte Example: • Send. Base-1 = 71; y= 73, so the rcvr wants 73+ ; y > Send. Base, so that new data is ACKed Trans 3 -4 port

TCP actions on receiver events: application takes data: data rcvd from IP: r free the room in r if Checksum fails, ignore buffer segment r give the freed cells r If checksum OK, then : new numbers if data came in order: m circular numbering r update AN+WIN r WIN increases by the number of bytes taken 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 -5

TCP: retransmission scenarios Host A start timer for SN 92 stop timer start timer for SN 100 stop timer SN=9 2, 8 b ytes SN=1 00 Host A Host B data start timer for SN 92 Host B SN=92 , 8 byt es dat a 100 AN= , 20 b ytes d ata 0 =12 AN NO timer X loss TIMEOUT start timer for new SN 92 timer setting actual timer run , 8 byt es dat a 100 AN= stop timer time. A. normal scenario SN=92 NO timer time B. lost ACK + retransmission 3 -6

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

TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver TCP Receiver action Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK Arrival of in-order segment with expected seq #. One other segment has ACK pending Immediately send single cumulative ACK, ACKing both in-order segments Arrival of out-of-order segment with higher-than-expect seq. #. Gap detected Immediately send duplicate ACK, indicating seq. # of next expected byte This Ack carries no data Arrival of segment that partially or completely fills gap Immediate send ACK, provided that segment starts at lower end of gap Transport Layer 3 -8

Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate ACKs. m m sender often sends many segments back-toback 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 -9

Host A Host B seq # x 1 seq # x 2 seq # x 3 seq # x 4 seq # x 5 triple duplicate ACKs X ACK x 1 seq X 2 timeout resend time Transport Layer 3 -10

Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > Send. Base) { Send. Base = 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 } a duplicate ACK for already ACKed segment fast retransmit Transport Layer 3 -11

TCP: Flow Control 12

TCP Flow Control for A’s data flow control r receive side of TCP connection at B has a receive buffer: Receive Buffer data taken by application TCP data in buffer spare room AN data from IP (sent by TCP at A) WIN node B : Receive process 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 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 133 -

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

TCP: setting timeouts 17

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

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

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

Setting Timeout Problem: r using the average of Sample. RTT will generate many timeouts due to network variations Solution: r freq. Estimted. RTT plus “safety margin” m RTT large variation in Estimated. RTT -> larger safety margin Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (typically, = 0. 25) Then set timeout interval: Timeout. Interval = Estimated. RTT + 4*Dev. RTT 21

An Example TCP Session 22

TCP: Congestion Control 24

TCP Congestion Control r Closed-loop, end-to-end, window-based congestion control r Designed by Van Jacobson in late 1980 s, 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 http: //lxr. linux. no/source/net/ipv 4/tcp_input. c for linux implementation 25

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 26

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

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

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

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 30

TCP Reno cwnd Trace 31

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 loss, so decrease rate sending rate X X X TCP’s “sawtooth” behavior X time r Q: how fast to increase/decrease? m details to follow Transport Layer 3 -32

TCP Congestion Control: details r sender limits rate by limiting number of un. ACKed bytes “in pipeline”: Last. Byte. Sent-Last. Byte. Acked cwnd m cwnd: differs from rwnd (how, why? ) m sender limited by min(cwnd, rwnd) r roughly, rate = cwnd RTT cwnd bytes/sec r cwnd is dynamic, function of perceived network congestion RTT ACK(s) Transport Layer 3 -33

TCP Congestion Control: more details segment loss event: reducing cwnd r timeout: no response from receiver m cut cwnd to 1 r 3 duplicate ACKs: at least some segments getting through (recall fast retransmit) m 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 cut cwnd in half, less aggressively than on timeout Transport Layer 3 -34

TCP Slow Start r when connection begins, cwnd = Host A RTT 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 m double cwnd every RTT m done by incrementing cwnd by 1 for every ACK received Host B one segme nt two segme nts four segme nts time Transport Layer 3 -35

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

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

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

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

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

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

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/2 RTT. m average throughout: . 75 W/RTT Transport Layer 3 -42

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

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

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 m new app asks for 1 TCP, gets rate R/10 new app asks for 11 TCPs, gets R/2 ! Transport Layer 3 -45