[standards-jig] Eliminating exceptions from the protocol
mlin at mlin.net
Tue Jun 4 13:12:48 UTC 2002
I would just like to point out that "reliable delivery" is often an
overrated feature when we are transporting individual discrete packets
like we are in Jabber. The reason is basically an end-to-end argument.
When I send an order request to a store, what I'm looking for in return
is not the knowledge that my request was delivered by the store's Jabber
server to the store's order processing nodes. What I'm looking for is
acknowledgement from the store that my order was received (as in, "We
are processing your order #xxx"), which does not coincide and cannot
come from any knowledge posessed by the server. Instead, it can only
come explicitly from the store itself.
If I know my packet was delivered but I never receive an acknowledegment
from the store's application, I'm still going to think that something is
wrong. If I don't receive any verification that my packet was delivered
but I do receive an acknowledgement from the store, then obviously I
So there are two observations. Firstly, it's not really so bad to resend
a packet. Secondly, with the one exception of s2s connection failures,
the server can not know for sure when you need to resend a packet. This
knowledge can only be posessed by the end nodes, and therefore it is
only they are the only appropriate point to make that decision - these
transactions are end-to-end.
This argument was outlined in 1984 by Saltzer, Reed, and Clark's
"End-to-End Arguments in System Design", which was very influential in
the design of the Internet. It can be found at
Anyway, I don't mean to be trivializing anything that is being debated,
but I just wanted to bring up the point that reliable delivery is often
thought of to be more useful than it really is. Of course it and store
and forward and so on are all very useful features that we should pursue
- I just want to make sure we keep them in perspective.
On Tue, 2002-06-04 at 08:49, Ralph Siemsen wrote:
> Sami Haahtinen wrote:
> > This is ofcourse how things should be and with the knowledge i have
> > about gabber source, it supports return receipts (atleast) and tracking
> > itself is not _that_ important. althought, i'm not sure how far agents
> > and transports are trusted, (never tried =) does the server allow
> > messages that don't originate from that agent to pass through. If the
> > servers do allow agents to pass along random jids, then we need tracking
> > of delivery path too.
> I was thinking more from a "reliable delivery" point of view. If one
> wants to use Jabber to conduct business, the big keywords are encryption
> and reliable delivery, the latter requires knowing exactly where a
> message is at any time. There is a JEP that addresses this partially
> (imho) but doesnt address 'finding' a lost message...
> >>* one-way "broadcast" information, such as headlines, news, notices,
> >> and also including presence... think of it as low-priority bulk mail
> > yes, and this sort of messages are getting popular, i have a few RSS
> > feeds in my roster which make up 50%+ of the messages i get =)
> Indeed... it would be nice to have an 'invisible' category for the
> roster, eg. items that don't show up normally, but have presence
> exchanged anyways. This is of course a client issue, but one that needs
> a push from Jabber otherwise it'll never get implemented widely enough
> to be useful...
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards