Summary

  • RFC 2187 defined parent and sibling caches primarily by what they were permitted to do after a miss: a parent could retrieve an uncached object, whereas a sibling was limited to supplying objects it already held.
  • The relationship was configured locally rather than encoded in ICP. A single neighbour could therefore be treated as a parent for some requests and a sibling for others, with domain, method, cacheability and access-control rules changing the effective hierarchy.
  • ICP HIT and MISS replies were evidence for a local selection decision, not proof of reciprocal authority, freshness, authenticated identity, optimal delivery, future capacity or eventual success.
  • Later cache documents sharpened the distinction between protocol semantics and deployment policy, while also showing that latency-sensitive peer selection could conflict with bandwidth and role suitability.

The deceptive part of the vocabulary in RFC 2187 is its apparent geometry. A parent sounds upstream. A sibling sounds lateral. It is tempting to imagine a stable topology in which one label captures both network position and operational responsibility.

That is not the useful reading.

Published in September 1997 by D. Wessels and K. Claffy as an Informational RFC, as recorded in the RFC Editor’s RFC 2187 entry, the document described a Web cache hierarchy in which the decisive distinction concerned handling a miss. A parent could retrieve an object whether or not the object was already cached. A sibling, by contrast, was supposed to supply only an object it already possessed. If the sibling did not have the requested object, it was not the cache through which the requester should continue toward the origin.

That is an authority boundary, not a statement of physical distance.

The distinction matters because both roles could look similar when the answer was a hit. If either neighbour reported that it held an object, the requesting cache could potentially fetch it there. The roles diverged when there was no cached copy. A parent could still act as transit. A sibling could not.

This also meant that role was not necessarily a permanent property of the remote machine. RFC 2187 allowed the same neighbour to be treated as a sibling for one class of requests and as a parent for another. A deployment could restrict a parent relationship to particular domains. It could forward only requests considered cacheable. Local destinations, other request classes, non-GET requests or URLs on a stop list could avoid the hierarchy or avoid ICP processing altogether.

The practical hierarchy therefore emerged from policy applied to individual requests. The labels summarized a permitted behaviour; they did not independently establish it.

A relationship had to exist on both sides

A configured peer relationship also depended on two different administrative decisions.

The requesting cache had to decide how it would classify and use the neighbour. The remote cache had to impose access controls consistent with that intended role. If the remote side allowed HTTP and ICP access in a way that also permitted miss forwarding, the operational result amounted to parent behaviour. To enforce a sibling relationship, the remote side needed a deny-miss policy so that a request arriving after an erroneous or stale assumption of a hit would not quietly become transit.

Communication between administrators was therefore part of making the relationship meaningful. A local label alone could not guarantee that the other cache applied corresponding restrictions.

That detail is easy to lose if parent and sibling are treated as facts discovered from the network. They were not carried as relationship declarations inside ICP messages. The protocol could report information about an object query, but the requester still had to interpret the reply through its own knowledge of the neighbour.

The neighbouring cache’s role came from configuration and access policy.

ICP supplied a signal, not the relationship

The companion RFC 2186 described ICPv2’s message format and opcodes. RFC 2187 addressed a different problem: how caches could use ICP within a hierarchy.

That separation is important. An ICP HIT from a neighbour did not say, “I am your sibling under these contractual permissions,” any more than a MISS said, “I am authorized to carry this request onward.” The message did not encode the relationship. The requesting cache had to combine the signal with its configured role information.

A HIT from a sibling was useful because the sibling was allowed to provide a cached copy. A MISS from that same sibling generally removed it from consideration because the sibling was not supposed to provide miss transit. A MISS from a parent could have the opposite significance: the parent might not currently hold the object, but it was still permitted to retrieve it.

The same protocol result could therefore lead to different next actions depending on the configured relationship.

This also explains why some requests bypassed ICP. A local cache hit required no neighbour search. A configured local origin could be selected directly. Non-GET requests and stop-listed URLs could be treated outside the ICP decision path. With only one usable parent, a cache might simply forward the request rather than spend time waiting for an ICP exchange whose result would not materially change the next-hop choice.

The protocol was an input to policy, not a mandatory ceremony before every request.

The no-cache case exposed the sibling boundary

RFC 2187’s treatment of Pragma: no-cache makes the authority distinction unusually clear.

A request carrying that directive could not safely be sent through the ordinary sibling-query logic. The point of using a sibling was that a confirmed cached object might be retrieved there without granting the sibling responsibility for an uncached request. But a no-cache request called for behaviour that could require going beyond the sibling’s stored copy. Querying a sibling in that case would create a path toward the very transit behaviour the role was intended to prohibit.

So the hierarchy could not be reduced to “ask nearby caches first.” Whether a neighbour was even eligible for consultation depended on what kind of handling the request required.

That is the more durable lesson of RFC 2187: resource discovery was constrained by authority.

Choosing among eligible sources was a separate problem

Even after policy narrowed the eligible neighbours, a cache still had to choose among them.

RFC 2187 discussed several inputs. Reply delay could influence peer selection. Implementations could retain source round-trip-time information. Administrators could apply configured weights. Multicast replies could arrive in an order that affected selection.

None of those measurements was a proof of the future delivery path.

A quick ICP response did not establish that the subsequent object transfer would have the best throughput. A stored RTT was evidence about prior communication, not a guarantee about the next transfer. A configured weight represented operator preference rather than an observed property of the current request. Multicast ordering could expose timing, but timing was not equivalent to capacity, congestion state or end-to-end completion.

RFC 2187 itself recorded an ambiguity between two objectives: locating an object and selecting or load-balancing among peers. Those tasks overlap, but they are not identical. A protocol that helps discover who says they have an object is not automatically a complete optimizer for choosing the best source.

That limitation became more explicit in RFC 3143. Its discussion of known HTTP proxy and caching problems observed that first-response selection could favor low latency even when another peer offered more useful bandwidth. It also noted that the characteristics making a high-bandwidth cache attractive as a parent did not necessarily make it equally suitable as a sibling.

This is another reason not to read the family labels as topology. The useful peer depends on both permission and performance, and those dimensions can point in different directions.

A HIT was not a broad trust statement

The bounded meaning of ICP matters most when considering what a reply did not establish.

A HIT indicated that the answering cache claimed an object was present under the relevant protocol conditions. It did not prove that the cache was an authenticated identity. It did not establish that the object was safe. It did not establish that the response would satisfy every freshness requirement. It did not promise that transfer would complete. It did not establish reciprocal policy, spare future capacity, the cheapest path or a favorable business result.

Those are separate questions.

RFC 2187 also identified concrete ways bad information could distort the selection process. A forged reply could force or prevent selection of a neighbour. Manipulated RTT information could similarly skew a choice. A false HIT was especially awkward when the supposed source was a sibling: the requester could send the HTTP request there on the assumption that the object existed, only for the sibling to refuse the resulting miss because its policy correctly prohibited transit.

In that failure, neither the sibling role nor the deny-miss policy is contradictory. The failure lies in treating an inaccurate selection signal as if it guaranteed the resource state.

Protocol semantics and application policy stayed distinct

The later RFC 3040, which described Internet Web replication and caching terminology, reinforces the need to distinguish ICP’s semantics from application policy. A wire-level indication is not a complete statement about how an operator must structure forwarding, authorization or fallback.

RFC 2187 had already embodied that separation operationally. Administrators decided which neighbours were parents, which were siblings, which request classes used them, which domains a parent could serve, what access controls applied, how long to wait, whether multicast was useful, how firewalls affected communication and what happened when the preferred decision path failed.

The protocol supplied evidence inside that decision system.

This is also why RFC 9211 belongs to a different evidentiary stage. Its delivery observability mechanisms concern information about cache handling after or during delivery. RFC 2187’s problem was choosing how a request should move through a cache hierarchy. Evidence produced at one stage should not be promoted into proof about another.

That distinction prevents a historical mechanism from being stretched beyond what it actually established. RFC 2187 does not support claims about present-day CDN economics, nor does it turn generic HTTP cache-control rules into evidence of a particular hierarchy relationship. Its more precise contribution is narrower: it shows how a distributed cache system could combine configured authority with lightweight network evidence while keeping the two conceptually separate.

That narrowness is exactly what makes the document useful.

The parent/sibling language described what a neighbour was permitted to do when a request could not be answered from cache. ICP helped estimate where an object might be and, in some implementations, which eligible source looked preferable. Neither layer replaced the other. Policy determined the valid choices; protocol signals helped discriminate within them; later HTTP behaviour determined whether the chosen path actually delivered what the requester needed.

The hierarchy was therefore not a map waiting to be discovered. It was an operating arrangement that had to be configured, enforced and interpreted.