Download Chapter 11 n` 12

Transport Layer - UDP & TCP
Protocols
"I cannot teach anybody anything, I
can only make them think.”
- Socrates
1
Transport Layer - UDP & TCP Protocols
 Connectionless & connection-oriented
protocols
 User Datagram Protocol (UDP)
 UDP Datagram Format
 Transmission Control Protocol (TCP)
 TCP Features and Segment Format
 Flow Control Mechanism and Congestion
Control
 Sections 11.6, 12.5, 12.9, 12.10, 12.11 will
not be discussed
2
Transport Protocols
Internet protocol architecture
OSI Layers 5 - 7
Application Services
(FTP, Telnet, SMTP, …)
Layer 4 - Transport
Transport Services
(TCP, UDP, SCTP)
Layer 3 - Network
Connectionless Packet
Delivery Service (IP)
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
SCTP - Stream Control Transmission Protocol
3
Encapsulating TCP/UDP in IP
Datagrams
TCP/UDP
Header
Layer 4
Layer 3
Layer 2
IP Header
Data Link Header
Application Data
IP Data
Data Link Data
FCS
FCS: Frame Check Sequence (for error checking)
4
Connection-oriented & Connectionless
protocols & services
• Why are they called connection-oriented and
connectionless?
• What are their distinct characteristics?
• Why these different protocols are needed?
• Examples of connection-oriented and
connectionless transport protocols
5
Connection-oriented protocols
• Three phases:
– Connection setup
– Data transfer
– Connection release
• A connection need to be setup between end points prior to the
data transfer
• Data delivery, integrity and sequencing are guaranteed
• Connection is released after the data transfer
• Better suited for applications that require guaranteed delivery,
but can tolerate some delays
• E.g. TCP (Transmission Control Protocol)
6
Connectionless protocols
• No connection setup necessary prior to data transfer
• Each datagram is routed independently and can take different
paths through the network; therefore datagrams could arrive
at the destination out of sequence
• Best-effort delivery (no guaranteed delivery)
• No connection release phase after data transfer
• Less overhead and therefore fast (less delay)
• Better suited for applications needing low delay but can
tolerate some data losses (E.g. voice applications)
• Examples: IP and UDP (User Datagram Protocol)
7
Transport Protocols
• How can a connection-oriented transport
protocol (like TCP) provide guaranteed
data delivery, integrity and sequencing
when they have to use connectionless IP
at the network layer?
8
Transport Protocols
• The connection-oriented transport
protocol (like TCP) has to implement
additional procedures at the transport
layer for ensuring data delivery, integrity
and sequencing
• This is at the cost of more overhead and
processing time (thus slower than
connectionless protocols)
9
User Datagram Protocol (UDP) - RFC 768
• Provides a minimal, simple, and best-effort
transport layer protocol, as some applications do
not require the robustness of TCP
• Provides a connection-less service to
applications
– Reliable data delivery or delivery of data in
the correct sequence are not guaranteed
• Faster and more efficient than TCP
• Examples of applications using UDP:
– DNS (Domain Name System)
– SNMP (Simple Network Management
10
UDP Datagram Format
Bits 0
15 16
31
Source Port
Destination Port
Length
Checksum
Data
……….
• Source & destination ports: identifies the source and
destination processes/applications
• Length: length of the UDP datagram (including header
and
data) in bytes
• Checksum: Covers the UDP header and data;
Optional (with
11
Port Numbers
Defined in three ranges:
• Well-known ports (0 - 1023)
• Defined in the “Assigned Numbers” RFC
• Assigned to core services that systems offer
• E.g. Telnet - Port 23, FTP Control data - Port 21
• Registered ports (1024 - 49151)
• Assigned to industry applications and processes
• E.g. Microsoft SQL Server process - Port 1433
• Dynamic (or, ephemeral) ports (49152 - 65535)
• Can use as temporary ports without being assigned
12
TCP Features
• Defined in RFC 793 (RFC 1122 contains some
corrections)
• Various enhancements proposed in subsequent RFCs
• Connection oriented protocol (needs specific
connection set up & release)
• Provides end-to-end (i.e., between hosts) reliable,
sequenced delivery of data segments
– Checksum covering header & payload
– End to end acknowledgements
– Retransmissions
• Flow control using a sliding window mechanism
• Congestion control (detection & avoidance)
13
Ports, Connections & End points
• A “port number” identifies an application process
• An “end point” is identified by IP Address & Port (called a TCP
socket)
• A “connection” is identified by two end points (two sockets)
App A
App B
Ports
TCP connection A
App A
App B
TCP
TCP
IP
IP
TCP connection B
14
TCP Segment Format
The basic unit of data transferred by TCP to IP is a “segment”
Bits 0
15 16
Source Port
31
Destination Port
Sequence Number
Ack Number
HLen
Resvd
Code bits
Checksum
Window Size
Urgent Pointer
Options (if any)
Padding
Data
……….
15
TCP Segment fields ...
• Source & destination ports: identifies the source
and destination processes or applications
• Ack number: indicates the sequence number of
the next expected data octet by the receiver.
– Acknowledges receipt of all data bytes up to
byte sequence number = (Ack number - 1)
– TCP Acks are cumulative (i.e., one Ack may
acknowledge receipt of data in several
consecutive segments)
16
TCP Segment fields ...
• Sequence number: indicates the sequence
number of the first byte in the segment
• HLen (or, Data Offset): Number of 32-bit words
in the TCP header. The typical value is 5 (20
bytes of header, if Options are not used)
• Window: indicates the number of bytes the
receiver is prepared to accept from the sender
(called rwnd). This reflects free buffer space
available at the receiver.
• Checksum: Covers the TCP header and data;
Mandatory in TCP.
17
TCP Segment fields ...
• Urgent Pointer:
– Used to deliver urgent data to the application at
the receiver, ahead of any other received data that
are buffered (jumping the queue)
– Indicates the position of the last byte of urgent
data
– Valid only when URG = 1 in the Code (or, Flags)
bits
• Options:
– One of the options is Max. Segment Size (MSS).
– If used, MSS is indicated only at the connection
set up
18
TCP Code bits
URG
ACK
PSH
RST
SYN
FIN
URG Urgent Pointer field is valid
ACK Ack field is valid
PSH This segment requests a “Push”
RST
Reset the connection
SYN Synchronize the sequence numbers
FIN
No more data from sender
19
Connection Establishment
• 3-way handshake
• Both sides agree on initial sequence numbers
• Two data streams (one in each direction) are established
Host A
Host B
Send SYN; Seq = x
Receive SYN
Receive SYN + ACK
Send SYN; Seq = y
Ack = x+1
Send Ack = y+1
Receive ACK
Time
20
Connection Release
• Each direction is shut down independently
Host A
Host B
Application closes
connection
Send FIN; Seq = x
Receive ACK
Connection half closed ...
Receive FIN + ACK
Send Ack = y+1
Time
Receive FIN
Send Ack = x+1
Inform application
B can still send data ...
App closes connection
Send FIN; Seq = y;
Ack = x+1
Receive ACK
Connection fully closed ...
21
22
Data Transfer
• In a SYN segment, a host may announce the MSS
(max. segment size) it expects to receive (default:
536 bytes)
• In each TCP header, a host indicates how many
“bytes” it is ready to accept - “receiver window
advertisement (rwnd)”.
• Sender divides its byte stream into “segments”.
Sequence numbers are assigned to each byte. Each
TCP segment header carries the Seq # of the first
byte in it.
• When a segment is sent (not to exceed the MSS or
the sender’s window size), a “retransmission timer” is
started. If an ACK is not received before the timer 23
Flow Control
• Hosts that send and receive TCP data segments
can operate at different data rates because of
differences in CPU and network bandwidth.
• A fast sender can overwhelm a slow receiver!
• TCP implements flow control based on a sliding
window mechanism
• The sender’s window size = min(rwnd, cwnd)
• cwnd - Congestion Window value is dependent
on the current “congestion control” phase of the
sending host. cwnd attempts to consider the
network congestion in determining the sender’s
window size at any given time.
24
TCP’s Sliding Window example ...
Receiver’s advertised window (30 bytes)
… 17 18 19 20 21
A
….
29 30 31
B
….
49
50 51 …
C
A
Sent & acked
B
Sent & not acked
C
Can be sent now, before receiving an ack
D
Cannot be sent until the window moves
(i.e., until an ack is received)
D
25
Silly Window Syndrome
• Sending application creating data slowly or the
receiving application consuming received data slowly
could result in sending of very few number of data
bytes in a segment
• This decreases the efficiency of TCP operation and is
called the “Silly Window Syndrome”
• Eg: If TCP sends segments with only 1 byte of user
data, a 41-byte IP packet (with 20 bytes of TCP header
+ 20 bytes of IP header) will have only have a data
delivery efficiency of: (1/41) x 100 --> 2.4% (without
even considering data link header + trailer overhead)
26
Syndrome created by Sender
• Sending application may create data slowly (eg: 1 byte
at a time) and sending TCP may create segments
containing only a single data byte
• “Nagle’s Algorithm” provides a solution
– Sending TCP sends the 1st segment even if it is only
1 byte
– After sending the 1st segment, sending TCP
accumulates data and waits until, either:
• Receives an ACK, or
• Enough data has accumulated to fill a max-size segment
27
Syndrome created by Receiver
• Receiving application may consume data slowly (eg: 1
byte at a time) and receiver-side TCP may announce a
window size of 1 byte (or, a very small window size),
resulting in sender creating very small segments
• Two solutions: Clark’s Solution & Delayed ACKs
• Clark’s solution:
– Send an ACK as soon as data is received, but announce a
window size of 0 until, either:
• there is enough buffer space to accommodate a segment
of max size, or
• half of the buffer is empty
28
Delayed ACKs
• When a segment is received, don’t send an ACK
immediately
• Receiver waits until there is sufficient amount of free
buffer space before sending an ACK
• One advantage of Delayed ACKs is reduced traffic (as
each segment doesn’t need to be ACKed individually)
• Disadvantage is, delayed ACKs may force the sender to
retransmit unacked segments
• To minimize retransmissions by sender, receiver should
not delay an ACK by more than 500 ms.
29
Selective ACKs (RFC 2018)
• Allows a receiver to inform the sender a list of
duplicate segments and lists of out-of-order segments
received in the “Options” field
• Sender can selectively retransmit only the missing
segments
• During connection setup phase, the two TCP hosts
agree whether they support this feature using “SACKpermitted” option
• SACKs improve TCP performance in congested
networks or networks with unreliable links
30
Fast Retransmission (RFC 2581)
• Originally, TCP was designed to discard out-of-order
segments by the receiving host. Most implementations
today store out-of-order segments until the missing
segment arrives.
• When an out-of-order segment is received with a seq #
higher than the expected seq #, receiver immediately
sends an ACK, announcing the seq # of the next expected
segment.
• When the sender receives 4 ACKs with the same value
(i.e., 3 duplicate ACKs), it retransmits the segment
expected by the receiver without waiting for
Retransmission Timer expiry.
31
Figure 12.27 Fast retransmission
32
TCP Congestion Control
• Congestion in a network happens when the input traffic
rate is greater than the traffic processing rate of network
nodes for consistently long periods of time
• To recover from congestion, traffic input rate needs to be
reduced by the sending hosts
• TCP handles congestion using following mechanisms
(RFC 2581):
– Slow start
– Congestion Avoidance
– Congestion detection
33
Slow-Start Phase
• At the beginning of data transfer phase, sending host
probes the status of the network to find out whether the
network is already congested or not
• Sender starts with cwnd = 1 or 2 MSS
• For each acknowledged segment, cwnd is increased by 1
MSS. cwnd is increased in this manner until a threshold
(called “ssthresh - slow start threshold”) is reached
• In most implementations, “ssthresh” is 65535 bytes
• Increase of cwnd in the slow-start phase is exponential
until the ssthresh is reached
34
Figure 12.33 Slow start, exponential increase
35
Congestion Avoidance Phase
• Congestion Avoidance Phase:
– Starts when cwnd in the slow-start phase reaches
ssthresh threshold
– To slow down the exponential increase of cwnd,
each time the “whole window of segments” is
acknowledged, cwnd is increased by 1 MSS.
– cwnd is increased additively in this manner until
congestion is detected
36
Figure 12.34 Congestion avoidance, additive increase
37
Congestion Detection Phase
• When a sender has to retransmit a segment, it is
considered as a sign of network congestion
• In most implementations, if the congestion detection
is due to:
– “Retransmission Timer expiry”, a new slow-start
phase is started
– “Receipt of 3 duplicate ACKs”, a new congestion
avoidance phase is started
38
Figure 12.36 Congestion example
39