1 / 71

CS 4284 Systems Capstone

CS 4284 Systems Capstone. Networking. Godmar Back. TCP. Study of TCP: Outline. segment structure reliable data transfer flow control connection management [ Network Address Translation ] [ Principles of congestion control ] TCP congestion control. full duplex data:

rico
Download Presentation

CS 4284 Systems Capstone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 4284Systems 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. 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 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 CS 4284 Spring 2013

  5. 32 bits source port # dest port # sequence number acknowledgement number head len not used receive window U A P R S F checksum urg data pnter options (variable length) application data (variable length) TCP Segment Structure 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 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 TCP Reliable Data Transfer CS 4284 Spring 2013

  7. 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 time TCP Seq. #’s and ACKs Host B Host A 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 simple telnet scenario CS 4284 Spring 2013

  8. 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 TCP Sender Events CS 4284 Spring 2013

  9. 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 */ 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, soknow that new data is acked, set SendBase to 73 CS 4284 Spring 2013

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

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

  12. TCP ACK generation[RFC 1122, RFC 2581] 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 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 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. TCP Timeout & Fast Retransmit

  16. 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 TCP Round Trip Time and Timeout 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. Setting the timeout EstimatedRTT plus “safety margin” large variation in EstimatedRTT  larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: TCP Round Trip Time and Timeout 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. 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 Fast Retransmit 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. receive side of TCP connection has a receive buffer: speed-matching service: matching the send rate to the receiving app’s drain rate flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast TCP Flow Control • app process may be slow at reading from buffer CS 4284 Spring 2013

  27. (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 TCP Flow Control (cont’d) 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. TCP Connection Management

  32. 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 TCP Connection Management 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 2001-09] • 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. 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 server close FIN ACK close FIN ACK timed wait closed TCP Connection Management (cont.) CS 4284 Spring 2013

  40. 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. TCP Connection Management (cont.) client server closing FIN ACK closing FIN ACK timed wait closed closed CS 4284 Spring 2013

  41. TCP ConnectionFSM 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. 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! Principles of Congestion Control CS 4284 Spring 2013

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

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

More Related