1

Transport Layer - UDP & TCP Protocols

"I cannot teach anybody anything, I can only make them think.”

- Socrates

2

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

3

Transport Protocols

Internet protocol architecture

Application Services(FTP, Telnet, SMTP, …)

Transport Services(TCP, UDP, SCTP)

Connectionless Packet Delivery Service (IP)

OSI Layers 5 - 7

Layer 4 - Transport

Layer 3 - Network

TCP - Transmission Control ProtocolUDP - User Datagram ProtocolSCTP - Stream Control Transmission Protocol

4

Encapsulating TCP/UDP in IP Datagrams

Layer 2 Data Link Header Data Link Data FCS

IP Header IP DataLayer 3

TCP/UDP Header Application DataLayer 4

FCS: Frame Check Sequence (for error checking)

5

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

6

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)

7

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)

8

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?

9

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)

10

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

Protocol)

11

UDP Datagram Format

Source Port

Destination Port

Checksum

Data

Length

……….

Bits 0 15 16 31

• 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 value set to 0, if not computed)

12

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

13

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)

14

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

TCP

IP

TCP

IP

App AApp B

App B

TCP connection A TCP connection B

Ports

15

TCP Segment Format

Source Port

Destination Port

Sequence Number

Ack Number

Checksum

Data

Urgent Pointer

PaddingOptions (if any)

……….

Code bitsHLen Resvd Window Size

Bits 0 15 16 31

The basic unit of data transferred by TCP to IP is a “segment”

16

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)

17

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.

18

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– If not specifically announced, a default segment

size of 536 bytes is assumed

19

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

20

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 = xReceive SYN

Send SYN; Seq = yAck = x+1Receive SYN + ACK

Send Ack = y+1Receive ACK

Time

21

Connection Release• Each direction is shut down independently

Host A Host B

Send FIN; Seq = xReceive FIN

Send Ack = x+1Inform applicationReceive ACK

Send Ack = y+1

Receive ACKTime

Application closesconnection

App closes connectionSend FIN; Seq = y;Ack = x+1

Receive FIN + ACK

Connection half closed ... B can still send data ...

Connection fully closed ...

22

23

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 expiry, the segment is resent.

24

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.

25

TCP’s Sliding Window example ...

… 17 18 19 20 21 …. 29 30 31 …. 49 50 51 …

Receiver’s advertised window (30 bytes)

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)

A B C D

26

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)

27

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

28

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

29

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.

30

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 “SACK-permitted” option

• SACKs improve TCP performance in congested networks or networks with unreliable links

31

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.

32

Figure 12.27 Fast retransmission

33

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

34

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

35

Figure 12.33 Slow start, exponential increase

36

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

37

Figure 12.34 Congestion avoidance, additive increase

38

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

39

Figure 12.36 Congestion example