Unit 5: Transport Layer and Congestion Control - Subjective Questions

The network layer and transport layer work together to provide end-to-end communication, but they operate at different scopes.

• Network layer:

  • Provides logical communication between hosts.
  • Selects routes and forwards packets through intermediate routers.
  • Uses logical addresses such as IP addresses.
  • IP generally provides a best-effort, connectionless delivery service.

• Transport layer:

  • Provides logical communication between application processes running on end hosts.
  • Uses port numbers to identify source and destination processes.
  • Performs segmentation, reassembly, multiplexing and demultiplexing.
  • Protocols such as TCP can add reliability, flow control and congestion control over the unreliable IP service.

Thus, the network layer provides host-to-host delivery, whereas the transport layer provides process-to-process delivery. Transport protocols are implemented primarily in end systems, while network-layer functions are performed by both hosts and routers.

The major transport-layer services are:

• Process-to-process delivery: Delivers data to the correct application using port numbers.
• Segmentation and reassembly: Divides application messages into smaller segments and reconstructs them at the destination.
• Multiplexing and demultiplexing: Allows multiple applications to share the network and directs received data to the appropriate socket.
• Connection management: Establishes, maintains and terminates logical connections in connection-oriented protocols such as TCP.
• Reliable transfer: Uses sequence numbers, acknowledgements, checksums and retransmissions to recover from loss or corruption.
• Ordered delivery: Ensures that bytes or segments are delivered to the application in the correct order.
• Flow control: Prevents a fast sender from overwhelming a slow receiver.
• Congestion control: Adjusts the transmission rate when the network becomes congested.

Not every transport protocol provides every service. TCP provides most of these services, while UDP provides a simpler connectionless service.

Multiplexing occurs at the sending host, where the transport layer accepts data from multiple application processes, adds transport headers and passes the resulting segments to the network layer.

Demultiplexing occurs at the receiving host, where the transport layer examines header information and delivers each segment to the correct application socket.

• A port number identifies an application endpoint within a host.
• A socket is an interface between an application process and the transport layer.
• A UDP socket is commonly identified by the destination IP address and destination port.
• A TCP connection is identified by a four-tuple:

This four-tuple allows a server to maintain separate TCP connections for many clients even when all clients communicate with the same server port.

Transport-layer performance is influenced by several factors:

• Throughput: Rate at which useful application data is delivered.
• Delay: Includes processing, transmission, propagation and queuing delays.
• Packet loss: Causes retransmissions and reduces effective throughput.
• Round-trip time: Affects acknowledgement and retransmission mechanisms.
• Receiver capacity: A slow receiver can limit the sender through flow control.
• Congestion: Excess traffic creates queues, packet drops and increased delay.
• Protocol overhead: Headers, acknowledgements and retransmissions consume bandwidth.

The bandwidth-delay product represents the amount of unacknowledged data required to keep a path fully utilized:

For example, a path with bandwidth Mbps and RTT ms has:

This equals bytes. The sender's effective window should be at least approximately this large to fully utilize the path. Small windows, poor timeout selection and excessive retransmissions reduce performance.

A TCP header has a minimum size of 20 bytes and can grow to 60 bytes when options are included. Its logical format is:

Important control flags include:

• SYN: Synchronizes sequence numbers during connection establishment.
• ACK: Indicates that the acknowledgement field is valid.
• FIN: Requests an orderly connection termination.
• RST: Resets an invalid or failed connection.
• PSH: Requests prompt delivery to the receiving application.
• URG: Indicates that the urgent pointer is valid.
• ECE and CWR: Support Explicit Congestion Notification.

The data offset is needed because TCP options make the header variable in length. Sequence and acknowledgement numbers provide reliable, ordered byte-stream delivery.

TCP treats application data as an ordered byte stream.

• Each transmitted byte has a sequence number.
• The sequence number in a segment identifies the first data byte carried by that segment.
• An acknowledgement is normally cumulative. An acknowledgement number means that all bytes up to have been received and byte is expected next.
• The receiver detects corruption using the TCP checksum and discards damaged segments.
• Missing data is recovered through retransmission after a timeout or after duplicate acknowledgements indicate likely loss.
• Out-of-order segments may be buffered until missing earlier data arrives.

TCP uses a sliding window to allow multiple bytes to remain unacknowledged. The usable sending window is limited by both receiver flow control and congestion control:

Here, is the receiver-advertised window and is the congestion window. This mechanism combines reliability with efficient pipelined transmission.

TCP uses a three-way handshake to establish a connection and synchronize initial sequence numbers.

1. SYN: Client sends a segment with SYN set and an initial sequence number .
2. SYN-ACK: Server replies with SYN and ACK set, sequence number , and acknowledgement number .
3. ACK: Client sends an ACK with acknowledgement number .

After the third step, both endpoints know that the other endpoint is reachable and that the initial sequence numbers have been accepted.

A two-way handshake is insufficient because:

• The server cannot be certain that its response reached the client.
• Old duplicate connection requests could create half-open or incorrect connections.
• Both directions need independent sequence-number synchronization.

The final ACK confirms the server's sequence number and prevents the server from treating an unconfirmed request as a fully established connection.

TCP connections are full duplex, so each direction is closed independently. A typical termination proceeds as follows:

1. Host A sends a FIN to indicate that it has no more data to send.
2. Host B acknowledges A's FIN with an ACK.
3. When Host B has finished sending its remaining data, it sends its own FIN.
4. Host A acknowledges B's FIN with a final ACK.

Four exchanges are normally required because receiving a FIN closes only one direction of data transfer. The other endpoint may still have data to send. The ACK and FIN from Host B can sometimes be combined, reducing the number of segments.

The endpoint performing the active close enters the TIME-WAIT state after sending the final ACK. TIME-WAIT:

• Allows retransmission of the final ACK if it is lost.
• Lets delayed duplicate segments expire before the same connection identifiers are reused.

A connection can also be terminated abruptly using an RST segment.

Network delay changes over time, so TCP calculates an adaptive retransmission timeout, or RTO. Let be a measured round-trip time. The smoothed estimate is:

A commonly used value is . TCP also estimates RTT variation:

where is commonly . The timeout is then approximately:

An adaptive timeout is necessary because:

• If RTO is too short, TCP performs unnecessary retransmissions.
• If RTO is too long, recovery from real loss is slow.
• Queuing delay and route changes cause RTT variation.

After a timeout, TCP commonly applies exponential backoff, increasing the RTO to avoid injecting repeated retransmissions into a congested network. RTT measurements for retransmitted segments must also be handled carefully because the sender may not know which transmission generated the ACK.

The UDP header has a fixed length of only 8 bytes:

UDP is considered lightweight because it provides:

• No connection establishment or handshake.
• No sequence numbers or acknowledgements.
• No retransmission or ordered delivery.
• No built-in flow control.
• No built-in TCP-style congestion-control mechanism.
• A small, fixed-size header.

These properties reduce delay and processing overhead. UDP is therefore useful for DNS, real-time audio or video, online games and applications that implement their own reliability. However, the application must tolerate or handle loss, duplication, corruption and reordering.

TCP is preferred when correctness and ordered delivery are important. UDP is preferred when low latency, low overhead or preservation of application message boundaries is more important. UDP applications should still behave responsibly under congestion, often by implementing rate adaptation at the application layer.

The UDP checksum detects corruption in the UDP header, payload and selected network-layer addressing information.

The sender performs these steps:

1. Construct a pseudo-header containing the source IP address, destination IP address, protocol number and UDP length.
2. Append the UDP header with its checksum field set to zero.
3. Append the UDP data and pad an odd-length datagram with one zero byte for calculation purposes.
4. Divide the result into 16-bit words.
5. Add the words using one's-complement addition, including end-around carry.
6. Take the one's complement of the final sum and place it in the checksum field.

The receiver performs the same addition, including the received checksum. A correct result should consist of all one bits in one's-complement arithmetic.

The pseudo-header is not transmitted as part of the UDP datagram. Its purpose is to detect delivery to an incorrect IP address or transport protocol. In IPv4, a zero UDP checksum can indicate that the checksum was not used, while the UDP checksum is mandatory in normal IPv6 UDP operation.

Flow control protects the receiver, whereas congestion control protects the network.

• Flow control:

  • Prevents a fast sender from overflowing a slow receiver's buffer.
  • The receiver advertises an available window called .
  • The sender limits outstanding data according to this advertised capacity.

• Congestion control:

  • Prevents excessive traffic from overloading routers and links.
  • TCP maintains a congestion window called .
  • It adjusts according to acknowledgements, packet loss, timeout events or congestion marks.

The actual amount of unacknowledged data permitted is approximately:

Therefore, a connection may be limited either by receiver capacity or by network congestion. Receiver buffer overflow is an endpoint problem, while congestion involves growing router queues, high delay, packet loss and reduced network efficiency.

In network-assisted congestion control, routers provide information or control signals to help end systems detect and respond to congestion.

• Binary feedback:

  • A router marks a packet with a one-bit or small congestion indication.
  • The receiver informs the sender, which reduces its transmission rate.
  • Examples include DECbit-style marking and IP Explicit Congestion Notification.

• Explicit-rate feedback:

  • Routers calculate or update a permitted transmission rate.
  • The sender adjusts its rate to the value allowed by the bottleneck.
  • This can respond more precisely than a simple congestion bit but requires additional router support.

• Choke packets:

  • A congested router sends a special control packet back to the source.
  • The message identifies the congested destination, path or traffic flow.
  • The source then reduces its sending rate.

Network assistance can provide earlier and clearer congestion signals than waiting for packet loss. Its disadvantages include implementation complexity, control-message overhead and the need for compatible routers and end systems.

Backpressure is a hop-by-hop congestion-control technique:

• A congested router asks its upstream neighbor to reduce or stop sending traffic.
• That neighbor may then signal its own upstream neighbor.
• The congestion signal can propagate back toward the source.
• It is most suitable for virtual-circuit or tightly controlled networks.

Choke-packet control is an end-to-end signaling technique:

• A congested router generates a control packet addressed to the source.
• The source reduces its transmission rate for the affected destination or flow.
• Additional choke packets may be suppressed temporarily to avoid excessive feedback traffic.

Advantages:

• Congestion can be reported directly rather than inferred only from loss.
• Sources can reduce traffic before severe buffer overflow occurs.

Limitations:

• Backpressure can spread congestion to upstream routers and affect unrelated traffic.
• Choke packets consume resources in an already congested network.
• Feedback may arrive late on paths with large propagation delays.
• These methods require support within network devices and suitable source behavior.

Networks can control congestion through several router- or network-level mechanisms:

• Traffic-aware routing:

  • Routes traffic away from heavily loaded links.
  • Uses measurements such as queue length, link utilization or delay.
  • Route changes must be stable because frequent changes can cause oscillations.

• Admission control:

  • A new flow or virtual circuit is accepted only if sufficient resources are available.
  • The network may reserve bandwidth and buffer capacity.
  • It is useful in quality-of-service networks but may reject users during high load.

• Load shedding:

  • Routers deliberately discard packets when congestion becomes severe.
  • Packet-selection policies may prefer important traffic or discard packets that are less useful.
  • Active queue management can drop or mark packets before a queue becomes completely full.

These techniques reduce congestion by changing routes, limiting offered load or removing traffic. They require careful policies to maintain fairness and avoid starvation of low-priority flows.

TCP controls its sending rate using the congestion window, , and the slow-start threshold, .

Slow start

• TCP begins with a relatively small congestion window.
• For each ACK, increases by approximately one MSS.
• As an entire window is acknowledged per RTT, the window approximately doubles each RTT.
• Slow start continues until reaches or congestion is detected.

Congestion avoidance

• TCP increases approximately linearly.
• A common per-ACK increase is:

• Across one RTT, this produces an increase of roughly one MSS.

Fast retransmit

• Three duplicate ACKs indicate that a segment is probably missing while later segments are arriving.
• TCP retransmits the missing segment without waiting for the RTO to expire.

Fast recovery

• TCP Reno reduces the congestion window after triple duplicate ACKs but does not return all the way to the initial window.
• It temporarily inflates the window for duplicate ACKs and continues transmitting when permitted.
• After an ACK covering the lost data arrives, it enters congestion avoidance near the reduced threshold.

These mechanisms create an adaptive transmission rate that rises when the network is uncongested and falls when congestion is detected.

Assume that the congestion window reaches a maximum of segments before a loss. Under multiplicative decrease, it falls to approximately . Under additive increase, it then grows by one segment per RTT until it reaches again.

The average congestion window is approximately:

The increase from to takes approximately RTTs. Therefore, the approximate number of segments sent in one cycle is:

If one packet loss occurs per cycle, the loss probability is approximately:

Solving for gives:

Thus, the average window is:

The approximate throughput is therefore:

This simplified result shows that TCP throughput is inversely proportional to RTT and approximately inversely proportional to . It assumes regular AIMD behavior, one loss per cycle, stable RTT and no retransmission timeouts.

TCP interprets a retransmission timeout as stronger evidence of severe congestion than three duplicate ACKs.

Retransmission timeout

• The slow-start threshold is commonly set to approximately half the current flight size, subject to a minimum value.
• The congestion window is reset to a small initial value in the traditional textbook model.
• TCP enters slow start.
• The retransmission timer is backed off, commonly using exponential backoff.

Three duplicate ACKs

The duplicate ACKs show that packets are still reaching the destination, so the path is probably not completely blocked.

• TCP Tahoe:

  • Performs fast retransmit.
  • Sets to approximately half the current flight size.
  • Resets to a small value.
  • Re-enters slow start.

• TCP Reno:

  • Performs fast retransmit and fast recovery.
  • Sets to approximately half the flight size.
  • Temporarily inflates while duplicate ACKs arrive.
  • Enters congestion avoidance after the lost segment is acknowledged.

Reno usually recovers faster from a single packet loss, whereas a timeout causes a more drastic reduction in transmission rate.

During slow start, the congestion window approximately doubles every RTT until it reaches the threshold.

At MSS, has reached , so TCP enters congestion avoidance. The window then increases by approximately one MSS per RTT:

If three duplicate ACKs occur when MSS, TCP Reno treats the event as a recoverable packet loss:

1. Set the new threshold to approximately half the flight size:

2. Retransmit the missing segment immediately using fast retransmit.
3. Enter fast recovery and temporarily inflate the congestion window for the duplicate ACKs.
4. When an ACK covering the retransmitted segment arrives, set to approximately MSS.
5. Continue in congestion avoidance with linear growth.

If the loss had instead caused a timeout, traditional TCP would reduce to a small initial value and restart slow start, producing a more severe rate reduction.