Summary

  • Plutarch did not propose abolishing the Internet. It retained the globally routed IPv4 Internet unchanged as one context while allowing other naming, addressing, routing and transport regimes to coexist above, below, beside or at its borders.
  • A context gave names and communication rules local meaning. Crossing contexts required an interstitial function to rebind or translate that meaning; reachability alone could not prove that the translation preserved identity, policy or service semantics.
  • The paper was a research starting point, not a completed deployment. Security, auditing, capability management, scalable discovery, failure notification and chain-selection policy remained open, making the boundary receipt more important than the architectural slogan.

The centre of the diagram became a participant

In an ordinary Internet diagram, specialised networks appear as awkward edges. A sensor network, a mobile carrier, an overlay or a private LAN must somehow present itself in terms the IP centre already understands. The centre supplies the address model and the packet semantics; everything else adapts.

Plutarch reversed the status relationship without pretending that the Internet had failed. Its authors began by crediting a strongly specified protocol suite and minimal in-network mechanisms with simplicity, robustness and extraordinary growth. Their objection was not that IP had been a mistake. It was that the success of one homogeneous waist had become the only accepted frame for imagining interconnection.

The paper therefore described the globally routable Internet as a context. Inside it, mechanisms could remain unchanged. A sensor network could be another context, an IPv6 network another, a resilient overlay another, and a private link network another. Some could sit above IP, some alongside it, some beneath it. The Internet was not destroyed or demoted operationally. It was demoted conceptually from the universal definition of networking to one powerful member of a plural system.

That distinction matters. “One context among many” is not a prediction that IP would disappear. It is a rule against treating every non-IP system as a defective edge waiting to be normalised.

A context was a boundary of meaning

Crowcroft and his co-authors did not define a context merely as a subnet or an administrative territory. A context was a region homogeneous in some relevant regard and, more abstractly, a set of bindings within which names could be resolved. The shared property might be an address format, a packet representation, a transport protocol, a naming service, a link technology or an administrative scope.

That makes a name incomplete without its context. An IP address, an Ethernet address, a user name or a sensor identifier is not assumed to carry one universal referent everywhere. A name that crosses a border must be rebound in the destination context. The destination needs a rule for saying what the foreign identifier refers to here.

The architecture consequently had no single global root context. Contexts could be disjoint, identical or nested. An endpoint could belong to several contexts at once—for example through different interfaces or roles—and membership could change. The local Ethernet context could sit inside an IP LAN context, which could in turn sit inside the wider Internet context.

This was pluralism with structure, not an invitation to arbitrary labels. Local meaning survived because the transition between regimes was explicit.

The interstitial function carried the missing receipt

The paper called that transition mechanism an interstitial function, or IF. Logically, an IF presented one interface to each of two adjoining contexts and contained the mechanism that translated data from one into the other. The examples ranged from familiar NAT boxes, signalling gateways and BGP routers to more ambitious translators that might bridge dissimilar transports, transcode video or add forward-error correction for an unreliable link.

The authors organised the mapping problem into four broad areas. Addressing required a binding between address regimes. Naming required movement between plural name systems rather than automatic dependence on one global hierarchy. Routing required more than dumping the churn of one protocol into another; an on-demand wireless network and an OSPF/BGP domain did not describe reachability in the same way. Transport required deciding where network-specific optimisation was appropriate rather than demanding that one transport behave optimally everywhere.

An IF was therefore not just a pipe. It could change representation, timing, state, error treatment and even the service offered. Its receipt would have to answer: which object entered, which object emerged, what equivalence rule connected them, what state was retained, which authority permitted the mapping and which properties could no longer be promised.

Without that record, “the packet got through” proves too little. A reachable name may refer to a different principal. A route may suppress volatility that matters to the sender. A proxy may terminate one transport and begin another. A transcoder may preserve intelligibility while changing fidelity. The border is where pluralism becomes either accountable composition or invisible substitution.

Chains let an endpoint choose how much to know

Interstitial functions could be assembled into a chain of contexts. A laptop on a GPRS network might reach a sensor network through an opaque mobile gateway, the IPv4 Internet and a sensor gateway. The chain could itself be abstracted as a context.

That abstraction served two kinds of endpoint. An uninterested application might want only evidence that its peer was reachable. A more demanding application might ask for several possible context chains and choose according to the service it needed. The paper imagined context-supporting services discovering chains and configuring IFs, with names and properties travelling through distributed lookup.

Choice did not erase dependence. If a chain failed, the endpoint might ask to be notified or permit automatic repair. If it accepted an abstracted chain, it also accepted that intermediate detail could be hidden. A different chain might reach the same apparent name through translators with different security, delay, loss or administrative control.

The useful evidence object was thus not a path of IP hops. It was a sequence of contexts, translators, bindings and capabilities, together with the policy that selected them.

Incremental deployment was the political engineering

Many future-Internet proposals stumble on the moment when everyone must move. Plutarch avoided that ceremony. The existing IPv4 Internet could remain exactly where it was. New contexts could be deployed incrementally and use the Internet for support or transit without asking it to adopt their internal semantics.

This was not merely a technical convenience. It changed who had to agree. A sensor-network operator could define a constrained local regime. An application could choose a chain that met its needs. A boundary operator could install an IF. The whole Internet did not need to ratify one new packet format before an experiment could run.

The paper even contemplated several management systems—“Plutarchies”—under distinct administrations, joined through appropriate IFs. That preserved the idea that interconnection did not require a single global manager. It also created a harder question: which management system issued the capability to inspect or configure a translator, and how could another administration verify it?

Incremental adoption reduced the coordination threshold. It did not remove authority; it moved authority into smaller, more numerous decisions.

The proposal left its own proof obligations visible

Plutarch is strongest where it refuses to look finished. The paper says its immediate concern is inter-networking, not resource allocation, timeliness, guarantees, security or auditing. Those would have to be addressed within the contexts being connected. Capability management was not specified. The interfaces were strawmen, and the authors reported no performance results.

The future-work list was substantial: scalable routing between contexts, IF discovery, failure notification, policy for choosing a context chain, programmer-facing APIs, transport adaptation and scalable name lookup. The paper expected only a manageable number of context types and short chains in common cases, but that was an architectural expectation, not an observed production distribution.

These omissions are not footnotes to be repaired by confident prose. They locate the boundary of the result. Plutarch supplied a vocabulary and composition model. It did not prove that arbitrary translators would be safe, that discovery would resist capture, that a chain would preserve application meaning, or that plural management systems would converge on compatible policy.

Crowcroft’s role belongs inside a five-author argument

Jon Crowcroft’s career has spanned Internet protocols, distributed systems and network architecture; Cambridge now identifies him as its Marconi Professor of Communications Systems. Plutarch fits that breadth because it treats networking less as one packet format than as a problem of composition between systems with different assumptions.

The work must still be attributed precisely. The paper belongs to Crowcroft, Steven Hand, Richard Mortier, Timothy Roscoe and Andrew Warfield. Its ideas drew on naming contexts, late binding, the end-to-end argument and a larger field of future-Internet proposals. Crowcroft should not be turned into the sole inventor of network pluralism, nor Plutarch into the ancestor of every later gateway or multi-network design.

What the paper contributed was a disciplined change of view. Heterogeneity was not residue at the edge of a real network. It was the reality an architecture should expose.

Sources