Chapter 3: TCP. TCP: Overview. TCP: Overview. TCP: Overview. TCP seq. # s and ACKs (I) TCP segment structure

Transcription

1 ECE-4670: Computer Communication Networks (CCN) Chapter 3: TCP hivkumar Kalyanaraman: Biplab ikdar: ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 1 Point-to-point: TCP: Overview one sender, one receiver eliable, in-order byte steam: no message boundaries But TCP chops it up into segments for transmission internally Pipelined (window) flow control: Window size decided by receiver and network end & receive buffers ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 2 TCP: Overview TCP: Overview socket door application writes data TCP send buffer segment application reads data TCP receive buffer socket door Full duplex data: bi-directional data flow in same connection M: maximum segment size Connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange Flow & Congestion Control: sender will not overwhelm receiver or the network ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 3 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 4 UG: urgent data (generally not used) ACK: ACK # valid PH: push data now (generally not used) T, YN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) TCP segment structure 32 bits source port # dest port # sequence number acknowledgement number head not UAP rcvr window size len used F checksum ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 5 TCP seq. # s and ACKs (I) equence Numbers: byte stream number of first byte in segment s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn t say, - up to implementor ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 6 1

2 TCP eq. # s and ACKs (II) Temporal edundancy Model User types C host ACKs receipt of echoed C Host A Host B eq=42, ACK=79, data = C eq=79, ACK=43, data = C eq=43, ACK=80 host ACKs receipt of C, echoes back C Timeout Packets tatus eports etransmissions equence Numbers CC or Checksum ACKs NAKs, ACKs Bitmaps Packets FEC information simple telnet scenario ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 7 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 8 tatus eport Design Cumulative acks: obust to losses on the reverse channel Can work with go-back-n retransmission Cannot pinpoint blocks of data which are lost The first lost packet can be pinpointed because the receiver would generate duplicate acks ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 9 TCP: reliable data transfer (I) event: data received from application above create, send segment wait for event event: ACK received, with ACK # y ACK processing event: timer timeout for segment with seq # y retransmit segment one way data transfer no flow, congestion control ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 10 TCP: reliable data transfer (II) implified TCP sender 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 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 ACK received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 11 Event TCP ACK generation in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected! arrival of segment that partially or completely fills gap TCP eceiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 12 2

3 TCP: retransmission scenarios timeout time Host A eq=92, 8 bytes data X loss Host B ACK=100 eq=92, 8 bytes data ACK=100 lost ACK scenario eq=100 timeout eq=92 timeout time Host A eq=100, 20 bytes data ACK=100 Host B eq=92, 8 bytes data ACK=120 eq=92, 8 bytes data ACK=120 premature timeout, cumulative ACKs ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 13 TCP Flow Control flow control sender won t overrun receiver s buffers by transmitting too much, too fast cvbuffer = size or TCP eceive Buffer cvwindow = amount of spare room in Buffer receiver buffering receiver: explicitly informs sender of free buffer space cvwindow field in TCP segment sender: keeps the amount of transmitted, unacked data less than most recently received cvwindow ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 14 Timeout and TT Estimation Timeout: for robust detection of packet loss Problem: How long should timeout be? Too long => underutilization Too short => wasteful retransmissions olution: adaptive timeout: based on estimate of max TT ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 15 How to estimate max TT? TT = prop + queuing delay Queuing delay highly variable o, different samples of TTs will give different random values of queuing delay Chebyshev s Theorem: MaxTT = Avg TT + k*deviation Error probability is less than 1/(k**2) esult true for ANY distribution of samples ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 16 ound Trip Time and Timeout (II) Q: how to estimate TT? amplett: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments amplett will vary wildly => want estimated TT smoother use several recent measurements, not just current amplett to calculate AverageTT ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 17 TCP ound Trip Time and Timeout (III) AverageTT = (1-x)*AverageTT + x*amplett Exponential weighted moving average (EWMA) influence of given sample decreases exponentially fast; x = 0.1 etting the timeout AverageTT plus safety margin proportional to variation Timeout = AverageTT + 4*Deviation Deviation = (1-x)*Deviation + x* amplett- AverageTT ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 18 3

4 TCP Connection Management - 1 ecall: TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. cvwindow) client: connection initiator ocket clientocket = new ocket("hostname","port number"); server: contacted by client ocket connectionocket = welcomeocket.accept(); ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 19 TCP Connection Management - 2 Three way handshake: tep 1: client end system sends TCP YN control segment to server specifies initial seq # tep 2: server end system receives YN, replies with YNACK control segment ACKs received YN allocates buffers specifies server-> receiver initial seq. # ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 20 TCP Connection Management - 3 TCP Connection Management - 4 Closing a connection: client closes socket: clientocket.close(); Fddfdf close client FIN server tep 1: client end system sends TCP FIN control segment to server ACK FIN close tep 2: server receives FIN, replies with ACK. Closes connection, sends FIN. timed wait closed d ACK ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 21 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 22 TCP Connection Management - 5 TCP Connection Management - 6 tep 3: client receives FIN, replies with ACK. Enters timed wait - will respond with ACK to received FINs tep 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 23 TCP client lifecycle ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 24 4

5 TCP Connection Management - 7 ecap: tability of a Multiplexed ystem Average Input ate > Average Output ate => system is unstable! TCP server lifecycle ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 25 How to ensure stability? 1. eserve enough capacity so that demand is less than reserved capacity 2. Dynamically detect overload and adapt either the demand or capacity to resolve overload ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 26 Congestion Problem in Packet witching A B 10 Mbs Ethernet queue of packets waiting for output link statistical multiplexing 1.5 Mbs ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 27 C 45 Mbs D E Cost: self-descriptive header per-packet, buffering and delays for applications. Need to either reserve resources or dynamically detect/adapt to overload for stability The Congestion Problem λ i µ Problem: demand i λ outstrips µ available capacity λ 1 Demand λ n Capacity If information about λ i, λ and µ is known in a central location where control of λ i or µ can be effected with zero time delays, the congestion problem is solved! ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 28 The Congestion Problem (Continued) Problems: Incomplete information (eg: loss indications) Distributed solution required Congestion and control/measurement locations different Time-varying, heterogeneous timedelay The Congestion Problem tatic fixes may not solve congestion a) Memory becomes cheap (infinite memory) No buffer Too late b) Links become cheap (high speed links)? All links 19.2 kb/s eplace with 1 Mb/s File Transfer time = 5 mins File Transfer Time = 7 hours ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 29 5

6 The Congestion Problem (Continued) c) Processors become cheap (fast routers & switches) A C B D cenario: All links 1 Gb/s. A & B send to C => high-speed congestion!! (lose more packets faster!) Principles of Congestion Control Congestion: informally: too many sources sending too much data too fast for network to handle different from flow control (receiver overload)! manifestations: lost packets (buffer overflow at routers) long delays (queuing in router buffers) a top-10 problem! ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 32 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 33 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 34 Causes/costs of congestion: scenario 2 (continued) Causes/costs of congestion: scenario 3 Costs of congestion: More work (retrans) for given goodput Unneeded retransmissions: link carries multiple copies of pkt due to spurious timeouts ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 35 Another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 36 6

7 Approaches towards congestion control - 1 Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Approaches towards congestion control - 2 Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (NA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 37 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 38 TCP congestion control - 1 TCP congestion control - 2 end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: w segments, each with M bytes sent in one TT: throughput = w * M TT Bytes/sec ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 39 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 40 TCP congestion control - 3 Probing for usable bandwidth: Window flow control: avoid receiver overrun Dynamic window congestion control: avoid/control network overrun Policy: Increase Congwin until loss (congestion) Loss => decrease Congwin, then begin probing (increasing) again Additive Increase/Multiplicative Decrease (AIMD) Policy For stability: rate-of-decrease > rate-of-increase Decrease performed enough times as long as congestion exists AIMD policy satisfies this condition, provided packet loss is congestion indicator window ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 41 time ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 42 7

8 Fairness Fairness Analysis Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 43 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 44 AIMD Converges to Fairness TCP congestion control - 4 TCP uses AIMD policy in steady state Two phases Transient phase: aka low start teady tate: aka Congestion avoidance Important variables: Congwin threshold: defines threshold between two slow start phase, congestion avoidance phase ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 45 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 46 TCP lowstart - 1 TCP lowstart - 2 lowstart algorithm initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event O CongWin > threshold) Exponential increase (per TT) in window size (not so slow!) Loss event: timeout (Tahoe TCP) and/or three duplicate ACKs (eno TCP) asdf Host A TT Host B one segment two segments four segments time ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 47 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 48 8

9 TCP Dynamics 1st TT 2nd TT 3rd TT 4th TT ate of acks determines rate of packets : elf-clocking property. 100 Mbps 10 Mbps outer Q TCP Congestion Avoidance - 1 Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 1 perform slowstart ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 49 1: TCP eno skips slowstart (aka fast recovery) after three duplicate ACKs and performs close to AIMD ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 50 TCP Congestion Avoidance - 2 TCP window dynamics (more) Congestion Window (cwnd) ssthresh Timeout eceiver Window Idle Interval 1 Time (units of TTs) ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 51 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 52 TCP latency modeling - 1 Q: How long does it take to receive an object from a Web server after sending a request? TCP connection establishment data transfer delay TCP latency modeling - 2 Notation, assumptions: Assume one link between client and server of rate Assume: fixed congestion window, W segments : M (bits) O: object size (bits) no retransmissions (no loss, no corruption) ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 53 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 54 9

10 TCP latency modeling - 3 Two cases to consider: W/ > TT + /: ACK for first segment in window returns before window s worth of data sent TCP latency modeling - 4 W/ < TT + /: wait for ACK after sending window s worth of data sent ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 55 Case 1: latency = 2TT + O/ ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 56 TCP latency modeling - 5 Case 2: latency = 2TT + O/ + (K-1)[/ + TT - W/] K = O/W ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 57 TCP latency modeling: slow start - 1 Now suppose window grows according to slow start. Will show that the latency of one object of size O is: O P Latency = 2TT + + P TT (2 1) + where P is the number of times TCP stalls at server: ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 58 TCP latency modeling: slow start - 2 TCP latency modeling: slow start - 3 P = min{ Q, K 1} - where Q is the number of times the server would stall if the object were of infinite size. - and K is the number of windows that cover the object. ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 59 Example: O/ = 15 segments K = 4 windows Q = 2 P = min{k-1,q} = 2 erver stalls P=2 times. initiate TCP connection request object first window = / TT second window = 2/ third window = 4/ fourth window = 8/ complete object transmission delivered time at time at server client ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 60 10

11 TCP latency modeling: slow start - 4 TT time from when server starts to send segment + = until server receives acknowledgement k 2 1 = time to transmit the kth window + k TT = stall time after the kth window latency = TCP latency modeling: slow start - 5 = = P O + 2TT + stalltime p P O k + 2TT + [ + TT 2 O p= 1 k = 1 + 2TT + P[ TT + ] (2 1 P ] 1) ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 61 ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 62 ample esults ummary: Chapter 3 O/ P Minimum Latency: O/ + 2 TT 28 Kbps 28.6 sec sec 28.9 sec 100 Kbps 8 sec sec 8.4 sec 1 Mbps 800 msec 5 1 sec 1.5 sec 10 Mbps 80 msec sec 0.98 sec Latency with slow start ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 63 Principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control Instantiation and implementation in the Internet UDP, TCP ensselaer Polytechnic Institute hivkumar Kalvanaraman & Biplab ikdar 64 11