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

[Jon Crowcroft]

so google do application layer retries in a
lot of things

the problem with that approach
is that automatic systems above
the network layer have no meaningful
equivalent to the RTT estimation process that
drives the retransmit timer process, and 
packet conservation mechanisms in transport
that is a part of the congestion control
loop, so we could end up either clobbering the
net and the end system, or using incredily
conservative timers for the retries...

with silent failure, we need to require
positive acknowledgement in the application
layer as you say- but i dont want to automate
it:) there's problably some wonderful ways
such a loop could interact with a vacation
mail trigger too.....(can u say feature
interaction? :-)

hey, TCP on SMTP, anyone?

In missive <1199975821.3801.119.camel at pc105-c703.uibk.a
c.at>, Michael Welzl typed:

 >>Yeah...
 >>
 >>Silent loss of email is one of the real problems that the
 >>Internet is facing today. Much more real, and much more
 >>severe, than many of the other issues that people like
 >>myself deal with on a daily basis.
 >>
 >>I've been looking into the problem a bit - there's a neat
 >>suggested solution from MS research called SureMail:
 >>http://research.microsoft.com/netres/projects/SureMail/
 >>(hm, maybe it was *you* who once pointed me to it?! sorry
 >>for sending it back to you in this case  :-)   ), and
 >>I considered just adding a reliability loop between my
 >>outgoing SMTP server and your POP server (because these
 >>are the entities between which reliability is assumed - if
 >>your *personal* spam folder delete's stuff, you usually
 >>accept that it's your fault), where I would get my emails
 >>marked in my "sent" folder when they reached your POP ...
 >>this way I know that some definitely made it, and several
 >>others *might* have made it to the other end - that would
 >>already be helpful I guess
 >>
 >>Turns out that there's a standard in place for doing that
 >>SMTP-POP loop described above, but it isn't normally used,
 >>no idea why ... I had to stop looking deeper at some point
 >>because all the other work pulled the carpet from under
 >>my feet, but I'm still quite interested in that
 >>
 >>Bottom line: email is badly broken, and one of the most
 >>heavily used Internet services, someone should truly
 >>fix it (and while I think that the SureMal approaches
 >>(actually multiple - the first and second papers
 >>are quite different, one has a DHT and one doesn't) area
 >>quite nice, they only partially solve the problem).
 >>
 >>Cheers,
 >>Michael
 >>
 >>
 >>On Thu, 2008-01-10 at 14:18 +0000, Jon Crowcroft wrote:
 >>> Michael, and others
 >>> 
 >>> we had several problems with NSDI this year
 >>> due to silent failure of email. Many of us
 >>> have taken for granted that e-mail had become
 >>> somewhat of a atomic building block for
 >>> delivery of notifications of various things,
 >>> but this is (alas) simply incorrect and things
 >>> are getting worse - I hate to say this, but we
 >>> may find ourselves pushing responsibility
 >>> around in future (e.g. authors must poll a
 >>> site to check on status, rather than (or as
 >>> well as) expecting an event reporting phase
 >>> changes such as submission received, 
 >>> pdf checked, paper in review, accept/reject 
 >>> notification etc 
 >>> 
 >>> obviously one can leave in place the e-mail
 >>> systems, but it is simply not working - some
 >>> of the bayesian rule based filters do not even
 >>> give consistent results over the same pair of
 >>> sender/recipient, or over a sequence of
 >>> messages with the same content...but (and of
 >>> course for a spam filter, this is "correct"
 >>> since teling a bad guy anything is deemed
 >>> self-defeating)
 >>> there's no SMTP error notification so end2end
 >>> delivery is assumed to have occurred....
 >>> 
 >>> users with white listing technologies should
 >>> consider adding conference submission sites to
 >>> the white list but it aint as simple as that
 >>> of course...
 >>> 
 >>> j.
 >>> 
 >>> p.s. we were even stymied partly by our own
 >>> mail system anti-spam measures which include
 >>> rate-limiting automatic mail outbound from our
 >>> site...
 >>> 
 >>> argh!!!
 >>

 cheers

   jon