1. Flow and Error Control

2. 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.

3. 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.

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

5. 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

6. 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.

7. 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.

8. 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.

9. 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.

10. 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) =
Inference
1kB in msec.
Throughput = Total Data/Total Time
= (1000 * 8)/
= 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

11. 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

12. 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, …

13. 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

14. 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.

15. 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.

16. 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.

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

18. 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)

19. 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

20. 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.

21. 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.

22. 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.

23. 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

24. 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

25. Figure
TCP segment format

26. Figure
Control field

27. 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)

28. 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

29. 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

30. 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

31. Example RTT estimation:

32. 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

33. 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

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

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

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

37. 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.

38. 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.

41. Figure 12-7
Sender buffer

42. Figure 12-8
Receiver Buffer

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

44. Sliding the sender window
Figure
Sliding the sender window

45. Expanding the sender window
Figure
Expanding the sender window

46. Shrinking the sender window
Figure
Shrinking the sender window

47. 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.

48. 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.

49. 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

50. 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

51. 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.

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

53. 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();

54. Three-way handshaking
Figure
Three-way handshaking

55. 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

56. 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

57. 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.

58. Thank You