[ih] There is no such thing as an "end-to-end failure"

[Dave Crocker]

The original term was "end-to-end arguments" which often is altered to 
"end-to-end principle", neither of which permit much meaning for a 
phrase like "end-to-end failure".  Similarly, the problematic term does 
not distinguish between design, implementation or operations errors.

The original terms suggested a style of thinking about networked system 
design.  It's possible to think inadequately, of course, just as it's 
possible to have bugs when programming or to set the wrong configuration 
value.  The term "end-to-end failure" offers no insight into which of 
these is involved, nor how.

The problematic term is often invoked by someone who has a clear meaning 
for its use.  And it is often heard by people who have a clear meaning 
for the term.  However their are two problems.  One is that the clear 
meanings well might be different and the other is that there is no clear 
documentation that can be referenced, analyzed, and repaired.

Further...

On 9/13/2020 8:26 AM, Joseph Touch via Internet-history wrote:
> On the one hand, that E2E is the composition of a set of applications 
> into a single service that was never implemented as E2E at the mail 
> delivery layer.

Oh?  Please clarify, with details.

Here are some reasons for my surprise:  email infrastructure RFCs 
(object and transport) have tended to describe an end-to-end design.

RFC 5598 documented the evolved state of affairs for recent history.  So 
if E2E was missing from that thinking, it will be helpful to understand 
this failure in detail.


> If it were, your mailer would have let you know that you didn’t 
> receive a copy of the mail or that your post didn’t appear in the 
> archive. So, at some level, one E2E failure happened in the design and 
> implementation of ALL mail readers. 

The operational reality of modern Internet mail is that perhaps 95% of 
the traffic across the Internet is spam.  This has required quite a bit 
of mitigation, of course, where one of the resulting requirements is to 
permit essentially no automated feedback to the author or originating 
operator.  Sorry.  That's unfortunate, but it's not a 'failure'.

To the extent that feedback is essential, please offer a design that is 
robust against abuse.  We do not currently have one. Return Receipt 
still works, but it's not quite what you are looking for, I suspect.


> However, understanding E2E means knowing what the ends are.

The importance of this observation cannot be overstated.  I used to 
think that MUAs were the endpoints -- and often, of course, they are.

Then I met EDI over email.


> So on the other hand, mail list posters can be considered an endpoint. If they had acted as endpoints, the NACK would have resulted in their retrying posts with varying content until they confirm success by receipt and in the archive. I.e., what I did, using the CS 100 method of binary search. Instead, they did something very un-E2E - they sought assistance from the management plane (me) and took issue with the lack of active feedback from various intermediate layers and hops (smtp, postfix, Mailman, etc.).

There is a tendency to think that mailing list managers (MLM) are the 
same as mail transfer agents (MTA).  They aren't.  The latter are relays 
holding roughly the same architectural role as an IP router.

However MLMs are actual email endpoints.  They take delivery of mail 
addressed to them and then generate and post a new message.

The fact that an original author and final recipients perceive a 
'direct' interaction is due to a layer /above/ normal email. And it is a 
poorly documented and inconsistently implemented and inconsistently 
operated layer.

To the extent that someone wants to declare a failure at that level, 
they need to point to the documentation involved and clarify what, 
exactly has failed.

Typically what has actually failed is that their entirely reasonable 
expectations, which were not documented anywhere, were not met.


> Over the years, I thought we had learned not to expect active feedback when things fail, for several reasons: security (why ICMPs are blocked), stability (to avoid NACK storms), info theory (you can’t NACK what you didn’t expect), or even the Postel Principle (be liberal in what you [don’t] receive).

I quite like this summary.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net