Transport Layer
Unit IV-Notes
UNIT – IV :Transport Layer: Transport Service, Elements of Transport protocols: Addressing,
Connection Establishment, Connection Release. Connection management. The Internet
Transport Protocols: Introduction to UDP, Remote Procedure calls, Introduction to TCP, The
TCP Service Model, The TCP Protocol, and The TCP Segment Header, The TCP Connection
Establishment, TCP Connection Release,TCP Connection management modeling,TCP Sliding
window,TCP Timer Management,TCP Congestion control.
Transport Layer Service:
The network layer provides end-to-end packet delivery using datagrams or virtual circuits. The transport layer
builds on the network layer to provide data transport from a process on a source machine to a process on a
destination machine with a desired level of reliability
Services Provided to the Upper Layers
Transport Service Primitives
Berkeley Sockets
Services Provided to the Upper Layers:
The ultimate goal of the transport layer is to provide efficient, reliable, and cost-effective data transmission
service to its users, normally processes in the application layer. To achieve this, the transport layer makes
use of the services provided by the network layer. The software and/or hardware within the transport layer
that does the work is called the transport entity
The connection -oriented transport service. Connections have three phases:
establishment, data transfer, and release.
The connectionless transport service
Addressing and flow control
Transport Service Primitives:
There are five types of service primitives:
1. LISTEN : When a server is ready to accept an incoming connection it executes the LISTEN
primitive. It blocks waiting for an incoming connection.
2. CONNECT : It connects the server by establishing a connection. Response is awaited.
3. RECIEVE: Then the RECIEVE call blocks the server.
4. SEND : Then the client executes SEND primitive to transmit its request followed by the
execution of RECIEVE to get the reply. Send the message.
5. DISCONNECT : This primitive is used for terminating the connection. After this primitive
one can’t send any message. When the client sends DISCONNECT packet then the server
also sends the DISCONNECT packet to acknowledge the client. When the server package
is received by client then the process is terminated.
Berkeley Sockets:
Socket Programming:
I) Server side:
Server startup executes SOCKET, BIND & LISTEN primitives.
LISTEN primitive allocate queue for multiple simultaneous clients.
Then it use ACCEPT to suspend server until request.
When client request arrives: ACCEPT returns.
Start new socket (thread or process) with same properties as original, this handles the
request, server goes on waiting on original socket.
If new request arrives while spawning thread for this one, it is queued.
If queue full it is refused.
II) Client side:
It uses SOCKET primitives to create.
Then use CONNECT to initiate connection process.
When this returns the socket is open.
Both sides can now SEND, RECEIVE.
Connection not released until both sides do CLOSE.
Typically client does it, server acknowledges.
Elements of Transport Protocols:
• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery
Addressing:
When an application (e.g., a user) process wishes to set up a connection to a remote application
process, it must specify which one to connect to. The method normally used is to define transport
addresses to which processes can listen for connection requests. In the Internet, these endpoints
are called ports. We will use the generic term TSAP (Transport Service Access Point) to mean a
specific endpoint in the transport layer. The analogous endpoints in the network layer (i.e.,
network layer addresses) are not-surprisingly called NSAPs (Network Service Access Points). IP
addresses are examples of NSAPs.
CONNECTION ESTABLISHMENT:
(a) Normal operation, (b) Old CONNECTION REQUEST appearing out of nowhere.
(c) Duplicate CONNECTION REQUEST and duplicate ACK.
Fig. (a). Host 1 chooses a sequence number, x, and sends a CONNECTION REQUEST segment
containing it to host 2. Host 2 replies with an ACK segment acknowledging x and announcing its
own initial sequence number, y. Finally, host 1 acknowledges host 2’s choice of an initial
sequence number in the first data segment that it sends.
Fig.(b), the first segment is a delayed duplicate CONNECTION REQUEST from an old
connection. This segment arrives at host 2 without host 1’s knowledge. Host 2 reacts to this
segment by sending host 1 an ACK segment, in effect asking for verification that host 1 was
indeed trying to set up a new connection.
The worst case is when both a delayed CONNECTION REQUEST and an ACK are floating
around in the subnet. This case is shown in Fig. (c).
Connection Release Release:
there are two styles of terminating a connection: asymmetric release and symmetric release
Asymmetric release is the way the telephone system works:
when one party hangs up, the connection is broken. Symmetric release treats the connection as
two separate unidirectional connections and requires each one to be released separately
Connection Release:
The two-army problem:
Imagine that a white army is encamped in a valley, On both of the surrounding hillsides are blue armies. The white
army is larger than either of the blue armies alone, but together the blue armies are larger than the white army. If
either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be
victorious. The blue armies want to synchronize their attacks. However, their only communication medium is to
send messengers on foot down into the valley, where they might be captured and the message lost
Four protocol scenarios for releasing a connection.
(a) Normal case of a three-way handshake. (b) final ACK lost.
(c) Response lost. (d) Response lost and subsequent DRs lost.
Flow Control and Buffering
(a)Chainedfixed-size buffers. (b)Chained variable-sized buffers.
(c) One large circular buffer per connection
Multiplexing:
Multiplexing, or sharing several conversations over connections, virtual circuits,
and physical links plays a role in several layers of the network architecture.
In the transport layer, the need for multiplexing can arise in a number of ways.
For example, if only one network address is available on a host, all transport connections
on that machine have to use it. When a segment comes in, some way is needed to tell which process to
give it to. This situation, called multiplexing,
Crash Recovery:
If hosts and routers are subject to crashes or connections are long-lived (e.g.,large software or media
downloads), recovery from these crashes becomes an issue. If the transport entity is entirely within the
hosts, recovery from network and router crashes is straightforward. The transport entities expect lost
segments all the time and know how to cope with them by using retransmissions.
The Internet Transport Protocols:
• Introduction to UDP
• Remote Procedure Call
• The Real-Time Transport
Protocol Introduction to UDP:
The User Datagram Protocol (UDP) is called a connectionless, unreliable transport protocol. It
does not add anything to the services of IP except to provide process-to-process communication
instead of host-to host communication.
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, which is lower than the largest number that will fit in 16 bits because of
the size limit on IP packets. An optional Checksum is also provided for extra reliability. It checksums the
header, the data, and a conceptual IP pseudo header. When performing this computation, the Checksum
field is set to zero and the data field is padded out with an additional zero byte if its length is an odd
number.
Remote Procedure Call:
Step 1 is the client calling the client stub. This call is a local procedure call, with the parameters
pushed onto the stack in the normal way.
Step 2 is the client stub packing the parameters into a message and making a system call to send
the message. Packing the parameters is called marshaling.
Step 3 is the operating system sending the message from the client machine to the server
machine.
Step 4 is the operating system passing the incoming packet to the server stub.
Finally, step 5 is the server stub calling the server procedure with the un marshaled parameters.
The reply traces the same path in the other direction
The TCP Service Model:
TCP (Transmission Control Protocol) was specifically designed to provide a reliable end-to-end byte
stream over an unreliable internetwork. An internetwork differs from a single network because different
parts may have wildly different topologies, bandwidths, delays, packet sizes, and other parameters. TCP
was designed to dynamically adapt to properties of the internetwork and to be robust in the face of many
kinds of failures.
TCP service is obtained by both the sender and the receiver creating endpoints, 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. A port is the TCP name for a TSAP. 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. In other words, two or more connections
may terminate at the same socket. Connections are identified by the socket identifiers at both ends, that is,
(socket1, socket2). No virtual circuit numbers or other identifiers are used.
The TCP Protocol:
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. When the Internet began, the lines between routers were mostly 56-
kbps leased lines, so a host blasting away at full speed took over 1 week to cycle through the sequence
numbers. At modern network speeds, the sequence numbers can be consumed at an alarming rate, as we
will see later. Separate 32-bit sequence numbers are carried on packets for the sliding window position in
one direction and for acknowledgements in the reverse direction,
:
The TCP Segment Header:
Source port address:. This is a 16-bit field that defines the port number of the application program in the
host that is sending the segment.
Destination port address:. This is a 16-bit field that defines the port number of the application program
in the host that is receiving the segment.
Sequence number: This 32-bit field defines the number assigned to the first byte of data contained in this
segment. As we said before, TCP is a stream transport protocol. To ensure connectivity, each byte to be
transmitted is numbered. The sequence number tells the destination which byte in this sequence
comprises the first byte in the segment. During connection establishment, each party uses a random
number generator to create an initial sequence number (ISN), which is usually different in each direction.
Acknowledgment number: This 32-bit field defines the byte number that the receiver of the segment is
expecting to receive from the other party. If the receiver of the segment has successfully received byte
number x from the other party, it defines x + I as the acknowledgment number. Acknowledgment and data
can be piggybacked together.
Header length:. This 4-bit field indicates the number of 4-byte words in the TCP header. The length of
the header can be between 20 and 60 bytes. Therefore, the value of this field can be between 5 (5 x 4 =20)
and 15 (15 x 4 =60).
Reserved:. This is a 6-bit field reserved for future use.
Control:. This field defines 6 different control bits or flags as shown in Figure. One or more of these bits
can be set at a time
Window size: This field defines the size of the window, in bytes, that the other party must maintain. Note
that the length of this field is 16 bits, which means that the maximum size of the window is 65,535 bytes.
This value is normally referred to as the receiving window (rwnd) and is determined by the receiver. The
sender must obey the dictation of the receiver in this case.
Checksum: This 16-bit field contains the checksum. The calculation of the checksum for TCP follows
the same procedure as the one described for UDP. However, the inclusion of the checksum in the UDP
datagram is optional, whereas the inclusion of the checksum for TCP is mandatory. The same pseudo
header, serving the same purpose, is added to the segment. For the TCP pseudo header, the value for the
protocol field is 6.
Urgent pointer: This l6-bit field, which is valid only if the urgent flag is set, is used when the segment
contains urgent data. It defines the number that must be added to the sequence number to obtain the
number of the last urgent byte in the data section of the segment.
Options: There can be up to 40 bytes of optional information in the TCP header. We will not discuss
these options here; please refer to the reference list for more information
.
.TCP Connection Establishment:
1. The client sends the first segment, a SYN segment, in which only the SYN flag is set. A SYN segment
cannot carry data, but it consumes one sequence number.
2. The server sends the second segment, a SYN +ACK segment, with 2 flag bits set: SYN and ACK. This
segment has a dual purpose. It is a SYN segment for communication in the other direction and serves as
the acknowledgment for the SYN segment. It consumes one sequence number. A SYN+ACK segment
cannot carry data, but does consume one sequence number
3. The client sends the third segment. This is just an ACK segment. It acknowledges the receipt of the
second segment with the ACK flag and acknowledgment number field. Note that the sequence number in
this segment is the same as the one in the SYN segment; the ACK segment does not consume any
sequence numbers.
TCP Connection Release :
Connection release can be done in two ways :
o 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.
o 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 connection management modeling:
TCP STATE TRANSITION DIAGRAM
Opening a TCP Connection
1. Server invokes a passive open on TCP, which causes TCP to move to LISTEN state
2. Client does an active open, which causes its TCP to send a SYN segment to the server and move to
SYN_SENT state.
3. When SYN segment arrives at the server, it moves to SYN_RCVD state and responds with a SYN + ACK
segment.
4. Arrival of SYN + ACK segment causes the client to move to ESTABLISHED state and sends an ACK to
the server.
5. When ACK arrives, the server finally moves to ESTABLISHED state.
Closing a TCP Connection
Client / Server can independently close its half of the connection or simultaneously. Transitions from
ESTABLISHED to CLOSED state are:
One side closes: ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED
Other side closes: ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED
Simultaneous close: ESTABLISHED → FIN_WAIT_1 → CLOSING → TIME_WAIT → CLOSED
TCP Sliding window:
As mentioned earlier, window management in TCP decouples the issues of acknowledgement of the
correct receipt of segments and receiver buffer allocation.
For example, suppose the receiver has a 4096-byte buffer, as shown in Fig.
If the sender transmits a 2048-byte segment that is correctly received, the receiver will acknowledge
the segment.
However, since it now has only 2048 bytes of buffer space (until the application removes some data
from the buffer), it will advertise a window of 2048 starting at the next byte expected.
Now the sender transmits another 2048 bytes, which are acknowledged, but the advertised window
is of size 0. The sender must stop until the application process on the receiving host has removed
some data from the buffer
Silly Window Syndrome
When either the sending application program creates data slowly or the receiving application program
consumes data slowly, or both, problems arise.
Any of these situations results in the sending of data in very small segments, which reduces the efficiency
of the operation.
This problem is called the silly window syndrome.
The sending TCP may create a silly window syndrome if it is serving an application program that creates
data slowly, for example, 1 byte at a time.
The application program writes 1 byte at a time into the buffer of the sending TCP.
The result is a lot of 1-byte segments that are traveling through an internet.
The solution is to prevent the sending TCP from sending the data byte by byte.
The sending TCP must be forced to wait and collect data to send in a larger block
Solution to Silly window syndrome
Nagle’s Algorithm
If there is data to send but is less than MSS, then we may want to wait some amount of time
before sending the available data
If we wait too long, then it may delay the process.
If we don’t wait long enough, it may end up sending small segments resulting in Silly
Window Syndrome. The solution is to introduce a timer and to transmit when the timer
expires
Nagle introduced an algorithm for solving this problem.
Tcp Timer Management
TCP timers are mechanisms used by the protocol to manage and control various aspects of the
data transmission process.
Essentially, these timers are implemented by a device's operating system and are used to track
different stages of a TCP connection. They ensure that packets are promptly delivered between
devices and help avoid issues such as packet loss or congestion.
TCP uses 3 kinds of timers:
1. Retransmission timer
2. Persistence timer
3. Keep-Alive timer.
1. Retransmission timer: When a segment is sent, a timer is started. If the segment is acknowledged before
the timer expires, the timer is stopped. If on the other hand, the timer goes off before the
acknowledgement comes in, the segment is retransmitted and the timer is started again. The algorithm
that constantly adjusts the time-out interval, based on continuous measurements of n/w performance
was proposed by JACOBSON
2. Persistence timer: It is designed to prevent the following deadlock:
· The receiver sends an acknowledgement with a window size of ‘0’ telling the sender to wait later, the
receiver updates the window, but the packet with the update is lost now both the sender and receiver are
waiting for each other to do something
· when the persistence timer goes off, the sender transmits a probe to the receiver the response to the
probe gives the window size
· if it is still zero, the persistence timer is set again and the cycle repeats
· if it is non zero, data can now be sent
3. Keep-Alive timer: When a connection has been idle for a long time, this timer may go off to cause one
side to check if other side is still there. If it fails to respond, the connection is terminated.
TCP Congestion Control
Congestion occurs if load (number of packets sent) is greater than capacity of the network (number of
packets a network can handle).
When load is less than network capacity, throughput increases proportionally.
When load exceeds capacity, queues become full and the routers discard some packets and throughput
declines sharply.
When too many packets are contending for the same link o The queue overflows o Packets get dropped o
Network is congested
Network should provide a congestion control mechanism to deal with such a situation.
TCP maintains a variable called CongestionWindow for each connection.
TCP Congestion Control mechanisms are:
1. Additive Increase / Multiplicative Decrease (AIMD)
2. Slow Start
3. Fast Retransmit and Fast Recovery
Additive Increase / Multiplicative Decrease (AIMD)
TCP source initializes CongestionWindow based on congestion level in the network.
Source increases CongestionWindow when level of congestion goes down and decreases the same when
level of congestion goes up.
TCP interprets timeouts as a sign of congestion and reduces the rate of transmission.
On timeout, source reduces its CongestionWindow by half, i.e., multiplicative decrease. For example, if
CongestionWindow = 16 packets, after timeout it is 8.
Value of CongestionWindow is never less than maximum segment size (MSS).
When ACK arrives CongestionWindow is incremented marginally, i.e., additive increase. Increment =
MSS × (MSS/CongestionWindow) CongestionWindow += Increment
For example, when ACK arrives for 1 packet, 2 packets are sent. When ACK for both packets arrive, 3
packets are sent and so on. CongestionWindow increases and decreases throughout lifetime of the
connection
Slow Start
Slow start is used to increase CongestionWindow exponentially from a cold start.
Source TCP initializes CongestionWindow to one packet.
TCP doubles the number of packets sent every RTT on successful transmission.
When ACK arrives for first packet TCP adds 1 packet to CongestionWindow and sends two packets.
When two ACKs arrive, TCP increments CongestionWindow by 2 packets and sends four packets and so
on.
Instead of sending entire permissible packets at once (bursty traffic), packets are sent in a phased manner,
i.e., slow start.
Initially TCP has no idea about congestion, henceforth it increases CongestionWindow rapidly until there
is a timeout. On timeout: CongestionThreshold = CongestionWindow/ 2 CongestionWindow = 1
Slow start is repeated until CongestionWindow reaches CongestionThreshold and thereafter 1 packet per
RTT.
Fast Retransmit And Fast Recovery
TCP timeouts led to long periods of time during which the connection went dead while waiting for a timer
to expire.
Fast retransmit is a heuristic approach that triggers retransmission of a dropped packet sooner than the
regular timeout mechanism. It does not replace regular timeouts.
When a packet arrives out of order, receiving TCP resends the same acknowledgment (duplicate ACK) it
sent last time.
When three duplicate ACK arrives at the sender, it infers that corresponding packet may be lost due to
congestion and retransmits that packet. This is called fast retransmit before regular timeout.
When packet loss is detected using fast retransmit, the slow start phase is replaced by additive increase,
multiplicative decrease method. This is known as fast recovery.
Instead of setting CongestionWindow to one packet, this method uses the ACKs that are still in pipe to
clock the sending of packets.
Slow start is only used at the beginning of a connection and after regular timeout. At other times, it follows
a pure AIMD pattern.