[e2e] End-to-end is a design guideline, not a rigid rule

[David P. Reed]

[oops, Dave C. pointed out that I replied only to him, instead of only 
to e2ei, and encouraged me to send it to the whole list]

The end-to-end argument was indeed a design guideline not a rigid rule
as proposed.   On the other hand, as you point out, Dave, its value as a
guideline is making a system scalable and evolvable.   And there's a
corollary:  building function into the network has costs as well as
benefits.   Too often we ignore those costs, because they are less
visible than the benefits.

However, I disagree with your example.  The problem is that topology
doesn't map to authority.   Yes, there are organizational boundaries,
and organizations have an interest in communications between peers.
However, those organizational boundaries do NOT correlate closely with
physical network boundaries.   The premature binding of organizational
boundaries to physical topological connect points is why NATs and so
forth so often miss the mark on solving the true "end-to-end" problems
we have.

So, I agree with you on your major point, but I disagree that email is a
good example of how to either apply or ignore the end-to-end argument.

One merely has to examine the move to having hotel ISPs spoofing SMTP
connections based on their organizational "interest" in blocking spam
(and their lawyers assert that the the law *requires* them to do this).
  That man-in-the-middle solution actually prevents better solutions
(such as crypto-authentication that prevents man-in-the-middle attacks)
to the actual end-to-end requirements that users want.

Dave Crocker wrote:

> Folks,
>
> 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" construct.
>
> 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 architecture:
>
>   <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>
>
> 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 inter-network operations.
>
> 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.
>
>
> d/