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

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.

The "ends" and "hops" in E2E are relative, at least they always have
been to me. All the E2E argument says, in that context, is that you
can't compose HBH services to end up with the equivalent E2E.

It never said not to do HBH (e.g., for performance). It never said where
the ends definitively were for all layers, IMO.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDj1FCE5f5cImnZrsRAtGTAJ90msM3c2fUYVwu8OivMsV68/xcAACgiF/b
sbQ1KPR4PBwotedQKCe40K4=
=Gldi
-----END PGP SIGNATURE-----