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
|
