Subject: [lp-wan] need for MAX_ACK_REQUESTS?

From: Arun <[email-masked]>
Date: Wed, 19 Jul 2017 13:19:49 +0200

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

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 
Phone: +33 (0)2.99.12.24.14

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 19 Jul 2017 13:58:37 +0200

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

---

From: Arun <[email-masked]>
Date: Wed, 19 Jul 2017 16:11:33 +0200

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,

-- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 19 Jul 2017 17:20:07 +0200

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

> 2 bis rue de la ChÃ¢taigneraie
> 35510 Cesson-SÃ©vignÃ©
> France

---

From: Arun <[email-masked]>
Date: Wed, 19 Jul 2017 18:35:28 +0200

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.

-- 
Arunprabhu Kandasamy
arun at ackl.io