Computer and Information Networking
Chapter 24
Transport Layer
Protocols
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
*
Chapter 3: Outline
24.1 INTRODUCTION
24.2 UDP
24.3 TCP
24.4 SCTP
24.#
Chapter 24: Objective
- The first section introduces the three transport-layer protocols in the Internet and gives some information common to all of them.
- The second section concentrates on UDP, which is the simplest of the three protocols. UDP lacks many services we require from a transport-layer protocol, but its simplicity is very attractive to some applications, as we show.
- The third section discusses TCP. The section first lists its services and features. Using a transition diagram, it then shows how TCP provides a connection-oriented service. The section then uses abstract windows to show how flow and error control are accomplished in TCP. Congestion control in TCP is discussed next, a topic that was discussed for the network layer.
24.#
Chapter 24: Objective (continued)
- The fourth section discusses SCTP. The section first lists its services and features. It then shows how STCP creates an association. The section then shows how flow and error control are accomplished in SCTP using SACKs.
24.#
24.*
24-1 INTRODUCTION
After discussing the general principle behind the transport layer in the previous chapter, we concentrate on the transport protocols in the Internet in this chapter. Figure 24.1 shows the position of these three protocols in the TCP/IP protocol suite.
24.#
24.*
Figure 24.1: Position of transport-layer protocols in the TCP/IP
protocol suite
24.#
24.*
24.24.1 Services
Each protocol provides a different type of service and should be used appropriately.
24.#
24.*
24.24.2 Port Numbers
As discussed in the previous chapter, a transport-layer protocol usually has several responsibilities. One is to create a process-to-process communication; these protocols use port numbers to accomplish this. Port numbers provide end-to-end addresses at the transport layer and allow multiplexing and demultiplexing at this layer, just as IP addresses do at the network layer. Table 24.1 gives some common port numbers for all three protocols we discuss in this chapter.
24.#
Table 24.1: Some well-known ports used with UDP and TCP
24.*
*
24.*
24-2 UDP
The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol. If UDP is so powerless, why would a process want to use it? With the disadvantages come some advantages. UDP is a very simple protocol using a minimum of overhead.
24.#
24.*
24.2.1 User Datagram
UDP packets, called user datagrams, have a fixed-size header of 8 bytes made of four fields, each of 2 bytes (16 bits). Figure 24.2 shows the format of a user datagram. The first two fields define the source and destination port numbers. The third field defines the total length of the user datagram, header plus data. The 16 bits can define a total length of 0 to 65,535 bytes. However, the total length needs to be less because a UDP user datagram is stored in an IP datagram with the total length of 65,535 bytes. The last field can carry the optional checksum (explained later).
24.#
24.*
Figure 24.2: User datagram packet format
24.#
The following is the contents of a UDP header in hexadecimal format.
a. What is the source port number?
b. What is the destination port number?
c. What is the total length of the user datagram?
d. What is the length of the data?
e. Is the packet directed from a client to a server or vice
versa?
f. What is the client process?
24.*
Example 24.1
*
Solution
a. The source port number is the first four hexadecimal
digits (CB84)16 or 52100
b. The destination port number is the second four
hexadecimal digits (000D)16 or 13.
c. The third four hexadecimal digits (001C)16 define the
length of the whole UDP packet as 28 bytes.
d. The length of the data is the length of the whole packet
minus the length of the header, or 28 − 8 = 20 bytes.
e. Since the destination port number is 13 (well-known
port), the packet is from the client to the server.
f. The client process is the Daytime (see Table 3.1).
24.*
Example 24.1 (continued)
*
24.*
24.2.2 UDP Services
Earlier we discussed the general services provided by a transport-layer protocol. In this section, we discuss what portions of those general services are provided by UDP.
24.#
24.*
Figure 24.3: Pseudoheader for checksum calculation
24.#
What value is sent for the checksum in one of the following hypothetical situations?
a. The sender decides not to include the checksum.
b. The sender decides to include the checksum, but the
value of the sum is all 1s.
c. The sender decides to include the checksum, but the
value of the sum is all 0s.
24.*
Example 24.2
*
Solution
a. The value sent for the checksum field is all 0s to show
that the checksum is not calculated.
b. When the sender complements the sum, the result is all
0s; the sender complements the result again before
sending. The value sent for the checksum is all 1s. The
second complement operation is needed to avoid
confusion with the case in part a.
c. This situation never happens because it implies that the
value of every term included in the calculation of the
sum is all 0s, which is impossible; some fields in the
pseudoheader have nonzero values.
24.*
Example 24.2 (continued)
*
24.*
24.2.3 UDP Applications
Although UDP meets almost none of the criteria we mentioned earlier for a reliable transport-layer protocol, UDP is preferable for some applications. The reason is that some services may have some side effects that are either unacceptable or not preferable. An application designer sometimes needs to compromise to get the optimum. For example, in our daily life, we all know that a one-day delivery of a package by a carrier is more expensive than a three-day delivery. Although high speed and low cost are both desirable features in delivery of a parcel, they are in conflict with each other.
24.#
A client-server application such as DNS (see Chapter 26) uses the services of UDP because a client needs to send a short request to a server and to receive a quick response from it. The request and response can each fit in one user datagram. Since only one message is exchanged in each direction, the connectionless feature is not an issue; the client or server does not worry that messages are delivered out of order.
24.*
Example 24. 3
*
A client-server application such as SMTP (see Chapter 26), which is used in electronic mail, cannot use the services of UDP because a user can send a long e-mail message, which may include multimedia (images, audio, or video). If the application uses UDP and the message does not fit in one single user datagram, the message must be split by the application into different user datagrams. Here the connectionless service may create problems. The user datagrams may arrive and be delivered to the receiver application out of order. The receiver application may not be able to reorder the pieces. This means the connectionless service has a disadvantage for an application program that sends long messages.
24.*
Example 24.4
*
Assume we are downloading a very large text file from the Internet. We definitely need to use a transport layer that provides reliable service. We don’t want part of the file to be missing or corrupted when we open the file. The delay created between the deliveries of the parts is not an overriding concern for us; we wait until the whole file is composed before looking at it. In this case, UDP is not a suitable transport layer.
24.*
Example 25.5
*
Assume we are using a real-time interactive application, such as Skype. Audio and video are divided into frames and sent one after another. If the transport layer is supposed to resend a corrupted or lost frame, the synchronizing of the whole transmission may be lost. The viewer suddenly sees a blank screen and needs to wait until the second transmission arrives. This is not tolerable. However, if each small part of the screen is sent using one single user datagram, the receiving UDP can easily ignore the corrupted or lost packet and deliver the rest to the application program. That part of the screen is blank for a very short period of time, which most viewers do not even notice.
24.*
Example 25.6
*
24.*
24-3 TCP
Transmission Control Protocol (TCP) is a connection-oriented, reliable protocol. TCP explicitly defines connection establishment, data transfer, and connection teardown phases to provide a connection-oriented service. TCP uses a combination of GBN and SR protocols to provide reliability.
24.#
24.*
24.3.1 TCP Services
Before discussing TCP in detail, let us explain the services offered by TCP to the processes at the application layer.
24.#
24.*
Figure 24.4: Stream delivery
24.#
24.*
Figure 24.5: Sending and receiving buffers
24.#
24.*
Figure 24.6: TCP segments
24.#
24.*
24.3.2 TCP Features
To provide the services mentioned in the previous section, TCP has several features that are briefly summarized in this section and discussed later in detail.
24.#
Suppose a TCP connection is transferring a file of 5,000 bytes. The first byte is numbered 10,0024. What are the sequence numbers for each segment if data are sent in five segments, each carrying 1,000 bytes?
Solution
The following shows the sequence number for each segment:
24.*
Example 24.7
*
24.*
24.3.3 Segment
Before discussing TCP in more detail, let us discuss the TCP packets themselves. A packet in TCP is called a segment.
24.#
24.*
Figure 24.7: TCP segment format
24.#
24.*
Figure 24.8: Control field
24.#
24.*
Figure 24.9: Pseudoheader added to the TCP datagram
24.#
24.*
24.3.4 A TCP Connection
TCP is connection-oriented. All of the segments belonging to a message are then sent over this logical path. Using a single logical pathway for the entire message facilitates the acknowledgment process as well as retransmission of damaged or lost frames. You may wonder how TCP, which uses the services of IP, a connectionless protocol, can be connection-oriented. The point is that a TCP connection is logical, not physical. TCP operates at a higher level. TCP uses the services of IP to deliver individual segments to the receiver, but it controls the connection itself.
24.#
24.*
Figure 24.10: Connection establishment using three-way handshaking
24.#
24.*
Figure 24.11: Data transfer
24.#
24.*
Figure 24.12: Connection termination using three-way handshaking
24.#
24.*
Figure 24.13: Half-close
Categories of ICMPv6 messages
24.#
24.*
24.3.5 State Transition Diagram
To keep track of all the different events happening during connection establishment, connection termination, and data transfer, TCP is specified as the finite state machine (FSM) as shown in Figure 24.14.
24.#
24.*
Figure 24.14: State transition diagram
24.#
Table 24.2: States for TCP
24.*
*
24.*
Figure 24.15: Transition diagram with half-close connection termination
24.#
24.*
Figure 24.16: Time-line diagram for a common scenario
24.#
24.*
24.3.6 Windows in TCP
Before discussing data transfer in TCP and the issues such as flow, error, and congestion control, we describe the windows used in TCP. TCP uses two windows (send window and receive window) for each direction of data transfer, which means four windows for a bidirectional communication. To make the discussion simple, we make an unrealistic assumption that communication is only unidirectional. The bidirectional communication can be inferred using two unidirectional communications with piggybacking.
24.#
24.*
Figure 24.17: Send window in TCP
24.#
24.*
Figure 24.18: Receive window in TCP
24.#
24.*
24.3.7 Flow Control
As discussed before, flow control balances the rate a producer creates data with the rate a consumer can use the data. TCP separates flow control from error control. In this section we discuss flow control, ignoring error control. We assume that the logical channel between the sending and receiving TCP is error-free.
24.#
24.*
Figure 24.19: Data flow and flow control feedbacks in TCP
24.#
24.*
Figure 24.20: An example of flow control
24.#
Figure 3.58 shows the reason for this mandate.
Part a of the figure shows the values of the last acknowledgment and rwnd. Part b shows the situation in which the sender has sent bytes 206 to 214. Bytes 206 to 209 are acknowledged and purged. The new advertisement, however, defines the new value of rwnd as 4, in which
210 + 4 < 206 + 12. When the send window shrinks, it creates a problem: byte 214, which has already been sent, is outside the window. The relation discussed before forces the receiver to maintain the right-hand wall of the window to be as shown in part a, because the receiver does not know which of the bytes 210 to 217 has already been sent. described above.
24.*
Example 3.18
*
24.*
Figure 24.21: Example 3.18
24.#
24.*
24.3.8 Error Control
TCP is a reliable transport-layer protocol. This means that an application program that delivers a stream of data to TCP relies on TCP to deliver the entire stream to the application program on the other end in order, without error, and without any part lost or duplicated.
24.#
24.*
Figure 24.22: Simplified FSM for the TCP sender side
24.#
24.*
Figure 24.23: Simplified FSM for the TCP receiver side
24.#
24.*
Figure 24.24: Normal operation
24.#
24.*
Figure 24.25: Lost segment
24.#
24.*
Figure 24.26: Fast retransmission
24.#
24.*
Figure 24.27: Lost acknowledgment
24.#
24.*
Figure 24.28: Lost acknowledgment corrected by resending a segment
24.#
24.*
24.3.9 TCP Congestion Control
TCP uses different policies to handle the congestion in the network. We describe these policies in this section.
24.#
24.*
Figure 24.29: Slow start, exponential increase
24.#
24.*
Figure 24.30: Congestion avoidance, additive increase
24.#
24.*
Figure 24.31: FSM for Taho TCP
24.#
Figure 24.32 shows an example of congestion control in a Taho TCP. TCP starts data transfer and sets the ssthresh variable to an ambitious value of 16 MSS. TCP begins at the slow-start (SS) state with the cwnd = 24. The congestion window grows exponentially, but a time-out occurs after the third RTT (before reaching the threshold). TCP assumes that there is congestion in the network. It immediately sets the new ssthresh = 4 MSS (half of the current cwnd, which is 8) and begins a new slow start (SA) state with cwnd = 1 MSS. The congestion grows exponentially until it reaches the newly set threshold. TCP now moves to the congestion avoidance (CA) state and the congestion window grows additively until it reaches cwnd = 12 MSS.
24.*
Example 24.9
*
At this moment, three duplicate ACKs arrive, another indication of the congestion in the network. TCP again halves the value of ssthresh to 6 MSS and begins a new slow-start (SS) state. The exponential growth of the cwnd continues. After RTT 15, the size of cwnd is 4 MSS. After sending four segments and receiving only two ACKs, the size of the window reaches the ssthresh (6) and the TCP moves to the congestion avoidance state. The data transfer now continues in the congestion avoidance (CA) state until the connection is terminated after RTT 20.
24.*
Example 24.9 (continued)
*
24.*
Figure 24.32: Example of Taho TCP
24.#
24.*
Figure 24.33: FSM for Reno TCP
24.#
Figure 24.34 shows the same situation as Figure 3.69, but in Reno TCP. The changes in the congestion window are the same until RTT 13 when three duplicate ACKs arrive. At this moment, Reno TCP drops the ssthresh to 6 MSS, but it sets the cwnd to a much higher value (ssthresh + 3 = 9 MSS) instead of 1 MSS. It now moves to the fast recovery state. We assume that two more duplicate ACKs arrive until RTT 15, where cwnd grows exponentially. In this moment, a new ACK (not duplicate) arrives that announces the receipt of the lost segment. It now moves to the congestion avoidance state, but first deflates the congestion window to 6 MSS as though ignoring the whole fast-recovery state and moving back to the previous track.
24.*
Example 24.10
*
24.*
Figure 24.34: Example of a Reno TCP
24.#
24.*
Figure 24.35: Additive increase, multiplicative decrease (AIMD)
24.#
If MSS = 10 KB (kilobytes) and RTT = 100 ms in Figure 3.72, we can calculate the throughput as shown below.
24.*
Example 24.11
*
Let us give a hypothetical example. Figure 3.73 shows part of a connection. The figure shows the connection establishment and part of the data transfer phases.
24. When the SYN segment is sent, there is no value for
RTTM, RTTS, or RTTD. The value of RTO is set to
6.00 seconds. The following shows the value of these
variables at this moment:
24.*
Example 24.12
*
2. When the SYN+ACK segment arrives, RTTM is
measured and is equal to 24.5 seconds. The following
shows the values of these variables:
24.*
Example 24.12 (continued)
*
3. When the first data segment is sent, a new RTT measurement starts. Note that the sender does not start an RTT measurement when it sends the ACK segment, because it does not consume a sequence number and there is no time-out. No RTT measurement starts for the second data segment because a measurement is already in progress.
24.*
Example 24.12 (continued)
*
24.*
24.3.10 TCP Timers
To perform their operations smoothly, most TCP implementations use at least four timers:
retransmission, persistence, keepalive, and TIME-WAIT.
24.#
24.*
Figure 24.36: Example 3.22
24.#
Figure 24.37 is a continuation of the previous example. There is retransmission and Karn’s algorithm is applied. The first segment in the figure is sent, but lost. The RTO timer expires after 4.74 seconds. The segment is retransmitted and the timer is set to 9.48, twice the previous value of RTO. This time an ACK is received before the time-out. We wait until we send a new segment and receive the ACK for it before recalculating the RTO (Karn’s algorithm).
24.*
Example 24.13
*
24.*
Figure 24.37: Example 3.23
24.#
24.*
24.3.11 Options
The TCP header can have up to 40 bytes of optional information. Options convey additional information to the destination or align other options. These options are included on the book website for further reference.
24.#
24.*
24-4 SCTP
Stream Control Transmission Protocol (SCTP) is a new transport-layer protocol designed to combine some features of UDP and TCP in an effort to create a protocol for multimedia communication.
24.#
24.*
24.4.1 SCTP Services
Before discussing the operation of SCTP, let us explain the services offered by SCTP to the application-layer processes.
24.#
24.*
Figure 24.38 : Multiple-stream concept
24.#
24.*
Figure 24.39 : Multihoming concept
24.#
24.*
24.4.2 SCTP Features
The following shows the general features of SCTP.
Transmission Sequence Number (TSN)
Stream Identifier (SI)
Stream Sequence Number (SSN)
24.#
24.*
Figure 24.40 : Comparison between a TCP segment and an SCTP
packet
24.#
24.*
Figure 24.41 : Packets, data chunks, and streams
24.#
24.*
24.4.3 Packet Format
An SCTP packet has a mandatory general header and a set of blocks called chunks. There are two types of chunks: control chunks and data chunks. A control chunk controls and maintains the association; a data chunk carries user data. In a packet, the control chunks come before the data chunks. Figure 24.42 shows the general format of an SCTP packet.
24.#
24.*
Figure 24.43 : SCTP packet format
24.#
24.*
Figure 8.50 : General header
24.#
24.*
Figure 24.44 : Common layout of a chunk
24.#
Table 24.3: Chunks
24.*
*
24.*
24.4.4 An SCTP Association
SCTP, like TCP, is a connection-oriented protocol. However, a connection in SCTP is called an association to emphasize multihoming.
24.#
24.*
Figure 24.45: Four-way handshaking
24.#
24.*
Figure 24.46 : Association termination
24.#
24.*
24.4.5 Flow Control
Flow control in SCTP is similar to that in TCP. In SCTP, we need to handle two units of data, the byte and the chunk. The values of rwnd and cwnd are expressed in bytes; the values of TSN and acknowledgments are expressed in chunks. To show the concept, we make some unrealistic assumptions. We assume that there is never congestion in the network and that the network is error free.
24.#
24.*
Figure 24.47: Flow control, receiver site
24.#
24.*
Figure 24.48: Flow control, sender site
24.#
24.*
24.4.6 Error Control
SCTP, like TCP, is a reliable transport-layer protocol. It uses a SACK chunk to report the state of the receiver buffer to the sender. Each implementation uses a different set of entities and timers for the receiver and sender sites. We use a very simple design to convey the concept to the reader.
24.#
24.*
Figure 24.49 : Error control, receiver site
24.#
24.*
Figure 24.50 : Error control, sender site
24.#
24.*
Figure 24.51: New state at the sender site after receiving a SACK chunk
24.#
Sending �processReceiving�processStream of bytes
Stream of bytes
Sending �process
Receiving�process