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

[Jon Crowcroft]

in response to various comments...

1. we did an asynch interface to conference managemet (i.e. email) because people
wanted it (as well as web interfaces) because a lot of people on PCs have tasks
that stretch over months and many journeys and want to work on things offline and
then submit online, ....pure web/synch/online only systems are a pain.

2. conf PCs aren't wrong - the email problem changes - email USED to be designed
(ask steve kille, one of the serious gurus of email) to be absoltuely the most
reliable app you could find on any net whether it was x.25, uucp/dialup, tcp,
whatever - now it isn't - the reason it isnt relaible (in the sense of succed of
error notification if it doesnt) is NEW and denying this, or claiming users are
wrong is incorrect interpretation of the problem which is a CHANGE in semantics -
silinet failure was NOT part of the design space.

3. people used email for a lot of thigns (sys admin for example) on the basis
that the smtp delivery semantics (and x.400) were good - and so it was a useful
building block for scripting lots of things even pre (yech) web 2.0 - now it isnt
any more - this is a surprise. (actually it isnt if you go back to uucp days, but
it is if you only go back to , say, late 80s) - 

4. if you want to design a useful building block , you need to consider a lot of
clever tricks about tiemrs - email people did that - but you also need to cope
with what telco folks used to call "signaled" and "unsignaled" errors - fail
silent errors are fine so long as thy are part of the spec - i could break most
TCPs out there if i built a thign that did cummulative acks for seqno above the
packets that were missing....what would happen to lots of programms like rsynch
or network backup?...

5.
changing the socket API wasn't my goal (since the RTT for email delivery is not
something tcp data/ack roudn trip time has much to do with....but having an open
API (like SysV layer 4 api ) might be useful - actually lots of systems had hacks
like it....in the same way giving applications access to routing tables is also
useful - actually all hosts should have access to all routeing info inclding link
and path metrics...even my cell phone has more memory than the average campus
router now....just in case it would be useful...in the words of 10000 maniacs,
you never no...


In missive <001701c853d1$9cb5f5a0$0200a8c0 at fun>, "Michael Welzl" typed:

 >>> 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.
 >>
 >>I'm not saying that there *has* to be a generic solution (that
 >>might just not be exist), I just said that I disagree that there's
 >>no need (or maybe better: demand) for it. There can be partial
 >>solutions like SureMail which actually make sense.
 >>
 >>The way you refer to "features in the network" above indicates
 >>to me that you're taking a "pro end-to-end" position here,
 >>whereas mine is "anti end-to-end".
 >>
 >>- but I don't think that this is the right way to see it. The end
 >>systems that we are talking about here are humans, and I'm
 >>not sure if we can take e2e as a guiding principle when that
 >>is the case - after all, the goal seems to be to build a system
 >>that's convenient for people to use.
 >>
 >>We don't require people to be involved in TCP ACKs, right?
 >>
 >>Just because SMTP and POP/IMAP servers aren't built in
 >>end hosts like TCP is, that doesn't mean that they are not the
 >>communication endpoints that people interact with. You seem
 >>to say that they are "in the network". I say they are the end
 >>systems that we must consider, because they are the entities that
 >>we (as human users of the system) expect a certain service from.
 >>
 >> 
 >>> The same logic justifies scanning airport passengers for Arabic names 
 >>> and presuming that contributes to "security".
 >>
 >>I don't get that analogy.
 >>
 >>Cheers,
 >>Michael
 >>

 cheers

   jon