Chapter 3: Transport Layer

3.1 Introduction and Transport-Layer Services

A transport-layer protocol provides for logical communication (as if the hosts running the
processes were directly connected) between application processes running on different hosts.
Application processes use the logical communication provided by the transport layer to send
messages to each other, free from the worry of the details of the physical infrastructure used.
Transport-layer protocols are implemented in the end systems but not in network routers. On
the sending side, the transport layer converts the application messages into transport-layer
packets, known as transport-layer segments. This is done by breaking them into smaller chunks
and adding a transport-layer header to each chunk. The transport-layer then passes the segment
to the network-layer packet at the sending end-system. On the receiving side, the network layer
extracts the transport-layer segment from the datagram and passes the segment up to the
transport-layer which then processes the received segment, making the data in the segment
available to the received application.

3.1.1 Relationship between Transport and Network Layers

A transport-layer protocol provides logical communication between processes running on

different hosts. Whereas a network-layer protocol provides a logical communication between
hosts.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

1
3.1.2 Overview of the Transport Layer in the Internet

A TCP/IP network (such as the Internet) makes two distinct transport-layer protocols available to
the application layer:

 UDP [User Datagram Protocol], which provides an unreliable, connectionless service to

the invoking application.

 TCP [Transmission Control Protocol] which provides a reliable, connection-oriented

service to the invoking application.

We need to spend a few words on the network-layer protocol: the Internet network-layer
protocol is the IP (Internet Protocol). It provides a logical communication between hosts. The IP
service model is a best-effort delivery service: it makes the best effort to deliver segments
between hosts, but it doesn’t provide guarantees:

 it doesn't guarantee segment delivery

 it doesn't guarantee orderly delivery of segments

 it doesn't guarantee the integrity of the data in the segments

Thus IP is said to be an unreliable service. Every host has at least one network-layer address a
so-called IP address.

UDP and TCP extend IP's delivery service between 2 end systems to a delivery service between
two processes running on the end systems. Extend host-to-host delivery to process-to-process
delivery is called transport-layer multiplexing and demultiplexing.

UDP provides process-to-process delivery and error checking services. Therefore it is an

unreliable service. TCP provides reliable data transfer using flow control, sequence numbers,
acknowledgements and timers. TCP thus converts IP's unreliable service between end systems
into a reliable data transport service between processes. TCP also provides congestion control, a
service not really provided to the invoking application as it is to the Internet as a whole: it
prevents any TCP connection from swamping the links and routers between communication
hosts with an excessive amount of traffic giving each connection traversing a congested link an
equal share of the bandwidth.

3.2 Multiplexing and Demultiplexing

Here we'll cover multiplexing & demultiplexing in the context of the Internet but a
multiplexing/demultiplexing service is needed for all computer networks.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

2
  The job of delivering the data in a transport-layer segment to the correct socket is called
demultiplexing.

 The job of gathering data chunks at the source host from different sockets,
encapsulating each data chunk with header information (which will be used in
demultiplexing) to create segments and passing the segments to the networks layer is
called multiplexing.

Therefore sockets need to have unique identifiers and each segment needs to have special fields
that indicate the socket to which the segment is delivered. These fields are the source port
number field and the destination port number field. Each port number is a 16-bit number
ranging from 0 to 65535. Port numbers ranging from 0 to 1023 are called well-known port
numbers and are restricted, reserved for us by well-known application protocols such as HTTP
(80) and FTP (21). Designing an application, we should assign it a port number.

Connectionless Multiplexing and Demultiplexing

A UDP socket is fully identified by the two-tuple: (destination IP address, destination port
number) therefore if two UDP segments have different source IP address and/or source port
numbers but have the same destination IP address and destination port number, than the two
segments will be directed to the same destination process via the same destination socket. The
source port number serves as part of the return address.

Connection-oriented Multiplexing and Demultiplexing

A TCP socket is identified by the four-tuple: (source IP address, source port number, destination
IP address, destination port number) When a TCP segment arrives from the network to a host,
the host uses all four values to demultiplex the segment to the appropriate socket. Two arriving
TCP segments with different source IP addresses or source port numbers will (with the
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

3
exception of a TCP carrying the original connection establishment request) be directed to two
different sockets.

Routine:

 The TCP server application always has a welcoming socket that waits for connection
establishment requests from TCP clients on port number X

 The TCP client creates a socket and sends a connection establishment request (a TCP
segment including destination port, source port number and a special connection-
establishment bit set in the TCP header)

 The server OS receives the incoming connection-request segment on port X , it locates

the server process that is waiting to accept a connection on port number X , then
creates a new socket which will be identified by (source port number in the segment
(cleint), IP address of source host (client), the destination port number in the segment
(its own), its own IP address)

 With the TCP connection in place, client and server can now send data to each other

The server may support many simultaneous TCP connection sockets, with each socket attached
to a process and each socket identified by its own four-tuple. When a TCP segment arrives at the
host, all the fours fields are used to demultiplex the segment to the appropriate socket.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

4
And there may be a threaded server that has multiple sockets for one process.

Port Scanning

Can be used both by attackers and system administrator to find vulnerabilities in the target or to
know network applications are running in the network. The most used port scanner is nmap
free and open source. For TCP it scans port looking for port accepting connections, for UDP
looking for UDP ports that respond to transmitted UDP segments. It then returns a list of open,
closed or unreachable ports. A host running nmap can attempt to scan any target anywhere in
the Internet.

Web Servers and TCP

In a web server, all segments have destination port 80 and both the initial connection-
establishment segments and the segments carrying HTTP request messages will have
destination port 80, the server will distinguish clients using the source IP addresses and port
numbers. Moreover in today's high-performing Web, servers often use only one process and
create a new thread with a new connection soket for each new client connection.

If using persistent HTTP, client and server will exchange messages via the same server socket. If
using non-persistent HTTP, a new TCP connection is created and closed for every
request/response and hence a new socket is created and closed for every request/response.

3.3 Connectionless Transport: UDP

UDP does multiplexing/demultiplexing, light error checking, nothing more. If the developer
chooses UDP, the application is almost directly talking with IP. Note that with UDP there is no
handshaking between sending and receiving transport-layer entities before sending a segment.
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

5
For this reason UDP is said to be connectionless. DNS is an example of an application layer
protocol that typically uses UDP: there is no handshaking and when a client doesn't receive a
reply either it tries sending the query to another name server or it informs the invoking
application that it can't get a reply.

Why should a developer choose UDP?

 Finer application-level control over what data is sent and when: as soon as the
application passes data to UDP, UDP will package the data inside a segment and
immediately pass it to the network layer. TCP's congestion control can delay the sending
of the segment and will try sending the packet until this is received. In real time
applications the sending rate is important, so we can trade off some data loss for some
sending rate.

 No connection establishment UDP just send data without any formal preliminaries
without introducing any delay, probably the reason why DNS runs over UDP.

 No connection state: because a UDP application doesn't need to keep track of the users
or to keep connections alive, it can typically support many more active clients than a
TCP application.

 Small packet header overhead TCP has 20 bytes of header overhead in every segment
versus the 8 of UDP.

It is possible for an application developer to have reliable data transfer when using UDP. This
can be done if reliability is built into the application itself (eg adding acknowledgement and
retransmission mechanisms) but it is a nontrivial task and may keep the developer busy for a
long time.

3.3.1 UDP Segment Structure

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

6
The UDP header has only four fields, each consisting of two bytes:

 source port number

 destination port number

 checksum (used for error detection.)

 length (which specifies the number of bytes in the UDP segment, header + data)

 This length field is needed since the size of the data field may differ from one UDP
segment to the next.

3.3.2 UDP Checksum

It provides for error detection, to determine whether the bits in the segment have been altered
as it moves from source to destination.

At the send side, UDP performs the 1s complement of the sum of all the 16-bit (max 64) words
in the segment, with any overflow encountered during the sum being wrapped around. This
result is put in the checksum field of the UDP segment header.

UDP implements error detection according to the end-end principle: certain functionality (error
detection in this case) must be implemented on an end-end basis:

"functions placed at the lower levels may be redundant or of little value when compared to the
cost of providing them at the higher level".

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

7
3.4 Principles of Reliable Data Transfer
It is the responsibility of a reliable data transfer protocol to implement reliable data service: no
transferred data bits are corrupted or lost and all are delivered in the order in which they were
sent. We will consider the following actions:

 The sending side of the data transfer protocol will be invoked from above by a call to
rdt_send()

 On the receiving side rdt_rcv() will be called when a packet arrives while deliver_data()
will be called when the rdt protocol wants to deliver data to the upper layer.

We use the term packet rather than segment because the concepts explained here applies to
computer networks in general. We will only consider the case of unidirectional data transfer
that is data transfer from the sending to the receiving side.

The case of reliable bidirectional (full-duplex) data transfer is not more difficult but more
tedious to explain. Nonetheless sending and receiving side will need to transmit packets in both
directions.

3.4.1 Building a Reliable Data Transfer Protocol

3.4.2 Pipelined Reliable Data Transfer Protocols

A more realistic model of the underlying channel is one in which bits in a packet may be
corrupted. Such bit errors typically occur in the physical components of a network as a packet is
transmitted, propagates, or is buffered. This protocol uses both positive acknowledgments
(“OK”) and negative acknowledgments (“Please repeat that.”). These control messages allow the
receiver to let the sender know what has been received correctly, and what has been received in
error and thus requires repeating. In a computer network setting, reliable data transfer
protocols based on such retransmission are known as ARQ (Automatic Repeat reQuest)
protocols.

We’ll continue to assume for the moment that all transmitted packets are received (although
their bits may be corrupted) in the order in which they were sent.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

8
The following figure shows the FSM representation of rdt2.0, a data transfer protocol employing
error detection, positive acknowledgments, and negative acknowledgments. The send side of
rdt2.0 has two states. In the leftmost state, the send-side protocol is waiting for data to be
passed down from the upper layer. When the rdt_send(data) event occurs, the sender will
create a packet (sndpkt) containing the data to be sent, along with a packet checksum and then
send the packet via the udt_send(sndpkt) operation. In the rightmost state, the sender protocol
is waiting for an ACK or a NAK packet from the receiver. If an ACK packet is received (the
notation rdt_rcv(rcvpkt) && isACK(rcvpkt) in the above figure, the sender knows that the most
recently transmitted packet has been received correctly and thus the protocol returns to the
state of waiting for data from the upper layer. If a NAK is received, the protocol retransmits the
last packet and waits for an ACK or NAK to be returned by the receiver in response to the
retransmitted data packet. It is important to note that when the sender is in the wait-for-ACK-
or-NAK state, it cannot get more data from the upper layer; that is, the rdt_send() event can’t
occur; that will happen only after the sender receives an ACK and leaves this state. Thus, the
sender will not send a new piece of data until it is sure that the receiver has correctly received
the current packet. Because of this behavior, protocols such as rdt2.0 are known as stop-and-
wait protocols.

Protocol rdt2.0 may look as if it works but, we haven’t accounted for the possibility that the ACK
or NAK packet could be corrupted! Minimally, we will need to add checksum bits to ACK/NAK
packets in order to detect such errors. The more difficult question is how the protocol should
recover from errors in ACK or NAK packets. The difficulty here is that if an ACK or NAK is

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

9
corrupted, the sender has no way of knowing whether or not the receiver has correctly received
the last piece of transmitted data.

A simple solution to this new problem is to add a new field to the data packet and have the
sender number its data packets by putting a sequence number into this field. the sequence
number of the received packet has the same sequence number as the most recently received
packet or a new packet . Since we are currently assuming a channel that does not lose packets,
ACK and NAK packets do not themselves need to indicate the sequence number of the packet
they are acknowledging. rdt2.1, the fixed version of rdt2.0. The rdt2.1 sender and receiver FSMs
each now have twice as many states as before. This is because the protocol state must now
reflect whether the packet currently being sent (by the sender) or expected (at the receiver)
should have a sequence number of 0 or 1.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

10
Protocol rdt2.1 uses both positive and negative acknowledgments from the receiver to the
sender. When an out-of-order packet is received, the receiver sends a positive acknowledgment
for the packet it has received. When a corrupted packet is received, the receiver sends a
negative acknowledgment.

We can accomplish the same effect as a NAK if, instead of sending a NAK, we send an ACK for
the last correctly received packet. A sender that receives two ACKs for the same packet (that is,
receives duplicate ACKs) knows that the receiver did not correctly receive the packet following
the packet that is being ACKed twice.

The NAK-free reliable data transfer protocol for a channel with bit errors is rdt2.2, shown in the
following figure.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

11
Suppose now that in addition to corrupting bits, the underlying channel can lose packets as well.
There are many possible approaches toward dealing with packet loss. Here, the burden of
detecting and recovering from lost packets is put on the sender. Suppose that the sender
transmits a data packet and either that packet, or the receiver’s ACK of that packet, gets lost. In
either case, no reply is forthcoming at the sender from the receiver. If the sender is willing to
wait long enough so that it is certain that a packet has been lost, it can simply retransmit the
data packet.

But how long must the sender wait? The sender must clearly wait at least as long as a round-trip
delay between the sender and receiver plus whatever amount of time is needed to process a
packet at the receiver. If an ACK is not received within this time, the packet is retransmitted. if a
packet experiences a particularly large delay, the sender may retransmit the packet even though
neither the data packet nor its ACK have been lost. This introduces the possibility of duplicate
data packets in the sender-to-receiver channel.

The rdt3.0, a protocol that reliably transfers data over a channel that can corrupt or lose
packets.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

12
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

13
In today's high-speed networks stop-and-wait protocols are simply not tolerable: we cannot
send one packet and wait for the ACK and then send the second one, it is inefficient as we can
see computing the utilization of the channel:

The solution is simple: rather than operate in a stop-and-wait manner, the sender is allowed to
send multiple packets without waiting for acknowledgements. Since the many in-transit send-to-
receiver packets can be visualized as filling a pipeline, this technique is known as pipelining.
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

14
Some consequences:

The range of sequence numbers must be increased: each in-transit packet must have a unique
sequence number Sender and receiver may have to buffer more than one packet.

Two basic approaches toward pipelined error recovery can be identified: Go-Back-N and
Selective Repeat.

3.4.3 Go-Back-N (GBN)

The window at the sender is as follows:

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

15
The sender is allowed to send N packets (sender window size = N), the receiver has a window of
size 1. If a segment from sender to receiver is lost, the receiver discards all the segments with
sequence number greater than the sequence number of the dropped packet, answering with
ACK with this sequence number. (no packet re-ordering) The sender will wait for ACK in order to
move the window and send new packets. The wait is not infinite, after a certain time a timeout
will occur and the sender will retransmit all the packets in the sending window. In a Go-Back-N
protocol, acknowledgements are cumulative: if sender receives ACK3 he will know that all the
packets from 0 to 3 have been received, even if hasn't received ACK2.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

16
3.4.4 Selective Repeat

When the window-size and bandwidth-delay product are both large, many packets can be in the
pipeline and a single packet error can thus cause GBN to retransmit a large number of packets,
many unnecessarily. Selective Repeat avoid unnecessary retransmissions by having the sender
retransmit only those that packets it suspects were received in error at the receiver: individual
acknowledgements (opposed to cumulative). sender window size = N and receiver window size
= N.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

17
The sender has a timer for each packet in its window. When a timeout occurs, only the missing
packet is resent. The receiver buffers out of order packets.

The following figure illustrate the idea of the Selective repeat:

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

18
3.5 Connection-Oriented Transport: TCP
3.5.1 The TCP Connection

TCP is said to be connection-oriented because before one application process can begin to send
data to another, the two processes must first "handshake" with each other. During the
connection establishment, both sides of the connection will initialize many TCP state variables.
TCP connection is not an end-to-end TDM or FDM circuit nor is it a virtual circuit as the
connection state resides entirely in the two end systems and not in the intermediate network
elements. A TCP connection provides a full-duplex service: when a connection between process
A and process B, application layer data can flow from A to B and, at the same time, from B to A.
TCP is also point-to-point: a connection is always between a single sender and a single receiver,
no multicast possible.

Establishment of the connection: the client first sends a special TCP segment, the server
responds with a second special TCP segment and the client answer again with a third special TCP
segment. The first two cannot contain a payload while the third can. Three segments: three-way
handshake. Both the sender and the receiver have buffers that are set up during the handshake.
The maximum amount if data that can be grabbed and placed in a segment is limited by the
maximum segment size (MSS). TCP therefore splits data into smaller chunks and pairs each
chunk of client data with a TCP header thereby forming TCP segments which are passed down to
the network layer. When TCP receives a segment at the other end, the segment's data is placed
in the TCP connection's receive buffer. Each side of the connection has its own send buffer and
its own receive buffer.

3.5.2 TCP Segment Structure

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

19
  32 bit sequence number and acknowledgement number necessary for reliable data
transmission

 16 bit receive window used for flow control, indicates the number of bytes that a
receiver is willing to accept

 4 bit header length field. The TCP header can be of a variable length due to the TCP
options field (usually empty therefore usual length is 20 bytes)

 options field used to negotiate MSS or as a window scaling factor for use in high speed
networks.

 flag field: 6 bits:

i. ACK used to indicate that the value carried in the acknowledgement field is valid, that is the
segment contains an acknowledgement for a segment that has been successfully received.

ii. , 3. and 4. RST, SYN, FIN for connection setup and teardown

iii. PSH indicates that the receiver should pass the data to upper layer immediately

iv. URG indicates that there is data in the segment that the sending side upper layer has marked
as urgent.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

20
Sequence Numbers and Acknowledgment Numbers

TCP views data as an unstructured, but ordered, stream of bytes and TCP's use of sequence
numbers reflects this view: sequence numbers are over the stream of bytes and not over the
series of transmitted segments. The sequence number for a segment is the byte-stream number
of the first byte in the segment. EX 500,000 bytes, MSS = 1,000 bytes => 500 segments are
created. First is numbered 0, second 1000, third 2000.....

The acknowledgement number that Host A puts in its segment is the sequence number of the
next byte Host A is expecting from Host B. TCP is said to provide cumulative acknowledgements:
if sender receives ACK 536 he will know that all the bytes from 0 to 535 have been well received.
What does a host do when it receives out-of-order segments? The receiver buffers the out-of-
order bytes and waits for the missing bytes to fill in the gaps. Usually both sides of a TCP
connection randomly choose an initial sequence number randomly both for security and for
minimizing the possibility that a segment that is still present in the network from an earlier,
already terminated connection between two hosts is mistaken for a valid segment in a later
connection between these same two hosts.

3.5.3 Round-Trip Time Estimation and Timeout

TCP uses a timeout/retransmit mechanism to recover from lost segments. The question rises:
How long should the timeout intervals be? Clearly the timeout should be larger than the
connection's round-trip time? How much larger? How can the RTT be evaluated?

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

21
Estimating the Round-Trip Time

The sample RTT, SampleRTT , for a segment is the amount of time between when the segment
is sent (passed to network layer) and when an acknowledgement for the segment is received.
Most TCP implementations take one SampleRTT at a time: at any point in time, the SampleRTT
is being estimated for only one of the transmitted but currently unacknowledged segments,
leading to a new value of SampleRTT for approximatively every RTT. TCP never computes a
SampleRTT for a segment that has been retransmitted, only for segments transmitted once. In
order to estimate a typical RTT, TCP keeps an average called EstimatedRTT of the SampleRTT
values. Upon obtaining a new SampleRTT TCP updates this estimation according to the formula:

EstimatedRTT = (1 - α) * EstimatedRTT + α * SampleRTT

where usually α = 1/8 = 0.125

We note that this weighted average puts more weight on recent samples than on old samples.
In statistics such an average is called an exponential weighted moving average (EWMA). It is also
useful to having an estimate of the variability of the RTT. We can measure how much
SampleRTT typically deviates from EstimatedRTT :

DevRTT = (1 - β) * DevRTT + β * | SampleRTT - EstimatedRTT |

The recommended value for b is β = 0.25

We note that this is an EWMA of the difference of estimated and last measured RTT. Setting and
Managing the Retransmission Timeout Interval

TimeoutInterval = EstimatedRTT + 4 * DevRTT

An initial TimeoutInterval value of 1 second is recommended. Also when a timeout occurs, the
value of TimeoutInterval is doubled in order to avoid a premature timeout occurring for a
subsequent segment that will soon be acknowledged. As soon as a segment is received and
EstimatedRTT is updated, the TimeoutInterval is again computed using the formula above.

3.5.4 Reliable Data Transfer

TCP creates a reliable data transfer service on top of IP's unreliable best-effort service. It
ensures that the data stream that a process reads out of its TCP receive buffer is uncorrupted,
without gaps, without duplication and in sequence. We supposed until now that an individual
timer was associated with each transmitted segment. However timer management can require
considerable overhead. Thus the recommended TCP timer management procedures (defined by
RFC standards) use only a single retransmission timer (it is helpful to think of the timer as being
associated with the oldest unacknowledged segment).
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

22
1. Upon receiving data from the application layer, TCP encapsulates it in a segment and passes
to the segment to IP. If the timer is not running for some other segment, TCP starts it when the
segment is passed to IP, the timer expiration interval being TimeoutInterval.

2. If the timeout occurs, TCP responds by retransmitting the segment that caused the timeout
and by restarting the timer.

3. An valid acknowledgement segment is received: TCP compares the ACK y value with its
sendBase (the sequence number of the oldest unacknowledged byte). If y > sendBase then ACK
is acknowledging one or more previously unacknowledged segments (cumulative
acknowledgement). The sendBase variable is updated and the timer is restarted if there are
not-yet-acknowledged segments.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

23
TCP Retransmission Scenarios

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

24
Doubling the Timeout Interval

Each time TCP retransmits, it sets the next timeout interval to twice the previous value.
However when the timer is restarted after receiving data from the application layer or after
receiving an ACK, the TimeoutInterval is recomputed as described previously.

Fast Retransmit

The problem with timeout-triggered retransmission is that the timeout period can be relatively
long. The sender can however often detect packet loss before the timeout event occurs by
noting duplicate ACKs. A duplicate ACK is an ACK that reacknowledges a segment for which the
sender has already received an earlier acknowledgement.

When the TCP sender receives three duplicate ACK for the same data it takes this as an
indication that the segment following the segment that has been ACKed three times has been
lost. In the case that three duplicate ACKs are received, the TCP sender performs a fast
restransmit: it retransmits the missing segment before that segment's timer expires.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

25
Go-Back-N or Selective Repeat?

Acknowledgments are cumulative (GBN) but many TCP implementations will buffer correctly
received but out-of-order segments. Also consider fast retransmit where only the missing packet
is resent (SR) instead of all the window (GBN). We can see that TCP's error recovery mechanism
is categorized as a hybdrid of GB and SR protocols.

3.5.5 Flow Control

The host on each side of a TCP connection set aside a receive buffer for the connection. When
TCP receives bytes that are correct and in sequence, it places the data in the receive buffer. The
associated application process will read data from this buffer, but necessarily at the instant the
data arrives (busy, not interested...). Thus the the sender can easily overflow the connection's
receive bufffer by sending too much data too quickly.

To avoid this event, TCP provides a flow-control service. Flow control is a speed-matching
service: matching the rate at which the sender is sending against the rate at which the receiving
application is reading.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

26
Flow control and congestion control are not the same: the former preventing overflow at
the receiver side and being actuated only by the two end points, the latter preventing
congestion of the network.

TCP provides flow control by having the sender maintain a variable called the receive window,
used to give the sender an idea of how much free buffer space is available at the receiver.

Host A sends a large file to Host B over TCP.

 Receiver B “advertises” free buffer space by including rwnd value in TCP header
of receiver-to-sender segments

• RcvBuffer size set via socket options (typical default is 4096 bytes)

• many operating systems autoadjust RcvBuffer

 sender A limits amount of unacked (“in-flight”) data to receiver’s rwnd value

 guarantees receive buffer will not overflow

B side

1. B allocates a receive buffer to its connection, its size being `RcvBuffer`

2. B also keeps the variables: `LastByteRead` (number of last byte in the data stream read by the
application process) and `LastByteRcvd` (the number of the last byte arrived from the network
and placed in the receive buffer)

We have:

LastByteRcvd - LastByteRead <= RcvBuffer (we don't want overflow!)

Receive window equal the amount of spare room in the buffer

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

27
 rwnd = RcvBuffer - [LastByteRcvd - LastByteRead] rwnd is dynamic

A side

A keeps track of two variables:

1. `LastByteSent`

2. `LastByteAcked`

Through the connection's life A must make sure that

LastByteSent - LastByteSent <= rwnd

If B's buffer becomes full, he sends rwnd = 0 . If B has nothing to send to A, when the
application process empties B's buffer, TCP does not send a new segment with the new value of
rwnd to A (TCP sends to A only if it needs to send data or if it needs to send an ACK). Therefore
A is never informed that B's buffer has some free space and he is blocked and can trasmit no
more data. To solve this problem, TCP requires A to continue to send segments with one data
byte when B's receive window is 0, these segments will be acknowledged by B. Eventually the
buffer will begin to empty and the acknowledgements will contain à non-zero rwnd value.

NOTE:

UDP has no flow control service

3.5.6 TCP Connection Management

How is the connection established? Three-way handshake

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

28
1. The client-side TCP sends a special TCP segment to server-side TCP. This segment doesn't
contain any application-layer data but the flag bit SYN is set to 1. The segment is referred to as a
SYN segment. The client also randomly chooses an initial sequence number ( client_isn ) and
puts this number in the sequence number field of the initial TCP SYN segment. (randomizing
client_isn is interesting to avoid security attacks).

2. The TCP SYN segment arrives at the server-side, it is extracted from the datagram. The server
allocates the TCP buffers and variables to the connection and sends a connection-granted
segment to the client. This segment also contains no application-layer data. The SYN flag is set
to 1, the ACK field in the header is set to client_isn+1. The server chooses its own initial
sequence number server_isn and puts this value in the sequence number field of the TCP
segment header. This segment is referred to as SYNACK segment.

3. Upon receiving the SYNACK segment, the client also allocates buffers and variables to the
connection. The client then sends the server yet another segment which acknowledges the
SYNACK ( server_isn+1 is set the acknowledgement field of the TCP segment header)

After this setup, all the segments will have the SYN bit set to 0 in their headers.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

29
Tearing down a TCP connection

The client decides to end the connection:

1. The client sends a special TCP segment to the server, this special segment having the FIN bit
flag set to 1 in the header.

2. The server receives the segment and sends an acknowledgement to the client.

3. The server then sends its own shutdown segment which also has the FIN bit set to

4. The client acknowledges the server's shutdown segment.

5. The "resources" (buffers and variables) in the hosts are deallocated.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

30
What if the two ends are not ready for communication?

A host receives a TCP segment whose port number or source IP address do not match with any
of the ongoing sockets in the host -> the host sends a special reset segment to the source (RST
flag bit set to 1) and drops the packet (UDP does responds with a special ICMP datagram)

3.6 Principles of Congestion Control

In practice, such loss typically results from the over-flowing of router buffers as the network
becomes congested. Packet retransmission thus treats a symptom of network congestion (the
loss of a specific transport-layer segment) but does not treat the cause of network congestion—
too many sources attempting to send data at too high a rate. To treat the cause of network
congestion, mechanisms are needed to throttle senders in the face of network congestion.

3.6.1 The Causes and the Costs of Congestion

Scenario 1: Two Senders, a Router with Infinite Buffers

We begin by considering perhaps the simplest congestion scenario possible:

Two hosts (A and B) each have a connection that shares a single hop between source and
destination, Let’s assume that the application in Host A is sending data into the connection (for
example, passing data to the transport-level protocol via a socket) at an average rate of in
bytes/sec. These data are original in the sense that each unit of data is sent into the socket only
once. The underlying transport-level protocol is a simple one. Data is encapsulated and sent; no
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

31
error recovery (e.g., retransmission), flow control, or congestion control is performed. Ignoring
the additional overhead due to adding transport- and lower-layer header information, the rate
at which Host A offers traffic to the router in this first scenario is thus λ in bytes/sec. Host B
operates in a similar manner, and we assume for simplicity that it too is sending at a rate of λ in
bytes/sec. Packets from Hosts A and B pass through a router and over a shared outgoing link of
capacity R. The router has buffers that allow it to store incoming packets when the packet-
arrival rate exceeds the outgoing link’s capacity. In this first scenario, we assume that the router
has an infinite amount of buffer space.

The following figures plots the performance of Host A’s connection under this first scenario. The
left graph plots the per-connection throughput (number of bytes per second at the receiver) as a
function of the connection-sending rate. For a sending rate between 0 and R/2, the throughput
at the receiver equals the sender’s sending rate—everything sent by the sender is received at
the receiver with a finite delay. When the sending rate is above R/2, however, the throughput is
only R/2. This upper limit on throughput is a consequence of the sharing of link capacity
between two connections. The link simply cannot deliver packets to a receiver at a steady-state

rate that exceeds R/2. No matter how high Hosts A and B set their sending rates, they will each
never see a throughput higher than R/2.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

32
Scenario 2: Two Senders, a Router with finite Buffers

 one router, finite buffers

 sender retransmission of timed-out packet

• application-layer input = application-layer output: λin = λout

• transport-layer input includes retransmissions : λ'in > λin

Packets can be lost, dropped at router due to full buffers

 sender only resends if packet known to be lost

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

33
  sender times out prematurely, sending two copies, both of which are delivered

From the two previous cases the goodput at the receiver will decrease as follows

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

34
3.7 TCP Congestion Control
TCP limits the rate at which it sends traffic into its connection as a function of perceived network
congestion. The TCP congestion-control mechanism operating at the sender keeps track of an
additional variable: the congestion window, noted cwnd which imposes a constraint on the rate
at which a TCP sender can send traffic into the network. Specifically:

LastByteSent - LastByteAcked <= min{cwnd, rwnd} .

Limiting the amount of unacknowledged data at the sender we can limit the sender's send rate.
At the beginning of each RTT the sender sends cwnd bytes of data and at the end of the RTT he
acknowledges. Thus the sender's send rate is roughly cwnd/RTT bytes/sec. Adjusting the value
of cwnd the sender can adjust the rate at which it sends data into the connection.

Let now consider a loss event (timeout OR three duplicate ACKs) .When there is excessive
congestion some router buffers along the path overflows, causing a loss event at the sender
which is taken by the sender to be an indication of congestion on the sender-to-receiver path. If
there is no congestion then all the acknowledgements will be received at the sender, which will
take these arrivals as an indication that segments have been received and that he can increase
the congestion window size and hence its transmission rate. If acknowledgements arrive at a
slow rate then the congestion window will be increased at a relatively slow rate and, vice versa,
it will be increased more quickly if ACKs arrive at a high rate. Because TCP uses
Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

35
acknowledgements to trigger (or clock) its increase in congestion window size, TCP is said to be
self-clocking.

TCP uses the principles:

1. A lost segment implies congestion therefore the sender rate should be decreased.

2. An acknowledged segment means the network's working, therefore the sender's rate can be
increased (if ACK of unacknowledged segment).

3. Bandwidth probing: the transmission rates increases with ACKs and decreases with loss
events: TCP is continuously checking (probing) the congestion state of the network

TCP Congestion-Control Algorithm

Generally, When a connection begins and assuming that losses are indicated by triple duplicate
ACKs rather than timeouts, TCP’s congestion control consists of linear (additive) increase in
cwnd of 1 MSS per RTT and then a halving (multiplicative decrease) of cwnd on a triple
duplicate-ACK event. For this reason, TCP congestion control is often referred to as an additive-
increase, multiplicative decrease (AIMD) form of congestion control. AIMD congestion control
gives rise to the “saw tooth” behavior, which also nicely illustrates our earlier intuition of TCP
“probing” for bandwidth—TCP linearly increases its congestion window size (and hence its
transmission rate) until a triple duplicate-ACK event occurs. It then decreases its congestion
window size by a factor of two but then again begins increasing it linearly, probing to see if there
is additional available bandwidth.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

36
Now we will illustrate the TCP congestion control Algorithm in more details. There are three
components in TCP congestion control algorithm:

1 - Slow Start
When a TCP connection begins, cwnd is usually initialized to a small value of 1 MSS and only one
segment is sent. Each acknowledged packet will cause the cwnd to be increased by 1 MSS and
the sender will send now two segments (because the window is increased by one for each ack).
Therefore the number of segments doubles at each RTT, therefore the sending rate also doubles
every RTT. Thus TCP send rate starts slow but grows exponentially during the slow start phase.

When does the growth end?

Timeout:

cwnd is set to 1 MSS

The slow start is started.

Also the variable slow start threshold is initialized:

ssthresh = cwnd / 2 - (half of value of cwnd when congestion is detected)

When cwnd >= ssthresh

slow starts is stopped -> congestion avoidance state.

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

37
2 - Congestion Avoidance
TCP suppose congestion is present, how to adapt?

Instead of doubling cwnd every RTT, cwnd is increased by just a single MSS every RTT.

When should this linear increase stop?

Timeout:

cwnd is set to 1 MSS,

ssthresh = cwnd (when loss happened) / 2

Three duplicate ACKs:

cwnd = (cwnd / 2) + 3 MSS

ssthresh = cwnd (when 3ACKs received) / 2 -> fast recovery state

3 - Fast Recovery

cwnd is increased by 1 MSS for every duplicate ACK received for the missing state that caused
TCP to enter this state.

When the ACK arrives for the missing segment, TCP goes into Congestion Avoidance after
reducing cwnd .

Timeout:

cwnd is set to 1 MSS

ssthresh is set to half the value of cwnd when the loss event occurred.

Fast recovery is recommended but not required in TCP, in fact only the newer version of TCP,
TCP Reno incorporated fast recovery.

This figure illustrates the three state of TCP congestion control algorithm:

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

38
The following figure illustrates an example of two TCP versions(TCP Tahoe, TCP Reno)
and how they behave in case of congestion control:

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

39
  loss indicated by timeout:

• cwnd set to 1 MSS;

• window then grows exponentially (as in slow start) to threshold, then grows
linearly

 loss indicated by 3 duplicate ACKs: TCP RENO

• dup ACKs indicate network capable of delivering some segments

• cwnd is cut in half window then grows linearly

 TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

Macroscopic Description of TCP Throughput

What is the average throughput (average rate) of a long-lived TCP connection? (Ignoring the
slow start phase (usually very short as the rate grows exponentially).

When the window size is w the transmission rate is roughly w/RTT. w is increased by 1 MSS
each RTT until a loss event.. Then we have

Average throughput of a connection = (0.75 * W)/RTT

Denote by W the value of w when a loss event occurs

TCP over High-Bandwidth Paths:

Today's high speed links allow having huge windows. What happens if one of the segments in
the window gets lost? What fraction of the transmitted segments could be lost that would allow
the TCP congestion control to achieve the desired rate?

Where L is the loss rate

TCP Fairness
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should
have average rate of R/K

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

40
Why TCP is Fair?
If we have two competing sessions:

 additive increase gives slope of 1, as throughout increases

 multiplicative decrease decreases throughput proportionally

Fairness in UDP
 multimedia apps often do not use TCP

• do not want rate throttled by congestion control

 instead use UDP:

• send audio/video at constant rate, tolerate packet loss

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

41
Fairness, parallel TCP connections
 application can open multiple parallel connections between two hosts

 web browsers do this

 e.g., link of rate R with 9 existing connections:

• new app asks for 1 TCP, gets rate R/10

• new app asks for 11 TCPs, gets R/2

Explicit Congestion Notification (ECN)

Network-assisted congestion control:

 two bits in IP header (ToS field) marked by network router to indicate congestion

 congestion indication carried to receiving host

 receiver (seeing congestion indication in IP datagram) ) sets ECE bit on receiver-

to-sender ACK segment to notify sender of congestion

Dr. Eman Sanad , Assistant Prof. IT Department, Faculty of computers and Artificial intelligence

42