Skip to main content

13. Fairness

Typically, HTTP implementations depend on the underlying transport to maintain fairness across connections competing for bandwidth. When an intermediary receives HTTP requests on a client connection, it forwards them to backend connections. Depending on how the intermediary coalesces or splits requests across different backend connections, different clients can experience different performance. This variance can be amplified if the intermediary also uses priority signals when forwarding requests. Sections 13.1 and 13.2 discuss mitigations for this amplification of unfairness.

Conversely, Section 13.3 discusses how a server can intentionally allocate unequal bandwidth to certain connections based on priority signals.

13.1. Coalescing Intermediaries​

When an intermediary coalesces HTTP requests from multiple clients into one HTTP/2 or HTTP/3 connection to a backend server, requests that originate from one client might carry signals indicating a higher priority than requests from other clients.

It is sometimes beneficial for servers running behind intermediaries to obey Priority header field values. For example, a resource-constrained server might defer the transmission of software update files with a background urgency level (7). However, in the worst case, asymmetry among the priorities declared by multiple clients might cause all responses bound for one user agent to be delayed until all responses bound for another user agent have been sent in their entirety.

To mitigate this fairness problem, servers can use knowledge about intermediaries as another input into their prioritization decisions. For example, if a server knows that the intermediary is coalescing requests, then it can avoid serving responses in their entirety and instead allocate bandwidth (for example, in a round-robin manner). This can work if the constrained resource is the network capacity between the intermediary and the user agents, as the intermediary buffers responses and forwards chunks according to the prioritization scheme it implements.

A server can determine that a request came from an intermediary by configuration, or it can check if the request includes one of the following header fields:

  • Forwarded [FORWARDED], X-Forwarded-For

  • Via (see Section 7.6.3 of [HTTP])

13.2. HTTP/1.x Back Ends​

It is common for Content Delivery Network (CDN) infrastructure to support different HTTP versions on the front end and back end. For example, a client-facing edge might support HTTP/2 and HTTP/3 while communication to backend servers is done using HTTP/1.1. Unlike connection coalescing, a CDN "demultiplexes" requests to discrete connections to backends. HTTP/1.1 (or earlier) does not support response multiplexing within a single connection, so there is no fairness issue. However, backend servers MAY still use client headers for request scheduling. Backend servers SHOULD schedule based on client priority information only when that information can be scoped to a single end client. Authentication and other session information might provide this linkability.

13.3. Intentional Introduction of Unfairness​

It is sometimes beneficial to deprioritize the transmission of one connection relative to others, knowing that doing so introduces a degree of unfairness between connections and, therefore, among the requests served on those connections.

For example, a server might use a scavenger congestion controller on connections that carry only responses of background priority (e.g., software update images). Doing so improves the responsiveness of other connections at the cost of delaying the delivery of updates.

Last updated on