Presentation is loading. Please wait.

Presentation is loading. Please wait.

CPSC 441:TCP1 Instructor: Anirban Mahanti Office: ICT 745 Class Location: ICT 121 Lectures: MWF 12:00 – 12:50 Notes derived.

Similar presentations


Presentation on theme: "CPSC 441:TCP1 Instructor: Anirban Mahanti Office: ICT 745 Class Location: ICT 121 Lectures: MWF 12:00 – 12:50 Notes derived."— Presentation transcript:

1 CPSC 441:TCP1 Instructor: Anirban Mahanti Office: ICT Class Location: ICT 121 Lectures: MWF 12:00 – 12:50 Notes derived from “ Computer Networking: A Top Down Approach Featuring the Internet”, 2005, 3 rd edition, Jim Kurose, Keith Ross, Addison-Wesley. Slides are adapted from the companion web site of the book, as modified by Anirban Mahanti (and Carey Williamson). Transmission Control Protocol

2 CPSC 441:TCP2 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)

3 CPSC 441:TCP3 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

4 CPSC 441:TCP4 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 A Host B Seq=42, ACK=79, data Seq=79, ACK=1043, no data Seq=1043, ACK=79, data 1000 byte data Host sends another 500 bytes host ACKs receipt of data time Seq=79, ACK=1544, no data

5 CPSC 441:TCP5 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 timeout events m duplicate acks r Initially consider simplified TCP sender: m ignore duplicate acks m ignore flow control, congestion control

6 CPSC 441:TCP6 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

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

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

9 CPSC 441:TCP9 TCP Flow control: how it works (Suppose TCP receiver discards out-of-order segments)  spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]  Rcvr advertises spare room by including value of RcvWindow in segments  Sender limits unACKed data to RcvWindow m guarantees receive buffer doesn’t overflow

10 CPSC 441:TCP10 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”

11 CPSC 441:TCP11 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.

12 CPSC 441:TCP12 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

13 CPSC 441:TCP13 TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s  buffers, flow control info (e.g. RcvWindow ) r client: connection initiator Socket clientSocket = new Socket("hostname","port number"); r server: contacted by client Socket connectionSocket = welcomeSocket.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 m server allocates buffers m specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data

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

15 CPSC 441:TCP15 TCP Connection Termination client FIN server ACK FIN closing timed wait FIN_WAIT1 FIN_WAIT2 CLOSE_WAIT LAST_ACK CLOSED TIME_WAIT CLOSED

16 CPSC 441:TCP16 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 Packet loss (buffer overflow at routers) m Increased end-to-end delays (queuing in router buffers) r Results in unfairness and poor utilization of network resources m Resources used by dropped packets (before they were lost) m Retransmissions m Poor resource allocation at high load

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

18 CPSC 441:TCP18 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

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

20 CPSC 441:TCP20 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

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

22 CPSC 441:TCP22 ACK data segment Congestion Avoidance r Starts when W  ssthresh r On each successful ACK: W  W+ 1/W r Linear growth of W each RTT: W  W receiversender

23 CPSC 441:TCP23 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” m ssthresh = W/2 m Enter Slow Start

24 CPSC 441:TCP24 Detecting Packet Loss r Assumption: loss indicates congestion r Option 1: time-out m Waiting for a time-out can be long! r Option 2: duplicate ACKs m How many? At least X SenderReceiver

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

26 CPSC 441:TCP26 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

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

28 CPSC 441:TCP28 TCP Round-Trip Time and Timeout EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT r EWMA r influence of past sample decreases exponentially fast  typical value:  = 0.125

29 CPSC 441:TCP29 TCP Round Trip Time and Timeout Setting the timeout  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin r first estimate how much SampleRTT deviates from EstimatedRTT: TimeoutInterval = µ*EstimatedRTT + Ø*DevRTT Typically, µ =1 and Ø = 4. DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: [Jacobson/Karels Algorithm]

30 CPSC 441:TCP30 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++ (SS) else W += 1/W (CA) } for every loss { ssthresh = W/2 W = 1 }

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

32 CPSC 441:TCP32 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?

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

34 CPSC 441:TCP34 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

35 CPSC 441:TCP35 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

36 CPSC 441:TCP36 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/2RTT. r Average throughout:.75 W/RTT

37 CPSC 441:TCP37 TCP Futures 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· Wow r New versions of TCP for high-speed needed!

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

39 CPSC 441:TCP39 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

40 CPSC 441:TCP40 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”


Download ppt "CPSC 441:TCP1 Instructor: Anirban Mahanti Office: ICT 745 Class Location: ICT 121 Lectures: MWF 12:00 – 12:50 Notes derived."

Similar presentations


Ads by Google