Transport
Layer

Overview

Just as the DataLink layer was responsible for providing reliability for the Physical layer, the Transport layer protocols are responsible for providing reliability for the end-to-end error recovery and flow control. Transport layer protocols also provide mechanisms for segmenting and sequentially organizing multiple Network layer messages into a single coherent message. PDUs at the Transport layer are referred to as segments (TCP) or datagrams (UDP).

Transport Layer Responsibilities

• Keeping track of the individual conversations taking place between applications on the source and destination hosts.
• Segmenting data and adding a header to identify and manage each segment
• Using the header information to reassemble the segments back into application data
• Passing the assembled data to the correct application
• Flow control between end-to-end applications

TCP and UDP Headers

Port Numbers

Port numbers are used in the data communications process to identify the applications being used at each end of the connection. For instance, when a Web browser forms a request that needs to be sent to a Web server, a port number greater than 1023 will be randomly generated and assigned to the Web browser as the source port and the "well known" port number of 80 will be designated as the destination port of the message because, by default, Web servers listen for incoming messages on port 80. This is an important part of the Transport layer's PDU because it uniquely defines which application on the sender is sending the message and which application on the destination device will process the message once it's received. If you think about modern day operating systems and their ability to run many applications simultaneously, it's very important that the operating system be able to sort out which messages need to be delivered to which applications.

Sockets

A connection between two data communications devices can be, and is, referred to logically. A connection's socket can be uniquely identified by combining five elements:

1. the Transport layer protocol being used (TCP or UDP)
2. the source port number being used
3. the IP address of the remote host
4. the destination port being used
5. the connection state.

By typing netstat at a Windows Command prompt you can see the connections your computer has.

Segmentation and Reassembly

Some applications transmit large amounts of data - in some cases, many gigabytes. It would be impractical to send all of this data in one large piece. No other network traffic could be transmitted while this data was being sent. A large piece of data could take minutes or even hours to send. In addition, if there were any error, the entire data file would have to be lost or re-sent. Network devices would not have memory buffers large enough to store this much data while it is transmitted or received. The limit varies depending on the networking technology and specific physical medium being in use.

Dividing application data into pieces both ensures that data is transmitted within the limits of the media and that data from different applications can be multiplexed on to the media.

TCP and UDP Handle Segmentation Differently

In TCP, each segment header contains a sequence number. This sequence number allows the Transport layer functions on the destination host to reassemble segments in the order in which they were transmitted. This ensures that the destination application has the data in the exact form the sender intended.

Although services using UDP also track the conversations between applications, they are not concerned with the order in which the information was transmitted, or in maintaining a connection. There is no sequence number in the UDP header. UDP is a simpler design and generates less overhead than TCP, resulting in a faster transfer of data.

Information may arrive in a different order than it was transmitted because different packets may take different paths through the network. An application that uses UDP must tolerate the fact that data may not arrive in the order in which it was sent.

TCP Segment Reassembly

When services send data using TCP, segments may arrive at their destination out of order. For the original message to be understood by the recipient, the data in these segments is reassembled into the original order. Sequence numbers are assigned in the header of each packet to achieve this goal.

During session setup, an initial sequence number (ISN) is set. This initial sequence number represents the starting value for the bytes for this session that will be transmitted to the receiving application. As data is transmitted during the session, the sequence number is incremented by the number of bytes that have been transmitted. This tracking of data byte enables each segment to be uniquely identified and acknowledged. Missing segments can be identified.

Segment sequence numbers enable reliability by indicating how to reassemble and reorder received segments, as shown in the figure.

The receiving TCP process places the data from a segment into a receiving buffer. Segments are placed in the proper sequence number order and passed to the Application layer when reassembled. Any segments that arrive with noncontiguous sequence numbers are held for later processing. Then, when the segments with the missing bytes arrive, these segments are processed.

Connection Establishment and Termination

When two hosts communicate using TCP, a connection is established before data can be exchanged. After the communication is completed, the sessions are closed and the connection is terminated. The connection and session mechanisms enable TCP's reliability function.

See the figure for the steps to establish and terminate a TCP connection.

The host tracks each data segment within a session and exchanges information about what data is received by each host using the information in the TCP header.

Each connection involves one-way communication streams, or sessions to establish and terminate the TCP process between end devices. To establish the connection, the hosts perform a three-way handshake. Control bits in the TCP header indicate the progress and status of the connection. The three-way handshake:
Establishes that the destination device is present on the network
Verifies that the destination device has an active service and is accepting requests on the destination port number that the initiating client intends to use for the session
Informs the destination device that the source client intends to establish a communication session on that port number

In TCP connections, the host serving as a client initiates the session to the server. To understand how the three-way handshake used in the TCP connection process works, it is important to look at the various values that the two hosts exchange. The three steps in TCP connection establishment, also known as the three-way handshake, are:

1. The initiating client sends a segment containing an initial sequence value, which serves as a request to the server to begin a communications session.

2. The server responds with a segment containing an acknowledgement value equal to the received sequence value plus 1, plus its own synchronizing sequence value. The value is one greater than the sequence number because the ACK is always the next expected Byte or Octet. This acknowledgement value enables the client to tie the response back to the original segment that it sent to the server.

3. Initiating client responds with an acknowledgement value equal to the sequence value it received plus one. This completes the process of establishing the connection.

Within the TCP segment header, there are six 1-bit fields that contain control information used to manage the TCP processes. Those fields are:

• URG - Urgent pointer field significant
• ACK - Acknowledgement field significant
• PSH - Push function
• RST - Reset the connection
• SYN - Synchronize sequence numbers
• FIN - No more data from sender

These fields are referred to as flags, because the value of one of these fields is only 1 bit and, therefore, has only two values: 1 or 0. When a bit value is set to 1, it indicates what control information is contained in the segment.

Using a four-step process, flags are exchanged to terminate a TCP connection.

TCP Acknowledgements

One of TCP's functions is making sure that each segment reaches its destination. The TCP services on the destination host acknowledge the data that it has received to the source application.

The segment header sequence number and acknowledgement number are used together to confirm receipt of the bytes of data contained in the segments. The sequence number is the relative number of bytes that have been transmitted in this session plus 1 (which is the number of the first data byte in the current segment). TCP uses the acknowledgement number in segments sent back to the source to indicate the next byte in this session that the receiver expects to receive. This is called expectational acknowledgement.

The source is informed that the destination has received all bytes in this data stream up to, but not including, the byte indicated by the acknowledgement number. The sending host is expected to send a segment that uses a sequence number that is equal to the acknowledgement number.

Remember, each connection is actually two one-way sessions. Sequence numbers and acknowledgement numbers are being exchanged in both directions.

In the example in the figure, the host on the left is sending data to the host on the right. It sends a segment containing 10 bytes of data for this session and a sequence number equal to 1 in the header.

The receiving host on the right receives the segment at Layer 4 and determines that the sequence number is 1 and that it has 10 bytes of data. The host then sends a segment back to the host on the left to acknowledge the receipt of this data. In this segment, the host sets the acknowledgement number to 11 to indicate that the next byte of data it expects to receive in this session is byte number 11. Note, the Ack. value in the source host stays 1 to indicate that the segment is part of an ongoing conversation and the number in the Acknowledgment Number field is valid.

When the sending host on the left receives this acknowledgement, it can now send the next segment containing data for this session starting with byte number 11.

Looking at this example, if the sending host had to wait for acknowledgement of the receipt of each 10 bytes, the network would have a lot of overhead. To reduce the overhead of these acknowledgements, multiple segments of data can be sent before and acknowledged with a single TCP message in the opposite direction. This acknowledgement contains an acknowledgement number based on the total number of bytes received in the session.

For example, starting with a sequence number of 2000, if 10 segments of 1000 bytes each were received, an acknowledgement number of 12000 would be returned to the source.

The amount of data that a source can transmit before an acknowledgement must be received is called the window size. Window Size is a field in the TCP header that enables the management of lost data and flow control.

Flow Control

TCP also provides mechanisms for flow control. Flow control assists the reliability of TCP transmission by adjusting the effective rate of data flow between the two services in the session. When the source is informed that the specified amount of data in the segments is received, it can continue sending more data for this session.

This Window Size field in the TCP header specifies the amount of data that can be transmitted before an acknowledgement must be received. The initial window size is determined during the session startup via the three-way handshake.

TCP feedback mechanism adjusts the effective rate of data transmission to the maximum flow that the network and destination device can support without loss. TCP attempts to manage the rate of transmission so that all data will be received and re-transmissions will be minimized.

See the figure for a simplified representation of window size and acknowledgements. In this example, the initial window size for a TCP session represented is set to 3000 bytes. When the sender has transmitted 3000 bytes, it waits for an acknowledgement of these bytes before transmitting more segments in this session.

Once the sender has received this acknowledgement from the receiver, the sender can transmit an additional 3000 bytes.

During the delay in receiving the acknowledgement, the sender will not be sending any additional segments for this session. In periods when the network is congested or the resources of the receiving host are strained, the delay may increase. As this delay grows longer, the effective transmission rate of the data for this session decreases. The slowdown in data rate helps reduce the resource contention.

Applications That Use TCP

• Web browsers (HTTP)
• Email (SMTP)
• File transfers (SMB)

Applications That Use UDP

• Domain Name System (DNS)
• Simple Network Management Protocol (SNMP)
• Dynamic Host Configuration Protocol (DHCP)
• Routing Information Protocol (RIP)
• Trivial File Transfer Protocol (TFTP)
• Online games