[e2e] Fwd: Camel's nose in the tent

[Graham Cope]

In summary, is it fair to sahy that the problem with the e2e argment, is
that the definition of 'end' varies depending on your view point
(although I recall that the original authors were clear), and sometimes
it is and 'edge' and not an 'end'.

My favourite is the somewhat glib statement used by some people
'intelligence is moving to the edge of the network'. I have three
problems with that statement:
1/ What is intelligence?
2/ What and where is an edge?
3/ What is a network? E.g., tunneling through, confusion between a
service and a network (what is the PSTN?, or in this case, what is an
e-mail network), virtual network, overlay (underlay?) networks etc.


My 1.44p on a Monday morning.


Graham



"Eric A. Hall" wrote:
> 
> Both sides are right, IMO.
> 
> > The end-to-end argument applies at each protocol layer, not just the
> > transport layer.  Both the rationale for it, and the explicit
> > description  we wrote in our paper apply at application layers as well.
> 
> My understanding is that in the context of an argument that applies to
> enforcement of data integrity, the number of layers/hops/whatever is
> irrelevant. IOW, if you are arguing that only the ends can ensure
> integrity, then that applies to SMTP over a quiet ethernet as much as it
> does to chunked messages over avian carrier.
> 
> EG, if you want to ensure that the contents of a particular message are
> always preserved, then sign it before you ship it. This is a great
> illustration of the strengths of the e2e argument, IMO.
> 
> But this is also a different argument from what goes on normally, and what
> goes on with SMTP as a case study of TCP's role in typical e2e functions
> on the Internet.
> 
> SMTP specifies an interaction between a sending system and a recieving
> system. The protocol specifically deals with a single hop. What happens at
> the next hop is beyond the scope of the protocol. After all, the recipient
> in any given SMTP exchange may strip off the headers, convert the body
> into EBCDIC, and then beam it off to the space station, and non of that
> would have had anything to do with SMTP, while the process may not have
> been the message recipient either.
> 
> In the most commmon scenario, unless there is some extraneous mechanism to
> verify the contents of the message, then SMTP relies on TCP to provide the
> integrity indicators. TCP works on the tuple. There is nothing that TCP
> can do beyond the current active session (this is particularly true with
> SMTP, where the recipient system may completely rewrite the message
> contents before opening another session and forwarding the message along a
> non-Internet path).
> 
> Thus, in the most common case, the TCP end-points are the end points for
> the e2e argument (as it applies to SMTP, inclusive). If this isn't
> reliable enough, sign the message.
> 
> --
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/