Networks Protocols

Lecture - 5
 Challenges of Reliable Data Transfer

• Over a perfectly reliable channel

– All of the data arrives in order, just as it was sent
– Simple: sender sends data, and receiver receives data
• Over a channel with bit errors
– All of the data arrives in order, but some bits corrupted
– Receiver detects errors and says “please repeat that”
– Sender retransmits the data that were corrupted
• Over a lossy channel with bit errors
– Some data are missing, and some bits are corrupted
– Receiver detects errors but cannot always detect loss
– Sender must wait for acknowledgment (“ACK” or “OK”)
– … and retransmit data after some time if no ACK arrives

2
 TCP Support for Reliable Delivery
• Checksum
– Used to detect corrupted data at the receiver
– …leading the receiver to drop the packet
• Sequence numbers
– Used to detect missing data
– ... and for putting the data back in order
• Retransmission
– Sender retransmits lost or corrupted data
– Timeout based on estimates of round-trip time
– Fast retransmit algorithm for rapid retransmission
3
 Protocol Data Units (PDU)
• At each layer, protocols are used to communicate.
• Control information is added to user data at each
layer
• Transport layer may fragment user data
• Each fragment has a transport header added
– Destination
– Sequence number
– Error detection code
• This gives a transport protocol data unit
 Initial Sequence Number (ISN)

• Sequence number for the very first byte

• So, TCP requires changing the ISN over time

5
TCP Three-Way Handshake

6
 Establishing a TCP Connection
A B
SYN

SYN A
CK Each host
tells its ISN
ACK to the other
Data host.
Data SYN (synchronize sequence number)

• Three-way handshake to establish connection

– Host A sends a SYN (open) to the host B
– Host B returns a SYN acknowledgment (SYN ACK)
– Host A sends an ACK to acknowledge the SYN ACK 7
 Automatic Repeat reQuest (ARQ)
• Automatic Repeat Request
– Receiver sends
acknowledgment (ACK) when
Sender Receiver
it receives packet
– Sender waits for ACK and Packe
t
timeouts if it does not arrive

Timeout
within some time period
ACK
• Simplest ARQ protocol
– Stop and wait Time
– Send a packet, stop and wait
until ACK arrives

8
 Reasons for Retransmission

Packe Packe Packe

t t t
Timeout

Timeout

Timeout
ACK K
AC
Packe
Packe Packe t
t t
Timeout

Timeout

Timeout
ACK
ACK ACK

Packet lost ACK lost Early timeout

DUPLICATE DUPLICATE
PACKET PACKETS
9
 How Long Should Sender Wait?
• Sender sets a timeout to wait for an ACK
– Too short: wasted retransmissions
– Too long: excessive delays when packet lost
• TCP sets timeout as a function of the RTT
– Expect ACK to arrive after an RTT
– … plus a fudge factor to account for queuing
• But, how does the sender know the RTT?
– Can estimate the RTT by watching the ACKs
– Smooth estimate: keep a running average of the RTT
• EstimatedRTT = a * EstimatedRTT + (1 –a ) * SampleRTT
– Compute timeout: TimeOut = 2 * EstimatedRTT
10
 Motivation for Sliding Window
• Stop-and-wait is inefficient
– Only one TCP segment is “in flight” at a time
– Especially bad when delay-bandwidth product is high
• Numerical example
– 1.5 Mbps link with a 45 msec round-trip time (RTT)
• Delay-bandwidth product is 67.5 Kbits (or 8 KBytes)
– But, sender can send at most one packet per RTT
• Assuming a segment size of 1 KB (8 Kbits)
• … leads to 8 Kbits/segment / 45 msec/segment  182 Kbps
• That’s just one-eighth of the 1.5 Mbps link capacity

11
 Sliding Window
• Allow a larger amount of data “in flight”
– Allow sender to get ahead of the receiver
– … though not too far ahead
Sending process Receiving process

TCP TCP
Last byte written Last byte read

Next byte expected

Last byte ACKed

Last byte received

Last byte sent 12
 Receiver Buffering
• Window size
– Amount that can be sent without acknowledgment
– Receiver needs to be able to store this amount of data
• Receiver advertises the window to the receiver
– Tells the receiver the amount of free space left
– … and the sender agrees not to exceed this amount
Window Size

Data ACK’d Outstanding Data OK Data not OK

Un-ack’d data to send to send yet 13
TCP provides flow control by having the sender maintain a
variable called the receive window.
Informally, the receive window is used to give the sender an
idea about how much free buffer space is available at the
receiver. In a full-duplex connection, the sender at each side
of the connection maintains a distinct receive window. The
receive window is dynamic, i.e., it changes throughout a
connection's lifetime.
 The receive window (RcvWindow) and the receive buffer (RcvBuffer)

Suppose that host A is sending a large file to host B over a TCP connection. Host B
allocates a receive buffer to this connection; denote its size by RcvBuffer. From time to
time, the application process in host B reads from the buffer. Define the following
variables:
LastByteRead = the number of the last byte in the data stream read from the buffer by the
application process in B.
LastByteRcvd = the number of the last byte in the data stream that has arrived from the
network and has been placed in the receive buffer at B.
 Because TCP is not permitted to overflow the allocated buffer, we
must have:

LastByteRcvd - LastByteRead <= RcvBuffer

The receive window, denoted RcvWindow, is set to the amount of
spare room in the buffer:

RcvWindow = RcvBuffer - [ LastByteRcvd - LastByteRead]

Because the spare room changes with time, RcvWindow is dynamic.

How does the connection use the variable RcvWindow to provide the flow control
service?
Host B informs host A of how much spare room it has in the connection buffer by
placing its current value of RcvWindow in the window field of every segment it
sends to A. Initially host B sets RcvWindow = RcvBuffer.
Note that to pull this off, host B must keep track of several connection-specific
variables.
Host A in turn keeps track of two variables, LastByteSent and
LastByteAcked, which have obvious meanings.
Note that the difference between these two variables, LastByteSent -
LastByteAcked, is the amount of unacknowledged data that A has sent
into the connection.
By keeping the amount of unacknowledged data less than the value of
RcvWindow, host A is assured that it is not overflowing the receive
buffer at host B. Thus host A makes sure throughout the connection's
life that LastByteSent - LastByteAcked <= RcvWindow.
There is one minor technical problem with this scheme. To see this, suppose host B's receive
buffer becomes full so that RcvWindow = 0.?
Fast Retransmission
 Timeout is Inefficient
• Timeout-based retransmission
– Sender transmits a packet and waits until timer expires
– … and then retransmits from the lost packet onward
 Tearing Down the Connection
B

SYN A

FIN A
ACK

ACK
ACK
SYN

FIN
FIN
Data

C
CK

K
A
time

• Closing the connection

– Finish (FIN) to close and receive remaining bytes
– And other host sends a FIN ACK to acknowledge
– Reset (RST) to close and not receive remaining bytes
20