Fwd: [Standards-JIG] Re: WHACK

Matthew Wild mwild1+jig at gmail.com
Sun Apr 30 12:32:16 UTC 2006


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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060430/4535f10b/attachment.html>


More information about the Standards mailing list