[e2e] was Re: A message to authors - nsdi
David P. Reed
dpreed at reed.com
Thu Jan 10 13:04:17 PST 2008
Putting "features" in the Berkeley Sockets interface doesn't solve the
problem generically. The problem has nothing to do with the lack of
features "in the network". Papering over that fact by positing that
"there exists a generic solution" doesn't actually prove that there
really is a generic *solution*. Just a pile of crappy new features
justified by a questionable claim of relevance.
The same logic justifies scanning airport passengers for Arabic names
and presuming that contributes to "security".
Michael Welzl wrote:
>> The simplest possible answer to program committee stuff is for the
>> committee to say: you will recieve a response by date A to acknowledge
>> your submission and date X to accept or reject. If you don't get
>> responses by those dates, send inquiries to Y. We will endeavor to
>> reply by mail within one day.
> That's a nice idea, but...
>> Note that all of the timeouts above are not "automagic". They are
>> protocol specifications. They don't require guesses, but embed the
>> timeout in the end-to-end protocol def. There is no need for generic
> I disagree that there's no need for generic solutions, because of the
> mismatch between people's expectations about the service they get
> from email, and the service that the system offers (as well as the
> work involved in personally checking! Note that your solution above
> involves people typing stuff on keyboards - as the reliability declines,
> the scalability of that system will become limited by the hours that
> people can devote to that kind of solution).
More information about the end2end-interest