3.1 .
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Chapter 3
Part 2: Transport Layer
3
3 USER DATAGRAM PROTOCOL (UDP)
–
3.2
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol.
• It does not add anything to the services of IP except for providing process-to-process instead of host-to-host communication.
• UDP is a very simple protocol using a minimum of overhead.
Figure 3.39: User datagram packet format
• UDP packets, called user datagrams, has a fixed size header of 8 bytes made of four fields, each of 2 bytes (16 bits).
• Figure 3.39 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.
3.3
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.11
The following is the contents of a UDP header in hexadecimal format.
a. What is the source port number?
The source port number is the first four hexadecimal digits (CB84)16 or (52100)10
b. What is the destination port number?
The destination port number is the second four hexadecimal digits (000D)16 or (13)10.
c. What is the total length of the user datagram?
The third four hexadecimal digits (001C)16 define the length of the whole UDP packet is 28 bytes.
d. What is the length of the data?
The length of the data is the length of the whole packet minus the length of the header, or
e. Is the packet directed from a client to a server or vice-versa?
Since the destination port number is 13 (well-known port), the packet is from the client to
28 − 8 = 20 bytes.
the server. A server listens for UDP datagrams on UDP port 13.
f. Whatistheclientprocess?
3.4
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
CB84000D001C001C
The client process is the Daytime request. When a datagram is received, from server
containing the current date and time (see Table 3.1).
3.3.2 UDPServices
3.5
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Process-to-Process Communication Connectionless Services
No flow Control
No error Control
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.
3.3.2 (continued)
3.6
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Checksum
Optional Inclusion of Checksum
Congestion Control
Encapsulation and Decapsulation
Queuing
Multiplexing and Demultiplexing Comparison : UDP and Simple Protocol
Figure 3.40: UDP Pseudoheader for checksum calculation
• Initial checksum= 0000000000000000
• Then [ Pseudoheader + header + data ] calculate
the checksum
• Then discard the Pseudoheader
0000000000…00
3.7
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.46: Pseudoheader added to the TCP datagram
3.8
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.12
3.9
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
What value is sent for the checksum in one of the following hypothetical situations?
a. The sender decides not to include the checksum.
The value sent for the checksum field is all 0s to show that the checksum is not calculated.
b. The sender decides to include the checksum, but the value of the checksum is all 1s.
When the sender computes the checksum, the result is all 0s; in such situations the sender complements the result again before sending it. The value sent for the checksum is now all 1s. The second complement operation is needed to avoid confusion with the case in part a.
3.3.3 UDPApplications
3.10
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• Although UDP does not meet any 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 results.
• In this section, we first discuss some features of UDP that may need to be considered when one designs an application program and then show some typical applications.
3.3.3 (continued)
3.11
UDP Features
Connectionless Service
Lack of Error Control
Lack of Congestion Control
Typical Applications
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.13 DNS services UDP Application
• A client-server application such as DNS (see Chapter 2) 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.
3.12
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.14
• A client-server application such as SMTP (see Chapter 2), 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.
3.13
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.15
• Assume we are downloading a very large text file from the Internet. (FTP)
• 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.
3.14
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
FTP
• File Transfer Protocol (FTP) is the standard protocol provided by TCP/IP for copying a file from one host to another.
• Although transferring files from one system to another seems simple and straightforward, some problems must be dealt with first.
• For example, two systems may use different file name conventions. Two systems may have different ways to represent data.
• All of these problems have been solved by FTP in a very simple and elegant approach. (Connection Control)
2.15
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure: FTP
Lifetimes of Two Connections
ControlConnectionusesTCPport#21
DataConnectionusesTCPport#20
Control connection
Data connection
Communication over Data Connection File Transfer
2.16
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Example 3.16
• 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.
3.17
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3
–
4 TRANSMISSION CONTROL PROTOCOL
3.18
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• 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 flow & error control protocols to provide reliability.
3.4.1 TCP Services
3.19
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Process-to-Process Communication Stream Delivery Service
Sending and Receiving Buffers Segments
Full-Duplex Communication
Multiplexing and Demultiplexing Connection-Oriented Service
Reliable Service
A Before discussing TCP in detail, let us explain the services offered by TCP to the processes at the application layer.
Figure 3.41: Stream delivery
Sending Receiving
process
process
Stream of bytes
3.20
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.43: TCP segments
3.21
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.2 TCPFeatures
Numbering System
Byte Number
Sequence Number
Acknowledgment Number
3.4.3 TCPSegment
Format
Encapsulation
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.
Before discussing TCP in more detail, let us discuss the TCP packets themselves. A packet in TCP is called a segment.
3.22
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.44: TCP segment format
Figure 3.45: Control field
3.23
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.4 A TCP Connection
• TCP is connection-oriented.
• Connection-oriented transport protocol establishes
a logical path between the source and destination.
• 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 segments.
3.24
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.4 (continued)
Connection Establishment
Three-Way TCP Handshaking
SYN Flooding Attack
Data Transfer
Pushing Data Urgent Data
Connection Termination Three-Way Handshaking
Half-Close
Connection Reset
3.25
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.47: Connection establishment using three-way handshaking
3.26
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.48: Data transfer
3.27
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.49: Connection termination using three-way handshaking
3.28
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.29
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.50: Half-close
Figure 3.53: Time-line diagram for a common scenario
3.30
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.6 Windows in TCP
3.31
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Send Window Receive Window
• 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 unidirectional; the bidirectional communication can be inferred using two unidirectional communications with piggybacking.
Figure 3.54: Send window in TCP
3.32
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.55: Receive window in TCP
3.33
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.7 Flow Control
• flow control balances the rate a producer creates data with the rate a consumer consuming the data.
• TCP separates flow control from error control.
• In this part we discuss flow control, ignoring error
control.
• We assume that the logical channel between the sending and receiving TCP is error-free.
3.34
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.7 (continued)
3.35
Syndrome Created by the Receiver
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Opening and Closing Windows A Scenario
Shrinking of Windows Window Shutdown
Silly Window Syndrome
Syndrome Created by the Sender
Figure 3.56: Data flow and flow control feedbacks in TCP
3.36
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.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.
3.37
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.8 (continued)
Checksum
Acknowledgment
Cumulative Acknowledgment (ACK) Selective Acknowledgment (SACK)
Generating Acknowledgments Retransmission
Retransmission after RTO
Retransmission after Three Duplicate ACK
Out-of-Order Segments
3.38
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.8 (continued)
Scenarios
Normal Operation
Lost Segment
Fast Retransmission
Delayed Segment
Duplicate Segment
Automatically Corrected Lost ACK
Correction by Resending a Segment
Deadlock Created by Lost Acknowledgment
3.39
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.61: Normal operation
Rule-1: It must include (piggyback) an acknowledgment that
gives the next sequence number it expects to receive
3.40
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.61: Normal operation
Rule-2: When the receiver has no data to send and it receives an in-order segment, the receiver delays sending an ACK segment until another segment ACK segments do not consume sequence numbers and are not acknowledged, arrives or until a period of time (normally 500 ms) has passed. This rule reduces ACK segments.
3.41
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.61: Normal operation
Rule-3: When a segment arrives with a sequence number that is expected by the receiver, and the previous in-order segment has not been acknowledged, the receiver immediately sends an ACK segment. In other words, there should not be more than two in-order unacknowledged segments at any time. This prevents the unnecessary retransmission of segments that may create congestion in the network.
3.42
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.62: Lost segment
Rule-3: When a segment arrives with a sequence number that is expected by the receiver, and the previous in-order segment has not been acknowledged, the receiver immediately sends an ACK segment. In other words, there should not be more than two in-order unacknowledged segments at any time. This prevents the unnecessary retransmission of segments that may create congestion in the network.
3.43
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.62: Lost segment
RULE-4:When a segment arrives with an out-of-order sequence number that is higher than expected, the receiver immediately sends an ACK segment announcing the sequence number of the next expected segment. This leads to the fast retransmission of missing segments.
3.44
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.62: Lost segment
RULE-5: When a missing segment arrives, the receiver sends an ACK segment to announce the next sequence number expected. This informs the receiver that segments reported missing have been received.
3.45
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.63: Fast retransmission
A fast retransmit algorithm is used when three duplicate ACKs are detected as packet loss.
3.46
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.64: Lost acknowledgment
TCP uses cumulative acknowledgment. We can say that the next acknowledgment
automatically corrects the loss of the previous acknowledgment.
3.47
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.65: Lost acknowledgment corrected by resending a segment
Figure shows a scenario in which an acknowledgment is lost. If the next acknowledgment is delayed for a long time or there is no next acknowledgment (the lost acknowledgment is the last one sent), the correction is triggered by the RTO timer. A duplicate segment is the result.
3.48
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
3.4.9 TCP Congestion Control
3.49
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
•
TCP uses different policies to handle the congestion in the network.
Congestion Window Congestion Detection Congestion Policies
Slow Start: Exponential Increase Congestion Avoidance: Additive Increase
Policy Transition
Taho TCP Reno TCP NewReno TCP
Additive Increase, Multiplicative Decrease TCP Throughput
Figure 3.66: Slow start, exponential increase
3.50
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.67: Congestion avoidance, additive increase
3.51
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.69: Example of TCP Taho
1. A fast retransmit algorithm is used when duplicate ACKs are detected as packet loss.
2. TCP Tahoe is the simplest one out of all variants. It doesn’t have fast recovery. At congestion avoidance phase, it treats the triple(3) duplicate ACKs same as timeout. When timeout or triple duplicate ACKs is received, it will perform fast retransmit, reduce congestion window to 1, and enters slow-start phase.
3.52
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.71: Example of a TCP Reno
3.53
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Figure 3.72: Additive increase, multiplicative decrease (AIMD)
3.54
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The additive-increase/multiplicative-decrease (AIMD) algorithm is a feedback control algorithm best known for its use in TCP congestion control.
• AIMD combines linear growth of the congestion window with an exponential reduction when a congestion takes place.
Chapter 3: Summary
3.55
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
The main duty of a transport-layer protocol is to provide process-to-process communication. To define the processes, we need port numbers.
The client program defines itself with an ephemeral port number. The server defines itself with a well-known port number.
To send a message from one process to another, the transport-layer protocol encapsulates and decapsulates messages.
Flow control balances the exchange of data items between a producer and a consumer.
A transport-layer protocol can provide two types of services: connectionless and connection-oriented. In a connectionless service, the sender sends packets to the receiver without any connection establishment. In a connection-oriented service, the client and the server first need to establish a connection between themselves.
Chapter 3: Summary (continued)
3.56
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
We have discussed several common transport-layer protocols in this chapter. The Stop-and-Wait protocol provides both flow and error control, but is inefficient. The Go-Back-N protocol is the more efficient version of the Stop-and-Wait protocol and takes advantage of pipelining. The Selective-Repeat protocol, a modification of the Go-Back-N protocol, is better suited to handle packet loss. All of these protocols can be implemented bidirectionally using piggybacking.
UDP is a transport protocol that creates a process-to-process communication. UDP is a (mostly) unreliable and connectionless protocol that requires little overhead and offers fast delivery. The UDP packet is called a user datagram.
Chapter 3: Summary (continued)
3.57
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Transmission Control Protocol (TCP) is another transport- layer protocol in the TCP/IP protocol suite. TCP provides process-to-process, full-duplex, and connection-oriented service. The unit of data transfer between two devices using TCP software is called a segment. A TCP connection consists of three phases: connection establishment, data transfer, and connection termination.