Transport, Traffic Engineering, and Quality of Service

Introduction

The transport layer provides end-to-end communication between applications running on different hosts. It is responsible not only for delivering data, but also for determining how applications share network capacity, how failures are detected, and how delay-sensitive traffic is treated. Modern networks must support interactive voice, video conferencing, cloud applications, industrial control, web services, bulk transfers, and increasingly dense wireless access. These applications have different requirements for reliability, latency, jitter, loss, bandwidth, and ordering.

Transport protocols and quality-of-service (QoS) mechanisms address these requirements at different layers. TCP and QUIC provide reliable, congestion-controlled delivery. UDP provides a minimal datagram service on which applications can build their own mechanisms. Traffic engineering determines how traffic is routed and allocated across a network, while QoS mechanisms classify, mark, queue, police, and shape traffic. Effective design requires understanding how these mechanisms interact rather than treating them as independent features.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the operation and design trade-offs of TCP, UDP, and QUIC.
2. Distinguish latency, jitter, loss, throughput, and application-level performance.
3. Describe congestion control and interpret the bandwidth–delay product.
4. Explain multicast delivery and its practical limitations.
5. Analyze QoS classification, marking, queuing, policing, and shaping.
6. Translate application requirements into service-level objectives.
7. Evaluate a network design using measurements, traffic models, and operational constraints.

1. Transport Services and Application Requirements

A transport protocol multiplexes application flows over a network. A port number identifies an application endpoint, while an IP address identifies a host or interface. A socket is commonly represented by an IP address and port, although a complete flow may also be distinguished by protocol and the remote address and port.

Transport services differ along several dimensions:

A useful distinction is between network performance and application performance. A flow may receive high throughput but still provide poor user experience if its initial response is delayed or if packets arrive in bursts. Conversely, a voice stream may function acceptably with modest bandwidth if its delay and loss remain within application tolerance.

2. TCP: Reliable Byte-Stream Transport

Transmission Control Protocol (TCP) presents applications with a reliable, ordered byte stream. TCP does not preserve application message boundaries: if an application writes three blocks, the receiver may read them as one block or several smaller blocks. Applications requiring explicit records must provide framing.

2.1 Connection establishment and termination

TCP traditionally establishes a connection with a three-way handshake. The client sends a segment containing an initial sequence number; the server acknowledges it and supplies its own sequence number; the client acknowledges the server’s sequence number. This exchange confirms bidirectional reachability and synchronizes sequence spaces. TCP connection termination is usually a four-segment exchange because each direction closes independently.

TCP options negotiated during establishment may include maximum segment size (MSS), window scaling, selective acknowledgements (SACK), and timestamp support. These options affect performance substantially, especially on paths with large bandwidth–delay products.

2.2 Reliability mechanisms

TCP numbers bytes rather than merely packets. The receiver acknowledges the next byte it expects, allowing the sender to infer which data has arrived. Retransmission may be triggered by a retransmission timeout or by duplicate acknowledgements indicating a likely gap. SACK allows the receiver to identify several received blocks, reducing unnecessary retransmission.

The retransmission timeout must be long enough to avoid treating normal delay variation as loss, but short enough to recover promptly. Implementations estimate the round-trip time (RTT) and its variation. A simplified engineering relationship is:

Here, SRTT is the smoothed round-trip-time estimate and RTTVAR is the smoothed RTT variation; both are measured in seconds. The expression is a conceptual form of the algorithm specified for TCP implementations, and actual calculation includes carefully defined update rules and minimum bounds. It is not a universal substitute for those rules.

2.3 Flow control and congestion control

Flow control prevents a sender from overrunning the receiver. The receiver advertises a receive window, rwnd. Congestion control limits the amount of data the sender injects into the network. The congestion window, cwnd, reflects the sender’s estimate of available network capacity. The effective sending limit is approximately:

where FlightSize is the amount of unacknowledged data in transit. This relationship applies to a conventional TCP sender and does not imply that every implementation transmits exactly at the limit.

TCP congestion control commonly includes slow start, congestion avoidance, fast retransmit, and fast recovery. In slow start, the congestion window grows rapidly, approximately doubling each RTT when acknowledgements arrive for a full window. In congestion avoidance, growth is more conservative, often described as additive increase. Loss or an equivalent congestion signal causes a reduction, commonly called multiplicative decrease.

The classic additive-increase/multiplicative-decrease approach is valuable because independent senders tend to share a bottleneck more fairly than uncontrolled senders. However, fairness depends on RTT, algorithm choice, traffic patterns, and the nature of the bottleneck. Wireless losses, software queues, and application pacing can make loss alone an imperfect congestion signal.

3. UDP and QUIC

3.1 UDP

User Datagram Protocol (UDP) offers connectionless datagrams with minimal transport-layer functionality. UDP does not guarantee delivery, ordering, duplicate suppression, congestion control, or retransmission. It does provide port multiplexing and a checksum mechanism; IPv6 requires UDP checksums except in narrowly defined cases.

UDP is appropriate when the application can tolerate loss, needs message boundaries, or implements specialized control. Examples include DNS, live media, some game traffic, and tunnelling protocols. UDP is not automatically low latency: application processing, queuing, retransmission strategies, and path conditions remain important.

An application using UDP on a shared network has a responsibility to avoid persistent congestion. Rate control, pacing, receiver feedback, and adaptive coding are essential for well-designed real-time systems.

3.2 QUIC

QUIC is a secure, connection-oriented transport protocol carried over UDP. It integrates TLS-based security, supports multiple independent streams, uses connection identifiers, and implements congestion control. QUIC avoids TCP’s cross-stream head-of-line blocking: loss affecting one stream need not prevent delivery of data on another stream, although packets remain subject to congestion control and processing constraints.

QUIC can reduce connection-establishment latency through integrated cryptographic negotiation and can survive some changes in network path because connection identity is not necessarily tied to a single address pair. HTTP/3 uses QUIC as its transport.

QUIC does not eliminate network congestion, packet loss, or delay. Encryption also means that intermediate devices cannot inspect transport headers in the same way they traditionally inspect TCP. Network operators therefore rely more on flow metadata, endpoint cooperation, and explicit measurement.

4. Performance: Throughput, Delay, Jitter, and Loss

4.1 Latency components

End-to-end delay can be decomposed conceptually as:

Processing delay is the time to examine headers and perform protocol operations. Queueing delay results from waiting behind other traffic. Transmission delay is the time required to place all packet bits onto a link. Propagation delay is determined mainly by physical distance and signal velocity.

For a packet of length L bits sent over a link of rate R bits per second:

For example, a 1,500-byte packet on a 100 Mb/s link has:

This calculation excludes propagation, processing, framing overhead, and queueing.

4.2 RTT and bandwidth–delay product

Round-trip time is the time between sending a probe or segment and receiving the corresponding response or acknowledgement. The bandwidth–delay product (BDP) estimates how much data can occupy a path while a sender waits for an acknowledgement:

C is capacity in bits per second and RTT is round-trip time in seconds. For a 1 Gb/s path with a 40 ms RTT:

Thus, approximately 5 MB of data may be in flight to fully utilize the path, assuming no competing traffic, adequate receiver windows, and suitable protocol behavior. BDP is an estimate, not a guaranteed throughput.

4.3 Jitter and loss

Jitter describes variation in packet arrival time. Definitions differ: some systems use variation in one-way delay, while others use variation in interarrival time or an RFC-defined estimator. A measurement report must therefore state its definition.

Real-time applications commonly use a playout buffer. Increasing the buffer can absorb delay variation but increases latency. Packet loss may be concealed through interpolation, forward error correction, redundancy, retransmission, or reduced media quality. The appropriate strategy depends on whether the application values immediacy or completeness.

Application behavior matters. TCP bulk transfer tends to fill available queues, while adaptive video changes its sending rate based on measured throughput and buffer state. Interactive audio sends small, periodic packets and is sensitive to delay and jitter. A network design that optimizes only average bandwidth can therefore fail to meet application objectives.

5. Traffic Engineering and Multicast

Traffic engineering is the systematic adjustment of routing, capacity, and traffic placement to meet performance and resilience objectives. It includes link-capacity planning, routing metrics, equal-cost multipath, segment routing, tunnel placement, and admission decisions.

A basic traffic-engineering workflow is:

1. Measure demand, path utilization, delay, loss, and failures.
2. Model traffic classes and peak or burst behavior.
3. Identify bottlenecks and failure-sensitive paths.
4. Select routing, capacity, or policy changes.
5. Validate under normal and failure conditions.
6. Monitor outcomes and revise the model.

Average utilization can hide short bursts. Percentile measurements, flow distributions, busy-hour demand, and correlated failures are often more useful than a single mean value. Overengineering every link is expensive; underengineering critical paths creates persistent queueing and poor user experience.

Multicast

Unicast sends a separate copy toward each receiver. Multicast allows a source to send one logical stream that is replicated at branching points in the network. Receivers join a multicast group, and routers use multicast control protocols to construct distribution trees.

Multicast can be efficient for large, synchronized audiences such as IPTV, financial data feeds, and campus announcements. It introduces operational complexity: group management, routing state, security, troubleshooting, receiver heterogeneity, and inter-domain deployment. Internet-scale multicast has not replaced unicast content distribution because access networks, firewalls, business models, and application requirements often favor CDNs and replicated unicast delivery.

6. Quality of Service Architecture

QoS is not a promise that every packet will be fast. It is a set of mechanisms for allocating limited resources according to defined policies. A complete QoS design typically includes:

1. Classification: identifying traffic by interface, address, port, application, identity, or deep metadata.
2. Marking: writing a class indicator, such as an IP differentiated-services code point (DSCP) or an Ethernet priority value.
3. Queuing and scheduling: deciding which packets are transmitted next.
4. Policing: enforcing a rate by dropping or remarking excess traffic.
5. Shaping: buffering traffic to smooth its rate.
6. Admission control: refusing new flows when resources are insufficient.
7. Measurement and verification: checking whether objectives are met.

Classification should be as close as possible to the trusted source of policy. A device should not blindly trust markings received from an untrusted network. At administrative boundaries, markings may be rewritten into a locally meaningful scheme.

6.1 Service classes

A practical design often defines a small number of classes rather than one queue per application. For example:

Priority should be bounded. An unlimited strict-priority queue can starve other classes. Real-time traffic should also be admitted and rate-limited; otherwise, the priority mechanism merely converts congestion for one class into starvation for another.

6.2 Queuing and scheduling

First-in, first-out queuing is simple but cannot distinguish traffic classes. Strict priority always serves the highest-priority nonempty queue, which minimizes delay for that class but risks starvation. Weighted fair queuing and its variants allocate service according to weights. Deficit-based algorithms handle variable packet sizes more fairly by tracking service deficits.

A queue becomes unstable when its long-term arrival rate exceeds its service rate. In a simplified single-server model, let λ be the average arrival rate and μ the service rate, both in packets per second. Stability requires:

This is a long-term condition, not a guarantee against finite bursts. As utilization approaches 100%, queueing delay can increase sharply, so operating links below nominal capacity is often necessary for predictable service.

6.3 Policing and shaping

A token-bucket model describes a rate policy. Tokens accumulate at rate r up to a bucket capacity B. Sending a packet of L bytes consumes L tokens. The bucket permits bursts up to approximately B bytes, followed by a sustainable average rate near r, assuming the implementation and units are defined consistently.

A policer usually discards or remarks traffic that lacks sufficient tokens. A shaper delays excess traffic until tokens become available. Policing protects a downstream resource but may cause loss; shaping reduces burstiness but requires memory and adds delay. Shaping is normally applied near the traffic source, where buffering can be controlled.

7. Service-Level Requirements and Measurement

Service-level requirements should be stated as measurable objectives rather than vague claims such as “high quality.” Examples include:

• median and 95th-percentile transaction latency;
• one-way delay for voice or control traffic;
• packet-loss rate over a specified interval;
• jitter according to a named measurement definition;
• availability over a monthly period;
• minimum throughput under a stated load;
• maximum recovery time after a link or device failure.

A service-level objective (SLO) is an operational target. A service-level agreement (SLA) is a formal commitment that may include remedies. Measurements must specify vantage points, sampling method, packet size, time window, and whether results represent a user, a site, or a synthetic probe.

The percentage of successful availability can be calculated as:

The terms must be defined contractually, including exclusions, planned maintenance, and measurement authority. A high availability percentage does not prove good application performance if latency or loss is unacceptable.

8. Illustrative Case: Voice and Data in a University Network

Background

A university operates voice over IP, interactive learning platforms, cloud backups, video lectures, and ordinary web traffic across a 1 Gb/s campus uplink. Users report choppy calls and slow web responses during evening backup jobs.

Problem

The uplink average utilization is only 65%, but five-minute samples hide bursts approaching line rate. Voice packets experience queueing delay and occasional loss. Backup traffic uses TCP and expands its congestion window whenever capacity becomes available.

Analysis

The engineering team measures one-way delay, jitter, loss, queue occupancy, application markings, and traffic by class. Voice packets are small and periodic, but they share a FIFO queue with large backup packets. The issue is therefore not simply insufficient average bandwidth; it is unmanaged competition and burst-induced queueing.

Approach and solution

The team classifies authenticated voice traffic at access switches and marks it with the organization’s real-time class. Trust boundaries are configured so that user devices cannot arbitrarily claim priority. Access and uplink switches use a bounded priority queue for voice, weighted service for interactive learning traffic, and a lower-weight class for backups. Backup traffic is shaped below the uplink rate during teaching hours. Admission control limits the number of simultaneous voice sessions according to measured capacity.

Monitoring is configured for call-quality indicators, queue drops, one-way delay, and 95th-percentile latency. The policy is tested during a simulated backup burst and during an uplink failure.

Outcome

Voice loss and jitter fall substantially, while backup completion time increases modestly during teaching hours. Web performance improves because large backup bursts no longer monopolize the queue. During a failure test, the team discovers that the alternate path lacks the same class mappings; this is corrected before production deployment.

Learning points

The case illustrates that QoS is a coordinated system, not merely a priority bit. Classification, trust, marking, scheduling, shaping, capacity, and measurement must be consistent end to end. It also demonstrates why percentile and burst measurements are more informative than average utilization alone.

9. Challenges, Governance, and Contemporary Developments

QoS policies can create unfairness if they privilege one department, customer, or application without transparent justification. Classification may expose sensitive metadata, and traffic inspection can raise privacy concerns. Governance should define who may request priority, how exceptions are approved, how markings are audited, and how policy effectiveness is reviewed.

Encryption reduces visibility into application identity. QUIC and encrypted DNS encourage operators to use endpoint cooperation, authenticated policy, flow statistics, and performance telemetry rather than indiscriminate payload inspection. Artificial intelligence can assist anomaly detection, traffic forecasting, and capacity planning, but models require reliable data and must not silently change priority policy without human oversight. False positives can degrade critical services, while biased training data can underrepresent unusual but legitimate traffic.

Contemporary networks increasingly use programmable data planes, software-defined traffic engineering, explicit congestion signals such as ECN, active queue management, and multipath transports. These technologies improve responsiveness but add operational complexity. New mechanisms should be introduced with controlled experiments, rollback plans, interoperability testing, and clear measurements.

Best-Practice Design Principles

1. Begin with application requirements, not device features.
2. Separate reliability, congestion control, and QoS responsibilities.
3. Measure delay, jitter, loss, throughput, bursts, and percentiles.
4. Keep the number of traffic classes small and operationally meaningful.
5. Establish trust boundaries for markings.
6. Bound priority queues and protect lower classes from starvation.
7. Shape near the source and police at administrative boundaries when appropriate.
8. Test normal operation, bursts, failures, and encrypted traffic.
9. Align technical targets with explicit SLOs and SLAs.
10. Reassess policies as applications, paths, and traffic patterns change.

Chapter Summary

TCP provides a reliable, ordered byte stream using acknowledgements, retransmission, flow control, and congestion control. UDP provides minimal datagram transport and leaves reliability and rate control to applications. QUIC combines secure transport, congestion control, stream multiplexing, and path flexibility while remaining UDP-based.

Network performance depends on throughput, delay, queueing, propagation, jitter, loss, and application behavior. The bandwidth–delay product helps estimate the amount of data needed to keep a path busy, but it does not guarantee throughput. Traffic engineering uses measurement, routing, capacity, and policy to place traffic effectively. Multicast can reduce replication for large audiences but introduces significant operational and security challenges.

QoS is a coordinated process involving classification, marking, scheduling, policing, shaping, admission control, and verification. Priority must be bounded, markings must be trusted appropriately, and service objectives must be stated using measurable metrics. Effective designs consider ethics, privacy, encryption, resilience, and changing application behavior.

Key Terms

Transport layer: Layer that provides end-to-end services to applications.

TCP: Reliable, ordered, connection-oriented byte-stream protocol.

UDP: Connectionless datagram protocol with minimal transport functions.

QUIC: Secure, congestion-controlled transport built over UDP.

RTT: Round-trip time between a sender and corresponding response.

Jitter: Variation in packet arrival or delay, according to a stated definition.

Congestion window: Sender estimate of data that may safely be in flight.

Receive window: Receiver-advertised limit for outstanding data.

Flow control: Protection of a receiver from sender overload.

Congestion control: Protection of a shared network from excessive offered load.

Bandwidth–delay product: Link capacity multiplied by round-trip or specified path delay.

Traffic engineering: Optimization of routing and capacity for performance and resilience.

Multicast: One-to-many delivery using shared distribution trees.

QoS: Policies and mechanisms for differentiated resource treatment.

Classification: Identification of packets or flows into policy classes.

Marking: Encoding a class indicator in a packet or frame.

Policing: Enforcing a rate by dropping or remarking excess traffic.

Shaping: Delaying traffic to smooth its transmission rate.

SLO: Measurable operational service target.

SLA: Formal service commitment between parties.

Review Questions

Short Answer Questions

1. Why does TCP not preserve application message boundaries?
2. Distinguish flow control from congestion control.
3. What is the purpose of a QUIC stream?
4. Why can average link utilization conceal a QoS problem?
5. State one difference between policing and shaping.

Long Answer Questions

1. Explain TCP connection establishment, reliability, flow control, and congestion control.
2. Compare TCP, UDP, and QUIC for a cloud-based interactive application.
3. Explain the components of end-to-end delay and their operational significance.
4. Describe a complete QoS workflow from classification through verification.
5. Analyze the benefits and limitations of multicast in a large organization.

Analytical / Application Questions

1. A 500 Mb/s path has an RTT of 80 ms. Calculate its bandwidth–delay product and explain why receiver windows and congestion control matter.
2. Design traffic classes and queueing policies for voice, interactive learning, backups, and ordinary web traffic on a constrained campus link. Justify trust boundaries and starvation protections.
3. A network reports low average utilization but poor video-conference quality. Propose a measurement and diagnosis plan that distinguishes delay, jitter, loss, burstiness, endpoint behavior, and path-specific faults.

Multiple Choice Questions with Answers

Question 1

Which statement best describes TCP?

A. It provides an unreliable datagram service without congestion control.

B. It provides a reliable, ordered byte stream with flow and congestion control.

C. It provides encrypted multiplexed streams without acknowledgements.

D. It preserves every application write as a separate message.

Correct Answer: B. It provides a reliable, ordered byte stream with flow and congestion control.

Question 2

A 1 Gb/s path has an RTT of 40 ms. What is its approximate bandwidth–delay product?

A. 5 MB

B. 40 MB

C. 400 MB

D. 0.5 MB

Correct Answer: A. 5 MB

Question 3

What is the principal risk of an unbounded strict-priority queue?

A. It prevents packet classification.

B. It disables congestion control.

C. It can starve lower-priority traffic.

D. It guarantees excessive propagation delay.

Correct Answer: C. It can starve lower-priority traffic.

Question 4

Which transport protocol integrates TLS-based security and multiplexed streams while operating over UDP?

A. TCP

B. IP

C. UDP

D. QUIC

Correct Answer: D. QUIC

Question 5

What does traffic shaping generally do with traffic exceeding the configured rate?

A. It buffers and delays the excess when resources are available.

B. It always encrypts the excess traffic.

C. It immediately routes the excess through multicast.

D. It changes every packet into a TCP segment.

Correct Answer: A. It buffers and delays the excess when resources are available.

Question 6

Which metric describes variation in packet arrival timing?

A. Throughput

B. Jitter

C. MSS

D. Availability

Correct Answer: B. Jitter

Question 7

What is the main purpose of congestion control?

A. To identify application ports.

B. To preserve application message boundaries.

C. To protect shared network resources from excessive load.

D. To eliminate all propagation delay.

Correct Answer: C. To protect shared network resources from excessive load.

Question 8

Which QoS function identifies packets as belonging to a policy class?

A. Classification

B. Propagation

C. Retransmission

D. Fragmentation

Correct Answer: A. Classification

Question 9

A shaper differs from a policer because a shaper normally:

A. Drops all packets immediately.

B. Buffers excess traffic to smooth its rate.

C. Removes the IP header.

D. Guarantees zero packet loss end to end.

Correct Answer: B. Buffers excess traffic to smooth its rate.

Question 10

Why is multicast potentially efficient for a large synchronized audience?

A. It sends a separate complete copy over every shared link.

B. It eliminates the need for receiver management.

C. It can replicate traffic at branching points rather than at the source for every receiver.

D. It guarantees encryption for every group member.

Correct Answer: C. It can replicate traffic at branching points rather than at the source for every receiver.