Networks and Operating Systems Chapter 7: Transport Layer

Transcription

1 Systems Group Department of Computer Science ETH Zürich Networks and Operating Systems Chapter 7: Transport Layer Donald Kossmann & Torsten Höfler Frühjahrssemester 2013

2 Overview Part 1 Transport layer services Multiplexing/Demultiplexing Connectionless transport: UDP 2 Part 2 Connection-oriented transport: TCP reliable transfer flow control connection management Principles of congestion control TCP congestion control:

3 3 Transport Layer

4 SENDER Transport layer in perspective 4 RECEIVER

5 Transport-layer protocols Internet transport services reliable, in-order unicast delivery (TCP) congestion control flow control connection setup unreliable ( best-effort ), unordered unicast or multicast delivery (UDP) application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical Services not available real-time / latency guarantees application transport network data link physical bandwidth guarantees reliable multicast 5

6 Multiplexing Demultiplexing IP (Internet protocol) delivers packages to interface (i.e., NIC). How do we know to which socket the package should go? Transport Layer is responsible for delivering data to correct socket. It does that based on info from IP and its own info (i.e., ports). UDP and TCP do it differently bits source port # dest port # other header fields application data (message) TCP/UDP segment format (inside of an IP packet that contains source & dest IP)

7 UDP Recall: The receiver has only one DatagramSocket identified by IP address and Port bind operation of socket will fail if violate uniqueness De-multiplexing based on destip, destport only (uniquely define socket)

8 UDP and ports (De-multiplexing) Application process Application process Application process Application process PORTS (sockets) queues UDP 8 packets

9 TCP Recall: server can have several sockets attached to the same interface (destip) and port (destport) Case 1: listener for new connection requests Case 2: sockets for established connections Case 2: de-multiplex based on destip, destport, sourceip, sourceport sender can have several connections to same destip, destport, but they have different sourceport Case 1: de-multiplex based on destip, destport, special SYN flag (see later) (SYN flag indicates connection request)

10 Multiplexing/Demultiplexing host A source port: x dest. port: 23 server B Web client host C source port:23 dest. port: x port use: simple telnet app (UDP) Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web client host A Source IP: A Dest IP: B source port: x dest. port: 80 Web server B port use: Web server (TCP) 10

11 UDP: User Datagram Protocol RFC 768 no frills, bare bones Internet transport protocol best effort service, UDP segments may be lost delivered out of order to application UDP is connectionless no handshaking between UDP sender and receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired 11

12 UDP Segment Structure often used for streaming multimedia apps Length, in loss tolerant bytes of UDP rate sensitive segment, other UDP uses including DNS header SNMP [Why?] reliable transfer over UDP add reliability at application layer application-specific error recovery 32 bits source port # dest port # length Application data (message) checksum UDP segment format 12

13 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender treat segment contents as sequence of 16-bit integers checksum: 1 s complement sum of addition of segment contents sender puts checksum value into UDP checksum field Receiver add all 16-bit integers (including checksum) check if computed sum is 11 1 NO! error detected YES! no error detected. But maybe errors nonetheless! 13

14 TCP Overview socket door application writes data TCP send buffer application reads data TCP receive buffer socket door segment Reliable, connection-oriented byte-stream Most widely used protocol today Byte stream: no message boundaries Connection oriented: point-to-point, 1 sender, 1 receiver Full-duplex: bidirectional data on one connection See RFCs: 793, 1122, 1323, 2018, 2581, 14 Or Stevens.

15 TCP functionality is complex! Lots of things happening Connection management Setup, teardown, protocol error handling, failures, etc. Multiplexing of connections over IP End-to-end management over many hops Flow control Sender should not be able to overwhelm receiver Reliability Data is always delivered eventually, nothing is lost or corrupted Data is delivered in order Congestion control Senders should not cause Internet to collapse 15 Note: all this functionality is intertwined!

16 TCP in stages Segment layout and basic operation Connection management Reliable delivery & Flow control Retransmissions and adaptive timeouts Congestion control 16

17 TCP Segment layout And basic operation

18 TCP Segments Port numbers for multiplexing head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U A P R S F rcvr window size ptr urgent data Options (variable length) application data (variable length) 18

19 TCP Segments Counting data for sliding window - Note: bytes not segments! head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U A P R S F rcvr window size ptr urgent data Options (variable length) application data (variable length) 19

20 TCP Segments Flags for connection management: ACK: ack # valid SYN: setup conn. FIN: teardown RST: error URG: urgent data PSH: push data head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U A P R S F application data (variable length) rcvr window size ptr urgent data Options (variable length) 20

21 TCP Segments Internet checksum (as in UDP) head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U A P R S F rcvr window size ptr urgent data Options (variable length) application data (variable length) 21

22 TCP Segments How many bytes the receiver is willing to accept (flow control) head len 32 bits source port # dest port # sequence number acknowledgement number not used checksum U A P R S F rcvr window size ptr urgent data Options (variable length) application data (variable length) 22

23 TCP sequence numbers and ACKs Sequence numbers byte stream number of first byte in segment s data ACKs Sequence number of next byte expected from other side cumulative ACK User types C Host A Host B host ACKs receipt of C, echoes back C Q How does receiver handle out-of-order segments? TCP spec doesn t say; it is up to implementation! but sender must assume worst (i.e., Go Back N) 23 host ACKs receipt of echoed C simple telnet scenario time

24 TCP Connection management

25 Generic problem Both client and server need to agree: Is there a connection at all? What state is it in? What sequence numbers shall we start with? start at random position disentangle with previous conversations between same entities improves security (more difficult to guess for man in middle ) When is the connection torn down? What to do if either side misbehaves? How to handle (any) packets being lost? 25

26 Three-way handshake Setting up a connection Need to exchange initial sequence numbers Acks are always sequence number + 1! Client Server time 26

27 Connection teardown 1) client sends FIN segment 2) server replies with ACK. Closes connection, sends FIN. closing client server 3) client replies with ACK. Enters timed wait - will respond with ACK to received FINs 4) server receives ACK. Connection closed. 27 timed wait closed closing closed

28 State transitions at client and server Server Client 28

29 TCP state-transition diagram Close / FIN SYN_rcvd Passive Open SYN / SYNACK Closed Listen Close Close Send / SYN SYN / SYNACK ACK SYNACK / ACK Established Active open / SYN SYN_sent Close / FIN FIN / ACK FIN_wait_1 FIN / ACK Close_wait ACK Close / FIN FIN_wait_2 Closing Last_Ack 29 FIN / ACK ACK Time_wait Timeout after 2 segment lifetimes ACK Closed

30 Not shown in the previous diagram! Most states that send a packet set a timeout If no reply, retry Eventually close If unexpected messages arrive (bad flags, or weird sequence numbers) RST segments used to immediately terminate connection Also used where server doesn t want to talk 30

31 TCP reliability and flow control

32 TCP: reliable data transfer event: data received from application above create, send segment wait wait for event event event: timer timeout for segment with seq # y retransmit segment simplified sender, with one way data transfer no flow control no congestion control event: ACK received, with ACK # y ACK processing 32

33 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 } Comment: SendBase-1: last cumulatively ack ed byte Example: SendBase-1 = 71 y= 73 so rcvr wants 73+ y > SendBase, so that new data is acked } /* end of loop forever */ 33

34 TCP: retransmission scenarios Host A Host B Host A Host B timeout X loss Seq=92 timeout SendBase = time lost ACK scenario Sendbase = 100 SendBase = 120 SendBase = 120 Seq=92 timeout time premature timeout

35 TCP: retransmission scenarios Host A Host B timeout X loss SendBase = time Cumulative ACK scenario

36 TCP ACK generation (RFC 1122, RFC 2581) 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, ACKing both in-order segments send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap 36

37 TCP Flow Control RcvBuffer size of TCP Receive Buffer RcvWindow amount of spare room in Buffer Receiver explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment Sender keeps the amount of transmitted, unacked data less than most recently received RcvWindow flow control sender won t overrun receiver s buffers by transmitting too much, too fast 37

38 Timeouts and RTT estimation

39 TCP Round Trip Time and Timeout Q: How do we set TCP timeout value? longer than RTT 39 note: RTT will vary too short premature timeout unnecessary retransmissions too long slow reaction to segment loss Q: How to estimate RTT? SampleRTT: ignore retransmissions, cumulatively ACKed segments SampleRTT will vary, we want estimated RTT smoother use several recent measurements, not just current SampleRTT

40 TCP Round Trip Time and Timeout EstimatedRTT = (1-α) EstimatedRTT + α SampleRTT Exponential weighted moving average influence of given sample decreases exponentially fast typical value α = Setting the timeout EstimatedRTT plus safety margin large variation in EstimatedRTT larger safety margin Timeout = EstimatedRTT + 4 Deviation 40 Deviation = (1-β) Deviation + β SampleRTT-EstimatedRTT

41 Example RTT estimation RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT

42 Fast Retransmit Time-out period often long long delay before resending lost packet Detect lost segments via duplicate ACKs Sender often sends many segments back-to-back If segment lost, there will be many duplicate ACKs. Hack: 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 implemented as part of TCP Reno (standard today) (TCP Tahoe only relies on timeouts.) 42

43 Fast retransmit algorithm event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y dupcounter = 1 if (there are currently not-yet-acknowledged segments) start timer } else { dubcounter++ if (dupcounter == 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit 43

44 Congestion and Congestion Control

45 Principles of Congestion Control Different from flow control! Manifestations long delays (queuing in router buffers) lost packets (buffer overflow at routers) Example: 45 Congestion too many sources sending too much data too fast for network to handle Router with infinite buffer size can handle 1Mb per second. There are 10 connections through router with 200kb/s each. Delays are growing with time! Question: How long are delays if 10 connections have 150kb/s only? What about 100 kb/s? 90kb/s? 50kb/s? 10kb/s?!?

46 Congestion Scenario 1 (no problem) two equal senders, two receivers one router with infinite buffer space with capacity C no retransmission large delays when congested maximum achievable throughput 46

47 Congestion Scenario 2 (no problem) one router with only finite buffer sender retransmission of lost packet more work for the same throughput 47

48 Congestion: Scenario 3 (Reality) A network of routers (queues), with multihop paths. Still analytically solvable when streams and routers are Markov. But there are retransmissions, timeouts, etc. Typical behavior (thrashing): throughput gets worse with more and more input. 48

49 Approaches for congestion control Two approaches generally used End-end congestion control no explicit feedback about congestion from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted cong. control routers provide feedback to end systems single bit indicating congestion (used in SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at 49

50 End-to-End Congestion Control Challenges How to detect congestion? If the network doesn t tell you How to react in the face of congestion? Back off perhaps, but by how much? And for how long? How fast to send at the beginning? When you don t know what the situation is 52

51 Detecting congestion in TCP Long delays Queues fill up in routers TCP sees estimated RTT going up Packet losses Routers drop packets TCP sees timeouts and duplicate ACKs 53

52 TCP congestion control Probe for usable bandwidth ideally: transmit as fast as possible without loss increase rate until loss (congestion) loss: decrease rate then begin probing (increasing) again Congestion window In bytes! Keeps track of current sending rate NOT the same as the receiver window! Actual window used is minimum of the two. 54

53 How much to increase and decrease? Additive increase, multiplicative decrease Increase cautiously, back off quickly Important for stability maths hard though! Increase: Linearly, when last congestion window s worth successfully sent Decrease: Halve the congestion window when loss is detected 55

54 TCP congestion window over time Window size Loss here Window halved sawtooth 56 Time

55 TCP congestion window details TCP segments have a maximum size (MSS) Determined by lower layer protocols Increase window by MSS bytes, never decrease to < 1 MSS. w segments, each with MSS bytes sent in one RTT: throughput = w MSS RTT Bytes/sec 57

56 How to start? What s the initial congestion window? Start slowly (CWND = 1 MSS) Initial rate = MSS/RTT But additive increase is slow takes too long to get up to speed! Solution: ramp up quickly to start This is called slow start At one time, it was (relatively) slow Increase rate exponentially until first loss Double CWND for each ack ed MSS. 58

57 TCP Slow start Slow start algorithm Host A Host B initialize: CWND = 1 for (each segment ACKed) CWND++ until (lost event OR CWND > threshold) RTT exponential increase (per RTT) in window size (not so slow!) lost event: timeout and/or three duplicate ACKs time 59

58 TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* CWND > threshold */ Repeat { w = CWND every w bytes ACKed: CWND++ } until (loss event) threshold = CWND/2 CWND = 1 Go back to slowstart 60