Summary

  • RFC 3466 named content internetworking as a way for independent content networks to share scale or reach, while treating each neighbor as a possible black box.
  • The memo supplied a model and common terms—not a peering protocol, price list, service authorization or proof that any two networks actually cooperated.

A packet network was no longer the whole story

A viewer asked for one image. The origin might be far away, a nearby cache might not have it, and a single provider might not have enough locations to serve every audience well. In the early 2000s, more of the answer was being placed in infrastructure that inspected application requests and content—not only IP headers.

RFC 3466, published in February 2003, gave that change a name: a content network. Its vocabulary described systems operating across layers four through seven, handling requests and responses for objects that could span many packets. That was not a replacement for Internet routing. It was a different coordination surface above it: which content was available, where a request should go, how copies moved, and how activity could be counted.

The memo also deliberately retired a tempting analogy. “Content peering” and “CDN peering” suggested that content networks might interconnect like IP networks. The group chose “content internetworking” instead. A familiar word can smuggle in expectations about open exchange, reciprocal settlement or protocol behavior. Renaming the problem did not solve it, but it made room to specify what cooperation actually meant.

One delivery, four different jobs

RFC 3466 resisted treating a CDN as one box. It separated four functions. Request-routing steered a user agent toward a suitable surrogate. Distribution moved publisher-controlled content from an origin to surrogates, either in advance or after a request. Delivery was the surrogate’s response to the client. Accounting recorded activity around routing, distribution and delivery—potentially because money, goods or obligations would later move.

Those functions leave different evidence. A redirect or routing decision does not prove that the content arrived. A copy at a surrogate does not prove that a client was sent there. A successful response does not establish which upstream network supplied it. And a log record is not itself an agreed bill. The model’s value was partly that it gave operators nouns for these separate events.

It also separated control. The publisher ultimately controlled the content and its distribution; the origin held its authoritative copy. A surrogate delivered content but was not the origin. A Content Internetworking Gateway could be a point of contact for distribution, request-routing, accounting, or only a subset. Interconnection therefore did not require one network to reveal every internal mechanism to another.

A black box still needs an agreement

The phrase “black box” can sound like a promise of effortless interoperability. RFC 3466 did not make that promise. It defined a negotiated relationship as one whose terms were partly or wholly established outside the content-internetworking protocols. Networks might agree to share resources to gain scale or reach, while keeping internal topology and systems private. But protocol vocabulary could not decide which content could be copied, where it could be delivered, what activity was billable, or who bore the cost of a bad record.

That distinction matters because interconnection joined technical and commercial control. A gateway could expose reachability while an external agreement constrained eligible content, accounting detail or responsibility. Even a technically valid request path was not authorization to serve every object. Nor did a common model guarantee that accounting information was accurate, complete or accepted by both parties. RFC 3466's security section accordingly flagged intended relationships, content integrity and auditable accounting as implementation concerns.

A map before the machinery

The memo was Informational. It offered a model for discussion, not a standards-track wire protocol. Its historical contribution is easy to miss if later CDN infrastructure is projected backward onto it. In 2012, RFC 6707 still framed CDN interconnection as a problem area, organized the work around interfaces such as control, request routing, metadata and logging, and left business arrangements outside its scope. That later document is a dated milestone, not evidence about today’s deployment.

RFC 3466 therefore captured a boundary rather than a finished system. Content networks could be discussed as peers in a broader sense—independent services that might exchange reach—without pretending that a vocabulary automatically produced an open market. Interconnection began with a shared map. The route, the copy, the service permission and the bill still needed their own receipts.

Sources