Fwd: [Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Sun Apr 30 18:00:34 UTC 2006


Hi,

  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.

Thanks,
Mridul


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
>     stanza.
>
>     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.
>
>     Dave.
>     --
>                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