The Internet Transport Protocols

• The Internet has two main protocols in the transport layer, a

connectionless protocol and a connection-oriented one
• The connectionless protocol is UDP
• It does almost nothing beyond sending packets between
applications, letting applications build their own protocols on top
as needed.
• The connection-oriented protocol is TCP
• It does almost everything. It makes connections and adds
reliability with retransmissions, along with flow control and
congestion control, all on behalf of the applications that use it
 UDP Header
• UDP transmits segments consisting of an 8-byte header followed by the payload.
• The two ports serve to identify the endpoints within the source and destination
machines
• When a UDP packet arrives, its payload is handed to the process attached to the
destination port.

• The source port is primarily needed when a reply must be sent back to the source.
By copying the Source port field from the incoming segment into the Destination
port field of the outgoing segment, the process sending the reply can specify which
process on the sending machine is to get it
• The UDP length field includes the 8-byte header and the data. The minimum length
is 8 bytes, to cover the header. The maximum length is 65,515 bytes
• An optional Checksum is also provided for extra reliability
 TCP
• TCP (Transmission Control Protocol) was specifically designed to provide a
reliable end-to-end byte stream over an unreliable internetwork
• Each machine supporting TCP has a TCP transport entity
• A TCP entity accepts user data streams from local processes, breaks them up
into pieces not exceeding 64 KB and sends each piece as a separate IP
datagram
• When datagrams containing TCP data arrive at a machine, they are given to
the TCP entity, which reconstructs the original byte streams.
• The IP layer gives no guarantee that datagrams will be delivered properly, nor
any indication of how fast datagrams may be sent.
• It is up to TCP to send datagrams fast enough to make use of the capacity but
not cause congestion, and to time out and retransmit any datagrams that are
not delivered
• Datagrams that do arrive may well do so in the wrong order; it is also up to
TCP to reassemble them into messages in the proper sequence.
• In short, TCP must furnish good performance with the reliability that most
applications want and that IP does not provide
• TCP service is obtained by both the sender and the receiver creating end points, called
sockets
• Each socket has a socket number (address) consisting of the IP address of the host and
a 16-bit number local to that host, called a port.
• For TCP service to be obtained, a connection must be explicitly established between a
socket on one machine and a socket on another machine.
• A socket may be used for multiple connections at the same time.
• Port numbers below 1024 are reserved for standard services that can usually only be
started by privileged users. They are called well-known ports.

A list of well known ports

• Other ports from 1024 through 49151 can be registered with IANA for use by
unprivileged users, but applications can and do choose their own ports.
• All TCP connections are full duplex and point-to-point
• Full duplex means that traffic can go in both directions at the same time.
• Point-to-point means that each connection has exactly two end points.
• TCP does not support multicasting or broadcasting
• A TCP connection is a byte stream, not a message stream.

For example, if the sending process does four 512-byte writes to a TCP stream, these data
may be delivered to the receiving process as four 512-byte chunks, two 1024-byte chunks,
one 2048-byte chunk

• When an application passes data to TCP, TCP may send it immediately or buffer it (in
order to collect a larger amount to send at once), at its discretion.
• A key feature of TCP, and one that dominates the protocol design, is that every byte on a
TCP connection has its own 32-bit sequence number
• The sending and receiving TCP entities exchange data in the form of segments.
• A TCP segment consists of a fixed 20-byte header (plus an optional part) followed by
zero or more data bytes.
• The TCP software decides how big segments should be.
TCP Header
• The Source port and Destination port fields identify the local end points of the
connection. A TCP port plus its host’s IP address forms a 48-bit unique end point. The
source and destination end points together identify the connection. This connection
identifier is called a 5 tuple because it consists of five pieces of information: the
protocol (TCP), source IP and source port, and destination IP and destination port.
• The Sequence number and Acknowledgement number fields perform their usual
functions.
• The TCP header length tells how many 32-bit words are contained in the TCP header.
This information is needed because the Options field is of variable length, so the
header is, too
• CWR and ECE are used to signal congestion when ECN (Explicit Congestion Notification)
is used. ECE is set to signal an ECN-Echo to a TCP sender to tell it to slow down when
the TCP receiver gets a congestion indication from the network. CWR is set to signal
Congestion Window Reduced from the TCP sender to the TCP receiver so that it knows
the sender has slowed down and can stop sending the ECN-Echo.
• URG is set to 1 if the Urgent pointer is in use.
• The Urgent pointer is used to indicate a byte offset from the current sequence number
at which urgent data are to be found.
• The ACK bit is set to 1 to indicate that the Acknowledgement number is valid. This is the
case for nearly all packets. If ACK is 0, the segment does not contain an
acknowledgement, so the Acknowledgement number field is ignored.
• The PSH bit indicates PUSHed data. The receiver is hereby kindly requested to deliver the
data to the application upon arrival and not buffer it until a full buffer has been received
• The RST bit is used to abruptly reset a connection that has become confused due to a
host crash or some other reason.
• The SYN bit is used to establish connections.
The connection request has SYN = 1 and ACK = 0 to indicate that the piggyback
acknowledgement field is not in use. The connection reply does bear an acknowledgement,
however, so it has SYN = 1 and ACK = 1.
In essence, the SYN bit is used to denote both CONNECTION REQUEST and CONNECTION
ACCEPTED
• The FIN bit is used to release a connection. It specifies that the sender has no more data
to transmit
• The Window size field tells how many bytes may be sent starting at the byte
acknowledged. A Window size field of 0 is legal.
• A Checksum is also provided for extra reliability.
• The Options field provides a way to add extra facilities not covered by the regular header
A widely used option is the one that allows each host to specify the MSS (Maximum
Segment Size) it is willing to accept.
The window scale option allows the sender and receiver to negotiate a window scale factor
at the start of a connection
 TCP Connection Establishment
• Connections are established in TCP by means of the three-way handshake
• To establish a connection, one side, say, the server, passively waits for an
incoming connection by executing the LISTEN and ACCEPT primitives in that
order, either specifying a specific source or nobody in particular
• The other side, say, the client, executes a CONNECT primitive, specifying the IP
address and port to which it wants to connect, the maximum TCP segment size
it is willing to accept, and optionally some user data
• The CONNECT primitive sends a TCP segment with the SYN bit on and ACK bit
off and waits for a response.
• When this segment arrives at the destination, the TCP entity there checks to
see if there is a process that has done a LISTEN on the port given in the
Destination port field.
• If not, it sends a reply with the RST bit on to reject the connection.
• If some process is listening to the port, that process is given the incoming TCP
segment
• It can either accept or reject the connection. If it accepts, an acknowledgement
segment is sent back
 TCP Connection Release

• To release a connection, either party can send a TCP segment with

the FIN bit set, which means that it has no more data to transmit.
• When the FIN is acknowledged, that direction is shut down for
new data.
• Data may continue to flow indefinitely in the other direction,
however
• When both directions have been shut down, the connection is
released.
• Normally, four TCP segments are needed to release a connection:
one FIN and one ACK for each direction.
• However, it is possible for the first ACK and the second FIN to be
contained in the same segment, reducing the total count to three
 TCP Retransmission Policy
After establishing the connection,

• Sender starts transmitting TCP segments to the receiver.

• A TCP segment sent by the sender may get lost on the way before reaching the
receiver.
• This causes the receiver to send the acknowledgement with same ACK number to the
sender.
• As a result, sender retransmits the same segment to the receiver.
• This is called as TCP retransmission.

When TCP Retransmission Occurs?

Sender discovers that the TCP segment is lost when-

1. Either Time Out Timer expires

2. Or it receives three duplicate acknowledgements
1. Retransmission After Time Out Timer Expiry-

Each time sender transmits a TCP segment to the receiver, it starts a Time Out Timer.

Now, following two cases are possible-

Case-01:

Sender receives an acknowledgement for the sent segment before the timer goes off.
In this case, sender stops the timer.

Case-02:

Sender does not receives any acknowledgement for the sent segment and the timer goes
off.
In this case, sender assumes that the sent segment is lost.
Sender retransmits the same segment to the receiver and resets the timer.
Retransmission After Receiving 3 Duplicate Acknowledgements-

• Consider sender receives three duplicate acknowledgements for a TCP segment

sent by it.
• Then, sender assumes that the corresponding segment is lost.
• So, sender retransmits the same segment without waiting for its time out timer to
expire.
• This is known as Early retransmission or Fast retransmission.
Note:

After receiving the retransmitted segment-2,

• Receiver does not send the acknowledgement asking for segment-3 or 4 or 5.

• Receiver sends the acknowledgement asking for segment-6 directly from the sender.
• This is because previous segments have been already received and
acknowledgements for them have been already sent (although wasted in asking for
segment-2).

Note:
• Consider time out timer expires before receiving the acknowledgement for a TCP
segment.
• This case suggests the stronger possibility of congestion in the network
• Consider sender receives 3 duplicate acknowledgements for the same TCP segment.
• This case suggests the weaker possibility of congestion in the network
 TCP Congestion Control

Congestion in Network:
The message traffic becomes so heavy that it slows down the network response time.

Congestion is an important issue that can arise in Packet Switched Network.

Congestion leads to the loss of packets in transit.
So, it is necessary to control the congestion in network.
It is not possible to completely avoid the congestion.

Congestion Control-
Congestion control refers to techniques and mechanisms that can-
Either prevent congestion before it happens
Or remove congestion after it has happened

TCP Congestion Control-

TCP reacts to congestion by reducing the sender window size.
The size of the sender window is determined by the following two factors-
• Receiver window size
• Congestion window size
1. Receiver Window Size-

• Sender should not send data greater than receiver window size.
• Otherwise, it leads to dropping the TCP segments which causes TCP Retransmission.
• So, sender should always send data less than or equal to receiver window size.
• Receiver dictates its window size to the sender through TCP Header.

2. Congestion Window-

• Sender should not send data greater than congestion window size.
• Otherwise, it leads to dropping the TCP segments which causes TCP Retransmission.
• So, sender should always send data less than or equal to congestion window size.
• Different variants of TCP use different approaches to calculate the size of congestion
window.
• Congestion window is known only to the sender and is not sent over the links.
So, always-
Sender window size = Minimum (Receiver window size, Congestion window size)
TCP Congestion Policy-

TCP’s general policy for handling congestion consists of following three phases-

1. Slow Start Phase-

Initially, sender sets congestion window size = Maximum Segment Size (1 MSS).
After receiving each acknowledgment, sender increases the congestion window size
by 1 MSS.
In this phase, the size of congestion window increases exponentially.
The followed formula is-
Congestion window size = Congestion window size + Maximum segment size
This phase continues until the congestion window size reaches the slow start threshold

= Maximum number of TCP segments that receiver window can accommodate / 2

= (Receiver window size / Maximum Segment Size) / 2

2. Congestion Avoidance Phase-

After reaching the threshold,

Sender increases the congestion window size linearly to avoid the congestion.
On receiving each acknowledgement, sender increments the congestion window size by 1.

The followed formula is-

Congestion window size = Congestion window size + 1

This phase continues until the congestion window size becomes equal to the receiver
window size.

3. Congestion Detection Phase-

Case-01: Detection On Time Out-

• Time Out Timer expires before receiving the acknowledgement for a segment.
• This case suggests the stronger possibility of congestion in the network.
• There are chances that a segment has been dropped in the network.
Reaction-

In this case, sender reacts by-

• Setting the slow start threshold to half of the current congestion window size.
• Decreasing the congestion window size to 1 MSS.
• Resuming the slow start phase

Case-02: Detection On Receiving 3 Duplicate Acknowledgements-

• Sender receives 3 duplicate acknowledgements for a segment.

• This case suggests the weaker possibility of congestion in the network.
• There are chances that a segment has been dropped but few segments sent later may
have reached.
Reaction-

In this case, sender reacts by-

• Setting the slow start threshold to half of the current congestion window size.
• Decreasing the congestion window size to slow start threshold.
• Resuming the congestion avoidance phase.
3. Congestion Detection Phase-

Case-01: Detection On Time Out-

• Time Out Timer expires before receiving the acknowledgement for a segment.
• This case suggests the stronger possibility of congestion in the network.
• There are chances that a segment has been dropped in the network
Reaction-
In this case, sender reacts by-
• Setting the slow start threshold to half of the current congestion window size.
• Decreasing the congestion window size to 1 MSS.
• Resuming the slow start phase.

Case-02: Detection On Receiving 3 Duplicate Acknowledgements-

Sender receives 3 duplicate acknowledgements for a segment.

This case suggests the weaker possibility of congestion in the network.
There are chances that a segment has been dropped but few segments sent later may
have reached
Reaction-
In this case, sender reacts by-
• Setting the slow start threshold to half of the current congestion window size.
• Decreasing the congestion window size to slow start threshold.
• Resuming the congestion avoidance phase.