Re: e2e [was: Non routable IPv6 registry proposal]

[Joseph Touch <[e-mail]>]

> On Jan 23, 2021, at 1:47 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Much as I had concerns about draft-ietf-spring-srv6-network-programming,
> I think we should be clear about what e2e is about. It *isn't* about
> idealised transparency or even about forbidding packet mangling.
> For example, what we said in RFC1958 is:
> "The basic argument is that, as a first principle, certain required end-
> to-end functions can only be performed correctly by the end-systems
> themselves."

Speaking of errors… this is a subtle one. Just because some functions can be performed correctly ONLY at the end systems, that does NOT mean the end is the ONLY performer of such functions (a good example of why the word “only” needs to be placed carefully).

> That wasn't the last word, of course: see RFC3724, for example.
> 
> Of course, that version of e2e does mean that any kind of packet
> mangling needs to be checked to see if it harms the e2e principle.
> For example, the e2e principle tells us that the decision to
> retransmit a damaged or lost packet needs to be taken at the
> originating host (which is why performance enhancing proxies are
> obnoxious). …

Agreed that the end is the only place that can ensure all lost packets are replaced. But it is incorrect that it is the only place where lost packets *can* or *should* be replaced.

ARQ and FEC at L2 can have significant benefit and are widely used. Though I agree that some PEPs are obnoxious, this kind can not only be useful, they provide a necessary ability to at least partly mitigate loss over shorter feedback loops.

Joe