Transport Layer. Transport Protocols. Transport Layer Services. Transport Services and Protocols. Transport vs. Application and Network Layer

Transcription

1 Transport Layer Transport Layer Services connection-oriented vs. connectionless multiplexing and demultplexing UDP: Connectionless Unreliable Service TCP: Connection-Oriented Reliable Service connection management: set-up and tear down reliable data transfer protocols flow and congestion control Readings: Chapter 5 (5.1, 5.2) Transport Protocols Lowest level end-toend protocol. Header generated by sender is interpreted only by the destination Routers view transport header as part of the payload Transport IP Datalink Physical IP router Transport IP Datalink Physical Csci 232 Computer Networks Transport Layer & TCP 1 Csci 232 Computer Networks Transport Layer & TCP 2 Transport Services and Protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP transport logical end-end transport transport Transport Layer Services Underlying best-effort drops messages re-orders messages delivers duplicate copies of a given message delivers messages after an arbitrarily long delay Common end-to-end services guarantee message delivery deliver messages in the same order they are sent deliver at most one copy of each message allow the receiver to flow control the sender support multiple processes on each host Csci 232 Computer Networks Transport Layer & TCP 3 Csci 232 Computer Networks Transport Layer & TCP 4 Transport vs. Application and Network Layer layer: processes and message exchange layer: logical communication between hosts transport layer: logical communication support for app processes relies on, enhances, layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill -layer protocol = postal service End to End Issues Transport services built on top of (potentially) unreliable service packets can be corrupted or lost s can be delayed or arrive out of order Do we detect and/or recover errors for apps? Error Control & Reliable Data Transfer Do we provide in-order delivery of packets? Connection Management & Reliable Data Transfer Potentially different capacity at destination, and potentially different capacity Flow and Congestion Control Csci 232 Computer Networks Transport Layer & TCP 5 Csci 232 Computer Networks Transport Layer & TCP 6 1

2 Internet Transport Protocols TCP service: connection-oriented: setup required between client, reliable transport between sender and receiver flow control: sender won t overwhelm receiver congestion control: throttle sender when overloaded UDP service: unreliable data transfer between sender and receiver does not provide: connection setup, reliability, flow control, congestion control Both provide logical communication between app processes running on different hosts! Csci 232 Computer Networks Transport Layer & TCP 7 Multiplexing/Demultiplexing Demultiplexing at rcv host: delivering received segments to correct process transport link = API ( socket ) P3 = process P1 P1 transport link host 1 host 2 Multiplexing at send host: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) transport Csci 232 Computer Networks Transport Layer & TCP 8 P2 P4 host 3 link How Demultiplexing Works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source, destination port number (recall: well-known port numbers for specific s) host uses IP addresses & port numbers to direct segment to appropriate app process (identified by socket ) 32 bits source port # dest port # other header fields data (message) TCP/UDP segment format 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 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 Csci 232 Computer Networks Transport Layer & TCP 9 Csci 232 Computer Networks Transport Layer & TCP 10 UDP (cont d) UDP Checksum often used for streaming multimedia apps loss tolerant rate sensitive other UDP users DNS SNMP reliable transfer over UDP: add reliability at layer -specific error recovery! Length, in bytes of UDP segment, including header 32 bits source port # dest port # length Application data (message) checksum UDP segment format 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 (1 s complement of 1 s complement sum of 16- bit words) 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 nonetheless? More later. Csci 232 Computer Networks Transport Layer & TCP 11 Csci 232 Computer Networks Transport Layer & TCP 12 2

3 Checksum: Example arrange data segment in sequences of bit words sum: checksum(1 s complement): Connection-oriented Byte-stream app writes bytes TCP sends segments app reads bytes Application process TCP Overview Write bytes Full duplex Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning Application process Read bytes verify by adding: TCP Send buffer TCP Receive buffer Segment Segment Segment Transmit segments Csci 232 Computer Networks Transport Layer & TCP 13 Csci 232 Computer Networks Transport Layer & TCP 14 Functionality Split Network provides best-effort delivery End-systems implement many functions Reliability In-order delivery Demultiplexing Message boundaries Connection abstraction Flow Control Congestion control 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 Use options to add information to the header Change processing at endpoints Backward compatibility is what makes it TCP Csci 232 Computer Networks Transport Layer & TCP 15 Csci 232 Computer Networks Transport Layer & TCP 16 Evolution of TCP TCP Through the 1990s 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) 1993 TCP Vegas (Brakmo et al) real congestion avoidance 1994 T/TCP (Braden) Transaction TCP 1994 ECN (Floyd) Explicit Congestion Notification 1996 S TCP (Floyd et al) Selective Acknowledgement Hoe F TCP Improving TCP (Mathis et al) startup extension to S Csci 232 Computer Networks Transport Layer & TCP 17 Csci 232 Computer Networks Transport Layer & TCP 18 3

4 TCP Segment Header Structure URG: urgent data (generally not used) : # valid PSH: push data now (generally not used) RST, SYN, : connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # sequence number acknowledgement number head not UAP R S rcvr window size len used F checksum ptr urgent data Options (variable length) data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Csci 232 Computer Networks Transport Layer & TCP 19 TCP Segment Format (cont) Each connection identified with 4-tuple: (SrcPort, SrcIPAddr, DstPort, DstIPAddr) Sliding window + flow control acknowledgment, SequenceNum, AdvertisedWinow Sender Data (SequenceNum) Receiver Acknowledgment + AdvertisedWindow Flags SYN,,, RESET, PUSH, URG Checksum pseudo header (src & dst IP addresses) + TCP header + data Csci 232 Computer Networks Transport Layer & TCP 20 TCP Connection Set Up TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. # buffers, flow control info client: end host that initiates connection : end host contacted by client Three way handshake: Step 1: client sends TCP SYN control segment to specifies initial seq # Step 2: receives SYN, replies with SYN+ control segment s received SYN specifies receiver initial seq. # Step 3:client receives SYN+, replies with segment (which may contain 1 st data segment) Csci 232 Computer Networks Transport Layer & TCP 21 initiate connection connection established client TCP 3-Way Hand-Shake SYN, seq=x SYN+, seq=y, ack=x+1, seq=x+1, ack=y+1 (1 st data segment) SYN received connection established Question: a. What kind of state client and need to maintain? b. What initial sequence # should client (and ) use? Csci 232 Computer Networks Transport Layer & TCP 22 TCP Connection Setup Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] TCP 1414 > 22 [SYN] Seq= Len=0 MSS= TCP 22 > 1414 [SYN, ] Seq= Ack= Win=25200 Len=0 MSS= TCP 1414 > 22 [] Seq= Ack= Win=16384 Len=0 TCP Connection Setup Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] TCP 1567 > 80 [SYN] Seq= Len=0 MSS= TCP 80> 1567 [SYN, ] Seq= Ack= Win=25200 Len=0 MSS= TCP 1567 > 80 [] Seq= Ack= Win=17640 Len= TCP 1567 > 80 [PSH,] Seq= Ack= Win=17640 Len= TCP 80> 1567 [] Seq= Ack= Win=25200 Len=0 MSS=1460 Csci 232 Computer Networks Transport Layer & TCP 23 Csci 232 Computer Networks Transport Layer & TCP 24 4

5 Connection Setup Error Scenarios Lost (control) packets What happen if SYN lost? client vs. actions What happen if SYN+ lost? client vs. actions What happen if lost? client vs. actions Duplicate (control) packets What does do if duplicate SYN received? What does client do if duplicate SYN+ received? What does do if duplicate received? Connection Setup Error Scenarios (cont d) Importance of (unique) initial seq. no.? When receiving SYN, how does know it s a new connection request? When receiving SYN+, how does client know it s a legitimate, i.e., a response to its SYN request? Dealing with old duplicate packets from old connections (or from malicious users) If not careful: TCP Hijacking How to choose unique initial seq. no.? randomly choose a number (and add to last syn# used) Other security concern: SYN Flood -- denial-of-service attack Csci 232 Computer Networks Transport Layer & TCP 25 Csci 232 Computer Networks Transport Layer & TCP 26 Detecting Half-Open Connections 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> (send 300, receive 100) ESTABLISHED (??) ESTABLISHED (Abort!!) D Csci 232 Computer Networks Transport Layer & TCP 27 TCP B TCP State Diagram: Connection Setup SYN RCVD Send Client D Server passive OPEN create TCP delete TCP rcv SYN snd SYN rcv of SYN LISTEN rcv SYN snd ESTAB SEND snd SYN Rcv SYN, Snd delete TCP active OPEN create TCP Snd SYN SYN SENT Csci 232 Computer Networks Transport Layer & TCP 28 TCP: Closing Connection Remember TCP duplex connection! Client wants to close connection: client Step 1: client end system sends TCP control segment to client closing Step 2: receives, replies with. half Step 3: client receives. half half, wait for to close Server finishes sending data, also ready to close: Step 4: sends. half closing TCP: Closing Connection (cont d) Step 5: client receives, replies with. connection fully Step 6:, receives. connection fully Well Done! Problem Solved? client closing half full client half closing full Csci 232 Computer Networks Transport Layer & TCP 29 Csci 232 Computer Networks Transport Layer & TCP 30 5

6 TCP: Closing Connection (revised) Two Army Problem! Step 5: client receives, replies with. Enters timed wait - will respond with to received s Step 6:, receives. connection fully Step 7: client, timer expires, connection fully client closing half timed wait full client X half closing timeout full TCP Connection Tear-Down Example No. Time Source > Destination Proto SrcPort>DstPort [Flags] TCP 1414 > 22 [PSH,] Seq= Ack= Win=15920 Len= TCP 1414 > 22 [, ] Seq= Ack= Win=15920 Len= TCP 22 > 1414 [] Seq= Ack= Win=25200 Len= TCP 22 > 1414 [] Seq= Ack= Win=25200 Len= TCP 22 > 1414 [,] Seq= Ack= Win=25200 Len= TCP 1414 > 22 [] Seq= Ack= Win=15920 Len=0 Csci 232 Computer Networks Transport Layer & TCP 31 Csci 232 Computer Networks Transport Layer & TCP 32 State Diagram: Connection Tear-down TCP Connection Management FSM TCP client lifecycle send WAIT-1 WAIT-2 Active Close ESTAB send rcv snd rcv + snd CLOSING rcv send rcv of Passive Close WAIT snd LAST- rcv of TCP client lifecycle rcv snd TIME WAIT =2min delete TCP D Csci 232 Computer Networks Transport Layer & TCP 33 Csci 232 Computer Networks Transport Layer & TCP 34 TCP Connection Management FSM TCP lifecycle TCP lifecycle Reliability and Error Recovery ARQ vs. FEC automatic retransmission request forward error correction General ARQ Algorithms Stop & Wait Perform issue: low utilization when delay-bw product large Sliding Window Protocols Go-Back-N Selective Repeat Key design issues: window size vs. size of seq. no. space Csci 232 Computer Networks Transport Layer & TCP 35 Csci 232 Computer Networks Transport Layer & TCP 36 6

7 Error Recovery: Stop and Wait ARQ Receiver sends acknowledgement () when it receives packet Sender waits for and timeouts if it does not arrive within some time period Simplest ARQ protocol Send a packet, stop and wait until arrives Time Sender Csci 232 Computer Networks Transport Layer & TCP 37 Receiver Time Recovering from Error lost lost Csci 232 Computer Networks Transport Layer & TCP 38 Early timeout DUPLICATE PETS!!! 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 Csci 232 Computer Networks Transport Layer & TCP 39 Csci 232 Computer Networks Transport Layer & TCP 40 Problem with Stop & Wait Protocol Sender first packet bit transmitted, t = 0 RTT arrives, send next packet, t = RTT + L / R data (L bytes) Receiver Can t keep the pipe full Utilization is low when bandwidth-delay product (R x RTT)is large! first packet bit arrives Stop & Wait: Performance Analysis Example: 1 Gbps connection, 15 ms end-end prop. delay, data segment size: 1 KB = 8Kb L (packet length in bits) 8 kb Ttransmit = = 9 R (transmiss ion rate, bps) 10 b/s 6 = 8 10 s = ms L / R L.008 U sender = = = = RTT + L / R RTT * R + L U sender : utilization, i.e., fraction of time sender busy sending 1KB data segment every 30 msec (round trip time) --> 0.027% x 1 Gbps = 33kB/sec throughput over 1 Gbps link Moral of story: protocol limits use of resources! Csci 232 Computer Networks Transport Layer & TCP 41 Csci 232 Computer Networks Transport Layer & TCP 42 7

8 How to Keep the Pipe Full? Send multiple packets without waiting for first to be acked Number of pkts in flight = window 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 How large a window is needed? Suppose 10Mbps link, 4ms delay, 500byte pkts 1? 10? 20? Round trip delay * bandwidth = capacity of pipe Csci 232 Computer Networks Transport Layer & TCP 43 Pipelined (Sliding Window) Protocols Pipelining: sender allows multiple, in-flight, yet-tobe-acknowledged data segments range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: Go-Back-N and Selective Repeat Csci 232 Computer Networks Transport Layer & TCP 44 Pipelining: Increased Utilization sender receiver Sliding Window first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT arrives, send next packet, t = RTT + L / R U sender = 3 * L / R RTT + L / R = first packet bit arrives last packet bit arrives, send last bit of 2 nd packet arrives, send last bit of 3 rd packet arrives, send = Increase utilization by a factor of 3! Reliable, ordered delivery Receiver has to hold onto a packet until all prior packets have arrived Why might this be difficult for just parallel stop & wait? 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 Csci 232 Computer Networks Transport Layer & TCP 45 Csci 232 Computer Networks Transport Layer & TCP 46 Sender/Receiver State Window Sliding Common Case Max received Sent & Acked Sender Next seqnum Sender window Sent Not Acked Receiver Next expected Received & Acked Receiver window Max acceptable Acceptable 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 Send cumulative acknowledges reception of all packets up to sequence number Increase sequence of max acceptable packet OK to Send Not Usable Not Usable Csci 232 Computer Networks Transport Layer & TCP 47 Csci 232 Computer Networks Transport Layer & TCP 48 8

9 Loss Recovery Go-Back-N recovery Set timer upon transmission of each packet Cumulative Retransmit all unacknowledged packets No receiver buffering, out-of-order packets are discarded Selective Repeat Sender keeps a timer for each packet Selective Receiver must buffer all out-of-order packets When timeout, retransmit only one packet Performance during loss recovery No longer have an entire window in transit Can have much more clever loss recovery Csci 232 Computer Networks Transport Layer & TCP 49 Go-Back-N in Action Csci 232 Computer Networks Transport Layer & TCP 50 Selective Repeat 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 Selective Repeat: Sender, Receiver Windows Csci 232 Computer Networks Transport Layer & TCP 51 Csci 232 Computer Networks Transport Layer & TCP 52 Sequence Numbers How large does size of sequence number space need to be? Must be able to detect wrap-around Depends on sender/receiver window size E.g. size of seq. no. space = 8, 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!!! size of sequence no. space must be send window + recv window Csci 232 Computer Networks Transport Layer & TCP 53 Sequence Numbers in TCP TCP regards data as a byte-stream each byte in byte stream is numbered. 32 bit value, wraps around initial values selected at start up time TCP breaks up byte stream in packets. size is limited to the Maximum Segment Size (MSS) Each packet has a sequence number seq. no of 1 st byte indicates where it fits in the byte stream TCP connection is duplex data in each direction has its own sequence numbers packet 8 packet 9 packet 10 Csci 232 Computer Networks Transport Layer & TCP 54 9

10 TCP Seq. # s and s Seq. # s: byte stream number of first byte in segment s data s: seq # of next byte expected from other side User types C host s receipt of echoed C Host A Host B Seq=42, =79, data = C Seq=79, =43, data = C Seq=43, =80 red: A-to-B green: B-to-A simple telnet scenario host s receipt of C, echoes back C time TCP Reliable Data Transfer TCP creates reliable data transfer service on top of IP s unreliable service Pipelined segments Cumulative s 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 Csci 232 Computer Networks Transport Layer & TCP 55 Csci 232 Computer Networks Transport Layer & TCP 56 TCP = Go-Back-N Variant Sliding window with cumulative acks Receiver can only return a single ack sequence number to the sender. Acknowledges all bytes with a lower sequence number Starting point for retransmission Duplicate acks sent when out-of-order packet received But: sender only retransmits a single packet. Reason??? Only one that it knows is lost Network is congested shouldn t overload it Error control is based on byte sequences, not packets. Retransmitted packet can be different from the original lost packet Why? 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 TCP Sender Events: timeout: retransmit segment that caused timeout restart timer received: If acknowledges previously uned segments update what is known to be ed start timer if there are outstanding segments Csci 232 Computer Networks Transport Layer & TCP 57 Csci 232 Computer Networks Transport Layer & TCP 58 TCP generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ed Arrival of in-order segment with expected seq #. One other segment has 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. Wait up to 500ms for next segment. If no next segment, send Immediately send single cumulative, ing both in-order segments Immediately send duplicate, indicating seq. # of next expected byte Immediate send, provided that segment starts at lower end of gap Csci 232 Computer Networks Transport Layer & TCP 59 receive side of TCP connection has a receive buffer: app process may be slow at reading from buffer TCP Flow Control flow control sender won t overflow receiver s buffer by transmitting too much, too fast speed-matching service: matching the send rate to the receiving app s drain rate Csci 232 Computer Networks Transport Layer & TCP 60 10

11 TCP Flow Control: How It Works (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow (dynamically changes) = RcvBuffer-[LastByteRcvd - LastByteRead] Rcvr advertises spare room by including value of RcvWindow in segments Sender limits uned data to RcvWindow guarantees receive buffer doesn t overflow URG: urgent data (generally not used) : # valid PSH: push data now (generally not used) RST, SYN, : connection estab (setup, teardown commands) Internet checksum (as in UDP) TCP Segment Structure 32 bits source port # dest port # sequence number acknowledgement number head not UAP R S rcvr window size len used F checksum ptr urgent data Options (variable length) data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Csci 232 Computer Networks Transport Layer & TCP 61 Csci 232 Computer Networks Transport Layer & TCP 62 Triggering Transmission How does TCP decide to transmit a segment? MSS (Maximum segment size) Set to size of the largest segment TCP can send without local IP fragmentation (MTU of directly connected) Sending process explicitly asked to do (Push to flush) Firing timer Silly Window Syndrome Flow control needs to be maintained Sender can transmit full segment (MSS) when Acked by receiver Silly Window Syndrome (cont d) Window currently from receiver opens MSS/2 bytes Should sender transmit MSS/2? Original TCP implementation silent Early implementation of TCP decided to go ahead Sender can not know when the window will open for full MSS If sender is aggressive, sending available window size results Silly window syndrome small segment size remains indefinitely Hence a problem when either sender transmits a small segment or receiver opens window a small amount Csci 232 Computer Networks Transport Layer & TCP 63 Csci 232 Computer Networks Transport Layer & TCP 64 Triggering Transmission (cont d) Receiver may delay s, but how long? Ultimate solution lies with sender: When does the TCP sender decide to transmit a segment? Nagle s Algorithm: Waiting too long hurt interactive s (Telnet) Without waiting, risk of sending a bunch of tiny packets (silly window syndrome) Wait till timer expires: Self clocking: As long as TCP has any data in flight, sender receives an which can be used to trigger transmission If no data in flight, immediately send the segment (setting TCP_NoDElAY option) TCP Round Trip Time and 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 receipt ignore retransmissions, why? SampleRTT will vary, want estimated RTT smoother average several recent measurements, not just current SampleRTT Csci 232 Computer Networks Transport Layer & TCP 65 Csci 232 Computer Networks Transport Layer & TCP 66 11

12 Round-trip Time Estimation Importance of accurate RTT estimators: Low RTT estimate unneeded retransmissions High RTT estimate poor throughput RTT estimator must adapt to change in RTT But not too fast, or too slow! Spurious timeouts Conservation of packets principle never more than a window worth of packets in flight Adaptive Retransmission (Original Algorithm) Measure SampleRTT for each segment/ pair Compute weighted running average of RTT EstRTT = α x EstimatedRTT + (1-α) x SampleRTT α between 0.8 and 0.9 ( to smooth Estimated RTT) - Small α indicates temp. fluctuation, a large value more stable, may not be quick to adapt to real changes Set timeout based on EstRTT TimeOut = 2 x EstRTT Csci 232 Computer Networks Transport Layer & TCP 67 Csci 232 Computer Networks Transport Layer & TCP 68 SampleR TT Sender Retransmission Ambiguity Original transmission Retransmission Receiver Sender Original transmission Receiver is for Original transmission but was for retransmission => Sample RTT is too large is for retransmission but was for original => Sample RTT too small SampleR TT Retransmission Karn/Partridge Algorithm Solution: Do not sample RTT when retransmitting only measures sample RTT for segments sent once Double timeout for each retransmission Next timeout to be twice the last timeout, rather than basing it on the last Estimated RTT Karn and Patridge proposal is exponential backoff Congestion is most likely cause of lost segments TCP sources should not react too aggressively to a timeout More timeouts mean more cautious the source should become (congestion problem) Csci 232 Computer Networks Transport Layer & TCP 69 Csci 232 Computer Networks Transport Layer & TCP 70 Jacobson/ Karels Algorithm Original computation for RTT did not take the variance of sample RTTs into account If variation among samples is small, Estimated RTT can be better used without increasing the estimate twice A large variance in the samples mean Time out values should not be too tightly coupled to the Estimated RTT New Calculations for average RTT Diff = SampleRTT - EstRTT EstRTT = EstRTT + ( δ x Diff) Dev = Dev + δ ( Diff - Dev) where δ is a fraction between 0 and 1 Consider variance when setting timeout value TimeOut = μ x EstRTT + φ x Dev where μ = 1 and φ = 4 TCP Round Trip Time Estimation EstimatedRTT = (1- α)*estimatedrtt + α*samplertt Exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = Setting the timeout interval Estimted RTT plus safety margin large variation in EstimatedRTT -> larger safety margin safty margin : accommodate variations in estimatedrtt DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (typically, β = 0.25) Interval = EstimatedRTT + 4*DevRTT Csci 232 Computer Networks Transport Layer & TCP 71 Csci 232 Computer Networks Transport Layer & TCP 72 12

13 Example RTT Estimation: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr Timestamp Extension 350 RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT Csci 232 Computer Networks Transport Layer & TCP 73 Used to improve timeout mechanism by more accurate measurement of RTT When sending a packet, insert current time into option 4 bytes for time, 4 bytes for echo a received timestamp Receiver echoes timestamp in Actually will echo whatever is in timestamp Removes retransmission ambiguity Can get RTT sample on any packet Csci 232 Computer Networks Transport Layer & TCP 74 Timer Granularity Many TCP implementations set RTO (Retransmission ) 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) Important Lessons TCP state diagram setup/teardown TCP timeout calculation how is RTT estimated Modern TCP loss recovery Why are timeouts bad? How to avoid them? e.g. fast retransmit Csci 232 Computer Networks Transport Layer & TCP 75 Csci 232 Computer Networks Transport Layer & TCP 76 13