[e2e] End-to-end is a design guideline, not a rigid rule
dhc2 at dcrocker.net
Thu Dec 1 07:04:04 PST 2005
A posting on Farber's IP list finally prompted me to write some thoughts
that have been wandering around in the back of my mind. I'm interested in
reactions you might have:
"Andrew W. Donoho" wrote:
> The debate about NAT obscures the real issue - that there are legitimate
reasons to assert policies for net access at organizational boundaries. Yes,
we want the internet architecture to be end to end.
This struck me as a particularly useful summary statement about some core
architectural issues at hand: Internet technical discussions tend to lack
good architectural constructs for describing operations, administration and
management (OA&M) boundaries, and we lack robustness in the "end to end"
The issue of OA&M boundaries has long been present in the Internet. Note the
distinction between routing within an Autonomous System and routing between
ASs. To carry this a bit further, note that the original Internet had a
single core (backbone) service, run by BBN. The creation of NSFNet finally
broke this simplistic public routing model and required development of a
routing protocol that supported multiple backbones.
As another example, the email DNS MX record, that one finds over the open
Internet, is also generally viewed as marking this boundary and is often
called a Boundary MTA. However the Internet Mail architecture does not have
the construct explicitly. For a year or so, I have been searching for a
term that marks independent, cohesive operational environments, but haven't
found one that the community likes. Some folks have suggested a derivation
of an old X.400 term: Administrative Management Domain (ADMD).
More generally I think that this issue of boundaries between islands of
cohesive policy -- defining differences in the trust within an island,
versus between islands -- is a key point of enhancement to the Internet
architecture work that we must focus on. I have found “Tussle in
Cyberspace: Defining Tomorrow’s Internet,” (Clark, D., Wroclawski, J.,
Sollins, K., and R. Braden, ACM SIGCOMM, 2002) a particularly cogent
starting point, for this issue.
On the question of the "end to end" construct I believe we suffer from
viewing it simplistically. What I think our community has missed is that it
is a design guideline, not a rigid rule. In fact with a layered
architecture, the construct varies according to the layer. At the IP level,
this is demonstrated two ways. One is the next IP hop, which might go
through many nodes in a layer-2 network, and the other is the
source/destination IP addresses, which might go through multiple IP nodes.
The TCP/IP split is the primary example of end-to-end, but it is deceptive.
TCP is end-to-end but only at the TCP layer. The applications that use TCP
represent points beyond the supposed end-to-end framework.
My own education on this point came from doing EDI over Email. Of course I
always viewed the email author-to-recipient as "end to end" but along comes
EDI that did additional routing at the recipient site. To the EDI world,
the entire email service was merely one hop.
This proved enlightening because the point has come up repeatedly: For
email, user-level re-routing and forwarding are common, but outside the
scope of the generally recognized architecture. I've been working on a
document that is trying to fully describe the current Internet Mail
However it is not clear whether it will reach rough consensus.
My own view is that the email concept of end to end has two versions. One
is between the posting location and the SMTP RCPT-TO (envelope) address and
the other is between the author and the (final) recipient. Failure to deal
with this explicitly in the architecture is proving problematic to such
email enhancements as transit responsibility, such as by SPF or DKIM).
In other words, the Internet technology has never been a pure "end to end"
model. Rather, end to end is a way of distinguishing between components
that compose an infrastructure versus components that use the infrastructure
-- at a particular layer. "End to end" is a way of characterizing a
preference to keep the infrastructure as simple as possible.
This does not mean that we are prohibited from putting anything into the
infrastructure or changing the boundaries of the infrastructure, merely that
we prefer to keep the it unchanged. In this light, NATs (and firewalls) are
merely a clear demonstration of market demand for some facilities that make
end to end layered with respect to some operational policies, to permit the
addition of a trust boundary between intra-network operations and
We should not be surprised by this additional requirement nor should we
resist it. The primary Internet lesson is about scaling, and this appears
to be a rather straightforward example of scaling among very large numbers
of independent and diverse operational groups. Growth like this always
comes with vast cultural diversity. That means that the basis for trust
among the independent groups is more fragile. It needs much more careful
definition and enforcement than was required in the kinder and gentler days
of a smaller Internet.
More information about the end2end-interest