[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Fri Apr 28 19:26:36 UTC 2006


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.

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.





More information about the Standards mailing list