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

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 5 Sep 2017 17:41:15 -0500

Comment on retransmission procedures:
I was reading mails in this chain, I have a question and a comment:

Are these procedures part of a Layer 3 protocol?

If yes, I think that you are in layer violation boundary.
Such procedures should be done either in Layer 2 or in Layer 4, transport
layer.

My two cents.

Regards,
Behcet

On Tue, Sep 5, 2017 at 4:54 PM, Arun <[email-masked]> wrote:

> 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 :
>
> “
>
> 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] <[email-masked]>]
> *Sent:* mardi 29 août 2017 22:04
> *To:* Pascal Thubert (pthubert) <[email-masked]> <[email-masked]>;
> Carles Gomez Montenegro <[email-masked]> <[email-masked]>
> *Cc:* lp-wan <[email-masked]> <[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;
>  - 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?
>
> 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] <[email-masked]>] *On
> Behalf Of *Arun
> *Sent:* mercredi 16 août 2017 10:50
> *To:* Carles Gomez Montenegro <[email-masked]>
> *Cc:* lp-wan <[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
>
>
>
> 2 bis rue de la Châtaigneraie
>
> 35510 Cesson-Sévigné
>
> France
>
> Phone: +33 (0)2.99.12.24.14 <+33%202%2099%2012%2024%2014>
>
>
>
> --
>
> 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 <+33%202%2099%2012%2024%2014>
>
>
>
> _______________________________________________
> lp-wan mailing [email-masked]://www.ietf.org/mailman/listinfo/lp-wan
>
>
> --
> 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 <+33%202%2099%2012%2024%2014>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 6 Sep 2017 10:20:42 +0200

Hi Behcet,

This is in an adaptation layer between an LPWAN technology (L2) and Layer 3
(IPv6). Layer 3 is not modified but header is compressed and datagram may
be fragmented by SCHC.

Laurent

On Wed, Sep 6, 2017 at 12:41 AM, Behcet Sarikaya <[email-masked]>
wrote:

>> Its not the same behavior, reset timer for each received fragment, for
>> ACK always mode where I explained the problem.
>>
>>
>> thanks,
>>
>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-con
>> text-hc-05#section-9.2
>>
>>
>>
>> The text has :
>>
>> “
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> *From:* lp-wan [mailto:[email-masked] <[email-masked]>]
>> *On Behalf Of *Arun