Fwd: [Standards-JIG] Re: WHACK
mridul at sun.com
Sun Apr 30 18:00:34 UTC 2006
Whatever be the final proposal , it should not be something which
breaks XMPP in any way - especially considering there are lot of clients
and server already deployed.
Sending whacks is breaking this - associating meaning with something
(sending whitespace) which did not have meaning until now and more
importantly , something which was allowed in xmpp.
This breakage was the only reason why I got involved in this discussion ...
Whichever be the final proposal that gets implemented for hop-to-hop ack
- whacks , whings , etc are not backwardly compatible change and imo not
a elegant solution.
There is a need for timebound hop-to-hop ack (there was a reason behind
retransmission being mentioned , but let us not get into that and change
discussion focus :-) ) : other higher level decisions would need to be
made based on this.
There is a need for end-to-end ack's too based on QoS requirements ...
but there are ways of handling this, none for reliably doing hop-to-hop ack.
Matthew Wild wrote:
> All this adds great complexity, compared to easy-to-implement,
> bandwidth-saving whacks. I also think that methods of 'quick
> reconnection' should be covered elsewhere, not by the implementation
> of acks themselves.
> There is also no question in my mind that acks should be hop-hop, not
> end-to-end. Makeshift methods of end-to-end acks exist already, and
> from my experience it doubles the lag aleady present in sending
> messages. Hop-to-hop acks make far more sense.
> On 4/30/06, *Dave Cridland* < dave at cridland.net
> <mailto:dave at cridland.net>> wrote:
> 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