Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 4284 Systems Capstone Networking Godmar Back.

Similar presentations


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

1 CS 4284 Systems Capstone Networking Godmar Back

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

4 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex 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 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 CS 4284 Spring 2013

5 TCP Segment Structure source port # dest port # sequence number
32 bits application data (variable length) sequence number acknowledgement number receive window urg data pnter checksum F S R P A U head len not used options (variable length) URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection establishment (setup, teardown commands) Internet checksum (as in UDP) CS 4284 Spring 2013

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

7 simple telnet scenario
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 User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario CS 4284 Spring 2013

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

9 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 event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) } } /* end of loop forever */ TCP sender (simplified) 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 CS 4284 Spring 2013

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

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

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

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

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

15 Timeout & Fast Retransmit
TCP Timeout & Fast Retransmit

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

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

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

19 Example RTT estimation:
CS 4284 Spring 2013

20 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: EstimatedRTT = (1-)*EstimatedRTT + *SampleRTT DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.125,  = 0.25) TimeoutInterval = EstimatedRTT + 4*DevRTT CS 4284 Spring 2013

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

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

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

24 Fast retransmit algorithm:
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 } a duplicate ACK for already ACKed segment fast retransmit CS 4284 Spring 2013

25 TCP Flow Control

26 TCP Flow Control receive side of TCP connection has a receive buffer:
sender won’t overflow receiver’s buffer by transmitting too much, too fast 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 CS 4284 Spring 2013

27 TCP Flow Control (cont’d)
Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow guarantees receive buffer doesn’t overflow (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] CS 4284 Spring 2013

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

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

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

31 Connection Management
TCP Connection Management

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

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

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

35 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 1948: ISN = 4s clock val + F(src, dst, sport, dport, random()) CS 4284 Spring 2013

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

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

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 close closed timed wait CS 4284 Spring 2013

40 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 server closing FIN ACK closing FIN ACK timed wait closed closed CS 4284 Spring 2013

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

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

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

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

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

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

47 TCP Congestion Control

48 Principles of Congestion Control
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! CS 4284 Spring 2013

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

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

51 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) R/2 lin lout R/2 lin lout R/3 R/2 lin lout R/4 c. a. b. “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt CS 4284 Spring 2013

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

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

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

55 Congestion Control Approaches
Two broad classes: 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 CS 4284 Spring 2013

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

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

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

59 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 Host B one segment RTT two segments four segments time CS 4284 Spring 2013

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

61 Timeouts vs 3-dup ACKs After 3 dup ACKs: CongWin is cut in half
Rationale: 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 CS 4284 Spring 2013

62 Summary: TCP Congestion Control
New ACK! congestion avoidance cwnd = cwnd + MSS (MSS/cwnd) dupACKcount = 0 transmit new segment(s), as allowed new ACK . dupACKcount++ duplicate ACK slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment cwnd = cwnd+MSS transmit new segment(s), as allowed new ACK dupACKcount++ duplicate ACK L ssthresh = 64 KB L cwnd > ssthresh timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 timeout ssthresh = cwnd/2 cwnd = 1 dupACKcount = 0 cwnd = ssthresh dupACKcount = 0 New ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 fast recovery cwnd = cwnd + MSS transmit new segment(s), as allowed duplicate ACK CS 4284 Spring 2013

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

64 TCP Sender Congestion Control
Event State TCP Sender Action Commentary 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 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 CA Threshold = CongWin/2, CongWin = Threshold, Set state to CA Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Timeout CongWin = 1 MSS, Set state to “Slow Start” Enter slow start Duplicate ACK Increment duplicate ACK count for segment being acked CongWin and Threshold not changed CS 4284 Spring 2013

65 TCP Throughput: Idealized
W W/2 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 CS 4284 Spring 2013

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

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

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

71 Fairness (more) Fairness and parallel TCP connections Fairness and UDP
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 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 CS 4284 Spring 2013


Download ppt "CS 4284 Systems Capstone Networking Godmar Back."

Similar presentations


Ads by Google