Functionality Split Computer Networking. Transport Protocols. Overview. Multiplexing & Demultiplexing

Transcription

1 Functionality Split Computer Networking Transport Layer Network provides best-effort delivery End-systems implement many functions Reliability In-order delivery Demultiplexing Message boundaries Connection abstraction Congestion control Lecture 14: Overview Transport introduction Error recovery TCP flow control TCP connection setup/data transfer TCP reliability Transport Protocols UDP provides just integrity and demux TCP adds Connection-oriented Reliable Ordered Point-to-point Byte-stream Full duplex Flow and congestion controlled Lecture 14: Lecture 14: UDP: User Datagram Protocol [RFC 768] Multiplexing & Demultiplexing No frills, bare bones Internet transport protocol Best effort service, UDP segments may be: Lost Delivered out of order to app Connectionless: No handshaking between UDP sender, 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 Recall: segment - unit of data exchanged between transport layer entities Aka TPDU: transport protocol data unit application-layer data P1 segment M header segment H t M Hn segment application transport network P3 Demultiplexing: delivering received segments to correct app layer processes Receiver M M application transport network P4 M P2 application transport network Lecture 14: Lecture 14:

2 Multiplexing & Demultiplexing UDP, cont. Multiplexing: Gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) Based on sender, receiver port numbers, IP addresses Source, dest port #s in each segment Recall: well-known port numbers for specific applications 32 bits Source port # Dest port # Other header fields Application data (message) TCP/UDP segment format Often used for streaming multimedia apps Loss tolerant Length, in Rate sensitive bytes of UDP segment, Other UDP uses including (why?): header DNS SNMP Reliable transfer over UDP: add reliability at application layer Application-specific error recover! 32 bits Source port # Dest port # Length Application data (message) Checksum UDP segment format Lecture 14: Lecture 14: UDP Checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: Treat segment contents as sequence of 16-bit integers Checksum: addition (1 s complement sum) of segment contents Sender puts checksum value into UDP checksum field Receiver: Compute checksum of received segment Check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonethless? High-Level TCP Characteristics Protocol implemented entirely at the ends Fate sharing Protocol has evolved over time and will continue to do so Nearly impossible to change the header Uses options to add information to the header Change processing at endpoints Backward compatibility is what makes it TCP Lecture 14: Lecture 14: TCP Header Evolution of TCP Flags: SYN FIN RESET PUSH URG Source port Destination port Sequence number Acknowledgement HdrLen 0 Flags Advertised window Checksum Urgent pointer Options (variable) 1975 Three-way handshake Raymond Tomlinson In SIGCOMM TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1984 Nagel s algorithm to reduce overhead 1987 of small packets; Karn s algorithm 1990 predicts congestion to better estimate 4.3BSD Reno collapse round-trip time fast retransmit delayed s 1983 BSD Unix supports TCP/IP Congestion Van Jacobson s collapse algorithms observed congestion avoidance 1982 and congestion control TCP & IP (most implemented in RFC 793 & BSD Tahoe) Data Lecture 14: Lecture 14:

3 TCP Through the 1990s Overview 1994 T/TCP (Braden) Transaction TCP 1996 S TCP (Floyd et al) Selective Acknowledgement Transport introduction Error recovery 1993 TCP Vegas (Brakmo et al) real congestion avoidance 1994 ECN (Floyd) Explicit Congestion Notification 1996 Hoe Improving TCP startup 1996 F TCP (Mathis et al) extension to S TCP flow control TCP connection setup/data transfer TCP reliability Lecture 14: Lecture 14: Transport vs. Link Layers Logical link vs. physical link Must establish connection Variable RTT May vary within a connection Reordering How long can packets live max segment lifetime Can t expect endpoints to exactly match link Buffer space availability Transmission rate Don t directly know transmission rate Lecture 14: Error Recovery Two forms of error recovery Forward Error Correction (FEC) Automatic Repeat Request (ARQ) FEC Use error correcting codes to repair losses ARQ Receiver sends acknowledgement () when it receives packet Sender waits for and timeouts if it does not arrive within some time period Lecture 14: Stop and Wait Recovering from Error Simplest ARQ protocol Send a packet, stop and wait until acknowledgement arrives Time Sender Receiver Time lost lost Early timeout Lecture 14: Lecture 14:

4 Problems with Stop and Wait How to recognize a duplicate Performance Can only send one packet per round trip How to Recognize Resends? Use sequence numbers both packets and acks Sequence # in packet is finite -- how big should it be? For stop and wait? One bit won t send seq #1 until received for seq #0 Pkt 0 0 Pkt Pkt 1 Lecture 14: Lecture 14: How to Keep the Pipe Full? Send multiple packets without waiting for first to be acked Number of pkts in flight = window How large a window is needed Round trip delay * bandwidth = capacity of pipe Reliable, unordered delivery Several parallel stop & waits Send new packet after each ack Sender keeps list of unack ed packets; resends after timeout Receiver same as stop&wait Lecture 14: Sliding Window Reliable, ordered delivery Receiver has to hold onto a packet until all prior packets have arrived Sender must prevent buffer overflow at receiver Circular buffer at sender and receiver s in transit? buffer size Advance when sender and receiver agree packets at beginning have been received Lecture 14: Sender/Receiver State Window Sliding Common Case Max received Sent & Acked OK to Send Sender Next seqnum Sender window Sent Not Acked Not Usable Receiver Next expected Received & Acked Receiver window Max acceptable Acceptable Not Usable On reception of new (i.e. for something that was not acked earlier) Increase sequence of max received Send next packet On reception of new in-order data packet (next expected) Hand packet to application Send cumulative acknowledges reception of all packets up to sequence number Increase sequence of max acceptable packet Lecture 14: Lecture 14:

5 Loss Recovery Go-Back-N in Action On reception of out-of-order packet Send nothing (wait for source to timeout) Cumulative (helps source identify loss) (Go-Back-N recovery) Set timer upon transmission of packet Retransmit all unacknowledged packets Performance during loss recovery No longer have an entire window in transit Can have much more clever loss recovery Lecture 14: Lecture 14: Selective Repeat Selective Repeat: Sender, Receiver Windows Receiver individually acknowledges all correctly received pkts Buffers packets, as needed, for eventual in-order delivery to upper layer Sender only resends packets for which not received Sender timer for each uned packet Sender window N consecutive seq # s Again limits seq #s of sent, uned packets Lecture 14: Lecture 14: Sequence Numbers How large do sequence numbers need to be? Must be able to detect wrap-around Depends on sender/receiver window size E.g. Max seq = 7, send win=recv win=7 If pkts 0..6 are sent succesfully and all acks lost Receiver expects 7,0..5, sender retransmits old 0..6!!! Max sequence must be? send window + recv window Overview Transport introduction Error recovery TCP flow control TCP connection setup/data transfer TCP reliability Lecture 14: Lecture 14:

6 Sequence Number Space Each byte in byte stream is numbered. 32 bit value Wraps around Initial values selected at start up time TCP breaks up the byte stream in packets. size is limited to the Maximum Segment Size Each packet has a sequence number. Indicates where it fits in the byte stream packet 8 packet 9 packet 10 Lecture 14: TCP Flow Control TCP is a sliding window protocol For window size n, can send up to n bytes without receiving an acknowledgement When the data is acknowledged then the window slides forward Each packet advertises a window size Indicates number of bytes the receiver has space for Original TCP always sent entire window Congestion control now limits this Lecture 14: Window Flow Control: Send Side Window Flow Control: Send Side Sent Received Sent and acked window Sent but not acked Not yet sent Source Port Port Dest. Dest. Port Port Sequence Number Acknowledgment HL/Flags Window D. D. Checksum Urgent Urgent Pointer Options.. Source Port Port Dest. Dest. Port Port Sequence Number Acknowledgment HL/Flags Window D. D. Checksum Urgent Urgent Pointer Options.. Next to be sent App write acknowledged sent to be sentoutside window Lecture 14: Lecture 14: Window Flow Control: Receive Side Receive buffer Acked but not delivered to user Not yet acked window TCP Persist What happens if window is 0? Receiver updates window when application reads data What if this update is lost? TCP Persist state Sender periodically sends 1 byte packets Receiver responds with even if it can t store the packet Lecture 14: Lecture 14:

7 Performance Considerations The window size can be controlled by receiving application Can change the socket buffer size from a default (e.g. 16Kbytes) to a maximum value (e.g. 64 Kbytes) The window size field in the TCP header limits the window that the receiver can advertise 16 bits 64 KBytes 10 msec RTT 51 Mbit/second 100 msec RTT 5 Mbit/second Overview Transport introduction Error recovery TCP flow control TCP connection setup/data transfer TCP reliability Lecture 14: Lecture 14: Connection Establishment A and B must agree on initial sequence number selection Use 3-way handshake Sequence Number Selection Why not simply chose 0? Must avoid overlap with earlier incarnation A B SYN + Seq A SYN+-A + Seq B -B Lecture 14: Lecture 14: Connection Setup Connection Tear-down SYN RCVD Send FIN passive OPEN create TCB rcvsyn snd SYN rcv of SYN D LISTEN rcvsyn snd ESTAB delete TCB SEND snd SYN RcvSYN, Snd delete TCB active OPEN create TCB Snd SYN SYN SENT Normal termination Allow unilateral close TCP must continue to receive data even after closing Cannot close connection immediately What if a new connection restarts and uses same sequence number? Lecture 14: Lecture 14:

8 Tear-down Exchange Connection Tear-down Sender FIN FIN- FIN Receiver Data write Data ack send FIN FIN WAIT-1 FIN WAIT-2 send FIN rcvfin snd ESTAB rcvfin+ snd CLOSING rcvfin send rcv of FIN WAIT snd FIN rcv of FIN LAST- FIN- rcvfin snd TIME WAIT =2msl delete TCB D Lecture 14: Lecture 14: Detecting Half-open Connections Observed TCP Problems TCP A 1. (CRASH) 2. D 3. SYN-SENT <SEQ=400><CTL=SYN> 4. (!!) <SEQ=300><=100><CTL=> 5. SYN-SENT <SEQ=100><CTL=RST> 6. SYN-SENT 7. SYN-SENT <SEQ=400><CTL=SYN> TCP B (send 300, receive 100) ESTABLISHED (??) ESTABLISHED (Abort!!) D Too many small packets Silly window syndrome Nagel s algorithm Initial sequence number selection Amount of state maintained Lecture 14: Lecture 14: Silly Window Syndrome Problem: (Clark, 1982) If receiver advertises small increases in the receive window then the sender may waste time sending lots of small packets Solution Receiver must not advertise small window increases Increase window by min(mss,recvbuffer/2) Nagel s Algorithm Small packet problem: Don t want to send a 41 byte packet for each keystroke How long to wait for more data? Solution: Allow only one outstanding small (not full sized) segment that has not yet been acknowledged Lecture 14: Lecture 14:

9 Why is Selecting ISN Important? Suppose machine X selects ISN based on predictable sequence Fred has.rhosts to allow login to X from Y Evil Ed attacks Disables host Y denial of service attack Make a bunch of connections to host X Determine ISN pattern a guess next ISN Fake pkt1: [<src Y><dst X>, guessed ISN] Fake pkt2: desired command Time Wait Issues Web servers not clients close connection first Established Fin-Waits Time-Wait Closed Why would this be a problem? Time-Wait state lasts for 2 * MSL MSL should be 120 seconds (is often 60s) Servers often have order of magnitude more connections in Time-Wait Lecture 14: Lecture 14: Overview Transport introduction Error recovery TCP flow control TCP connection setup/data transfer TCP reliability Reliability Challenges Like reliability on links Similar techniques (timeouts, acknowledgements, etc.) New challenges Congestion related losses Variable packet delays What should the timeout be? Reordering of packets Ensure sequences numbers are not reused How long do packets live? MSL = 120 seconds based on IP behavior Lecture 14: Lecture 14: TCP = Go-Back-N Variant Receiver can only return a single ack sequence number to the sender. Acknowledges all bytes with a lower sequence number Starting point for retransmission But: sender only retransmits a single packet. Reason??? Error control is based on byte sequences, not packets. Retransmitted packet can be different from the original lost packet why? s can overlap why? Sliding window with cumulative acks Ackfield contains last in-order packet received Duplicate acks sent when out-of-order packet received Round-trip Time Estimation Wait at least one RTT before retransmitting Importance of accurate RTT estimators: Low RTT unneeded retransmissions High RTT poor throughput RTT estimator must adapt to change in RTT But not too fast, or too slow! Spurious timeouts Conservation of packets principle more than a window worth of packets in flight Lecture 14: Lecture 14:

10 Initial Round-trip Estimator Round trip times exponentially averaged: New RTT =? (old RTT) + (1 -? ) (new sample) Recommended value for? : for most TCP s Retransmit timer set to? RTT, where? = 2 Every time timer expires, RTO exponentially backed-off Like Ethernet Not good at preventing spurious timeouts Jacobson s Retransmission Key observation: At high loads round trip variance is high Solution: Base RTO on RTT and standard deviation or RRTT rttvar =? * dev + (1-?)rttvar Dev = linear deviation Inappropriately named actually smoothed linear deviation Lecture 14: Lecture 14: Retransmission Ambiguity Karn s RTT Estimator Sample RTT A B Original transmission RTO retransmission X Sample RTT A B Original transmission RTO retransmission Accounts for retransmission ambiguity If a segment has been retransmitted: Don t count RTT sample on s for this segment Keep backed off time-out for next packet Reuse RTT estimate only after one successful transmission Lecture 14: Lecture 14: Timestamp Extension Used to improve timeout mechanism by more accurate measurement of RTT When sending a packet, insert current timestamp into option 4 bytes for seconds, 4 bytes for microseconds Receiver echoes timestamp in Actually will echo whatever is in timestamp Removes retransmission ambiguity Can get RTT sample on any packet Timer Granularity Many TCP implementations set RTO in multiples of 200,500,1000ms Why? Avoid spurious timeouts RTTs can vary quickly due to cross traffic Make timers interrupts efficient What happens for the first couple of packets? Pick a very conservative value (seconds) Lecture 14: Lecture 14:

11 Delayed S TCP Generation [RFC 1122, RFC 2581] Problem: In request/response programs, you send separate and Data packets for each transaction Solution: Don t data immediately Wait 200ms (must be less than 500ms why?) Must every other packet Must not delay duplicate s Event In-order segment arrival, No gaps, Everything else already ed In-order segment arrival, No gaps, One delayed 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. Wait up to 500ms for next segment. If no next segment, send Immediately send single cumulative Send duplicate, indicating seq. # of next expected byte Immediate if segment starts at lower end of gap Lecture 14: Lecture 14: