Re: [lp-wan] need for MAX_ACK_REQUESTS?

["Carles Gomez Montenegro" <[e-mail]>]

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]
>
>
>