Subject: Re: [lp-wan] retransmission in the last window

From: Laurent Toutain <[email-masked]>
Date: Tue, 5 Sep 2017 14:46:25 +0200

Hi,

I think we need a simple mechanism with only entity able to use timers. In
my views the sender/fragmenter is the only one able to start a timer. The
receiver obeys.

The receiver sends the bitmap when it receives a all-0 or all-1 FCN frags.
If the sender do not receives the bitmap, then it sends again the all-0 or
all-1 frag until it gets an answer.

To take Arun's example

   	 Sender               Receiver
             |-----W=1, CFN=6----->|
             |-----W=1, CFN=5----->|
             |-----W=1, CFN=4--X-->|
             |-----W=1, CFN=3----->|
             |-----W=1, CFN=2--X-->|
             |-----W=1, CFN=1----->|
             |-----W=1, CFN=0----->|
             |<-----ACK, W=1-------|bitmap:11010111
             |-----W=1, CFN=4----->|
             |-----W=1, CFN=2----->|
             |<-----ACK, W=1-------|no bitmap
             |-----W=0, CFN=6----->|
             |-----W=0, CFN=5----->|
             |-----W=0, CFN=4--X-->|
             |-----W=0, CFN=3--X-->|
             |-----W=0, CFN=2--X-->|
             |-----W=0, CFN=7----->|MIC checked
             |<-----ACK, W=0-------|bitmap:11000001
*
             |-----W=0, CFN=4----->|MIC checked: wrong
             |-----W=0, CFN=3----->|MIC checked: wrong
             |-----W=0, CFN=2----->|MIC checked: right*

*             |-----W=0, CFN=7----->|             |<-----ACK,
W=0-------|no bitmap*

This basic scenario can be optimized in two ways:

- All-1 or All-0 can be without data and the meaning is: give me the bitmap.

- if the window is full or if the MIC is right then the receiver can
spontaneously send the bitmap. If it is lost then

 the sender will send a All-0 or all-1 frag.

             |-----W=0, CFN=2--X-->|
             |-----W=0, CFN=7----->|MIC checked
             |<-----ACK, W=0-------|bitmap:11000001*
             |-----W=0, CFN=4----->|MIC checked: wrong
             |-----W=0, CFN=3----->|MIC checked: wrong
             |-----W=0, CFN=2----->|MIC checked: right*
*             |  X---ACK, W=0-------|no bitmap*

    timeout  |                     |

*             |-----W=0, CFN=7----->|             |<-----ACK,
W=0-------|no bitmap*

I tried to define a Finite State Machine describing this behavior for
both the sender and the receiver, see the ppt included (I didn't have
the courage

to do ascii art). If you are interested we can discuss that during the
interim meeting.

Laurent

On Wed, Aug 30, 2017 at 11:20 PM, Arun <[email-masked]> wrote:

> Hi Carels,
> I agree.
> just a thought:
>
> We need to reset the timer (on receiver) for ACKs (with bitmap) sent
> after 2^N-1?
> Also, we don't have to maintain MAX #of timeouts for this timer as it
> can be superseded by reassembly timeout.
>
>
> regards,
>
> On 30/08/2017 19:39, Carles Gomez Montenegro wrote:
> > Hi Arun, Pascal,
> >
> > Thanks to both for triggering this discussion, and sorry for the late
> > response (I was in vacation).
> >
> > There is new text in the github working version (not in -05) that touched
> > a bit on this matter, but I think that Arun's proposal below is much
> > better defined.
> >
> > That is:
> >
> >> Solution could be;
> >>  - Start the timer on the receiver;
> >>  - Check MIC for every retransmitted packet that is received;
> >>  - Send ACK:
> >>     - when timeout occurs or
> >>     - when MIC validation passes.
> >>
> >> your thoughts?
> > So this means that there would be a timer on the receiver side that would
> > be started for the first time upon reception of the fragment with
> > FCN=2^N-1.
> >
> > On the other hand, we need to add that the "ACK Always Timer" (which is
> > defined for the fragment sender) will not be used any more for the
> current
> > IPv6 packet after an ACK for the last window of the IPv6 packet is
> > received by the fragment sender.
> >
> > If there is agreement, we can add this mechanism in -06.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Carles
> >
> >
> >
> >>> We could avoid some of that by indicating the number of the last
> >>> message in the message CFN=2^N-1 one. If that last message was
> >>> received, then the missing one is the last 0 in the bitmap before it.
> >>> Else it is it. Knowing which is the last expected message in the retry
> >>> window, the receiver now can treat it as the CFN=2^N-1 of the retried
> >>> window.
> >>>
> >> We need some additional bits to indicate this number?  can you please
> >> elaborate?
> >>>
> >>>
> >>> Makes sense?
> >>>
> >>>
> >>>
> >>> Pascal
> >>>
> >>>
> >>>
> >>> *From:*lp-wan [mailto:[email-masked]] *On Behalf Of *Arun
> >>> *Sent:* mercredi 16 aoÃ»t 2017 10:50
> >>> *To:* Carles Gomez Montenegro <[email-masked]
> >>> <mailto:[email-masked]>>
> >>> *Cc:* lp-wan <[email-masked] <mailto:[email-masked]>>
> >>> *Subject:* [lp-wan] retransmission in the last window
> >>>
> >>>
> >>>
> >>> Hi Carles and all,
> >>>
> >>> Scenario : More than one fragment is lost in the last window of ACK
> >>> always mode;
> >>> Per my understanding, this is bit different than the retransmission
> >>> behavior that is observed in non-last window.
> >>> Since there can be lesser number of fragments than the window size in
> >>> the last window the receiver has to validate MIC and send ACK for every
> >>> received packet.
> >>> In other cases(other than the last window), the receiver shall wait
> >>> until the least CFN of the lost fragments before sending the ACK with
> >>> bitmap.
> >>>
> >>> example of the expected sequence: (took most part of it from Fig:20
> >>> draft-05)
> >>>
> >>>           Sender               Receiver
> >>>              |-----W=1, CFN=6----->|
> >>>              |-----W=1, CFN=5----->|
> >>>              |-----W=1, CFN=4--X-->|
> >>>              |-----W=1, CFN=3----->|
> >>>              |-----W=1, CFN=2--X-->|
> >>>              |-----W=1, CFN=1----->|
> >>>              |-----W=1, CFN=0----->|
> >>>              |<-----ACK, W=1-------|bitmap:11010111
> >>>              |-----W=1, CFN=4----->|
> >>>              |-----W=1, CFN=2----->|
> >>>              |<-----ACK, W=1-------|no bitmap
> >>>              |-----W=0, CFN=6----->|
> >>>              |-----W=0, CFN=5----->|
> >>>              |-----W=0, CFN=4--X-->|
> >>>              |-----W=0, CFN=3--X-->|
> >>>              |-----W=0, CFN=2--X-->|
> >>>              |-----W=0, CFN=7----->|MIC checked
> >>>              |<-----ACK, W=0-------|bitmap:11000001
> >>>              |-----W=0, CFN=4----->|MIC checked
> >>>              |<-----ACK, W=0-------|bitmap:11100001
> >>>        |-----W=0, CFN=3----->|MIC checked
> >>>              |<-----ACK, W=0-------|bitmap:11100001
> >>>        |-----W=0, CFN=2----->|MIC checked
> >>>        |<-----ACK, W=0-------|no bitmap
> >>>                             (End)
> >>>
> >>> is this the expected behavior?
> >>> if yes, an example in the "Appendix" of the draft and a discussion in
> >>> "Baseline mechanism" section would be useful (please ignore if it is
> >>> already planned in 06 version).
> >>>
> >>> 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: +33 (0)2.99.12.24.14
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Sep 2017 13:38:13 +0000

Hello Arun :

I’m confused now. Yes, there is a receive side timer in https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05#section-9.2

The text has :
“
When Window mode - ACK on error is used, the fragment receiver starts
   a timer (denoted "ACK on Error Timer") upon reception of the first
   fragment for an IPv6 datagram.  The initial value for this timer is
   not provided by this specification, and is expected to be defined in
   additional documents.  This timer is reset and restarted every time
   that a new fragment carrying data from the same IPv6 datagram is
   received.  In Window mode - ACK on error, after reception of the last
   fragment of a window (i.e. the fragment with CFN=0 or CFN=2^N-1),

“
How are we desync’ed?

Take care,

Pascal

From: Arun [mailto:[email-masked]]
Sent: mardi 29 août 2017 22:04
To: Pascal Thubert (pthubert) <[email-masked]>; Carles Gomez Montenegro <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: Re: [lp-wan] retransmission in the last window

Hello Pascal,

thanks for jumping in. my comments inline.
On 29/08/2017 15:50, Pascal Thubert (pthubert) wrote:

Hello Arun :

I did not see Carles’ answer. I’d not expect this behavior, though. I understand that the case is normally covered by a timer, either on sender (ack always) or receiver (ack on error).

The timer will elapse if the last packet in the window (CFN=0 or CFN=2^N-1 in the first try) is not processed through, regardless of how many other messages are lost, the timer will elapse and one way or another a bitmap is then sent back.

The draft doesn't specify any timer (other than reassembly timer for the complete packet) on the receiver side. So the sender is going to timeout multiple times until MAX_ACK_REQUESTS and then discard the packet finally because the receiver isn't going to send the ACK. The receiver doesn't know the ACK request fragment for the last window retransmission.

Solution could be;

your thoughts?

If the last message in the window is received, and the MIC does not match, then the bitmap is provided with the errors. Now: the text expects that the CFN=2^N-1 is not resent at the end of the retried window. So it is hard for the receiver to figure which is the last message of the retry window so as to treat it as the CFN=2^N-1 of the retried last window and ack then. IOW if there is a loss in the second try of the window, the loss will always cause a time out.
Agreed.

We could avoid some of that by indicating the number of the last message in the message CFN=2^N-1 one. If that last message was received, then the missing one is the last 0 in the bitmap before it. Else it is it. Knowing which is the last expected message in the retry window, the receiver now can treat it as the CFN=2^N-1 of the retried window.
We need some additional bits to indicate this number?  can you please elaborate?

Makes sense?

Pascal

From: lp-wan [mailto:[email-masked]] On Behalf Of Arun
Sent: mercredi 16 août 2017 10:50
To: Carles Gomez Montenegro <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: [lp-wan] retransmission in the last window

Hi Carles and all,

Scenario : More than one fragment is lost in the last window of ACK always mode;

Per my understanding, this is bit different than the retransmission behavior that is observed in non-last window.

Since there can be lesser number of fragments than the window size in the last window the receiver has to validate MIC and send ACK for every received packet.

In other cases(other than the last window), the receiver shall wait until the least CFN of the lost fragments before sending the ACK with bitmap.

example of the expected sequence: (took most part of it from Fig:20 draft-05)

          Sender               Receiver

             |-----W=1, CFN=6----->|

             |-----W=1, CFN=5----->|

             |-----W=1, CFN=4--X-->|

             |-----W=1, CFN=3----->|

             |-----W=1, CFN=2--X-->|

             |-----W=1, CFN=1----->|

             |-----W=1, CFN=0----->|

             |-----W=1, CFN=4----->|

             |-----W=1, CFN=2----->|

             |-----W=0, CFN=6----->|

             |-----W=0, CFN=5----->|

             |-----W=0, CFN=4--X-->|

             |-----W=0, CFN=3--X-->|

             |-----W=0, CFN=2--X-->|

                            (End)

if yes, an example in the "Appendix" of the draft and a discussion in "Baseline mechanism" section would be useful (please ignore if it is already planned in 06 version).

Thanks,

--

Arunprabhu Kandasamy

arun at ackl.io

35510 Cesson-Sévigné

France

--

Arunprabhu Kandasamy

arun at ackl.io

35510 Cesson-Sévigné

France

---

From: Arun <[email-masked]>
Date: Tue, 5 Sep 2017 23:54:29 +0200

Hello Pascal,

Its not the same behavior, reset timer for each received fragment, for
ACK always mode where I explained the problem.

thanks,

On 05/09/2017 15:38, Pascal Thubert (pthubert) wrote:
>
> Hello Arun :
>
>  
>
> I’m confused now. Yes, there is a receive side timer in
> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05#section-9.2
>
>  
>
> The text has :
>
> “
>
> *From:*Arun [mailto:[email-masked]]
> *Sent:* mardi 29 août 2017 22:04
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Carles Gomez
> Montenegro <[email-masked]>
> *Cc:* lp-wan <[email-masked]>
> *Subject:* Re: [lp-wan] retransmission in the last window
>
>  
>
> Hello Pascal,
>
>     I did not see Carles’ answer. I’d not expect this behavior,
>     though. I understand that the case is normally covered by a timer,
>     either on sender (ack always) or receiver (ack on error).
>
>      
>
>     The timer will elapse if the last packet in the window (CFN=0 or
>     CFN=2^N-1 in the first try) is not processed through, regardless
>     of how many other messages are lost, the timer will elapse and one
>     way or another a bitmap is then sent back.
>
>      
>
> The draft doesn't specify any timer (other than reassembly timer for
> the complete packet) on the receiver side. So the sender is going to
> timeout multiple times until MAX_ACK_REQUESTS and then discard the
> packet finally because the receiver isn't going to send the ACK. The
> receiver doesn't know the ACK request fragment for the last window
> retransmission.
>
> Solution could be;
>     If the last message in the window is received, and the MIC does
>     not match, then the bitmap is provided with the errors. Now: the
>     text expects that the CFN=2^N-1 is not resent at the end of the
>     retried window. So it is hard for the receiver to figure which is
>     the last message of the retry window so as to treat it as the
>     CFN=2^N-1 of the retried last window and ack then. IOW if there is
>     a loss in the second try of the window, the loss will always cause
>     a time out.
>
> Agreed.
>
>      
>
>     received, then the missing one is the last 0 in the bitmap before
>     it. Else it is it. Knowing which is the last expected message in
>     the retry window, the receiver now can treat it as the CFN=2^N-1
>     of the retried window.
>
>     *Sent:* mercredi 16 août 2017 10:50

-- 
Arunprabhu Kandasamy
arun at ackl.io