[Standards-JIG] Re: Council decision on "Stanza Acking" proposal

David Waite dwaite at gmail.com
Sat Mar 26 01:02:45 UTC 2005


On Fri, 25 Mar 2005 23:05:28 +0100, Bart van Bragt <jabber at vanbragt.com> wrote:
> If I send a message I either want this message to arrive or receive an
> error message that states that this message didn't arrive at the
> recipient. I had quite a few problems with this while I was still using
> a (fairly overloaded) public MSN/ICQ transport (yeah, yeah, transports
> are evil :D). I can tell you from experience that it's _extremely_
> annoying to not know if your messages arrive intact. Didn't the person
> on the other side respond because he's away? Is he ignoring your remark?
> Is he just not interested into going into a specific topic that you
> mention? Was he offended? Is he too busy? Or did the message get lost in
> space somewhere?

If the problem is not knowing whether a message arrived or not, the
solution is not a hop-to-hop keepalive/ping/acknowledgement, but
end-to-end acknowledgement of message receipt. Knowing that my message
got to my local server tells me nothing about whether the message got
to the final recipient. Having me tell my local server that my
connection is still alive does nothing to let the remote user know
that my message arrived successfully.

> Delivery notifications are a sort of stop gap solution that works fairly
> well as long as the other side supports them and if you're only
> interested in <message>-es. IMO it would be very, very nice if there
> would be some kind of protection against link breakages on a somewhat
> lower level.

Link breakages imply that messages are not delivered. I do not get why
acknowledgements are a short-term solution.

IMHO XMPP is defective in this respect, because acknowledgement policy
of a stanza is just an implicit property of the stanza type. I want
delivery notifications of my messages, thank-you-very-much. And I
don't want it to be an optional tack-xml-into-the-stanza-body thing
that servers and clients may or may not cooperate with.

Message and Presence stanzas (as defined by XMPP) have no
acknowledgement, they are fire and forget. IQ request has ACK (but,
the responses are both ACKs and data, so you have no idea if a
response was delivered correectly.)

In an ideal world a stanza would be a stanza would be a stanza, and
the data carried within that stanza would be used by the remote party
for processing. instead of <message> we would have <stanza> with all
the delivery information separated from the message, and allowing for
ACK/NAK behavior. If a client does not acknowledge received stanzas
which are marked as requiring an ack, their local server can
disconnect them.  There are some privacy policies needed for clients
to not give away their presence based on ACKing, but I believe these
would be solvable in a satifactory way.

And yes, a server could send empty ack/nak messages if they wanted as
a local connection ping. Or whitespace/tcp keepalive messages if they
are willing to wait for tcp timeout.

> Reverting to HTTP on a mobile device makes everything horribly
> inefficient because of the overhead and the fact that the mobile client
> has to poll for updates (and polling is extremely evil in my book :D).
> The nice thing about Jabber on a mobile device is that it costs close to
> nothing as long as you're not doing anything (and as long as you don't
> have a 500 user roster :D). IMO Jabber should just be able to handle a
> dropped connection gracefully, simple clients...

But XMPP oer TCP doesn't handle dropped connectiosn gracefully. The
lifetime of your XMPP session is directly tied to the lifetime of your
TCP session. There is no mechanism for 'resuming' a session on TCP,
and I daresay TCP is poorly designed for when networking capabilities
and stability changes often (such as a mobile phone.)

> IMO the experiment then standardize process works pretty well for
> clients but it's horrible for servers. How can you test something like
> this when all you control is your client or your server? This needs
> cooperation of a conciderable amount of people/groups which in the end
> amounts to standardization :) At least to some extent... Experimenting
> with most client side code is easy because you control both ends of the
> connection.

Yes, and this is how Jabber was created. :)

> > Finally, I really would be curious to know how serious a "problem" this
> > is, as shown by hard numbers and actual statistics. So far, all we have
> > is anecdotal evidence as far as I'm concerned.
> Well, what do we think is acceptable? 1 out of 100 messages getting
> dropped? 1 in 1000? 1 in a million? IMO 1 in a million is starting to
> get close and I wouldn't be surprised if the current drop rate would be
> on or two orders of magnitude higher than that. But, indeed, I don't
> have hard numbers. But there is also no evidence of this being 'just an
> edge case' either :)

But you aren't solving message drops at all with stream-level ACKs,
and you aren't providing a mechanism for me to be assured that my
messages made it through. In short, you've not solved the problem you
set out to solve.

-David Waite



More information about the Standards mailing list