CHAPTER 3: TRANSPORT LAYER
• Transport Layer Services• Establishing/Releasing Connections• Multiplexing/Demultiplexing• User Datagram Protocol (UDP)• Reliable Data Transfer• Flow Control• Error Control• Transmission Control Protocol (TCP)• Congestion Control
TRANSPORT LAYER SERVICES
Page 2Chapter 3CS 447
Hardware
Network Interface
Internet
Transport
Application
OUTPUT PROCESS: FROM APPLICATION TO HARDWARE
Page 3Chapter 3CS 447
Hardware
Operating System
Operating System
Application ProgramsAn application calls system routines to have UDP allocate an IP datagram, fill in the proper destination address, encapsulate the UDP packet, and send it to the IP process for delivery.
An application calls a system routine to buffer data, and notifythe output process.
The output process segments the data stream, encapsulates the TCP packets, and sends them to the IP process for delivery.
UDP Output
TCPOutputProcess
TCPTimer
Process
Net2 Hardware
Net2 Device
Net1 Hardware
Net1 Device
Netn Hardware
Netn Device
IPProcess
ControlMessages
TCPOutput
PortQueue ForDatagramsSent To IP
Queues ForOutgoingPackets
TCP Output
When the IP process enqueues an outgoing datagram, a device driver routine is called to start the hardware. When the output has occurred, the interrupt handler dequeues the datagram and restarts the hardware to send the next datagram.
Source: Internetworking with TCP/IP, Volume II by Douglas E. Comer and David L. Stevens
INPUT PROCESS: FROM HARDWARE TO APPLICATION
Page 4Chapter 3CS 447
Hardware
Operating System
Operating System
Application Programs
UDP packets are delivered to UDP ports, from which application programs read them.
IP demultiplexes packets and delivers them to appropriate transport protocol.
Incoming IP datagrams are queued for the IP process.
Source: Internetworking with TCP/IP, Volume II by Douglas E. Comer and David L. Stevens
Net2 Hardware
Net2 Device
Net1 Hardware
Net1 Device
Netn Hardware
Netn Device
IPProcess
Queues ForPackets
Sent To IP
TCP Input UDP Input
TCPInput
Process
Semaphore-Controlled
Buffers
Port ForSegments
Sent To TCP
UDPDatagram
PortsTCP packets are delivered to TCP buffers, from which application programs read them.
ESTABLISHING CONNECTIONS
Page 5Chapter 3CS 447
In the Transport Layer, the common approach for establishing an end-to-end connection involves a three-way handshake.
This approach helps to determine whether connection requests or acknowledgements are disposable duplicates or not.
Connection Request(Sequence #A)
Acknowledgement(Seq #B/Ack #A)
Data Packet(Seq #C/Ack #B) OLD DUPLICATE
Connection Request(Sequence #A)
Acknowledgement(Seq #B/Ack #A)
REJECT(NAK #B)
OLD DUPLICATEConnection Request
(Sequence #A)Acknowledgement(Seq #B/Ack #A)
REJECT(NAK #B)
OLD DUPLICATEData Packet
(Seq #C/Ack #D)
RELEASING CONNECTIONS
Page 6Chapter 3CS 447
The three-way handshake is also used to release an end-to-end connection, since it facilitates the detection of lost disconnect
messages and/or ACKs.Disconnect Request(Start Sender Timer)
Disconnect Request(Start Receiver Timer)
Disconnect ACK(Connection Released)
Disconnect Request(Start Sender Timer)
Disconnect Request(Start Receiver Timer)
Disconnect ACK Connection Released
When Timer Expires
Disconnect Request(Start Sender Timer)Disconnect Request
(Start Receiver Timer)
Disconnect ACK(Connection Released)
Disconnect Request(Start Sender Timer)
Disconnect Request(Start Sender Timer)Disconnect Request
(Start Receiver Timer)Disconnect Request(Start Sender Timer)Disconnect Request(Start Sender Timer)Disconnect Request(Start Sender Timer)Disconnect Request(Start Sender Timer)
Connection Released
When Timer Expires
Connection Released
When Timer Expires N
Times
Disconnect Request(Start Receiver Timer)
TRANSPORT LAYER COMMUNICATION
Page 7Chapter 3CS 447
The Transport Layer only deals with logical end-to-end message transport, but those messages are physically relayed through
intermediary devices operating at lower layers.
INTERNET TRANSPORT-LAYER PROTOCOLS
Page 8Chapter 3CS 447
Transmission Control Protocol (TCP)
• Connection-Oriented (end-to-end session is set up in advance)
• Reliable, In-Order Delivery (packets are numbered and any missing packets are sent again)
• Flow Control (transmission rate adjusted to receiver’s capacity to receive)
• Congestion Control (throttles traffic to avoid bottlenecks)
User Datagram Protocol (UDP)
• Connectionless (no end-to-end session is set up)
• Unreliable, Unordered Delivery (depends on IP for “best delivery”)
• No Congestion Avoidance (could hog excessive bandwidth)
MULTIPLEXING
Page 9Chapter 3CS 447
Depending on the application layer service being used, a source host specifies a 16-bit source port number and a 16-bit destination port number, attaching a header to the outgoing application information
that includes these port numbers.Transport Layer Segment
SourcePort #
Destination
Port #Other Header Fields Application Layer Payload
The endpoint in a Transport Layer communication is called a socket, with the port number and IP address comprising the socket address.
Any specific Transport Layer communication uses two sockets, the source port and IP address, and the destination port and IP address,
all of which together comprises a socket pair.
DEMULTIPLEXING (CONNECTIONLESS)
Page 10Chapter 3CS 447
In connectionless Transport Layer service (e.g., UDP), sockets are created with port numbers that are local to the host.
Process 1 Process
2Process
3
DatagramSocket clientSocketA = new DatagramSocket(8945) DatagramSocket clientSocketA = new DatagramSocket(9601)
DatagramSocket serverSocketC = new DatagramSocket(6734)
Port 8945 Port
9601Port 6734
8945 6734 payload,etc. 6734 8945 response,etc. 9601 6734 payload,etc.6734 9601 response,etc.
Note that IP datagrams with different source IP addresses and/or source port numbers may be directed to same socket.
DEMULTIPLEXING (CONNECTION-ORIENTED)
Page 11Chapter 3CS 447
In connection-oriented Transport Layer service (e.g., TCP), a receiving host uses all four values (the source and destination ports, and the
source and destination IP addresses) to direct a segment to the appropriate socket.
Process 1 Process
3
Process 5
Port 7530 Port
4378Port 8641
Process 4
Process 6 Process
2Port 92567530 8641 payload,etc.E.F.G.H W.X.Y.Z
9256 8641 payload,etc.L.M.N.O W.X.Y.Z4378 8641 payload,etc.L.M.N.O W.X.Y.Z
A server host may support several simultaneous TCP sockets (each socket identified by its own 4-tuple), and web servers have different
sockets for each connecting client.
USER DATAGRAM PROTOCOL
Page 12Chapter 3CS 447
Source Port Destination Port
Message Length Checksum
UDP provides an unreliable delivery service using IP to transport messages between machines.
As an unreliable service, it supports:
• No flow control and no congestion control• No acknowledgements, no timers, and no retransmissions
• Error recovery, using the same checksums as TCP
Source Port: Application’s UDP port number at the source station.
Message Length: # of bytes in the UDP datagram, including header and data.Destination Port: Application’s UDP port number at the destination station.
Source Port Destination Port
Message Length Checksum
Checksum: 1’s complement of 1’s complement sum of all 16-bit words in header, data, & “pseudoheader”.
The UDP Header
An application using UDP accepts full responsibility for handling reliability, including: message loss, duplication, delay, out-of-order
delivery, and loss of connectivity!
UDP/TCP PSEUDOHEADER
Page 13Chapter 3CS 447
Source Address
Transport Segment Length00000000
Destination Address
Protocol #
Destination Address: IP address of the destination station.
Protocol Number: IP’s identification of the protocol type being used (i.e., 6 for TCP, 17 for UDP).
Source Address: IP address of the source station.
00000000: Padding.
Segment Length: Number of bytes in the Transport segment, including header and data.
Source Address
Transport Segment Length00000000
Destination Address
Protocol #
When the destination receives an IP datagram, IP passes the source and destination IP addresses, the datagram’s total length, and its protocol ID, to
the Transport Layer, along with the Transport segment itself.The Transport protocol formulates the pseudoheader, and then calculates and
checks the checksum.Note that the pseudoheader is not counted in the segment length
(since it’s not part of the segment!) and is not transmitted!
The Transport protocol uses the pseudoheader as part of its checksum calculation in order to verify both the source and destination sockets when
the Transport segment is delivered.
RELIABLE DATA TRANSFER
Page 14Chapter 3CS 447
A Transport protocol is considered reliable if it delivers all bits uncorrupted and in the correct order, regardless of how unreliable the
underlying network is.
Common Reliability Concerns
w/Common Solutions
Error Control
Use ACKs, NAKs, Timeouts
ACK/NAK Loss Or Corruption
Resend Packet
Duplicate Packets Due To
ResendUse Sequence
Numbers
Duplicate Packets Due To
TimeoutUse Sequence
Numbers
Flow Control
Automatic Repeat Request (ARQ)
Receiver Burdened With Bookkeeping
Use Go-Back-N
Pipeline Burdened With
RetransmissionsUse Selective Repeat
Congestion Control
Vary Transmission Rates
Inability To Locate Precise
ProblemMultiplicative
Decrease Congestion Avoidance
Inability To Recognize RecoveryAdditive Increase
Slow-Start Recovery
Segment 0
ACK 1Segment 1
ACK 2Segment 2
ACK 3Segment 3
ACK4
Segment 0
ACK1
Segment 4
ACK5
Segment 1
ACK2
Segment 5 ACK 6Segment
6NAK 6Segment
6NAK 6Segment
6ACK 7Segment
7ACK 8Segment
8Segment
8Segment
8ACK 9Segment
9
FLOW CONTROL
Page 15Chapter 3CS 447
When an endstation transmits segments faster than the recipient can “digest” them, either due to a lack of memory capacity or a
preoccupation with other tasks, the recipient will usually just discard the excess frames.
The “Stop-and-Wait” approach to Transport Layer flow control has the recipient respond with an acknowledgement (ACK) whenever it has
finished dealing with the previous transport segment and is ready to receive the next segment.
• “Piggybacking” ACKs on segments going the opposite direction on the link, in order to reduce channel utilization.
• Sending negative acknowledgements (NAKs) whenever a segment is corrupted or not received in a timely fashion.
• Retransmitting a segment automatically whenever an ACK is not received in a timely fashion.
Variations on this approach include:
SLIDING WINDOWS
Page 16Chapter 3CS 447
By increasing the memory on each endstation and using a more sophisticated algorithm for keeping track of which Transport
segments have and haven’t been accepted, traffic can flow more smoothly between the endstations.
The “sliding windows” approach sets a particular window size for the total number of segments that the receiving station has either not received, not
acknowledged, or not delivered to the current application.
Every time the receiver transmits a segment to the sender, it includes a field advertising the number of slots in the window that are not
occupied by segments that have been received and acknowledged, but not yet delivered.
That number serves as a limit on how many more segments the sender can send to the receiver.
Each segment is numbered with a “sequence number” so lost or duplicate segments can be determined, and the sequence
numbers cycle back to zero to start repeating when the likelihood decreases that duplicate numbers will occur.
ERROR CONTROL
Page 17Chapter 3CS 447
When a Transport segment is determined to be corrupted, there are two principal response alternatives.
Go-Back-NHave the sending station resend
the faulty segment and all subsequent segments.
• Simplifies processing on the endstations.
• Yields a lot of unnecessary retransmissions.
Selective RepeatHave the sending station resend only the segment that was faulty.
• More productive use of bandwidth.
• More sophisticated (i.e., expensive) endstations.
Sliding Window Size
4
Current Window Gap
4
Last Sent Segment -
Last Received Segment -
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
3
Last Sent Segment 0
Last Received Segment 0
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
2
Last Sent Segment 1
Last Received Segment 1
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
1
Last Sent Segment 2
Last Received Segment 2
Last Acknowledged Segment
-
Last Received Segment 2
Last Acknowledged Segment
1
Sliding Window Size
4
Current Window Gap
3
Last Sent Segment 2
Sliding Window Size
4
Current Window Gap
2
Last Sent Segment 3
Sliding Window Size
4
Current Window Gap
1
Last Sent Segment 4
Sliding Window Size
4
Current Window Gap
0
Last Sent Segment 5
Sliding Window Size
4
Current Window Gap
4
Last Sent Segment 2
Sliding Window Size
4
Current Window Gap
3
Last Sent Segment 3
Sliding Window Size
4
Current Window Gap
2
Last Sent Segment 4
Sliding Window Size
4
Current Window Gap
1
Last Sent Segment 5
Sliding Window Size
4
Current Window Gap
0
Last Sent Segment 6
Sliding Window Size
4
Current Window Gap
3
Last Sent Segment 6
Sliding Window Size
4
Current Window Gap
2
Last Sent Segment 7
Sliding Window Size
4
Current Window Gap
1
Last Sent Segment 0
Sliding Window Size
4
Current Window Gap
0
Last Sent Segment 1
Sliding Window Size
4
Current Window Gap
4
Last Sent Segment 7
Sliding Window Size
4
Current Window Gap
3
Last Sent Segment 0
Sliding Window Size
4
Current Window Gap
2
Last Sent Segment 1
Sliding Window Size
4
Current Window Gap
1
Last Sent Segment 2
Sliding Window Size
4
Current Window Gap
0
Last Sent Segment 3
Last Received Segment 3
Last Acknowledged Segment
1
Last Received Segment 4
Last Acknowledged Segment
1
Last Received Segment 5
Last Acknowledged Segment
1
Last Received Segment 2
Last Acknowledged Segment
2
Last Received Segment 3
Last Acknowledged Segment
2
Last Received Segment 4
Last Acknowledged Segment
2
Last Received Segment 5
Last Acknowledged Segment
2
Last Received Segment 6
Last Acknowledged Segment
2
Last Received Segment 6
Last Acknowledged Segment
5
Last Received Segment 7
Last Acknowledged Segment
5
Last Received Segment 0
Last Acknowledged Segment
5
Last Received Segment 1
Last Acknowledged Segment
5
Last Received Segment 7
Last Acknowledged Segment
7
Last Received Segment 0
Last Acknowledged Segment
7
Last Received Segment 1
Last Acknowledged Segment
7
Last Received Segment 2
Last Acknowledged Segment
7
Last Received Segment 3
Last Acknowledged Segment
7
Segment 0
ACK 2 Segment 1
Segment 2
Segment 3
Segment 4
Segment 5
Segment 3
Segment 4
Segment 5
NAK 3 Segment 6
Segment 7
Segment 0
ACK 6NAK 0 Segment 1
Segment 0
Segment 1
Segment 2
Segment 3
Sliding Window Size
4
Current Window Gap
4
Sent Segments -
Received Segments -
Last Acknowledged Segment
-
Segment 0
ACK 2 Segment 1
Segment 2
Segment 3
Segment 4
Segment 5
Segment 3
NAK 3 Segment 6
Segment 7
Segment 0
ACK 5NAK 0 Segment 1
Segment 0
Segment 2
Segment 3
Sliding Window Size
4
Current Window Gap
3
Sent Segments 0
Received Segments 0
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
2
Sent Segments 0,1
Received Segments 0,1
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
1
Sent Segments 0,1,2
Received Segments 0,1,2
Last Acknowledged Segment
-
Sliding Window Size
4
Current Window Gap
3
Sent Segments 2
Received Segments 2
Last Acknowledged Segment
1
Sliding Window Size
4
Current Window Gap
2
Sent Segments 2,3
Received Segments 2,3
Last Acknowledged Segment
1
Sliding Window Size
4
Current Window Gap
1
Sent Segments 2,3,4
Received Segments 2,3,4
Last Acknowledged Segment
1
Sliding Window Size
4
Current Window Gap
0
Sent Segments 2,3,4,5
Received Segments 2,3,4,5
Last Acknowledged Segment
1
Sliding Window Size
4
Current Window Gap
1
Sent Segments 4,5
Received Segments 4,5
Last Acknowledged Segment
2
Sliding Window Size
4
Current Window Gap
1
Sent Segments 4,5,3
Received Segments 4,5,3
Last Acknowledged Segment
2
Sliding Window Size
4
Current Window Gap
0
Sent Segments 4,5,3,6
Received Segments 4,5,3,6
Last Acknowledged Segment
2
Sliding Window Size
4
Current Window Gap
2
Sent Segments 5,6
Received Segments 5,6
Last Acknowledged Segment
4
Sliding Window Size
4
Current Window Gap
1
Sent Segments 5,6,7
Received Segments 5,6,7
Last Acknowledged Segment
4
Sliding Window Size
4
Current Window Gap
0
Sent Segments 5,6,7,0
Received Segments 5,6,7,0
Last Acknowledged Segment
4
ACK 7
Sliding Window Size
4
Current Window Gap
2
Sent Segments 7,0
Received Segments 7,0
Last Acknowledged Segment
6
Sliding Window Size
4
Current Window Gap
1
Sent Segments 7,0,1
Received Segments 7,0,1
Last Acknowledged Segment
6
Sliding Window Size
4
Current Window Gap
0
Sent Segments 7,0,1,2
Received Segments 7,0,1,2
Last Acknowledged Segment
6
Sliding Window Size
4
Current Window Gap
1
Sent Segments 1,2
Received Segments 1,2
Last Acknowledged Segment
7
Sliding Window Size
4
Current Window Gap
1
Sent Segments 1,2,0
Received Segments 1,2,0
Last Acknowledged Segment
7
Sliding Window Size
4
Current Window Gap
0
Sent Segments 1,2,0,3
Received Segments 1,2,0,3
Last Acknowledged Segment
7
TRANSMISSION CONTROL PROTOCOL
Page 18Chapter 3CS 447
To provide reliable Transport service, TCP must use a
much more elaborate header
than UDP.
Source Port: TCP port number of the application at the source station.
Acknowledgement Number: Sequence number of the next Transport segment expected from the destination.
Reserved: Not currently used.
Sequence Number: Position in the sender’s byte stream of this Transport segment.Destination Port: TCP port number of the application at the destination station.
Header Length: Total length of the header (in 32-bit multiples).
Window Size: Current sliding window size (in bytes) - for end-to-end flow control.
Urgent Pointer: Position in the Transport segment where urgent data ends.
Code Bits: 6 flags: URG (Is Urgent pointer field valid?), ACK (Is Ack. # Valid?), PSH (Push delivery w/o waiting for full buffer), RST (Reset connection), SYN (Synchronize sequence #s), FIN (End of sender’s byte stream)
Checksum: 1’s complement of 1’s complement sum of 16-bit words in header, data, & pseudoheader.
Options & Padding: For example, Maximum-Segment-Size, Selective-Repeat, Delay-ACKs.
Source Port Destination Port
Sequence Number
Window SizeHdrLen
Checksum
Options & Padding
Acknowledgement Number
Urgent Pointer
Reserved Code Bits
Source Port Destination Port
Sequence Number
Window SizeHdrLen
Checksum
Options & Padding
Acknowledgement Number
Urgent Pointer
Reserved Code Bits
TCP CONGESTION CONTROL
Page 19Chapter 3CS 447
Flow control deals with one pair of endstations adjusting transmission rates to accommodate the receiver’s capacity, but congestion control deals with a station’s perception that it might be contributing to an
overall network traffic problem.How does a station “perceive” a congestion problem?
ACK#527
ACK#527
ACK#527
Duplicate AcknowledgementsWhile ACKs usually indicate that something is successfully getting through the network, duplicate ACK numbers indicate that the segment in question has been
lost or corrupted.
Acknowledgement TimeoutsIf no ACK is received in the
required time, then it is unknown whether anything is getting through the network
and a problem definitely exists.
MULTIPLICATIVE DECREASE CONGESTION AVOIDANCE
Page 20Chapter 3CS 447
Since endstations cannot pinpoint the cause of perceived congestion problems, TCP dictates that they respond dramatically, as if they are
the source of the problem.
The standard TCP response to a perceived congestion
problem is to have the endstation try to avoid
contributing to the problem by setting
ssthresh to ½cwnd and then resetting cwnd to
mss.
This prevents the station from having too many segments, without ACKs, and from returning to a high transmission
rate, until the traffic problem has dissipated.
TCP handles this response by means of three values:• The maximum TCP segment size (mss) that the receiving endstation can
accommodate.• The slow-start threshold (ssthresh) that prevents a station from
recovering too quickly after it has perceived congestion.• The congestion window (cwnd) that limits how much unacknowledged
traffic a station can have on the network.
old cwnd
old ssthres
h
new cwnd
new ssthres
h
ADDITIVE INCREASESLOW-START RECOVERY
Page 21Chapter 3CS 447
While TCP’s Congestion Avoidance scheme responds severely to bad news about congestion, TCP responds very cautiously to good news
about successful transmissions.Whenever a positive ACK is received, the station increases cwnd by 1mss for
each acknowledged segment until cwnd reaches ssthresh.
To prevent a recurrence of the congestion problem, once cwnd reaches ssthresh, cwnd only increases by 1 mss for every passage of rtt milliseconds
(where rtt is the estimated round-trip time for a segment to successfully travel across this connection to its destination and for an ACK to return).