15. Transport-Layer Services - TCP and UDP

Transport protocols provide logical communication between application processes running on different hosts.

The sender side breaks the application messages into segments and passes it to the network layer, while the receiver reassembles segments into messages and passes it to the application layer.

Multiple transport layer protocols are available, the most common being TCP and UDP.

The internet transport layer extends IP’s host-to-host delivery to process-to-process delivery (hence requiring multiplexing and demultiplexing), with TCP specifically adding reliable delivery, flow control and congestion control.

Multiplexing and Demultiplexing

Demultiplexing: the host receives IP datagrams; each has source/destination IP addresses and carries a single transport-layer segment. Inside each segment is the source/destination port number.

Connectionless-demultiplexing

With connectionless-demultiplexing (e.g. UDP), a two-tuple of the destination IP and port number can be used to identify the socket. Packets with different source IP and/or port numbers will be directed to the same socket.

Connection-oriented-demultiplexing

TCP sockets are identified by a 4-tuple: all four of the source and destination IP addresses and port numbers are required to direct the segment to the appropriate socket.

Hence, the server host may support many simultaneous TCP sockets through a single port number.

UDP

A bare bones, best effort service: segments can be lost or delivered out of order.

UDP is often used for streaming multimedia applications as this use case is loss-tolerate and rate-sensitive. UDP is also used in RIP, DNS, SNMP.

Segment structure:

|   16 bits   |      16 bits     |
| Source port | Destination port |
|   Length    |     Checksum     |
|              Data              |

The length is the length in bytes of the segment, including the header.

Advantages:

• No connection establishment - no delay
• Simple: no connection state at sender or receiver
• Small header - 8 bytes
• No congestion control - sender can send as fast as possible

The UDP socket for an incoming packet can be identified by its destination IP and port.

TCP

Properties:

• Point-to-point: one sender, one receiver
• Provides a reliable, in-order byte stream
  • No application-layer message boundaries
• Pipelined: TCP congestion/flow control sets the window size
• Full-duplex data: bi-directional data flow
• Connection-oriented: handshaking to initialize sender/receiver state
• Flow-controlled: sender will not overwhelm the receiver

Packet structure:

| 16 bits     | 16 bits           |
| Source port | Destination port  |
|         Sequence Number         |
|      Acknowledgement Number     |
| Flags       | Receive window    |
| Checksum    | Urg. data pointer |
|     Options (variable)          |
|        Application Data         |

Notes:

• Sequence number: byte stream number of the first byte in the segment’s data
• Acknowledgement: sequence number of next byte expected from the other side (cumulative ACK and hence acknowledges that all bytes prior to that have arrived)
• Urgent data pointer field rarely used
• Options can be padded with zeros to ensure its size is a multiple of 4 bytes.

Flags:

• Header length (4 bits) - number of bytes in header divided by 4
• Reserved (3 bits)
• NS: ECE-nonce
• CWR: congestion window reduced
• ECE: ECN-echo; if SYN ECN capable else packet with congestion experienced flag set
• URG: urgent pointer field significant
• ACK: acknowledgement field significant - all packets sent by the client should have this set to true, excluding the initial SYN
• PSH: push function: asks to push buffered data to the application
• RST: reset connection
• SYN: synchronize sequence number: only the first packet sent by each end should have this sent
• FIN: last packet from the sender

TCP Connection Management

Opening: three-way handshake

NB: segments with SYN or FIN flags are treated as if they have a 1 byte payload.

Step 1:

• Client host sends TCP SYN segment (SYN = 1) to server
• Randomly picks initial sequence number: client_isn
• No application data

The second step both acknowledges the segment and sends the server’s ISN:

• Server host receives SYN, replies with SYNACK segment
  • Allocates buffers
  • Randomly picks initial sequence number: server_isn
  • SYN= 1, ACK = 1, ACK_number = client_isn + 1, sequence_number = server_isn

This third step is needed to confirm that the client has received the server’s ISN:

• Client host receives SYNACK, replies with ACK
  • Response may contain data
  • SYN = 0, ACK = 1, ACK_number = server_isn + 1; sequence_number = client_isn + 1

Termination

• Step 1: client host sends FIN to server
• Step 2: server host receives FIN, responds with ACK
• Step 3: once server successfully closes connection (freeing buffers etc.), sends FIN
• Step 4: client receives FIN, responds with ACK

Client waits for double the maximum segment lifespan to ensure the ACK arrives.