Subject: Re: [lp-wan] Problem with downlink fragmentation (and proposed solution)

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 6 Nov 2017 19:29:04 +0100

Hi Laurent,

Thanks a lot for the great figures!

I have two comments, and then I copy the text I propose for describing the
ACK retry mechanism (for downlink fragmentation, ACK Always).

Comments:

- With regard to your last figure, as per Alexander's proposal, the last
two ACK transmissions would not be needed (please see the last paragraph
in my proposed text, which should hopefully capture Alexander's proposal).

- I understand a fragment may be temporarily buffered in some element
(e.g. the NGW as you indicate), but it may depend also on the underlying
LPWAN technology. For example, buffering may happen at the entity
performing fragmentation itself (or there may be other possibilities).

Proposed description of the ACK retry mechanism (to be added in section
5.8, after the currently existing paragraph):

   For fragmented packet transmission in the downlink, and when ACK Always
   is used, the fragment receiver MAY support timer-based ACK
   retransmission. In this mechanism, the fragment receiver initializes and
   starts a timer (denoted "ACK Retry timer") after the transmission of an
   ACK, except when the ACK is sent in response to the last fragment of a
   packet. In the latter case, the fragment receiver does not start a timer
   after transmission of the ACK.

   If, after transmission of an ACK that is not a response to the last
   fragment of the packet, and before expiration of the corresponding ACK
   Retry timer, the fragment receiver receives a fragment that belongs to
   the next window, the ACK Retry timer for the ACK is stopped. However, if
   the ACK Retry timer expires, the ACK is resent and the ACK Retry timer
   is reinitialized and restarted.

   The default initial value for the ACK Retry timer, as well as the
   maximum number of retries for a specific ACK, denoted MAX_ACK_RETRIES,
   are not defined in this document, and need to be defined in other
   documents (e.g. technology-specific profiles). The initial value of the
   ACK Retry timer is expected to be greater than that of the ACK Always
   timer, in order to make sure that a (buffered) fragment to be
   retransmitted can find an opportunity for that transmission.

   When the fragment sender transmits the last fragment of a packet, it
   initializes and starts its retransmission timer (ACK Always timer) to a
   long value (e.g. several times the initial ACK Retry timer). If an ACK
   is received before expiration of this timer, the fragment sender
   retransmits any lost fragments reported by the ACK, or if the ACK
   confirms successful reception of all fragments of
   the last window, transmission of the fragmented packet ends.
   If the timer expires, and no ACK has been received since the
   start of the timer, the fragment sender assumes that the last
   fragment has been successfully received (and possibly, the last ACK
   has been lost: this mechanism assumes that the ACK Always timer for the
   last fragment is long enough to allow several ACK retries if the last
   fragment has not been received by the fragment receiver, and it also
   assumes that it is unlikely that several ACKs become all lost).

Cheers,

Carles

> Hi Carles,
>
> Thank you to raise this element for the FSM.
> As we discussed yesterday, I think we can solve the problem with only on
> Downlink message at the time and then generalize if with a special uplink
> request. I will also reverse the scenario it is easier for me (uplink from
> the left to the right).
>
> A exchange without losses looks like that:
>
>            D                  Network
>            |                     |
> DL request |-------------------->|
>    Wbitmap |<--------------------| W=0; FCN=0; data
> BM=01      |-------------------->|
>            |<--------------------| W=1; FCN=0; data
> BM=11      |-------------------->|
>            |<--------------------| W=0; FCN=0; data
> BM=01      |-------------------->|
>            |<--------------------| W=1; FCN=0; data
> BM=11      |-------------------->|
>            |<--------------------| W=0; FCN=1; data
> BM=01      |-------------------->|
>
>
>
> if a all-0 is lost:
>
>            D                  Network
>            |                     |
> DL request |-------------------->|
>            |<--------------------| W=0; FCN=0; data
> BM=01      |-------------------->|
>         |  |        x------------| W=1; FCN=0; data
>         |  |                     | |
>         |  |                     | |
>         |  |                     | v
>         |  |                     H W=1; FCN=0; data
>         v  |                     H
> BM=01      |-------------------->H ignored since w is wrong
>            |<--------------------|
>
>
>
> The sender  timer expire, the frag is sent again but blocked by the NGW.
> In
> any case, we can say that the device expect data since it has not received
> FCN=1. The device must send a UL to get it. Timer must be higher than the
> one used by the fragmenter.
>
> If bitmap is lost (the FSM states are shown: on the left hand-side which
> window is expected, and in the right hand-side which is the current
> window).
>
>              D                  Network
>        expect|                     | current window
>             v|                     | v
> DL request  0|-------------------->| 0|
>             0|<--------------------| 0|  W=0; FCN=0; data
> BM=01       1|-------------------->| ----------------------
>             1|<--------------------| 1|  W=1; FCN=0; data
> BM=11       0|----------X          | 1|   |
>           | 0|                     | 1|   |
>           | 0|                     | 1|   |
>           | 0|                     | 1|   |
>           | 0|                     | 1|   |
>           | 0|                     | 1|   v
>           | 0|                     H 1|  W=1; FCN=0; data
>           v 0|                     H 1|
> BM=11       0|-------------------->H -------------
> ignore w==1 0|<--------------------H 0|  frag is NGW sent
> BM=11       0|-------------------->| 0|  W==1; ignored
>             1|<--------------------| 0|  W=0; FCN=0; data
> BM=01       1|-------------------->| -------------
>
> In that case, the fragmentation side sends again the frag, which is
> buffered in the NGW.
> Then the receiver timer expires which triggers the bitmap retransmission.
>
>
> For an All-1 lost, the scenario is almost the same, the receivers knows
> that all fragmentation
> ends with an All-1. So the same timer in the receiver side can be used to
> request a DL transmission
>
>
>            D                  Network
>            |                     |
> DL request |-------------------->|
>            |<--------------------| W=0; FCN=0; data
> BM=01      |-------------------->|
>         |  |        x------------| W=1; FCN=1; data
>         |  |                     | |
>         |  |                     | |
>         |  |                     | v
>         |  |                     H W=1; FCN=1; data
>         v  |                     H
> BM=01      |-------------------->H ignored since w is wrong
>            |<--------------------H
> BM=11      |-------------------->| end
>
>
> if the bitmap is lost, it is more complex, I don't remember clearly Alex's
> proposal. The problem is that the
> receiver state machine considers that the transmission is over, and I
> don't
> see why it should send
> again the bitmap to be sure that the sender has received it.
>
>             1|<--------------------| 1|  W=1; FCN=1; data
> BM=11       e|----------X          | 1|   |
>           | e|                     | 1|   |
>           | e|                     | 1|   |
>           | e|                     | 1|   |
>           | e|                     | 1|   |
>           | e|                     | 1|   v
>           | e|                     H 1|  W=1; FCN=1; data
>           v e|                     H 1|
> BM=11       e|-------------------->H e
>             e|<--------------------H e
>             e|-------------------->| e
>             e|                     | e
>
> Laurent
>
>
> On Wed, Oct 4, 2017 at 9:01 PM, Juan Carlos Zuniga <
> [email-masked]> wrote:
>
>> Hi Carles,
>>
>> > -----Original Message-----
>> > From: lp-wan [mailto:[email-masked]] On Behalf Of Carles
>> Gomez
>> > Montenegro
>> > Sent: October 4, 2017 3:20 AM
>> > To: [email-masked]
>> > Subject: [lp-wan] Problem with downlink fragmentation (and proposed
>> > solution)
>> >
>> > Dear LPWANners,
>> >
>> > I would like to report a possible problem with downlink fragmentation
>> in
>> > Window mode - ACK Always, and a possible solution for it.
>> >
>> > The problem
>> > ***********
>> >
>> > Let us assume *downlink* transmission of an IPv6 packet that requires
>> > fragmentation, and ACK Always mode. Recall that in some LPWAN
>> > technologies and scenarios, a number of downlink transmissions can
>> only
>> be
>> > performed after reception of an uplink frame that allows the
>> opportunity
>> for
>> > downlink transmissions.
>> >
>> > As an example, let us assume a window size of 4 fragments is used (and
>> > supported by the lower layer technology as well), and an IPv6 packet
>> that
>> > requires 6 fragments to be carried. In the example, after an uplink
>> frame that
>> > triggers transmission in the downlink, the first 4 fragments are
>> transmitted
>> > and successfully delivered to the receiver. Since ACK Always is used,
>> an
>> ACK is
>> > sent by the receiver (to confirm that all those first 4 fragments were
>> > successfully received). But the ACK is lost.
>> >
>> > If the ACK is lost, the ACK Always timer will expire and the sender
>> will
>> > attempt a retry of the last fragment sent (as a way to request the
>> ACK).
>> > However, since transmission of the fragments is in the downlink, such
>> retry
>> > will not be possible without an uplink frame transmission that allows
>> the
>> > opportunity to transmit further downlink frames:
>> >
>> >    ----> downlink
>> >    <---- uplink
>> >
>> >             Sender               Receiver
>> >               |<-- trigger UL ------|
>> >               |-----W=0, FCN=3----->|
>> >               |-----W=0, FCN=2----->|
>> >               |-----W=0, FCN=1----->|
>> >               |-----W=0, FCN=0----->|
>> >          lost |<--X--ACK, W=1-------|no bitmap
>> >           (*) |-----W=0, FCN=0----->|
>> >
>> >    (*) This fragment should be (re)sent, but it will not be possible
>> >        without a previous uplink frame
>> >
>> > At this point, i.e. after loss of the ACK, fragmented IPv6 packet
>> transmission
>> > would stall as per the current SCHC draft. Something similar would
>> happen if
>> > some of the fragments had been lost and the ACK (with a
>> > bitmap) was lost.
>> >
>> [JCZ] True. This would be a problem
>>
>> >
>> > Possible solution
>> > *****************
>> >
>> > A possible solution to the above problem would be to allow the
>> receiver
>> to
>> > resend the ACK after some time without receiving further fragments. In
>> fact,
>> > the receiver can tell that the packet transmission has not finished at
>> the
>> > moment of transmission of the ACK, since it has not received yet the
>> "all-1"
>> > fragment (FCN=2^N-1, e.g. FCN=7 in the example).
>> >
>> > This means adding a timer at the receiver for downlink fragment
>> > transmission  (possibly as an optional feature).
>> >
>> > What does the WG think about adding this feature to the SCHC draft?
>> >
>> > Do you see other approaches to solve the above mentioned problem?
>>
>> [JCZ] I think that the proposed solution makes sense and it is a minor
>> change to the current spec.
>> The specific timer value could be defined in an eventual SCHC-over-foo
>> document.
>>
>> Best,
>>
>> Juan Carlos
>>
>> >
>> > Thanks,
>> >
>> > Carles
>> >
>> > _______________________________________________
>> > lp-wan mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/lp-wan
>>
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 8 Nov 2017 18:42:54 +0100

Hello,

I ask you the same thing during the interim meeting. When we have a downlink flow the ONLY fragmentation reliable option is the ACK always but it needs some modifications, is this right? 

So the device needs to support the timer-based ACK retransmission. How about the first fragment that I need to send? One idea could be, as the device sends regularly data to the gateway I can piggyback a request to the ACK of this regular information to reinitialize my transmission?

Ana

Ana Minaburo

Research Division

Phone: +33 (0)2.99.12.24.14
ana at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 

www.acklio.com

> On 06 Nov 2017, at 19:29, Carles Gomez Montenegro <[email-masked]> wrote:
> 
> Hi Laurent,
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 17 Nov 2017 03:29:28 +0100

Hello Ana,

(Apologies for the delay.)

> I ask you the same thing during the interim meeting. When we have a
> downlink flow the ONLY fragmentation reliable option is the ACK always but
> it needs some modifications, is this right?

As I see it, the answer is yes (in the scenarios for which those
modifications are required).

In ACK on error, and in the scenarios where an uplink message is needed to
allow transmitting a downlink message, there is a problem for packets that
exceed the size of a window of fragments: if a window of (downlink)
fragments is correctly received, the receiver does not generate an ACK,
and therefore an uplink message (that would trigger the transmission of
the next fragments) will not be transmitted, stalling the fragmented
packet transmission.

It is true that some other approach (e.g. sending uplink L2 ACKs, which is
somewhat an "ACK Always") may be used, but if an L2 ACK is lost,
fragmented packet transmission stalls anyway.

And since currently, and typically, the window size for many of those
scenarios for downlink fragmentation is "one fragment", the problem exists
even for the smallest fragmented packets.

> So the device needs to support the timer-based ACK retransmission. How
> about the first fragment that I need to send? One idea could be, as the
> device sends regularly data to the gateway I can piggyback a request to
> the ACK of this regular information to reinitialize my transmission?

For the first fragment, I think the sender can only wait until the
receiver (the device, Dev) transmits successfully some uplink message.

If the Dev periodically transmits uplink messages, one of those
transmissions can serve as the trigger for transmitting the first downlink
fragment (as you say). If there have to be "frequent" opportunities for
downlink fragmented transmission, the Dev needs to "frequently" transmit
uplink messages, so there is a trade-off here...

Cheers,

Carles