Summary

  • XCP placed a signed change in throughput inside each packet. Every participating router could reduce it, so the value returned by the receiver represented the tightest allocation encountered on that path for that control loop.
  • That feedback changed a sender's permitted rate; it did not reserve capacity, certify achieved throughput or prove deployment. The distinction between request, allocation and outcome is the enduring lesson of Dina Katabi's design.

Suppose a sender is moving 100 units of traffic and wants to add twenty. It distributes that desired increase across the packets expected during one round trip. A packet enters the network carrying its small share of the request. One router could support it. A more constrained router can support only half. That router overwrites the field, and no later router may restore the larger wish.

At the receiver, the number has become a report from the narrowest point on the forward path. The receiver copies it into returning traffic. One round trip after making the request, the sender can change its congestion window or sending rate by the amount the network left intact.

This was the core feedback loop of XCP, the eXplicit Control Protocol developed in the 2002 SIGCOMM paper by Dina Katabi, Mark Handley and Charlie Rohrs. The paper addressed a problem the authors expected to worsen as links became faster and paths retained long delays: TCP's familiar increase-and-loss response could become slow, oscillatory and queue-heavy when the bandwidth-delay product grew large.

XCP's answer was not merely to add more bits to a congestion mark. It made the packet a temporary carrier of control state and divided the router's job into two calculations. That architecture later earned the paper an ACM SIGCOMM Test of Time award. Its historical importance, however, should not be confused with universal deployment. XCP remained an experimental research protocol whose most complete Internet-Draft expired in 2008.

The path edits a request into a bottleneck result

The last XCP draft described four congestion-header quantities relevant to the loop. The sender reported an RTT estimate and X, an estimate of inter-packet time. It put the desired or already allocated change in throughput into Delta_Throughput. A receiver returned the arriving value in Reverse_Feedback.

The delta was signed. A positive value allowed the sender to increase; a negative one told it to slow. It was expressed as a change in bytes per second, not as the flow's final rate. A value of plus five therefore did not mean “this flow owns five units of capacity.” It meant that, under the current calculation, the sender should adjust its rate by five units relative to where it was.

That relative meaning matters. A sender might ask to reach an application target, but it had to spread the requested change over the packets it expected to send in one RTT. Each router compared the packet's field with its own per-packet allocation. If the request exceeded the router's result, the router reduced the field. If the request was already smaller, the router left it alone while updating its aggregate feedback pools.

The receiver consequently saw the minimum allocation across the participating routers. The draft called it the bottleneck allocation: the result from the queue that could not accommodate the flow's current or desired throughput. Returning that value closed the loop. The sender, not the router, performed the final change to the congestion window or permitted rate.

Calling the value an allocation was legitimate inside the algorithm. Treating it as a grant with contractual persistence would not be. The feedback belonged to one path observation and one control interval. Traffic could change, routes could move, another queue could become tight, or the application could fail to use the allowed window. The header did not record delivery, reserve future capacity or promise that the same number would survive the next RTT.

Efficiency and fairness were separate arguments

Conventional congestion control often used one rule to pursue both high utilization and fair sharing. Katabi and her coauthors separated those aims. An efficiency controller estimated spare bandwidth and persistent queue at an output link. It decided how much aggregate positive or negative feedback the link should issue so that the pipe remained useful without maintaining a standing queue.

A fairness controller decided how to distribute that aggregate adjustment among packets and therefore among flows. In the paper's design, positive feedback was allocated so flows could converge toward equal shares, while negative feedback was related to the bandwidth a flow was using. The division made it possible to analyse stability without pretending that a fair allocation rule and a queue-control rule were the same problem.

This separation also exposes why one number cannot summarize the whole decision. A positive delta is the product of a utilization judgment and a distribution rule. Change the fairness objective—perhaps to weighted service—and the same link state can produce different per-flow feedback. Change the efficiency controller and the aggregate pool can change while the fairness rule stays intact.

For operators, the provenance of the number is therefore as important as its magnitude. Which output port calculated it? Over what average RTT? Under which controller parameters and fairness policy? Was this router actually the limiting point, or did an earlier router already write a smaller value? A telemetry system that records only the returned delta loses the chain of authority that made the value meaningful.

No per-flow table did not mean no state

One attraction of XCP was that a router could calculate flow-sensitive feedback without keeping a congestion record for every flow. The packet carried the sender's RTT and rate-related evidence. The router used those fields to apportion aggregate feedback and handled each departing packet independently. This avoided the scaling and churn of a flow table in the core.

But “no per-flow state” is easily inflated into “stateless networking.” XCP routers still measured arrival traffic and queue state, estimated an average RTT, ran a control interval, kept efficiency and fairness parameters, and accounted for remaining positive and negative feedback pools. The state moved up a level: from durable entries keyed by flow to aggregate state attached to an output queue, combined with claims travelling in packets.

That bargain creates a different trust boundary. A router that does not keep a per-flow record must rely on the sender's reported throughput or inter-packet estimate and RTT. It must also rely on the sender to obey the returned feedback. The original work assumed mostly cooperative endpoints and mentioned policing at network edges. Katabi's follow-on study of malicious flows made the assumption visible by separating senders that lied about header values from senders that ignored or only partly followed feedback.

The results were not a single “XCP is insecure” verdict. False throughput reports chiefly harmed fairness in the reported experiments; large RTT lies could damage efficiency when widely adopted; an unresponsive flow and a strategically under-reacting flow had different effects. The important point is evidentiary: a header supplied by an endpoint is an input to a control law, not independent proof that the endpoint is truthful.

The specification also exposed mundane engineering limits. Its fixed-point fields bounded the representable RTT and rate change. Per-packet rounding errors could accumulate over a control interval. A value might round to zero even when a small fractional adjustment was intended. These were not defects to hide behind a clean diagram; they were part of what an experimental specification needed to test.

A celebrated paper was not a deployment receipt

The original paper offered control-theory analysis and extensive packet-level simulations. Its results showed XCP filling high-bandwidth, long-delay links with small queues and stable behaviour under the tested conditions. The protocol could coexist with TCP through boundary mechanisms discussed in the paper, and later work built implementations and tutorials.

The 2007 Internet-Draft was more cautious than a retrospective summary sometimes becomes. It said XCP was not ready for wide-scale deployment on the public Internet. Routers as well as endpoints had to change. The pure model assumed participation by every queue that might become the bottleneck, an unlikely condition across an arbitrary path. Interoperation with non-XCP congestion control and non-participating queues remained open work.

Those qualifications do not diminish the design. They locate its achievement. XCP showed how explicit, multi-bit feedback could separate utilization control from fairness and calculate a bottleneck response without a per-flow table. Later congestion-control research could borrow, challenge or refine those ideas even if the exact header never became a universal wire format.

The Test of Time award records intellectual influence, not install base. An expired draft records a serious experimental protocol, not an Internet standard. Simulation graphs record behaviour in specified models, not a promise for every topology or adversarial endpoint. Keeping those categories separate makes the history stronger because it preserves what the evidence can actually bear.

The durable artifact is a chain of edits

XCP's feedback field is best read as a small audit trail compressed into one number. The sender establishes the upper bound by stating the change it wants. Every participating router receives authority only to leave that request intact or make it more restrictive. The receiver reflects the surviving result. The sender acts on it.

The compression has a cost: the final field does not identify which router changed it or preserve the discarded values. For diagnosis, a modern experiment would need supplementary observations—path identity, controller configuration, queue measurements, returned deltas and achieved sending rates—to reconstruct why a flow changed. A single packet shows the decision outcome but not its full provenance.

That is precisely why it was not a bandwidth certificate. A certificate would name an issuer, a subject, a quantity, a validity period and conditions of use. XCP's delta named none of those in durable form. Its authority came from the live cooperation of routers and endpoints, and it expired into the next control loop.

Katabi's design offers a general rule for network evidence: ask who was allowed to modify a field, which earlier claims were erased, and which action the remaining value authorized. Only then decide whether the number is a request, an allocation, an observation or a guarantee. XCP made that distinction visible one packet at a time.

Sources