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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 4 Oct 2017 09:19:41 +0200

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.

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?

Thanks,

Carles

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Wed, 4 Oct 2017 19:01:11 +0000

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,
> 
> 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.
> 
> 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.
> 
> 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----->|
> 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

> 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).
> 

[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

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 26 Oct 2017 11:07:48 +0200

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:

> retry
> transmission
> fact,