[Standards-JIG] Re: WHACK

Dave Cridland dave at cridland.net
Sun Apr 30 09:23:06 UTC 2006

On Fri Apr 28 20:26:36 2006, Mridul Muralidharan wrote:
> 1) Not every stanza would require ack : depends on the QoS 
> requirement of a particular stanza.
> Like SOAP/XMPP might require end to end ack or just hop to hop ack 
> , or no ack at all.
> Similarly, if I am chatting with my boss , I might want to know if 
> he does not recieve any packets ;-)
> Anyway , the basic intention is that , there might be different 
> requirements for different stanzas : not a flat out hop by hop for 
> all stanzas.
end-to-end receipts are a wholly different thing. In general, you 
don't just want to know if your boss's client has received the 
message, you want to know if your boss has read it. This has privacy 
issues all over it, plus some very complicated problems when combined 
with message encryption. There's been discussion in SIMPLE about IMDN 
for some time, and it looks pretty complex to my cursory look.

Loosely, you always want hop-by-hop reliability, and sometimes that's 
not enough.

> 2) Retransmission would happen when you do not get ack within some 
> negotiated timeout (or maybe static timeout).
> So extra n/w usage is acceptable imo ... since alternative is 
> potentially losing packets.
As Michal says, "retransmission" and "packets" are TCP layer issues. 
What we're talking about is handling the specific case where the 
connection is lost and we have sent stanzas. So the extra bandwidth 
usage ideally needs to happen on reconnection only - you don't want 
to be spending extra data all the time on the off-chance that the 
connection dies.

This is why I'm saying that you don't implicitly ack. You ack when 
asked - but that's not tremendously important - the key feature is 
that the remote end knows what ack sequence number was last received 
from the client when the client has reconnected.

> 3) I was not paying much attention to 'monotonically increasing' 
> ;-).
> Let me put it this way, each subsequent is one more than the 
> previous - with initial value selected randomly :-)
You mean arbitrarily, rather than randomly, I assume. It doesn't 
matter if hop-by-hop ack sequence numbers are predictable.

You also appear to think "monotonically" means "increasing by one" - 
I thought that too, originally, and it's cropped up in at least one 
IETF draft. Sadly it doesn't. "1,5,22" is a strictly monotonically 
increasing sequence.

> 4) Sending server's current_ack instead of ack for each stanza 
> would be a nice optimisation - did not think of it :-) Thanks !
Yes, now consider not sending it except in the error recovery (ie, 
reconnect) stage.

> 5) If you club with point 1 and 4 above , the actual cost of ack is 
> not very high and stanza traffic would be pretty low IMO.
> Whether you optimise away and send current_ack of server 
> periodically or for every stanza could be an impl detail - we just 
> need to specify what ... how could be handled by impl's I guess.

No, you do it on request, most likely. How often to ack is fairly 
complex, and there's enough ways of implicitly acking (like getting 
any response from any <iq>) that it can be avoided.

> Like, if number of packet's requiring ack's is high - makes sense 
> to send back ack's at higher rate to prevent too much packet 
> queuing at client.
> Similarly , we would need to send ack such that we prevent 
> retransmission if possible.
The client usually has a very good idea of how much memory, etc, it 
has. I think you can work it by using an explicit ACK request.

So we're looking at (something a bit like):

1) For each direction of an XMPP stream, there is a stanza sequence 
number. Each time a stanza is sent, a new sequence number is 
allocated, which MUST be higher than any previous sequence number 
used in the stream.

2) The Sender of a stanza includes an "a:seq" attribute in every 

3) At any time, the Sender MAY choose to send an <iq/> stanza 
containing a <query/> element qualified by the ack namespace. 
(Whatever that namespace turns out to be).

4) The Receiver of a stanza MUST maintain a record of the last 
sequence number received, and MAY maintain this record after the 
session ends.

5) On connection, a Sender MAY request the last sequence number 
received. This can be used to resend stanzas that were, for some 
reason, lost.

I also think we need to have an "I am intentionally closing this 
session forever" as a hook for future quick-reconnection work, for 
instance to avoid the roster download, but I'm only making an 
educated guess here.

           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

More information about the Standards mailing list