[e2e] was Re: A message to authors - nsdi

[David P. Reed]

Wow! we have gone from a problem with conference management to invention 
of new APIs for the Berkeley Sockets layer.

I'm not sure how RTT and B*RTT/2 are related to silent email filtering, 
but may I suggest that we formulate this as a well-defined problem to be 
solved rather than the invention of generalized answers to even more 
general hypotheticals?

The road of systems research (operating systems and others) is littered 
with people who have fallen in love with arcane solutions to 
non-problems.  Many of them cruft up the systems we use today.   
Windows, for example, but also Linux and OS X.   And you can find lots 
of non-working things in network standards, too.   IEEE 802.11 Ad hoc 
mode, for example - especially multicast.   And the "TOS" field in 
IPv4.   ANd the duration of port reuse intervals in NAT "standards".

If you posit that a proposal actually "solves" a problem, you won't mind 
having the end-to-end argument posed - does it completely solve it, or 
must the endpoints be involved.   If they must be involved, why is your 
"in the guts of the system" solution needed?   If it is an optimization, 
does it also have bad cases that wouldn't have been there if the 
solution hadn't been invented in the first place?

Email, like paper mail before it, does NOT guarantee delivery.   The 
fault is not with email or the US post office.  The fault is with the 
users (in this case the program committees).