ECSE-4670: Computer Communication Networks (CCN) Chapter 3: TCP. Shivkumar Kalyanaraman: Biplab Sikdar:

Transcription

1 ECSE-4670: Computer Communication Networks (CCN) Chapter 3: TCP Shivkumar Kalyanaraman: Biplab Sikdar: Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 1

2 Point-to-point: TCP: Overview one sender, one receiver Reliable, 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 Send & receive buffers Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 2

3 TCP: Overview socket door application writes data TCP send buffer segment application reads data TCP receive buffer socket door Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 3

4 TCP: Overview Full duplex data: bi-directional data flow in same connection MSS: 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 4

5 TCP segment structure URG: urgent data (generally not used) ACK: ACK # valid SH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used UAP R S F checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 5

6 TCP seq. # s and ACKs (I) Sequence 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 6

7 TCP Seq. # s and ACKs (II) Host A Host B User types C Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C host ACKs receipt of C, echoes back C host ACKs receipt of echoed C Seq=43, ACK=80 simple telnet scenario Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 7

8 Temporal Redundancy Model Timeout Packets Status Reports Retransmissions Sequence Numbers CRC or Checksum ACKs NAKs, SACKs Bitmaps Packets FEC information Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 8

9 Status Report Design Cumulative acks: Robust 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 9

10 TCP: reliable data transfer (I) event: data received from application above create, send segment one way data transfer wait for event event: timer timeout for segment with seq # y retransmit segment no flow, congestion control event: ACK received, with ACK # y ACK processing Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 10

11 TCP: reliable data transfer (II) Simplified 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 ACKS 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 */ Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 11

12 TCP ACK generation Event 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 Receiver 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 12

13 TCP: retransmission scenarios Host A Host B Host A Host B Seq=92, 8 bytes data ACK=100 X timeout loss Seq=92, 8 bytes data Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=120 ACK=100 Seq=92, 8 bytes data Seq=100 timeout Seq=92 timeout ACK=120 ACK=100 time lost ACK scenario time premature timeout, cumulative ACKs Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 13

14 TCP Flow Control flow control sender won t overrun receiver s buffers by transmitting too much, too fast RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver: explicitly informs sender of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unacked data less than most recently received RcvWindow receiver buffering Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 14

15 Timeout and RTT Estimation Timeout: for robust detection of packet loss Problem: How long should timeout be? Too long => underutilization Too short => wasteful retransmissions Solution: adaptive timeout: based on estimate of max RTT Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 15

16 How to estimate max RTT? RTT = prop + queuing delay Queuing delay highly variable So, different samples of RTTs will give different random values of queuing delay Chebyshev s Theorem: MaxRTT = Avg RTT + k*deviation Error probability is less than 1/(k**2) Result true for ANY distribution of samples Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 16

17 Round Trip Time and Timeout (II) Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments SampleRTT will vary wildly => want estimated RTT smoother use several recent measurements, not just current SampleRTT to calculate AverageRTT Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 17

18 TCP Round Trip Time and Timeout (III) AverageRTT = (1-x)*AverageRTT + x*samplertt Exponential weighted moving average (EWMA) influence of given sample decreases exponentially fast; x = 0.1 Setting the timeout AverageRTT plus safety margin proportional to variation Timeout = AverageRTT + 4*Deviation Deviation = (1-x)*Deviation + x* SampleRTT- AverageRTT Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 18

19 TCP Connection Management - 1 Recall: TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator Socket clientsocket = new Socket("hostname","port number"); server: contacted by client Socket connectionsocket = welcomesocket.accept(); Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 19

20 TCP Connection Management - 2 Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 20

21 TCP Connection Management - 3 Closing a connection: client closes socket: 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. Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 21

22 TCP Connection Management - 4 Fddfdf client server close FIN ACK FIN close d timed wait closed ACK Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 22

23 TCP Connection Management - 5 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. Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 23

24 TCP Connection Management - 6 TCP client lifecycle Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 24

25 TCP Connection Management - 7 TCP server lifecycle Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 25

26 Recap: Stability of a Multiplexed System Average Input Rate > Average Output Rate => system is unstable! How to ensure stability? 1. Reserve enough capacity so that demand is less than reserved capacity 2. Dynamically detect overload and adapt either the demand or capacity to resolve overload Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 26

27 Congestion Problem in Packet Switching A 10 Mbs Ethernet statistical multiplexing C B queue of packets waiting for output link 1.5 Mbs 45 Mbs D Cost: self-descriptive header per-packet, buffering and delays for applications. Need to either reserve resources or dynamically detect/adapt to overload for stability Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 27 E

28 The Congestion Problem λ i λ µ Problem: demand outstrips available capacity λ 1 µ i Demand Capacity λ n 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! Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 28

29 The Congestion Problem (Continued) Problems: Incomplete information (eg: loss indications) Distributed solution required Congestion and control/measurement locations different Time-varying, heterogeneous timedelay Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 29

30 The Congestion Problem Static 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 Replace with 1 Mb/s SS SS SS SS SS SS SS SS File Transfer time = 5 mins File Transfer Time = 7 hours

31 The Congestion Problem A B (Continued) c) Processors become cheap (fast routers & switches) S C D Scenario: All links 1 Gb/s. A & B send to C => high-speed congestion!! (lose more packets faster!)

32 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! Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 32

33 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 33

34 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 34

35 Causes/costs of congestion: scenario 2 (continued) Costs of congestion: More work (retrans) for given goodput Unneeded retransmissions: link carries multiple copies of pkt due to spurious timeouts Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 35

36 Causes/costs of congestion: scenario 3 Another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 36

37 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 37

38 Approaches towards congestion control - 2 Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 38

39 TCP congestion control - 1 end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 39

40 TCP congestion control - 2 w segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 40

41 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 41

42 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 time Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 42

43 Fairness 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 R Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 43

44 Fairness Analysis Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 44

45 AIMD Converges to Fairness Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 45

46 TCP congestion control - 4 TCP uses AIMD policy in steady state Two phases Transient phase: aka Slow start Steady State: aka Congestion avoidance Important variables: Congwin threshold: defines threshold between two slow start phase, congestion avoidance phase Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 46

47 TCP Slowstart - 1 Slowstart algorithm initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) Exponential increase (per RTT) in window size (not so slow!) Loss event: timeout (Tahoe TCP) and/or three duplicate ACKs (Reno TCP) Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 47

48 TCP Slowstart - 2 asdf Host A Host B RTT one segment two segments four segments time Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 48

49 TCP Dynamics 1st RTT 2nd RTT 3rd RTT 4th RTT Rate of acks determines rate of packets : Self-clocking property. 100 Mbps 10 Mbps Router Q Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 49

50 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 1: TCP Reno skips slowstart (aka fast recovery) after three duplicate ACKs and performs close to AIMD Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 50

51 TCP Congestion Avoidance - 2 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 51

52 TCP window dynamics (more) Congestion Window (cwnd) ssthresh Timeout Receiver Window Idle Interval 1 Time (units of RTTs) Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 52

53 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 53

54 TCP latency modeling - 2 Notation, assumptions: Assume one link between client and server of rate R Assume: fixed congestion window, W segments S: MSS (bits) O: object size (bits) no retransmissions (no loss, no corruption) Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 54

55 TCP latency modeling - 3 Two cases to consider: WS/R > RTT + S/R: ACK for first segment in window returns before window s worth of data sent WS/R < RTT + S/R: wait for ACK after sending window s worth of data sent Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 55

56 TCP latency modeling - 4 Case 1: latency = 2RTT + O/R Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 56

57 TCP latency modeling - 5 K = O/WS Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 57

58 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: Latency O S P = 2RTT + + P RTT (2 1) R + R where P is the number of times TCP stalls at server: S R Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 58

59 TCP latency modeling: slow start - 2 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. Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 59

60 TCP latency modeling: slow start - 3 Example: O/S = 15 segments K = 4 windows Q = 2 P = min{k-1,q} = 2 initiate TCP connection request object RTT first window = S/R second window = 2S/R third window = 4S/R fourth window = 8S/R Server stalls P=2 times. object delivered time at client time at server complete transmission Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 60

61 TCP latency modeling: slow start - 4 S RTT time from when server starts to send segment R + = until server receives acknowledgement k S 2 1 = time to transmit the kth window R S R + RTT + k S 2 1 = stall time after the kth window R Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 61

62 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 62 TCP latency modeling: slow start - 5 R S R S RTT P RTT R O R S RTT R S RTT R O stalltime RTT R O P k P k P p p 1) (2 ] [ 2 ] 2 [ 2 2 latency = = + + = = =

63 Sample Results R O/R P Minimum Latency: O/R + 2 RTT Latency with slow start 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 Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 63

64 Summary: Chapter 3 Principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control Instantiation and implementation in the Internet UDP, TCP Rensselaer Polytechnic Institute Shivkumar Kalvanaraman & Biplab Sikdar 64