TCP: Flow and Error Control

Transcription

1 1 TCP: Flow and Error Control Required reading: Kurose 3.5.3, 3.5.4, CSE 4213, Fall 2006 Instructor: N. Vlajic

2 TCP Stream Delivery 2 TCP Stream Delivery unlike UDP, TCP is a stream-oriented protocol TCP allows sending process to deliver data as a stream of bytes and receiving process to obtain data as a stream of bytes TCP creates an environment in which the two processes / applications seem to be connected by an imaginary tube sending process writes into the tube and receiving process reads from the tube

3 TCP Buffers 3 TCP Sending and Receiving Buffers TCP needs buffers for storage sending and receiving processes may not produce and consume data at the same speed (e.g. receiving application or CPU may be busy with some other task) one sending + one receiving buffer for each direction sending buffer has 3 types of locations: 1) locations that can be filled by sending process (W) 2) bytes to be sent (P) 3) bytes that have been sent but not yet acknowledged (B) receiving buffer has 2 types of locations: 1) locations to be filled by bytes received from the network (W) 2) bytes to be consumed by receiving process (P)

4 TCP Segments 4 TCP Segments TCP groups a number o bytes together into a segment, and adds a header, before handing them over to IP layer IP can transmit only packets of data, not streams of bytes! TCP segments are not necessarily of the same size TCP segment size depends on many factors including: (a) should not be too small TCP+IP overhead alone = = 40 bytes (b) should not be too large max IP = 65,535 bytes (c) should not overwhelm receiving buffer nor network (sliding adjustable-size size sender window mechanism, see pp. 7) 7

5 TCP Segments (cont.) 5 TCP Numbering Principles TCP keeps track of transmitted and received segments using two parameters: sequence number and acknowledgment number both refer to byte number not sequence number numbering is independent in each direction Sequence Number defines the number associated with the first byte contained in that segment byte numbering starts with a randomly generated 32-bit number not (necessarily) 0 Acknowledgment Number defines the number of the next byte that the receiving party expects to receive acknowledgment numbering is cumulative the receiver takes the number of the last received byte, adds 1 to it, and announces this sum as the acknowledgment number

6 TCP Flow Control 6 Network Flow Control regulates the amount of data a source can send before receiving an acknowledgment from the destination extreme case 1: send byte by byte to slow extreme case 2: send all data overwhelm receiver solution: speed matching service rate at which sender application is sending is matched against rate at which receiving application is receiving

7 TCP Flow Control (cont.) 7 TCP Flow Control controls amount of buffer data that sender can send to receiver at any particular time, using sliding window principle SLIDING WINDOW spans a portion of sending buffer containing bytes that host can safely send to other side without worrying that it might overwhelm receiver window s left pointer moves as host sends more bytes window s right pointer moves as host receives new acknowledgment What is is max size of of sliding window?! How is is it it determined?! Max window size sender buffer

8 TCP Flow Control (cont.) 8 Receive Window variable used to give sender an idea of how much free buffer space is available at the receiver during connection establishment receiver allocates a receive buffer buffer size = RcvBuffer (such allocation, in fact, happens both on client and server side) as receiver receives bytes that are correct and in sequence, it places them in receive buffer spare room in buffer = RcvWindow = RcvBuffer [Last Byte Received Last Byte Read] receiver advertises available space in receive buffer by placing RcvWindow in window size field of TCP headers RcvWindow value can be changed at any point during communication - window size field is adjusted accordingly last byte received last byte read spare room for new unacknowledged data correct, in-order, acknowledged data receiver buffer

9 TCP Flow Control (cont.) 9 Sender Window sliding window over sender buffer must be of receive window (RcvWindow) size! by keeping amount of unacknowledged data RcvWindow sender is assured that it is not overflowing the receiver sender buffer Expending Sender Window if application reads data faster than it comes in RcvWindow increases new window size value can be relayed to sender resulting in sender window expansion sender buffer

10 TCP Flow Control (cont.) 10 Shrinking Sender Window if application reads data slower than it comes in RcvWindow decrease receiver must inform sender to shrink its sender window size sender buffer Closing Sender Window if receiver buffer is totally full RcvWindow = 0 sender must entirely close its sender window now, suppose receiver does not have anything to send back to sender sender cannot learn if/when receive window opens solution: sender sends 1-byte segments to make receiver re-announce receive window size RcvWindow is sent only as part of header carrying new data and/or acknowledgment!

11 TCP Flow Control (cont.) 11 Example [ TCP window size adjustment ] What is the value of the receiver window (RcvWindow) for host A if the receiver, host B, has a buffer of size 5,000 and 1,000 bytes of received and unprocessed data? Solution: RcvWindow = 5,000 1,000 = 4,000. Host B can receive only 4,000 bytes of data before overflowing its buffer. Host B advertises this value in its next segment to A. Example [ TCP window size adjustment ] In the figure below, the sender receives a packet with an acknowledgment value of 206 and RcvWindow of 12. The host has not sent any new bytes. Show the new window. Solution: window size = 12

12 TCP Flow Control (cont.) 12 Silly Window Syndrome (SWS) phenomenon occurs as a result of 1) a transmitter immediately sends out very small amounts of data SWS by Sender 2) recipient advertises window sizes that are too small SWS by Receiver basic TCP sliding window technique does NOT set minimum size on transmitted segments this can result in a situation where many small inefficient segments are sent, rather than a smaller number of larger ones Example [ SWS by Sender ] Suppose a TCP client is receiving data from the sending application in blocks of 10 bytes. How long should the client wait before sending data? (a) send right away 10 bytes data + 40 bytes TCP/IP header 400% overhead (b) wait for more data may have to wait too long may considerably delay receiving application

13 TCP Flow Control (cont.) 13 Example [ SWS by receiver ] This diagram shows one example of how the phenomenon known as TCP silly window syndrome can arise. The client is trying to send data as fast as possible to the server, which is very busy and cannot clear its buffers promptly. Each time the client sends data the server reduces its receive window. The size of the messages the client sends shrinks until it is only sending very small, inefficient segments. source:

14 TCP Flow Control (cont.) 14 SWS by Sender occurs if sending application creates data slowly (e.g. 1 byte at a time), and TCP immediately sends data considerable network overhead! (20 byte IP + 20 byte TCP) Client Telnet: send a key header byte 41 bytes header 40 bytes Server Telnet: acknowledge header 40 bytes Server Telnet: after processing data update RcvWindw SWS by Sender Avoidance Nagle s Solution: (a) as long as there is no un-ack data outstanding in the buffer, data can be immediately send even if only 1 byte (b) while there is un-ack data, all subsequently segments are held in the buffer until (b.1) previous segment is acknowledged (fast network) (b.2) enough data have accumulated to fill a max-size segment (slow network) advantage: algorithm self-adjusts to traffic load disadvantage: should be disabled in interactive applications

15 TCP Flow Control (cont.) 15 SWS by Receiver: Receive Window Size = 0 receiver s buffer is full application reads 1 byte room for one more byte inform sender header new RcvWindow sent data from sender header byte new byte arrives receiver s buffer is full SWS by Receiver Avoidance 1) Clark s Solution: send an ACK as soon as data arrives with RcvWindow = 0 as long as (a) half the buffer frees up, or (b) enough space for maximum size segment 2) Delayed Acknowledgments: do NOT ACK segments immediately wait until decent amount of space available advantage: less traffic than with Clark s Solution disadvantage: delayed ACKs may force sender to retransmit

16 TCP Error Control 16 TCP Error Control TCP delivers entire stream to application program on the other end reliably no lost segments no corrupted segments no duplicated segments all segments in order TCP Error Control provides service for detecting corrupted segments, lost segments, duplicated and out-of-order of-order order segments. Special Tools for TCP Error Control (a) sequence numbers enable detection of lost, out-of -order or duplicate segments on receiver side (b) checksum enables detection of corrupted segments on receiver s side (c) acknowledgment (d) timers enable error control on sender side TCP sender starts one timer for each segment sent (theoretically see Kurose, pp. 239); ; if corresponding ACK does not arrive before timer expires segment is considered lost or corrupted and must be retransmitted

17 TCP Error Control (cont.) 17 TCP ACK Generation Recommendation [ RFC 1122, RFC 2581 ] 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. TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK. (prevents creating extra traffic) Immediately send single cumulative ACK, ACKing both in-order segments. Immediately send duplicate ACK, indicating seq. # of next expected byte. (enables fast retransmit) Immediately send ACK, provided that segment starts at lower end of gap. Many of of TCP error correction procedures have evolved as as a result of of more than years of of experience!

18 TCP Error Control (cont.) 18 Example [ TCP error control normal operation ] receiver sender

19 TCP Error Control (cont.) 19 Detection of Lost, Out-Of Of-Order Order and Corrupted Segments 1) receiver detects (a) lost and out-of-order segments by receiving seg. with higher sequence numbers than expected action: discard out-of-order segments? (b) corrupted segments - immediately using checksum action: discard corrupted segment 2) sender detect lost, out-of-order and corrupted seg. by NOT receiving their ACKs within Time-out interval action: retransmit Rule 3 Rule 4

20 TCP Error Control (cont.) 20 Receiver Action on Detecting Lost and Out-of of-order Segments: Fast Retransmit simply discard segments ineffective keep segments but do not send any ACK ineffective (must wait entire Time-out to receive missing segment) keep segment and reacknowledge last in-order byte received enables fast retransmit Example [ TCP error control fast retransmit ] (a) (b) receiver - on every out-of-order seg. acknowledge the last in-order byte received sender - in case that 3 duplicate ACKs are received immediately retransmit the missing segment (fast retransmit) even if the segment s timer has not expired; then proceed with fast recovery... (Kurose, pp. 245!) Why should we wait for (at (at least) 3 duplicate ACK before initiating ing fact recovery?!

21 TCP Error Control (cont.) 21 Detection of Lost Acknowledgments 1) receiver detects lost acknowledgments by receiving duplicate segments action: resend acknowledgement, discard duplicate 2) sender detects lost acknowledgments (a) if corresponding timer expires, as in lost segments (sender cannot tell the difference between a lost segment and a lost ACK the same recovery mechanism applies) (b) may not even notice a lost acknowledgment - TCP uses cumulative acknowledgment system, so each ACK is confirmation that everything up to the byte specified

22 TCP Error Control (cont.) 22 Example [ TCP error control lost ACK scenario ] Host A Host B Host A Host B Seq=92, 8 bytes data timeout X loss ACK=100 Seq=92, 8 bytes data timeout Seq=92, 8 bytes data Seq=100, 20 bytes data X loss ACK=100 ACK=120 ACK=100 time lost ACK scenario time Cumulative ACK scenario Sender notices lost acknowledgments if its packets are sent timeout (or more) time units apart.

23 23

24 TCP Error Control (cont.) 24 TCP Timers detects missing ACKs checks 0-size windows detects idle clients used in connection termination Time-waited Timer during connection termination, connection is held limbo for time-waited period (usually 2*MSL) to make sure that all packets created by this connection have died off (see pp. 30 earlier lecture) MSL 120 [sec] may depend on OS implementation Keep-alive Timer timer used in some implementations to prevent a long idle connection between two TCPs (usually 2h) each time server hears from client, it resets this timer if server does not hear from client in 2h, it sends a probe segment; if there is no response in 10 probes, 75 sec apart, server terminates connection

25 TCP Error Control (cont.) 25 Persistence Timer timer used to correct 0-size receive window deadlock (see pp. 10) assume: (a) sender receives and ACK with RcvWindow = 0 (b) sender stops transmission (c) receiver eventually frees buffer and sends and ACK with non-zero RcvWindow, but this ACK gets lost! consequence: deadlock sender may wait forever! SOLUTION: each time a sender gets a 0-window segment it starts persistence timer (a) if timer goes off send a probe segment with only 1-byte of data (b) probe segments alert receiving TCP that acknowledgment may have got lost and should be resent initially persistence timer = 2*RTT = retransmission timer; after that it is doubled until reaching 60 sec; finally one probe every 60 sec

26 TCP Error Control (cont.) 26 Retransmission Timer / Timeout (RTO) determines how long to wait for ACK of a previously sent segment before retransmission depends on distance and network congestion different for each connection, may change during connection-lifetime estimated RTO = RTT + Δ(RTT), accounts for irregularities in the network or simply RTO 2 * RTT RTT t( ACK received ) - t( data sent ) Initiating TCP T1 Data Tx Data Propagation Responding TCP Ack Processing T2 Data Processing Ack Tx Ack Propagation ~ Round-Trip Time (RTT) = T2 T1 Calculation of RTT TCP determines approximate RTT between devices and adjusts it over time to compensate for increases and decreases does not use a single number instead, uses dynamic / adaptive formulas that employ a sequence of earlier observations of RTT

27 TCP Error Control (cont.) 27 Average / Smoothed RTT Update Formulas 1) Simple Average estimated ARTT(K + 1) = 1 K + 1 observed K + 1 RTT(i) i= 1 easier to calculate not necessary to calculate entire summation K 1 ARTT(K + 1) = ARTT(K) + RTT(K + 1) K + 1 K + 1 drawback: gives equal weight to each observation solution: give greater weight to more recent instances since they are more likely to reflect future behavior 2) Exponential (Smoothed) SRTT(K + 1) = α SRTT(K) + ( 1 α) RTT(K + 1) Average 0<α<1 smaller values of α give greater weight to more recent observations α=0.5 last 4-5 observations matter, α=0.85 last 10 observations matter

28 TCP Error Control (cont.) 28 Example [ simple vs. exponential average significance of choosing right α ]

29 TCP Error Control (cont.) 29 Karn s Algorithm assume an ACK has arrived after retransmission of a TCP segment does this ACK correspond to the original or retransmitted segment?! the source cannot distinguish between two cases misinterpreatation can cause RTT to be set much too high or much too low solution Karn s Algorithm: do not update the value of ARTT with RTTs measured for retransmitted segments

30 Exercise In data are sent or processed at a very inefficient rate, such as 1 byte at a time. (a) Nagle s syndrome (b) silly window syndrome (c) sliding window syndrome (d) delayed acknowledgment. 2. Suppose Host A sends two TCP segments back to back to Host B over a TCP connection. The first segment has a sequence number 90, the second segment has sequence number 110. (a) How much data is in the first segment? (b) Suppose that the first segment is lost but the second segment arrives at B. In the ACK that Host B sends to Host A, what will be the ACK number?