Flow and Error Control

Flow Control Flow control coordinates the amount of data that can be sent before receiving acknowledgement It is one of the most important functions of data link layer. Receiver has a limited speed at which it can process incoming data and a limited amount of memory in which to store incoming data. Receiver must inform the sender before the limits are reached and request that the transmitter to send fewer frames or stop temporarily. Since the rate of processing is often slower than the rate of transmission, receiver has a block of memory (buffer) for storing incoming data until they are processed.

Error Control Error control includes both error detection and error correction. It allows the receiver to inform the sender if a frame is lost or damaged during transmission and coordinates the retransmission of those frames by the sender. Error control in the data link layer is based on automatic repeat request (ARQ). Whenever an error is detected, specified frames are retransmitted.

Error and Flow Control Mechanisms Stop-and-Wait Go-Back-N ARQ Selective-Repeat ARQ

Sender keeps a copy of the last frame until it receives an acknowledgement. For identification, both data frames and acknowledgements (ACK) frames are numbered alternatively 0 and 1. Sender has a control variable (S) that holds the number of the recently sent frame. (0 or 1) Receiver has a control variable that holds the number of the next frame expected (0 or 1). Sender starts a timer when it sends a frame. If an ACK is not received within an allocated time period, the sender assumes that the frame was lost or damaged and resends it Receiver send only positive ACK if the frame is intact. ACK number always defines the number of the next expected frame Stop-and-Wait

Stop-and-Wait ARQ, damaged frame When a receiver receives a damaged frame, it discards it and keeps its value of R. After the timer at the sender expires, another copy of frame 1 is sent.

Stop-and-Wait, lost ACK frame If the sender doesn’t receives an ACK (or damaged ACK, it discards it) When the timer of the sender expires, the sender retransmits frame 1. Receiver has already received frame 1 and expecting to receive frame 0 (R=0). Therefore it discards the second copy of frame 1.

Stop-and-Wait, delayed ACK frame The ACK can be delayed at the sender due to some problem It is received after the timer for frame 0 has expired. Sender retransmitted a copy of frame 0. However, R =1 means receiver expects to see frame 1. Receiver discards the duplicate frame 0. Sender receives 2 ACKs, it discards the second ACK.

Piggybacking A method to combine a data frame with ACK. Station A and B both have data to send. Instead of sending separately, station A sends a data frame that includes an ACK. Station B does the same thing. Piggybacking saves bandwidth.

Disadvantage of Stop-and-Wait RTD 3.0 Example (Stop & Wait) RTT (2 times propagation delay) for a signal = 30msec Transmission Rate, R = 1 Gbps Packet Size, L = 1kB = 8000b Transmission Delay dtrans = L/R = 8 micro sec Utilization - Fraction of time sender is busy sending U sender = (L/R) / (RTT + L/R) = 0.00027 Inference 1kB in 30.008msec. Throughput = Total Data/Total Time = (1000 * 8)/30.0008 = 267kbps (even in 1 Gbps link) In stop-and-wait, at any point in time, there is only one frame that is sent and waiting to be acknowledged. This is not a good use of transmission medium. To improve efficiency, multiple frames should be in transition while waiting for ACK. Two protocol use the above concept, Go-Back-N ARQ Selective Repeat ARQ

Pipelined Protocols send multiple packets without waiting number of outstanding packets > 1, but still limited range of sequence numbers needs to be increased buffering at sender and/or receiver Two generic forms Go-Back-N and Selective Repeat

Go-Back-N ARQ Sequence Numbers We can send up to W frames before worrying about ACKs. We keep a copy of these frames until the ACKs arrive. This procedure requires additional features to be added to Stop-and-Wait ARQ. Sequence Numbers Frames from a sender are numbered sequentially. We need to set a limit since we need to include the sequence number of each frame in the header. If the header of the frame allows m bits for sequence number, the sequence numbers range from 0 to 2 m – 1. for m = 3, sequence numbers are: 0,1, 2, 3, 4, 5, 6, 7. We can repeat the sequence number. Sequence numbers are: 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, …

Sender Sliding Window At the sending site, to hold the outstanding frames until they are acknowledged, we use the concept of a window. The size of the window is at most 2m -1 where m is the number of bits for the sequence number. Size of the window can be variable, e.g. TCP. The window slides to include new unsent frames when the correct ACKs are received

Receiver Sliding Window Size of the window at the receiving site is always 1 in this protocol. Receiver is always looking for a specific frame to arrive in a specific order. Any frame arriving out of order is discarded and needs to be resent. Receiver window slides as shown in fig. Receiver is waiting for frame 0 in part a.

Control Variables Sender has 3 variables: S, SF, and SL S holds the sequence number of recently sent frame SF holds the sequence number of the first frame SL holds the sequence number of the last frame Receiver only has the one variable, R, that holds the sequence number of the frame it expects to receive. If the seq. no. is the same as the value of R, the frame is accepted, otherwise rejected.

Acknowledgement Receiver sends positive ACK if a frame arrived safe and in order. If the frames are damaged/out of order, receiver is silent and discard all subsequent frames until it receives the one it is expecting. The silence of the receiver causes the timer of the unacknowledged frame to expire. Then the sender resends all frames, beginning with the one with the expired timer. For example, suppose the sender has sent frame 6, but the timer for frame 3 expires (i.e. frame 3 has not been acknowledged), then the sender goes back and sends frames 3, 4, 5, 6 again. Thus it is called Go-Back-N-ARQ The receiver does not have to acknowledge each frame received, it can send one cumulative ACK for several frames.

Go-Back-N ARQ, normal operation The sender keeps track of the outstanding frames and updates the variables and windows as the ACKs arrive.

Go-Back-N ARQ, lost frame Frame 2 is lost When the receiver receives frame 3, it discards frame 3 as it is expecting frame 2 (according to window). After the timer for frame 2 expires at the sender site, the sender sends frame 2 and 3. (go back to 2)

Go-Back-N ARQ, damaged/lost/delayed ACK If an ACK is damaged/lost, we can have two situations: If the next ACK arrives before the expiration of any timer, there is no need for retransmission of frames because ACKs are cumulative in this protocol. If ACK1, ACK2, and ACk3 are lost, ACK4 covers them if it arrives before the timer expires. If ACK4 arrives after time-out, the last frame and all the frames after that are resent. Receiver never resends an ACK. A delayed ACK also triggers the resending of frames

Selective Repeat ARQ, sender and receiver windows Go-Back-N ARQ simplifies the process at the receiver site. Receiver only keeps track of only one variable, and there is no need to buffer out-of-order frames, they are simply discarded. However, Go-Back-N ARQ protocol is inefficient for noisy link. It is bandwidth inefficient and slows down the transmission. In Selective Repeat ARQ, only the damaged frame is resent. More bandwidth efficient but more complex processing at receiver. It defines a negative ACK (NAK) to report the sequence number of a damaged frame before the timer expires.

Selective Repeat ARQ, lost frame Frames 0 and 1 are accepted when received because they are in the range specified by the receiver window. Same for frame 3. Receiver sends a NAK2 to show that frame 2 has not been received and then sender resends only frame 2 and it is accepted as it is in the range of the window.

Selective Repeat ARQ, sender window size Size of the sender and receiver windows must be at most one-half of 2 m. If m = 2, window size should be 2 m /2 = 2. Fig compares a window size of 2 with a window size of 3. Window size is 3 and all ACKs are lost, sender sends duplicate of frame 0, window of the receiver expect to receive frame 0 (part of the window), so accepts frame 0, as the 1st frame of the next cycle – an error.

Summary of Reliable Data Transfer Used to detect bit errors in a transmitted packet. Checksum Used to timeout/retransmit a packet, possibly because the packet (or its ACK) was lost within the channel. Timer Used for sequential numbering of packets of data. Sequence Nos Used by the receiver to tell the sender that packet(s) has been received correctly. Acknowledgement Used by the receiver to tell the sender that a packet has not been received correctly. Negative Ack The sender may be restricted to send only packets with sequence numbers that fall within a given range. Window, Pipelining

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 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 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

Figure 12-19 TCP segment format

Figure 12-20 Control field

TCP segment structure source port # dest port # application data 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F S R P A U head len not used Options (variable length) 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 estab (setup, teardown commands) Internet checksum (as in UDP)

simple telnet scenario TCP seq. #’s and ACKs 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 Host A Host B 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 time simple telnet scenario

TCP Round Trip Time and Timeout 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 ignore retransmissions SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT

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

Example RTT estimation:

TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT

Q1. Round-trip time estimation. Let α = 0. 2 Q1. Round-trip time estimation. Let α = 0.2. Suppose for a given TCP connection three acknowledgments have been returned with RTTs: RTT for first ACK = 80 msec; RTT for second ACK = 60 msec; and RTT for third ACK = 100 msec. Determine the value of EstimatedRTT after each of the three acknowledgments. A1. After the first ACK, the EstimatedRTT is equal to the RTT associated with the ACK, namely, 80 msec. After the second ACK, we use the following formula: EstimatedRTT = (1 - a) EstimatedRTT + a SampleRTT to obtain: EstimatedRTT = (0.8)(80 msec) + (0.2)(60 msec) = 76 msec Similarly, after third ACK, we get EstimatedRTT = (0.8)(76 msec) + (0.2)(100 msec) = 71.2 msec

Sending and receiving buffers Figure 12-5 Sending and receiving buffers

The bytes of data being transferred in each connection are numbered by TCP. The numbering starts with a randomly generated number.

The value of the sequence number field in a segment defines the number of the first data byte contained in that segment.

The value of the acknowledgment field in a segment defines the number of the next byte a party expects to receives. The acknowledgment number is cumulative.

A sliding window is used to make transmission more efficient as well as to control the flow of data so that the destination does not become overwhelmed with data. TCP’s sliding windows are byte oriented.

Figure 12-7 Sender buffer

Figure 12-8 Receiver Buffer

Sender buffer and sender window Figure 12-9 Sender buffer and sender window

Sliding the sender window Figure 12-10 Sliding the sender window

Expanding the sender window Figure 12-11 Expanding the sender window

Shrinking the sender window Figure 12-12 Shrinking the sender window

In TCP, the sender window size is totally controlled by the receiver window value. However, the actual window size can be smaller if there is congestion in the network.

Some Points about TCP’s Sliding Windows: 1. The source does not have to send a full window’s worth of data. 2. The size of the window can be increased or decreased by the destination. 3. The destination can send an acknowledgment at any time.

TCP Flow Control flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast flow control receive side of TCP connection has a receive buffer: speed-matching service: matching the send rate to the receiving app’s drain rate app process may be slow at reading from buffer

TCP Flow control: how it works (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

Q2. Flow control. Host A and B are directly connected with a 100 Mbps link. There is one TCP connection between the two hosts, and Host A is sending an enormous file to Host B over this connection. Host A can send application data into the link at 50 Mbps but Host B can read out of its TCP receive buffer at a maximum rate of 10 Mbps. Describe the effect of TCP flow control. A2. Host A sends data into the receive buffer faster than Host B can remove data from the buffer. The receive buffer fills up at a rate of roughly 40 Mbps. When the buffer is full, Host B signals to Host A to stop sending data by setting RcvWindow = 0. Host A then stops sending until it receives a TCP segment with RcvWindow > 0. Host A will thus repeatedly stop and start sending as a function of the RcvWindow values it receives from Host B. On average, the long-term rate at which host A sends data to host B as part of this connection is no more than 10 Mbps.

TCP Connection Establishment 6-31 (a) TCP connection establishment in the normal case. (b) Call collision.

TCP Connection Management 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 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 Socket clientSocket = new Socket("hostname","port number"); server: contacted by client Socket connectionSocket = welcomeSocket.accept();

Three-way handshaking Figure 12-28 Three-way handshaking

TCP Connection Management (cont.) Closing a connection: client closes socket: clientSocket.close(); 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 FIN server ACK close closed timed wait

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

Q3. TCP connection management. A server process in Host B has a welcoming socket at port 977. What will trigger the server process to create a connection socket? What is the source IP address and source port number for this connection socket? b. How many bytes is a TCP SYN segment? What flags are set in a TCP SYN segment? c. What must happen for Host B to complete this connection? A3. When Host B receives a TCP SYN segment with destination port number 977, the operating system at Host B will create a (half-open) connection socket. The TCP SYN packet has a source port number, which becomes the source port number of the socket. The TCP SYN segment is also contained in an IP datagram, which has a source IP address, which in turn becomes the source IP address for the socket. A TCP SYN packet contains no data and is thus 20 bytes. In a SYN segment, the SYN flag is set, but not the ACK flag. After receiving the SYN packet, the server sends to the client on Host A a SYNACK segment, which is also 20 bytes, and which has both the SYN and ACK flags set. The client then sends an ACK packet back to the server. Upon receiving this ACK packet, the connection is fully open at both the client and server sides.

Thank You