Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer – TCP 1 BBBB TCP Flow Control, Congestion Control, Connection Management, etc. Part 2.

Similar presentations


Presentation on theme: "Transport Layer – TCP 1 BBBB TCP Flow Control, Congestion Control, Connection Management, etc. Part 2."— Presentation transcript:

1 Transport Layer – TCP 1 BBBB TCP Flow Control, Congestion Control, Connection Management, etc. Part 2

2 Transport Layer – TCP 2 BBBB Encapsulation in TCP/IP IP datagram

3 Transport Layer – TCP 3 BBBB TCP: Overview  full duplex data:  bi-directional app. data flow in same connection  MSS  MSS: maximum segment size  connection-oriented:  handshaking (exchange of control msgs) init's sender, receiver state before data exchange  flow controlled:  sender will not ''flood'' receiver with data  point-to-point:  one sender, one receiver  reliable, in-order byte stream:  no message boundaries  pipelined:  TCP congestion and flow control set window size  send & receive buffers Error detection, retransmission, cumulative ACKs, timers, header fields for sequence and ACK numbers socket door TCP send buffer TCP receive buffer socket door segment application writes data application reads data

4 Transport Layer – TCP 4 BBBB Recall  Reliable Data Transfer Mechanisms:  Checksum  Timer  Sequence number  ACK  NAK  Window, pipelining socket door TCP send buffer TCP receive buffer socket door Packet -> application writes data application reads data - Verification of integrity of packet - Signals necessary re-transmission is required - Keeps track of which packet has been sent and received - Indicates receipt of packet in good or bad form - Allows for the sending of multiple yet-to-be-acknowledged packets

5 Transport Layer – TCP 5 BBBB Internet Checksum Example  Note  When adding numbers, a carryout from the most significant bit needs to be added to the result  Example: add two 16-bit integers wraparound sum checksum To check: data 1

6 Transport Layer – TCP 6 BBBB Connection Oriented Transport: TCP  TCP Segment Structure  SEQ and ACK numbers  Calculating the Timeout Interval  The Simplified TCP Sender  ACK Generation Recommendation (RFC 1122, RFC 2581)  Interesting Transmission Scenarios  Flow Control  TCP Connection Management

7 Transport Layer – TCP 7 BBBB TCP segment structure source port # dest. port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size URGent data ptrchecksum F S R 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 established (setup, tear down commands) # bytes the rcvr is willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP) In practice, PSH, URG, and the Urgent Data Pointer are not used. Header We can view these teeny-weeny details using Ethereal.

8 Transport Layer – TCP 8 BBBBExample Suppose that a process in Host A wants to send a stream of data to a process in Host B over a TCP connection. Assume: 500,000 bytes Data stream: file consisting of 500,000 bytes 1,000 bytes MSS: 1,000 bytes 0 First byte of data stream: numbered as 0 TCP constructs 500 segments out of the data stream. 500,000 bytes/1,000 bytes = 500 segments

9 Transport Layer – TCP 9 BBBB TCP sequence #'s and ACKs Sequence. Numbers (#'s):  byte stream 'number' of first byte in segment's data R  Do not necessarily start from 0, use random initial number R RSegment 1: 0 + R RSegment 2: R etc... ACKs (acknowledgment):  Seq # of next byte expected from other side (last byte +1)  Cumulative ACK  If received segment 1, waits for segment 2  E.g. Ack= R (received up to 999 th byte) Segment 1 Segment 2...

10 Transport Layer – TCP 10 BBBB TCP sequence #'s and ACKs Q: how receiver handles out-of-order segments does not  A: TCP specs. does not say, - decide when implementing 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 (with echo on) 4279 Assuming that the starting sequence numbers for Host A and Host B are: 42 and 79 respectively Send me the bytes from 43 onward ACK is being piggy-backed on server-to-client data I’m sending data starting at seq. num=42 server client

11 Transport Layer – TCP 11 BBBB Yet another server echo example Host A Host B Seq=42, ACK=79, data = ‘Hello’ Seq=79, ACK=47, data = ‘Hello’ Seq=47, ACK=84, data = ‘200’ User types 'Hello' host ACKs receipt of echoed 'Hello' send something else host ACKs receipt of 'Hello', echoes back 'Hello' time Host A: seq=42 ack=79 seq=47 ack=84 Host B: seq=79 ack=47 seq=84 ack=50 Seq=84, ACK=50, data = ‘200’ ACK tells about up to what byte has been received and what is the next startingbyte the host is expecting to receive ACK tells about up to what byte has been received and what is the next starting byte the host is expecting to receive

12 Transport Layer – TCP 12 BBBB TCP Round Trip Time and Timeout how to set TCP timeout value? Q: how to set TCP timeout value?  longer than RTT *  note: RTT will vary  too short: premature timeout  unnecessary retransmissions  too long: slow reaction to segment loss * RTT = round trip time how to estimate RTT? Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt  ignore retransmissions, cumulatively ACKed segments  SampleRTT will vary, we would want estimated RTT to be ''smoother''  use several recent measurements  use several recent measurements, not just current SampleRTT Main Issue Main Issue: How long is the sender willing to wait before re-transmitting the packet?

13 Transport Layer – TCP 13 BBBB TCP Round Trip Time and Timeout EstimatedRTT = (1-x) * EstimatedRTT + x * SampleRTT  Exponential weighted moving average  influence of given sample decreases exponentially fast  typical value of x: (RFC 2988) Setting the timeout safety margin  EstimatedRTT plus ''safety margin''  large variation in EstimatedRTT -> larger safety margin x: 0.25  recommended value of x: 0.25 Timeout = EstimatedRTT + (4 * Deviation) Deviation Deviation = (1-x) * Deviation + x * |SampleRTT-EstimatedRTT|

14 Transport Layer – TCP 14 BBBB EstimatedRTT = * EstimatedRTT * SampleRTT EstimatedRTT after the receipt of the ACK of segment 1: EstimatedRTT = RTT for Segment 1 = second EstimatedRTT after the receipt of the ACK of segment 2: EstimatedRTT = * * = EstimatedRTT after the receipt of the ACK of segment 3: EstimatedRTT = * * = EstimatedRTT after the receipt of the ACK of segment 4: EstimatedRTT = * * = EstimatedRTT after the receipt of the ACK of segment 5: EstimatedRTT = * * = EstimatedRTT after the receipt of the ACK of segment 6: EstimatedRTT = * * = Sample Calculations

15 Transport Layer – TCP 15 BBBB RTT Samples and RTT estimates time Estimated RTT Sample RTT RTT (msec.) The variations in the SampleRTT are smoothed out in the computation of the EstimatedRTT.

16 Transport Layer – TCP 16 BBBB An Actual RTT estimation:

17 Transport Layer – TCP 17 BBBB Simplified TCP sender, assuming: wait for event wait for event event: data received from application above event: timer timeout for segment with seq. number y event: ACK received, with ACK number y create, send segment retransmit segment process ACK - one way data transfer - no flow, congestion control FSM of TCP for Reliable Data Transfer

18 Transport Layer – TCP 18 BBBB 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 If (timer is currently not running) start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout 11 retransmit not-yet-ACKed segment with smallest Seq. # 12 Start timer 13 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 sendbase = y 17 If (there are currently any not-yet-ACKed segments) 18 start timer 19 } 20 } /* end of loop forever */ Associated with the oldest unACKed segment SIMPLIFIED TCP SENDERAssumptions: sender is not constrained by TCP flow or congestion control that data from above is less than MSS in size that data transfer is in one direction only

19 Transport Layer – TCP 19 BBBB Transport Layer 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

20 Transport Layer – TCP 20 BBBB 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 { 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y is 3) { 22 /* perform TCP fast retransmission */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } } 26 } /* end of loop forever */ TCPwith MODIFICATIONS TCP with MODIFICATIONSSENDER Why wait for the timeout to expire, when consecutive ACKs can be used to indicate a lost segment With Fast Retransmit

21 Transport Layer – TCP 21 BBBB TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending (due to action 1) out-of-order segment arrival with higher than expect seq. # - a gap is detected arrival of segment that partially or completely fills gap TCP Receiver action Delay sending the ACK. Wait up to 500ms for next segment. If next segment does not arrive in this interval, send ACK immediately send a single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte Immediately send an ACK if segment starts at lower end of gap Receiver does not discard out-of-order segments

22 Transport Layer – TCP 22 BBBB TCP: Interesting Scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 Host A Seq=100, 20 bytes data ACK=100 Seq=92 timeout time premature timeout, cumulative ACKs Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data ACK=120 Retransmission due to lost ACK Segment with Seq=100 not retransmitted Timer is restarted here for Seq=92 Simplified TCP version

23 Transport Layer – TCP 23 BBBB Host A Seq=100, 20 bytes data ACK=100 Seq=92 timeout time Host B ACK=120 Seq=92, 8 bytes data X loss Cumulative ACK avoids retransmission of the first segment. TCP: Retransmission Scenario

24 Transport Layer – TCP 24 BBBB Doubling the Timeout Interval TCP Modifications: Doubling the Timeout Interval Provides a limited form of congestion control Timer expiration is more likely caused by congestion in the network TimeoutInterval = 2 * TimeoutInterval Previous TCP acts more politely by increasing the TimeoutInterval, causing the sender to retransmit after longer and longer intervals. Congestion may get worse if sources continue to retransmit packets persistently. After ACK is received, TimeoutInterval is derived from most recent EstimatedRTT and DevRTT Others: check RFC 2018 – selective ACK

25 Transport Layer – TCP 25 BBBB receiver receiver: explicitly informs sender of (dynamically changing) amount of free buffer space  RcvWindow  RcvWindow field in TCP segment sender less than RcvWindow sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow sender won't overrun receiver's buffer by transmitting too much, too fast flow control receiver buffering RcvBuffer RcvBuffer = size of TCP Receive Buffer RcvWindow RcvWindow = amount of spare room in Buffer TCP Flow Control

26 Transport Layer – TCP 26 BBBB FLOW CONTROL: Receiver LastByteRcvd EXAMPLE: HOST A sends a large file to HOST B LastByteRead Application Process Data from IP RcvBuffer RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead] RcvWindow, LastByteRcvd, LastByteRead RECEIVER: HOST B – uses RcvWindow, LastByteRcvd, LastByteRead Initially, RcvWindow = RcvBuffer Application reads from the buffer HOST BHOST Ahow much spare room RcvWindow HOST A HOST B tells HOST A how much spare room it has in the connection buffer by placing its current value of RcvWindow in the receive window field of every segment it sends to HOST A.

27 Transport Layer – TCP 27 BBBB Sender FLOW CONTROL: Sender LastByteSent EXAMPLE: HOST A sends a large file to HOST B LastByteACKed Data To ensure that HOST B does not overflow, HOST A maintains throughout the connection’s life that [LastByteSent-LastByteACKed] <= RcvWindow SENDER: HOST A ACKs from Host B RcvWindow of HostB, LastByteSent, LastByteACKed SENDER: HOST A – uses RcvWindow of HostB, LastByteSent, LastByteACKed

28 Transport Layer – TCP 28 BBBB FLOW CONTROL Some issue to consider: RcvWindow flow control service RcvWindow – used by the connection to provide the flow control service TCP requires that HOST A continue to send segments with one data byte when HOST B’s receive window is 0. Such segments will be ACKed by HOST B. Eventually, the buffer will have some space and the ACKs will contain RcvWindow > 0 What happens when the receive buffer of HOST B is full ? (that is, when RcvWindow=0) dataACK alive TCP sends a segment only when there is data or ACK to send. Therefore, the sender must maintain the connection ‘alive’.

29 Transport Layer – TCP 29 BBBB TCP Connection Management connection Recall: TCP sender, receiver establish “ connection ” before exchanging data segments  Initialize TCP variables:  sequence numbers  buffers, flow control info (e.g. RcvWindow )  Client  Client is the connection initiator In Java, Socket clientSocket = new Socket("hostname","port number"); connect;  Server  Server is contacted by client In Java,Socket accept(); connect if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) != 0) { printf("connect failed\n"); WSACleanup(); exit(1); } accept ns = accept(s,(struct sockaddr *)(&remoteaddr),&addrlen);

30 Transport Layer – TCP 30 BBBB TCP Connection Management Three way handshake: clientSYN Step 1: client end system sends TCP SYN control segment to server (executed by TCP itself)  specifies initial seq number (isn) serverSYN SYNACK Step 2: server end system receives SYN, replies with SYNACK control segment  ACKs received SYN  allocates buffers  specifies server’s initial seq. number clientACKs Step 3: client ACKs the connection with ACK=server_isn +1  allocates buffers SYN=0  sends SYN=0 Connection established! Client Accept Accept (SYN=1, seq=server_isn,ack=client_isn+1) time Server Connect Connect (SYN=1, seq=client_isn) ACK (SYN=0, seq=client_isn+1,ack=server_isn+1) Establishing a connection This is what happens when we create a socket for connection to a server (SYN=0) After establishing the connection, the client can receive segments with app-generated data! (SYN=0)

31 Transport Layer – TCP 31 BBBB TCP Connection Management (cont.) Closing a connection: client closes socket: closesocket(s); Java: 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. client FIN server ACK FIN close closed timed wait How TCP connection is established and torn down

32 Transport Layer – TCP 32 BBBB TCP Connection Management (cont.) 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. Note: with small modification, can handle simultaneous FINs. client FIN server ACK FIN closing closed timed wait closed

33 Transport Layer – TCP 33 BBBB TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle Used in case ACK gets lost. It is implementation-dependent (e.g. 30 seconds, 1 minute, 2 minutes Connection formally closes – all resources (e.g. port numbers) are released

34 Transport Layer – TCP 34 BBBB End of Flow Control and Error Control

35 Transport Layer – TCP 35 BBBB Flow Control vs. Congestion Control Similar actions are taken, but for very different reasons Flow Control point-to-point traffic between sender and receiver speed matching service, matching the rate at which the sender is sending against the rate at which the receiving application is reading prevents Receiver Buffer from overflowing Congestion Congestion – happens when there are too many sources attempting to send data at too high a rate for the routers along the path Congestion Control service that makes sure that the routers between End Systems are able to carry the offered traffic prevents routers from overflowing Same course of action: Throttling of the sender

36 Transport Layer – TCP 36 BBBBCongestion:  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 (queuing in router buffers)  a top-10 problem! Principles of Congestion Control

37 Transport Layer – TCP 37 BBBB Approaches towards congestion control End-to-end congestion control:  no explicit feedback from network  congestion inferred by end-systems from observed packet loss & delay  approach taken by TCP Network-assisted congestion control:  routers provide feedback to End Systems in the form of:  single bit indicating link congestion (SNA, DECbit, TCP/IP ECN, ATM ABR)  explicit transmission rate the sender should send at 12 Two broad approaches towards congestion control:

38 Transport Layer – TCP 38 BBBB TCP Congestion Control How TCP sender limits the rate at which it sends traffic into its connection? SENDER: (Amount of unACKed data) SENDER < min(CongWin, RcvWindow) LastByteSent - LastByteACKed Indirectly limits the sender’s send rate Assumptions: TCP receive buffer is very large – no RcvWindow constraint  Amt. of unACKed data at sender is solely limited by CongWin Packet loss delay & packet transmission delay are negligible Sending rate: (approx.) CongWin RTT By adjusting CongWin, sender can therefore adjust the rate at which it sends data into its connection New variable! – Congestion Window

39 Transport Layer – TCP 39 BBBB TCP Congestion Control TCP uses ACKs to trigger (“clock”) its increase in congestion window size – “self-clocking” Arrival of ACKs – indication to the sender that all is well 1.Slow Rate Congestion window will be increased at a relatively slow rate 2.High rate Congestion window will be increased more quickly

40 Transport Layer – TCP 40 BBBB TCP Congestion Control How TCP perceives that there is congestion on the path? “Loss Event” – when there is excessive congestion, router buffers along the path overflows, causing datagrams to be dropped, which in turn, results in a “loss event” at the sender 1.Timeout no ACK is received after segment loss 2.Receipt of three duplicate ACKs segment loss is followed by three ACKs received at the sender

41 Transport Layer – TCP 41 BBBB TCP Congestion Control: details  sender limits transmission: LastByteSent-LastByteAcked  cwnd  roughly,  cwnd is dynamic, function of perceived network congestion How does sender perceive congestion?  loss event = timeout or 3 duplicate acks  TCP sender reduces rate (cwnd) after loss event Three mechanisms: 1. AIMD 2. slow start 3. conservative after timeout events rate = cwnd RTT Bytes/sec

42 Transport Layer – TCP 42 BBBB congestion avoidance additive increase, multiplicative decrease TCP congestion avoidance : additive increase, multiplicative decrease  approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs  additive increase: increase cwnd by 1 MSS every RTT until loss is detected  multiplicative decrease: cut cwnd in half after loss time cwnd : congestion window size saw tooth behavior: probing for bandwidth

43 Transport Layer – TCP 43 BBBB Slow Start TCP Slow Start  when connection begins, increase rate exponentially until first loss event: cwnd  initially cwnd = 1 MSS cwnd  double cwnd every RTT cwnd by 1 MSS  done by incrementing cwnd by 1 MSS for every ACK received  summary: initial rate is slow but ramps up exponentially fast (doubling of the sending rate every RTT) Host A one segment RTT Host B time two segments four segments

44 Transport Layer – TCP 44 BBBB Refinement: inferring loss  after 3 dup ACKs:  cwnd half  cwnd is cut in half linearly  window then grows linearly  but after timeout event:  cwnd is 1 MSS  cwnd is set to 1 MSS exponentially  window then grows exponentially  Up to a threshold linearly  Up to a threshold, then grows linearly 3 dup ACKs  3 dup ACKs indicates network capable of delivering some segments timeout  timeout indicates a “more alarming” congestion scenario Philosophy:

45 Transport Layer – TCP 45 BBBB Refinement Q: when should the exponential increase switch to linear? cwnd 1/2 A: when cwnd gets to 1/2 of its value before timeout. Implementation: ssthresh (slow-start threshold)  variable ssthresh (slow-start threshold)  on loss event ssthresh 1/2 cwnd  on loss event, ssthresh is set to 1/2 of cwnd just before loss event

46 Transport Layer – TCP 46 BBBB TCP Sender Congestion Control STATEEVENTTCP SENDER Congestion- Control Action Commentary SLOW START (SS) ACK receipt for previously unACKed data CongWin = CongWin + MSS, If(CongWin > Threshold) set state to “Congestion Avoidance” Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) ACK receipt for previously unACKed data CongWin = CongWin + MSS * (MSS/CongWin) Additive increase, resulting in increasing of CongWin by 1 MSS every RTT SS or CALoss event detected by triple duplicate ACK Threshold = CongWin / 2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, implementing multiplicative decrease, CongWin will not drop below 1 MSS. SS or CATimeout Threshold = CongWin / 2, CongWin = 1 MSS, Set state to “Slow Start” Enter Slow Start. SS or CADuplicate ACK Increment duplicate ACK count for segment being ACKed CongWin and Threshold not changed

47 Transport Layer – TCP 47 BBBB Summary: TCP Congestion Control timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh congestion avoidance cwnd = cwnd + MSS (MSS/cwnd) dupACKcount = 0 transmit new segment(s), as allowed new ACK. dupACKcount++ duplicate ACK fast recovery cwnd = cwnd + MSS transmit new segment(s), as allowed duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 timeout ssthresh = cwnd/2 cwnd = 1 dupACKcount = 0 retransmit missing segment ssthresh= cwnd/2 cwnd = ssthresh + 3 MSS retransmit missing segment dupACKcount == 3 cwnd = ssthresh dupACKcount = 0 New ACK slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s), as allowed new ACK dupACKcount++ duplicate ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0 New ACK! New ACK! New ACK!

48 Transport Layer – TCP 48 BBBB Congestion control TCP’s Congestion Control Service CLIENT SERVER Problem: Gridlock sets-in when there is packet loss due to router congestion decrease the rate at which packets are sent forces the End Systems to decrease the rate at which packets are sent during periods of congestion The sending system’s packet is lost due to congestion, and is alerted when it stops receiving ACKs of packets sent

49 Transport Layer – TCP 49 BBBB Transport Layer Macroscopic Description of TCP throughput  what’s the average throughout of TCP as a function of window size and RTT?  ignore slow start (typically very short phases)  let W be the window size when loss occurs.  when window is W, throughput is W/RTT  just after loss, window drops to W/2, throughput to W/2RTT.  Throughput increases linearly (by MSS/RTT every RTT)  Average Throughput:.75 W/RTT (Based on Idealised model for the steady-state dynamics of TCP)

50 Transport Layer 3-50 TCP Futures TCP Futures: TCP over “long, fat pipes”  Example: GRID computing application  1500-byte segments, 100ms RTT, desired throughput of 10 Gbps  requires window size W = 83,333 in-flight segments  Throughput in terms of loss rate:  ➜ L = 2· – a very small loss rate! (1 loss event every 5 billion segments)  new versions of TCP is needed for high- speed environments

51 Transport Layer – TCP 51 BBBB TCP Fairness N R/N Fairness goal: if N TCP sessions share same bottleneck link, each should get an average transmission rate of R/N, an equal share of the link’s bandwidth TCP connection 1 bottleneck router R capacity R TCP connection 2 Go to Summary of TCP Congestion Control

52 Transport Layer – TCP 52 BBBBAnalysis of 2 connections sharing a link Link with transmission rate of R RR R Each connection have the same M MM MSS, R RR RTT No other TCP connections or UDP datagrams traverse the shared link Ignore slow start phase of TCP Operating in c cc congestion-avoidance mode (linear increase phase) Goal: adjust sending rate of the two connections to allow for e ee equal bandwidth sharing Assumptions:

53 Transport Layer – TCP 53 BBBB Why is TCP fair? Two competing sessions:  Additive increase gives slope of 1, as throughout increases  multiplicative decrease: decreases throughput proportionally R equal bandwidth share Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2R jointly consumed A point on the graph depicts the amount of link bandwidth jointly consumed by the connections Full bandwidth utilisation line We can view a simulation on this View Simulation View Simulation

54 Transport Layer – TCP 54 BBBB The End The next succeeding slides are just for additional reading.

55 Transport Layer – TCP 55 BBBBTCP Latency Modeling In practice, client/server applications with smaller RTT gets the available bandwidth more quickly as it becomes free. Therefore, they have higher throughputs Multiple parallel TCP connection allows one application to get a bigger share of the bandwidth Multiple End Systems sharing a link R bps – link’s transmission rate Loop holes in TCP: 1 TCP connection 3 TCP connections Multithreading implementation

56 Transport Layer – TCP 56 BBBB TCP latency modeling  TCP connection establishment time  data transfer delay  Actual data transmission time Two cases to consider:  WS/R > RTT + S/R: An ACK for the first segment in window returns to the Sender before a window’s worth of data is sent  WS/R < RTT + S/R: Sender has to wait for an ACK after a window’s worth of data sent Q : How long does it take to receive an object from a Web server? No data transfer delay There’s data transfer delay the time from when the client initiates a TCP connection until when the client receives the requested object in its entirety

57 Transport Layer – TCP 57 BBBBTCP Latency Modeling Network is uncongested, with one link between end systems of rate R RR R CongWin (fixed) determines the amount of data that can be sent No packet loss, no packet corruption, no retransmissions required Header overheads are negligible File to send = integer number of segments of size MSS Connection establishment, request messages, ACKs, TCP connection- establishment segments have n nn negligible transmission times CLIENT SERVER FILE Initial T TT Threshold of TCP congestion mechanism is very big R bps – link’s transmission rate Assumptions: O - Size of object in bits S – number of bits of MSS (max. segment size)

58 Transport Layer – TCP 58 BBBB TCP latency Modeling Case 1: latency = 2RTT + O/R K = Number of Windows of data that cover the object K = O/WS Case Analysis: STATIC CONGESTION WINDOW Case 1: WS/R > RTT + S/R: An ACK for the first segment in window returns to the Sender before a window’s worth of data is sent Number of segments; Rounded up to the nearest integer Assume: W=4 segments e.g. O=256bits, S=32bits, W=4

59 Transport Layer – TCP 59 BBBB TCP latency Modeling Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Number of Windows of data that cover the object K:= O/WS Case Analysis: STATIC CONGESTION WINDOW Case 2: WS/R < RTT + S/R: Sender has to wait for an ACK after a window’s worth of data sent STALLED PERIOD If there are k windows, sender will be stalled (k-1) times

60 Transport Layer – TCP 60 BBBB Case Analysis: DYNAMIC CONGESTION WINDOW STALLED PERIOD 4 windows O/S=15

61 Transport Layer – TCP 61 BBBB Let K be the number of windows that cover the object. Let K be the number of windows that cover the object. We can express K in terms of the number of segments in the object as follows: We can express K in terms of the number of segments in the object as follows: Case Analysis: DYNAMIC CONGESTION WINDOW Note:

62 Transport Layer – TCP 62 BBBB From the time the server begins to transmit the k window until the time the server receives an ACK for the in the window From the time the server begins to transmit the kth window until the time the server receives an ACK for the first segment in the window Transmission of k window = Transmission of k th window = Stall Time = Stall Time = Latency = Latency = Case Analysis: DYNAMIC CONGESTION WINDOW

63 Transport Layer – TCP 63 BBBB Q Let Q be the number of times the server would stall if the object contained an infinite number of segments. Case Analysis: DYNAMIC CONGESTION WINDOW The actual number of times that the server stalls is P = min{ Q, K-1 }.

64 Transport Layer – TCP 64 BBBB Q Let Q be the number of times the server would stall if the object contained an infinite number of segments. Case Analysis: DYNAMIC CONGESTION WINDOW The actual number of times that the server stalls is P = min{ Q, K-1 }. Closed-form expression for the latency:

65 Transport Layer – TCP 65 BBBB Q Let Q be the number of times the server would stall if the object contained an infinite number of segments. Case Analysis: DYNAMIC CONGESTION WINDOW *Slow start will not significantly increase latency if RTT << O/R

66 Transport Layer – TCP 66 BBBB  97/ftp/tcp_over_atm/index.htm#atm-features


Download ppt "Transport Layer – TCP 1 BBBB TCP Flow Control, Congestion Control, Connection Management, etc. Part 2."

Similar presentations


Ads by Google