[Standards-JIG] Re: WHACK

Michal vorner Vaner michal.vaner at kdemail.net
Sat Apr 29 09:09:05 UTC 2006


On Sat, Apr 29, 2006 at 12:56:36AM +0530, Mridul Muralidharan wrote:
> Hi,
> 
>  Some responses , some comments and somethings I was envisioning :
> 
> 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.
> 
> 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.

Retransmision is the job for TCP. You do not need to retransmit. The
only time a stanza (not packet, but it gets retransmited by TCP
automatically) is when the connection is lost. And in that case, you do
not need a timeout - you just see it was lost with an error - and you
can not retransmit. Client must reconnect again (and then maybe
retransmit) and server just stores it to offline message store and does
not retransmit in the usual meaning at all.

> 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 :-)
> 
> 4) Sending server's current_ack instead of ack for each stanza would be 
> a nice optimisation - did not think of it :-) Thanks !
> 
> 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.
> 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.
> 
> 
> Thanks and Regards,
> Mridul
> 
> Dave Cridland wrote:
> 
> >On Fri Apr 28 05:30:22 2006, Mridul Muralidharan wrote:
> >
> >>Dave Cridland wrote:
> >>
> >>>On Fri Apr 28 00:18:34 2006, Mridul Muralidharan wrote:
> >>>
> >>>>Dave Cridland wrote:
> >>>>
> >>>>>On Thu Apr 27 23:40:33 2006, Mridul Muralidharan wrote:
> >>>>>
> >>>>>> If you have some form of id'ing each stanza which requires ack 
> >>>>>>and use that in the ack , then yes we can find out which have 
> >>>>>>been delivered and which have not.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Nope, you still can't. You can find out ones which have definitely 
> >>>>>been delivered, but you don't know that the unacknowledged stanzas 
> >>>>>have not been delivered.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>That would be simple to handle.
> >>>>The server discards stanza's which have ackid's which have been 
> >>>>already processed.
> >>>>Client retransmits unack'ed stanza's after timeout.
> >>>>This way stanza retransmission would not have a functionality loss 
> >>>>: except for a minor load increase.
> >>>>
> >>>>Just one possibility, I am sure there could be better alternatives.
> >>>>
> >>>>
> >>>Yes, I've suggested one already.
> >>>
> >>>Your suggestion suffers from the problem that since the server 
> >>>cannot know if its acks have been received, it has to assume they 
> >>>aren't, meaning it has to remember every id ever received.
> >>
> >>
> >>
> >>I was thinking of the 'rid' in JEP 124 when I was suggesting this.
> >>Over there you have :
> >>1) Monotonically increasing rid values from initial rid.
> >
> >
> >That's "strictly monotonically increasing". I've never actually seen a 
> >purpose to the word "monotonically", but apparently mathematicians 
> >love it.
> >
> >
> >>2) If connection manager recieves a request with an rid it has 
> >>already processed ,it will just return the same response. (an 
> >>intermediary could have lost the stanza).
> >>
> >>
> >Uh-oh. That's fine, but not good over links that charge by transfer, 
> >like GPRS, for instance.
> >
> >
> >>So , trying to apply the same to our case , if ackid's are 
> >>monotonically increasing - we will not have the problem you describe.
> >>If client retransmit a stanza 'cos of late arrival of ack , server 
> >>would ignore the stanza if stanza_ack_id < current_ack_id.
> >
> >
> >Right... But if the server says what current_ack_id *is*, then you 
> >don't have that issue either, because that client doesn't retransmit, 
> >even if...
> >
> >
> >>The only thing that would not get handled is stream terminates while 
> >>ack is not yet recieved.
> >
> >
> >Which rather suggests that the ACK itself is a waste of time, except 
> >that an occasional, periodic stanza indicating the current_ack_id is 
> >useful to reduce the sender's history.
> >
> >
> >>This is something we will live with I guess ... there could be ways 
> >>of solving this , but the requirements would be significantly 
> >>stringer in that case.
> >>
> >>I have not had the chance to read your proposal, where can I pick it 
> >>up from ? Thanks.
> >>
> >>
> >It's on the list, but the essentials are in this message. There's 
> >nothing formal.
> >
> >>Simple way to illustrate this :
> >>stazna1 , stanza2 sent from client , server recieves them in order as 
> >>stanza1 and stanza2 : so in order delivery is achieved.
> >>Sending ack would now need to be part of stanza acceptance , else ack 
> >>for stanza2 could make it back while not the one for stanza1 - and if 
> >>whacks , no way of differentiating this at client side.
> >
> >
> >Exactly. But it has to be anyway - so for an <iq type='get'/> stanza, 
> >for instance, you have two stanzas in return, one with the ACK, one 
> >with the result/error.
> >
> >>>Agreed, whitespace acks don't provide anything more than acks do 
> >>>themselves. That's why I'm arguing against them both.
> >>>
> >>>
> >>Great ! I think there is a need to have hop to hop acks ... whacks 
> >>are interesting and simple idea but I feel not enough as they have 
> >>been described.
> >
> >
> >Hopefully, I'm explaining that hop-by-hop ACKs, at least for every 
> >stanza, aren't needed either. Just the sequence numbering.
> >
> >Dave.
> 
> 
> 
> 

-- 

NAT should extinkt like dinosaurs did.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060429/1e34eb5e/attachment.sig>


More information about the Standards mailing list