Re: [lp-wan] need for MAX_ACK_REQUESTS?

[Arun <[e-mail]>]

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]