Transmission Control Protocol Instructor Carey Williamson Office ICT

Transmission Control Protocol Instructor: Carey Williamson Office: ICT 740 Email: carey@cpsc. ucalgary. ca Class Location: ICT 122 Lectures: MWF 12: 00 – 12: 50 Notes derived from “Computer Networking: A Top Down Approach”, by Jim Kurose and Keith Ross, Addison-Wesley. Slides are adapted from the book’s companion Web site, with changes by Anirban Mahanti and Carey Williamson. CPSC 441: TCP 1

TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum Receive window Urg data pnter Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) CPSC 441: TCP 2

Sequence and Acknowledgement Number r TCP views data as unstructured, but ordered stream of bytes. r Sequence numbers are over bytes, not segments r Initial sequence number is chosen randomly r TCP is full duplex – numbering of data is independent in each direction r Acknowledgement number – sequence number of the next byte expected from the sender r ACKs are cumulative CPSC 441: TCP 3

TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementor Host B Host A 1000 byte data Seq=4 2, ACK = 79, da ta ta a no d , 3 4 0 1 CK= A , 9 q=7 host ACKs receipt of data Se Host sends another 500 bytes Seq=1 043, A CK=79 , data , 79 Seq= data o n , 4 =154 K C A CPSC 441: TCP time 4

TCP reliable data transfer r TCP creates rdt service on top of IP’s unreliable service r Pipelined segments r Cumulative acks r TCP uses single retransmission timer r Retransmissions are triggered by: m m timeout events duplicate acks r Initially consider simplified TCP sender: m m ignore duplicate acks ignore flow control, congestion control CPSC 441: TCP 5

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) r expiration interval: Time. Out. Interval timeout: r retransmit segment that caused timeout r restart timer Ack rcvd: r If acknowledges previously unacked segments m m update what is known to be acked start timer if there are outstanding segments CPSC 441: TCP 6

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 ack’ed byte Example: • Send. Base-1 = 71; y= 73, so the rcvr wants 73+ ; y > Send. Base, so that new data is acked CPSC 441: TCP 7

TCP Flow Control r receive side of TCP connection has a receive buffer: flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast r speed-matching r app process may be service: matching the send rate to the receiving app’s drain rate slow at reading from buffer CPSC 441: TCP 8

TCP Flow control: how it works r Rcvr advertises spare (Suppose TCP receiver discards out-of-order segments) r spare room in buffer room by including value of Rcv. Window in segments r Sender limits un. ACKed data to Rcv. Window m guarantees receive buffer doesn’t overflow = Rcv. Window = Rcv. Buffer-[Last. Byte. Rcvd Last. Byte. Read] CPSC 441: TCP 9

Silly Window Syndrome r Recall: TCP uses sliding window r “Silly Window” occurs when small-sized segments are transmitted, resulting in inefficient use of the network pipe r For e. g. , suppose that TCP sender generates data slowly, 1 -byte at a time r Solution: wait until sender has enough data to transmit – “Nagle’s Algorithm” CPSC 441: TCP 10

Nagle’s Algorithm 1. TCP sender sends the first piece of data obtained from the application (even if data is only a few bytes). 2. Wait until enough bytes have accumulated in the TCP send buffer or until an ACK is received. 3. Repeat step 2 for the remainder of the transmission. CPSC 441: TCP 11

Silly Window Continued … r Suppose that the receiver consumes data slowly m Receive Window opens slowly, and thus sender is forced to send small-sized segments r Solutions m Delayed ACK m Advertise Receive Window = 0, until reasonable amount of space available in receiver’s buffer CPSC 441: TCP 12

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e. g. Rcv. Window) r client: connection initiator Socket client. Socket = new Socket("hostname", "port number"); r server: contacted by client Socket connection. Socket = welcome. Socket. accept(); Three way handshake: Step 1: client host sends TCP SYN segment to server m specifies initial seq # m no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers m specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data m CPSC 441: TCP 13

TCP Connection Establishment client CLOSED Passive open SYN/SYN+ACK Active open; SYN server SYN, s eq=x LISTEN x+1 SYN_SENT SYN_RCVD SYN+ACK/ACK SYN K, +AC seq ACK, a ck= =y, a ck=y+ 1 Established Solid line for client Dashed line for server CPSC 441: TCP 14

TCP Connection Termination client server closing FIN_WAIT 1 FIN CLOSE_WAIT ACK TIME_WAIT CLOSED timed wait FIN_WAIT 2 FIN LAST_ACK CLOSED CPSC 441: TCP 15

Principles of Congestion Control r Congestion: informally: “too many sources sending too much data too fast for network to handle” r Different from flow control! r Manifestations: m m Packet loss (buffer overflow at routers) Increased end-to-end delays (queuing in router buffers) r Results in unfairness and poor utilization of network resources m m m Resources used by dropped packets (before they were lost) Retransmissions Poor resource allocation at high load CPSC 441: TCP 16

Historical Perspective r October 1986, Internet had its first congestion collapse r Link LBL to UC Berkeley 400 yards, 3 hops, 32 Kbps m throughput dropped to 40 bps m factor of ~1000 drop! m r Van Jacobson proposes TCP Congestion Control: Achieve high utilization m Avoid congestion m Share bandwidth m CPSC 441: TCP 17

Congestion Control: Approaches r Goal: Throttle senders as needed to ensure load on the network is “reasonable” r End-end congestion control: m no explicit feedback from network m congestion inferred from end-system observed loss, delay m approach taken by TCP r Network-assisted congestion control: m routers provide feedback to end systems m single bit indicating congestion (e. g. , ECN) m explicit rate sender should send at CPSC 441: TCP 18

TCP Congestion Control: Overview r end-end control (no network assistance) r Limit the number of packets in the network to window W r Roughly, rate = W RTT Bytes/sec r W is dynamic, function of perceived network congestion CPSC 441: TCP 19

TCP Congestion Controls r Tahoe (Jacobson 1988) m Slow Start m Congestion Avoidance m Fast Retransmit r Reno (Jacobson 1990) m Fast Recovery r SACK r Vegas (Brakmo & Peterson 1994) m Delay and loss as indicators of congestion CPSC 441: TCP 20

Slow Start r “Slow Start” is used to r r reach the equilibrium state Initially: W = 1 (slow start) On each successful ACK: W W+1 Exponential growth of W each RTT: W 2 x W Enter CA when W >= ssthresh: window size after which TCP cautiously probes for bandwidth receiver sender cwnd 1 2 data segment ACK 3 4 5 6 7 8 CPSC 441: TCP 21

Congestion Avoidance r Starts when W ssthresh r On each successful ACK: sender 1 2 receiver data segment ACK W W+ 1/W r Linear growth of W each RTT: W W+1 3 4 CPSC 441: TCP 22

CA: Additive Increase, Multiplicative Decrease r We have “additive increase” in the absence of loss events r After loss event, decrease congestion window by half – “multiplicative decrease” ssthresh = W/2 m Enter Slow Start m CPSC 441: TCP 23

Detecting Packet Loss r Assumption: loss 10 11 indicates congestion r Option 1: time-out for a time-out can be long! 12 X 13 14 15 m Waiting 16 17 10 11 11 r Option 2: duplicate ACKs m How many? At least 3. 11 11 Sender Receiver CPSC 441: TCP 24

Fast Retransmit r Wait for a timeout is quite long r Immediately retransmits after 3 dup. ACKs without waiting for timeout r Adjusts ssthresh W/2 r Enter Slow Start W=1 CPSC 441: TCP 25

How to Set TCP Timeout Value? r longer than RTT m but RTT varies r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss CPSC 441: TCP 26

How to Estimate RTT? r Sample. RTT: measured time from segment transmission until ACK receipt m ignore retransmissions r Sample. RTT will vary, want estimated RTT “smoother” m average several recent measurements, not just current Sample. RTT CPSC 441: TCP 27

TCP Round-Trip Time and Timeout Estimated. RTT = (1 - )*Estimated. RTT + *Sample. RTT r EWMA r influence of past sample decreases exponentially fast r typical value: = 0. 125 CPSC 441: TCP 28

TCP Round Trip Time and Timeout [Jacobson/Karels Algorithm] Setting the timeout r Estimted. RTT plus “safety margin” m large variation in Estimated. RTT -> larger safety margin r first estimate how much Sample. RTT deviates from Estimated. RTT: Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (typically, = 0. 25) Then set timeout interval: Timeout. Interval = µ*Estimated. RTT + Ø*Dev. RTT Typically, µ =1 and Ø = 4. CPSC 441: TCP 29

TCP Tahoe: Summary r Basic ideas m Gently probe network for spare capacity m Drastically reduce rate on congestion m Windowing: self-clocking m Other functions: round trip time estimation, error recovery for every ACK { if (W < ssthresh) then W++ else W += 1/W } for every loss { ssthresh = W/2 W =1 } (SS) (CA) CPSC 441: TCP 30

TCP Tahoe Window W 2 W 1 ssthresh=W 2/2 ssthresh=W 1/2 Reached initial ssthresh value; switch to CA mode W 2/2 W 1/2 Time Slow Start CPSC 441: TCP 31

Questions? r Q. 1. To what value is ssthresh initialized to at the start of the algorithm? r Q. 2. Why is “Fast Retransmit” triggered on receiving 3 duplicate ACKs (i. e. , why isn’t it triggered on receiving a single duplicate ACK)? r Q. 3. Can we do better than TCP Tahoe? CPSC 441: TCP 32

TCP Reno Note how there is “Fast Recovery” after cutting Window in half Window Reached initial ssthresh value; switch to CA mode Slow Start Time CPSC 441: TCP 33

TCP Reno: Fast Recovery r Objective: prevent `pipe’ from emptying after fast retransmit m each dup ACK represents a packet having left the pipe (successfully received) m Let’s enter the “FR/FR” mode on 3 dup ACKs ssthresh W/2 retransmit lost packet W ssthresh + ndup (window inflation) Wait till W is large enough; transmit new packet(s) On non-dup ACK (1 RTT later) W ssthresh (window deflation) enter CA mode CPSC 441: TCP 34

TCP Reno: Summary r Fast Recovery along with Fast Retransmit used to avoid slow start r On 3 duplicate ACKs m Fast retransmit and fast recovery r On timeout m Fast retransmit and slow start CPSC 441: TCP 35

TCP Throughput r What’s the average throughout ot TCP as a function of window size and RTT? m 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/2 RTT. r Average throughout: . 75 W/RTT CPSC 441: TCP 36

TCP Futures r Example: 1500 byte segments, 100 ms RTT, want 10 Gbps throughput r Requires window size W = 83, 333 in-flight segments r Throughput in terms of loss rate: r ➜ L = 2·10 -10 Wow r New versions of TCP for high-speed needed! CPSC 441: TCP 37

TCP 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 CPSC 441: TCP 38

Fairness (more) r TCP fairness: dependency on RTT m Connections with long RTT get less throughput r Parallel TCP connections r TCP friendliness for UDP streams CPSC 441: TCP 39

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