Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 4284 Systems Capstone Godmar Back Networking. TCP CS 4284 Spring 2013.

Similar presentations


Presentation on theme: "CS 4284 Systems Capstone Godmar Back Networking. TCP CS 4284 Spring 2013."— Presentation transcript:

1 CS 4284 Systems Capstone Godmar Back Networking

2 TCP CS 4284 Spring 2013

3 Study of TCP: Outline segment structure reliable data transfer flow control connection management [ Network Address Translation ] [ Principles of congestion control ] TCP congestion control

4 CS 4284 Spring 2013 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 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 controlled: –sender will not overwhelm receiver 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

5 CS 4284 Spring 2013 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 establishment (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

6 CS 4284 Spring 2013 TCP Reliable Data Transfer TCP creates rdt service on top of IP’s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission timer Retransmissions are triggered by: –timeout events –duplicate acks Initially consider simplified TCP sender: –ignore duplicate acks –ignore flow control, congestion control

7 CS 4284 Spring 2013 TCP Seq. #’s and ACKs Seq. #’s: –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 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

8 CS 4284 Spring 2013 TCP Sender Events data rcvd from app: create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer ack rcvd: If acknowledges previously unacked segments –update what is known to be acked –start timer if there are outstanding segments

9 CS 4284 Spring 2013 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; so SendBase = 72, say Ack received with y= 73, so the rcvr acknowledges up to including 72, now wants 73+ ; y is > SendBase, so know that new data is acked, set SendBase to 73

10 CS 4284 Spring 2013 TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time SendBase = 100 Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Seq=92 timeout SendBase = 120 SendBase = 120 Sendbase = 100

11 CS 4284 Spring 2013 TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120

12 CS 4284 Spring 2013 TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment 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, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

13 CS 4284 Spring 2013 Nagle’s algorithm Consider again apps writing byte-by-byte (or in small chunks) –If you send 1-byte segments with 20 byte TCP header overhead + overhead of lower layer headers – you get a huge waste of network capacity. Nagle: –Transmit first byte –Buffer outgoing bytes until ack has been received – then send all at once You can turn this off via –Use setsockopt (SOL_SOCKET, TCP_NODELAY)

14 CS 4284 Spring 2013 Delayed ACK vs Nagle These two mechanisms have nothing to do with each other –often confused, especially by various online sources –TCP_NODELAY means “disable Nagle”, not “disable delayed ACKs” Delayed ACK: implemented by TCP Receiver –Delays sending an acknowledgement (because acks are cumulative, can reduce # of acks sent) Nagle’s algorithm: implemented by TCP Sender –Delays sending actual data (so that more data can be fit into a single segment)

15 TCP Timeout & Fast Retransmit

16 CS 4284 Spring 2013 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT –but RTT varies too short: premature timeout –unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT : measured time from segment transmission until ACK receipt SampleRTT will vary, want estimated RTT “smoother” –average several recent measurements, not just current SampleRTT

17 CS 4284 Spring 2013 RTT Distributions (a) Probability density of ACK arrival times in the data link layer. (b) Probability density of ACK arrival times for TCP.

18 CS 4284 Spring 2013 TCP Round Trip Time and Timeout EstimatedRTT = (1 -  ) * EstimatedRTT +  * SampleRTT exponential weighted moving average influence of past sample decreases exponentially fast typical value:  = 0.125

19 CS 4284 Spring 2013 Example RTT estimation:

20 CS 4284 Spring 2013 TCP Round Trip Time and Timeout Setting the timeout EstimatedRTT plus “safety margin” –large variation in EstimatedRTT  larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.125,  = 0.25) EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT

21 CS 4284 Spring 2013 RTT Measurement & Retransmissions How should you handle acks for retransmitted segments when measuring RTT? –Note: ACK could be delayed for original segment or early for retransmitted segment Choices: –Associate with original packet  may overestimate true RTT –Associate with retransmitted packet  may underestimate true RTT

22 CS 4284 Spring 2013 Karn’s Algorithm Idea: don’t consider samples from retransmitted segments –Ok, but what if current timeout value is too small for network delay? –In this case, would keep timing out but couldn’t adjust timeout according to formula Solution: If measurement can’t be made, use exponential backoff until new measurement can be made –By factor of 2 with limit Resume normal sampling algorithm afterwards –Usual sampling period is once per RTT See also RFC 2988 – TCP timestamp option can be used to remove ambiguity which ack matches which packet

23 CS 4284 Spring 2013 Fast Retransmit Time-out period often relatively long: –long delay before resending lost packet Detect lost segments via duplicate ACKs. –Sender often sends many segments back-to-back –If segment is lost, there will likely be many duplicate ACKs. If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: –fast retransmit: resend segment before timer expires

24 CS 4284 Spring 2013 event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) resend segment with sequence number y } Fast retransmit algorithm: a duplicate ACK for already ACKed segment fast retransmit

25 TCP Flow Control

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

27 CS 4284 Spring 2013 TCP Flow Control (cont’d) (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 –guarantees receive buffer doesn’t overflow

28 CS 4284 Spring 2013 Flow Control: Persistence Timer Suppose sender is blocked cause receiver application hasn’t picked up data Then receiver app reads n bytes TCP receiver advertises new window of size RcvWindow = n But suppose this advertisement is lost Sender would be stuck –Solution: persistence timer, sender sends probe after a period of inactivity to provoke window update

29 CS 4284 Spring 2013 Flow Control: Silly Window Syndrome Clark’s solution: don’t advertise windows below a certain size

30 CS 4284 Spring 2013 Study of TCP: Outline segment structure reliable data transfer –delayed ACKs –Nagle’s algorithm timeout management, fast retransmit flow control + silly window syndrome connection management [ Network Address Translation ] [ Principles of congestion control ] TCP congestion control

31 TCP Connection Management

32 CS 4284 Spring 2013 TCP Connection Management 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 connect(s, &dstaddr, …) server: contacted by client cl=accept(sv, &caddr,…); Three way handshake: Step 1: client host sends TCP SYN segment to server –specifies initial seq # –no data Step 2: server host receives SYN, replies with SYNACK segment –server allocates buffers –specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data

33 CS 4284 Spring 2013 TCP 3-way handshake TCP connection establishment: Q1: why 3-way and not 2-way handshake? Q2: how do sender & receiver determine initial seqnums?

34 CS 4284 Spring way Handshake & Delayed Dups (a) Normal operation (b) Old SYN appearing out of nowhere. (c) Duplicate SYN and duplicate ACK following SYN. 3-way handshake required to deal with scenarios (b) and (c)

35 CS 4284 Spring 2013 Sequence Number Reuse Idea: Tie initial TCP seq numbers to clock –Increment every 4  s, guards against previous incarnations of a connection with identical sequence numbers Must also guard against sequence number prediction attack –Use PRNG see [RFC 1948], [CERT ]RFC 1948CERT RFC 1948: ISN = 4  s clock val + F(src, dst, sport, dport, random())

36 CS 4284 Spring 2013 When Sequence Numbers Attack Suppose attacker A can predict sequence number a host B is going to use next By using spoofed source IP C, A can engage in successful 3-way handshake with B –B believes it is talking to C, might grant permissions based on C’s IP address –Attacker on A must suppress the RST packets C is likely to send – use a denial-of-service attack for that A sends message to compromise B

37 CS 4284 Spring 2013 When SYNs Attack Servers receiving SYN must allocate resources –Opens up possibility of denial-of-service attack where server is flooded with bogus SYN packets with forged IP source addresses Solution: –SYN cookies Server creates ACK number, sends ACK – but does not allocate buffers –If client continues with SYNACK, check if ACK could have been sent, then allocate buffers if correct

38 Sequence Number Summary Goals Set 1: –Guard against old duplicates in one connection -> don’t reuse sequence numbers until after it’s reasonably certain that old duplicates have disappeared –Even after a crash restart -> hence tie to time -> but don’t use global clock -> hence need 3-way handshake were each side verifies the sequence number chosen by the other side before successful connection occurs Goals Set 2: –Don’t allow high-jacking of connections unless attacker can eavesdrop – use PRNG for initial seq number choice –Don’t allow SYN attacks – compute, but don’t store initial sequence number CS 4284 Spring 2013

39 TCP Connection Management (cont.) Closing a connection: client closes socket: close(s); 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

40 CS 4284 Spring 2013 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

41 CS 4284 Spring 2013 TCP Connection FSM The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled by the event causing it and the action resulting from it, separated by a slash.

42 CS 4284 Spring 2013 TCP Connection Management (cont’d) TCP client lifecycleTCP server lifecycle

43 CS 4284 Spring 2013 Closing a Connection Note: previous charts showed normal case Can we reliably close a connection if packets (FIN, ACK) can be lost? –No: Famous two-army problem

44 CS 4284 Spring 2013 Summary TCP segments, acknowledgements & retransmission –Delayed ACKs, Nagle’s algorithm –Fast retransmit RTT estimation & Karn’s algorithm Flow Control & Silly Window Syndrome Connection Management in TCP Attacks against TCP’s connection management scheme –SYN attack –Sequence number prediction attacks

45 CS 4284 Spring 2013 TCP Miscellaneous MSS Maximum Segment Size Option –Client/server agree on larger than default (536 outside same subnet) MSS, option on SYN SACK – selective acknowledgements WSCALE – scale factor for receive window to allow for LFN (“elefant”) – Large Fat Networks RFC 1323 timestamps for accurate RTT measurement, PAWS for protection against wrap-around for sequence numbers …

46 CS 4284 Spring 2013 Study of TCP: Outline segment structure reliable data transfer –delayed ACKs –Nagle’s algorithm timeout management, fast retransmit flow control + silly window syndrome connection management [ Network Address Translation ] [ Principles of congestion control ] TCP congestion control

47 TCP Congestion Control

48 CS 4284 Spring 2013 Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: –long delays (queueing in router buffers) –lost packets (buffer overflow at routers) a top-10 problem!

49 CS 4284 Spring 2013 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested (but no reduction in throughput here!) unlimited shared output link buffers Host A in : original data Host B out

50 CS 4284 Spring 2013 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet after timeout finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

51 CS 4284 Spring 2013 Causes/costs of congestion: scenario 2 Always: in = out (goodput) a) if no loss ’ in = in b) assume clairvoyant sender: retransmission only when loss certain. c) retransmission of both delayed and lost packets makes ’ in larger for same out (every packet transmitted twice) “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt b. R/2 in out a. c. R/2 in out R/4 R/2 in out R/3

52 CS 4284 Spring 2013 Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Q: what happens as in and ’ in increase ? finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

53 CS 4284 Spring 2013 Causes/costs of congestion: scenario 3 Another “cost” of congestion: when packet is dropped, any upstream transmission capacity used for that packet was wasted! ultimately leads to congestion collapse HostAHostA HostBHostB o u t

54 CS 4284 Spring 2013 Reasons for Congestion Control Congested networks increase delay even if no packet loss occurs If packet loss occurs, needed retransmission require offered load to be greater than goodput Downstream losses waste upstream transmission capacity, leading to congestion collapse in the worst case

55 CS 4284 Spring 2013 Congestion Control Approaches End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP 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 Two broad classes:

56 CS 4284 Spring 2013 TCP Congestion Control end-end control (no network assistance) sender limits transmission: LastByteSent-LastByteAcked  min(CongWin, RcvWindow) CongWin and RTT influence throughput CongWin is dynamic, function of perceived network congestion How does sender notice congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate ( CongWin ) after loss event (assumes congestion is primary cause of loss!) Three mechanisms: AIMD slow start fast recovery rate = CongWin RTT Bytes/sec

57 CS 4284 Spring 2013 TCP AIMD multiplicative decrease: cut CongWin in half after loss event additive increase: increase CongWin by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection

58 CS 4284 Spring 2013 TCP Slow Start When connection begins, CongWin = 1 MSS –Example: MSS = 500 bytes & RTT = 200 msec –initial rate = 20 kbps available bandwidth may be >> MSS/RTT –desirable to quickly ramp up to respectable rate When connection begins, increase rate exponentially fast until first loss event

59 CS 4284 Spring 2013 TCP Slow Start (more) When connection begins, increase rate exponentially until first loss event: –double CongWin every RTT –done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast Host A one segment RTT Host B time two segments four segments

60 CS 4284 Spring 2013 TCP Tahoe vs. Reno Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event If timeout event, set CongWin to 1 If triple-ack event: set CongWin to Threshold and increase linearly (this is called fast recovery and was added in version TCP Reno)

61 CS 4284 Spring 2013 Timeouts vs 3-dup ACKs After 3 dup ACKs: –CongWin is cut in half –window then grows linearly But after timeout event: –CongWin instead set to 1 MSS; –window then grows exponentially –to a threshold, then grows linearly 3 dup ACKs indicates network capable of delivering some segments timeout before 3 dup ACKs received is stronger, “more alarming” indicator of congestion Rationale:

62 CS 4284 Spring 2013 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 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!

63 CS 4284 Spring 2013 Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

64 CS 4284 Spring 2013 TCP Sender Congestion Control EventStateTCP Sender ActionCommentary ACK receipt for previously unacked data Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) set state to CA Resulting in a doubling of CongWin every RTT ACK receipt for previously unacked data Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT Triple duplicate ACK SS or CAThreshold = CongWin/2, CongWin = Threshold, Set state to CA Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. TimeoutSS or CAThreshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” Enter slow start Duplicate ACKSS or CAIncrement duplicate ACK count for segment being acked CongWin and Threshold not changed

65 CS 4284 Spring 2013 TCP Throughput: Idealized What’s the average throughout of TCP as a function of window size and RTT? –Long-lived connection: Ignore slow start When window is W, throughput is W/RTT Just after loss, window drops to W/2, throughput to W/2RTT. Average steady-state throughput:.75 W/RTT W W/2

66 CS 4284 Spring 2013 TCP Throughput & Loss Example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput Requires window size W = 83,333 in-flight segments Throughput in terms of loss rate: ➜ L = 2· Very low Require almost perfect link!

67 Equation-Based Control Note: TCP congestion control forms control loop: –Inputs: round-trip time, “loss events” (which are samples of timeout events + 3-ack events) Instead, equation-based control uses an equation to compute sending rate based on this input See RFC 5348 for more info CS 4284 Spring 2013

68 TCP Fairness

69 CS 4284 Spring 2013 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

70 CS 4284 Spring 2013 Why is TCP fair? Consider two competing sessions: additive increase gives slope of 1, as throughput increases multiplicative decrease decreases throughput proportionally R R equal bandwidth share Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2

71 CS 4284 Spring 2013 Fairness (more) Fairness and UDP Multimedia apps often do not use TCP –do not want rate throttled by congestion control Instead use UDP: –pump audio/video at constant rate, tolerate packet loss TCP friendliness Fairness and parallel TCP connections nothing prevents app from opening parallel connections between 2 hosts. Example: link of rate R supporting 9 connections; –new app asks for 1 TCP, gets rate R/10 –new app asks for 9 TCPs, gets R/2! That’s what “download accelerators” do


Download ppt "CS 4284 Systems Capstone Godmar Back Networking. TCP CS 4284 Spring 2013."

Similar presentations


Ads by Google