Re: [lp-wan] need for MAX_ACK_REQUESTS?

[Arun <[e-mail]>]

Thanks Carles for the explanation.
Yes, I agree. Keeping a lower value of retries seems reasonable in case
of large window.
I prefer to have simpler option, MAX_ACK_REQUEST to decide when to abort
but will wait for inputs from others as well.

On 19/07/2017 17:20, Carles Gomez Montenegro wrote:
> Hi Arun,
>
> Thanks for your response.
>
> Yes, I understand your example is correct. On your question, the same
> problem will happen anyway when any applicable "MAX_" parameter is
> reached.
>
> The main reason I can see for having two separate parameters is that a
> sender may want to resend the last fragment "many times" (say, e.g. 5) to
> request for an ACK. But when the ACK is received, maybe a sender cannot
> afford to resend as many times each specific fragment reported to be lost
> (imagine a "large window", say of 30 fragments where 8 out of those need
> to be resent). Maybe doing up to 5 retries for each lost fragment is too
> much, but a lower number of retries could be acceptable.
>
> Maybe a more simple option is to reduce the number of "MAX_" parameters to
> only 1 (you favor that to be MAX_ACK_REQUESTS), and if a sender determines
> from an ACK that there have been too many losses (and maybe it is not
> worth trying to recover all of them since link quality appears to be low),
> it can always abort.
>
> Thoughts?
>
> Carles
>
>
>
>
>> Hi Carles,
>> I'm not clear about the purpose of having retry counter for each
>> fragments.
>>
>> My understanding is as follows (w.r.t. ACK always) :
>>  - whenever there is a retransmission  the receiver would expect the
>> ACK_REQUEST packet to be least the CFN in the bitmap.
>>  we resend (at the same time increment retry counter for this fragment)
>> only last fragment in case of timer expiry. when the counter reaches
>> MAX_FRAG_RETRIES for CFN =1, what do we do?
>>  we cannot try resending CFN !=1 (in this case cfn=4) because the
>> receiver would still expect CFN=1 for ACK_REQUEST or to send bitmap.
>> So, I think it would be good to have only variable, can be
>> MAX_ACK_REQUEST.
>>
>>
>>
>>                        Tx                        Rx
>>                         +                         +
>>                         |                         |
>>                         |          cfn=6          | expected
>> ACK_REQ_PACKET = cfn_0
>>                         +------------------------->
>>                         |          cfn=5          |
>>                         +------------------------->
>>                         |          cfn=4          |
>>                         +--------------------X---->
>>                         |          cfn=3          |
>>                         +--------------------X---->
>>                         |          cfn=2          |
>>                         +------------------------->
>>                         |          cfn=1          |
>>                         +--------------------X---->
>>                         |          cfn=0          |
>>                         +------------------------->
>>                         |  ACK:11001011           |expected
>> ACK_REQ_PACKET = cfn_1
>>                         <-------------------------+
>>                         |         cfn=4           |
>>                         +-------------------X----->
>>                         |         cfn=3           |
>>                         +------------------------->
>>                         |         cfn=1           |
>>                         +-------------------X----->
>>           timer expired |    ACK:11011011         |expected
>> ACK_REQ_PACKET = cfn_1
>>                         <--X----------------------+
>>                         |        cfn=1            |
>>                         +------------------------->
>>           timer expired |    ACK:11011011         |expected
>> ACK_REQ_PACKET = cfn_1
>>                         <--X----------------------+
>>     reached MAX_ACK_REQ |                         |
>>          discard cfn=1  |      cfn=4??            |
>>                         +-------------------------> wait until cfn=1 to
>> send ACK
>>                         |                         |
>>                         |                         |
>> regards,
>>
>> On 19/07/2017 13:58, Carles Gomez Montenegro wrote:
>>> Hi Arun,
>>>
>>> Thanks for commenting on this.
>>>
>>> Currently, MAX_ACK_REQUESTS applies only to the last fragment in a
>>> window,
>>> which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applies
>>> to
>>> the previous fragments in the window.
>>>
>>> I have been thinking about this several times, and I see two options:
>>>
>>> 1.- Keep the two parameters. There might be reasons for setting
>>> MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be
>>> specially critical to get an ACK (which gives feedback on the delivery
>>> of
>>> all fragments in the window), while one might want to be careful
>>> regarding
>>> how many times a fragment (from the rest of fragments in the window) is
>>> resent. In addition, it is possible to set the two parameters to the
>>> same
>>> value if desired.
>>>
>>> 2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying to
>>> all
>>> fragments.
>>>
>>> Which are your (and other) opinions on this?
>>>
>>> Thanks,
>>>
>>> Carles
>>>
>>>
>>>
>>>> Hi Carles, all,
>>>>
>>>>  Do we still need this variable MAX_ACK_REQUESTS ?
>>>>  MAX_FRAG_RETRIES is going to be the same (during retransmission we
>>>> only
>>>> send the last fragment of the received bitmap which would be considered
>>>> as ACK REQUEST). correct?
>>>>
>>>>  if this is already discussed in the thread of Dominique's review
>>>> please
>>>> point me to the same.
>>>>
>>>> thanks,
>>>>
>>>> --
>>>>
>>>> Arunprabhu Kandasamy
>>>> arun at ackl.io
>> --
>> Arunprabhu Kandasamy
>> arun at ackl.io
>>
>> 2 bis rue de la Châtaigneraie
>> 35510 Cesson-Sévigné
>> France
>> Phone: [phone]
>>
>>
>>
>

-- 
Arunprabhu Kandasamy
arun at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 
Phone: [phone]