Subject: [lp-wan] variable fragment size : Fragmentation problem.

From: Nicolas Sornin <[email-masked]>
Date: Wed, 12 Sep 2018 13:32:25 +0000

Dear LPWAN contributors.

While attempting an implementation of the SCHC fragmentation algorithm over LoRaWAN we encountered a severe problem.
In LoRaWAN the available payload size can vary on a packet per packet basis for many reasons:

·         The packet may contain MAC commands in the Fopt field reducing the space vailable for application payload

·         The data rate may be adjusted at any moment by the network, hence modulating the max application payload size available.

The cool thing with the current scheme is that all fragments may have a different size , so I was very happy with this until we started to try retransmissions.
An uplink fragment gets lost, the receiver send the all-0 ACK with a bitmap indicating the missing fragments.
But the available payload is now smaller than previously (because the data rate has gone down for example), the sender has to use smaller fragment size, but how ? This cannot be handled currently because the retransmitted fragment must be identical to the one originally transmitted.

The only solution I can think of so far, is to limit the fragment size to the smallest possible available payload size, but this ruins the efficiency of the entire scheme, because each small fragment now bears the protocol addressing + security overhead.

Any idea would be much appreciated.

Nicolas.

From: lp-wan <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, September 7, 2018 4:12 PM
To: Laurent Toutain <[email-masked]>
Cc: lp-wan <[email-masked]>; BARTHEL Dominique IMT/OLPS <[email-masked]>
Subject: Re: [lp-wan] Increasing window index size

WARNING - External Email
________________________________
Hello all

It seems that a window count that never wraps and a single window are pretty much the same thing from the transmission standpoint.

 Just that this enables intermediate check points that may be missed, in which case confusion arises, thus Juan Carlos’s proposal etc... iow the alternate check points are more are than good in terms of algorithms.

The problem with the single window is the size of the bitmap.

The best of both worlds could be to send a single window but reply errors with bitmap snippets, a snippet being the same as the nth smaller window. So if my window is indexed in 10 bits and my ack bitmap can only be 6 bits, I can signal the snippet offset using 4 bits and then the bitmap. The result is the same as ack on error but all the recovery happens in the end, so we avoid the checkpoint problem.

Would that simplify the logic?

Regards,

Pascal

Le 7 sept. 2018 à 14:38, Laurent Toutain <[email-masked]<mailto:[email-masked]>> a écrit :
Hi Dominique,

I think that we may impose for this mode that the window number never rolls down. You must have enough numbers for your entire packet.
The math I gave in an example are encouraging and Ethernet frame need only 1 byte to number the windows and the FCN. With longer fragment this can also be the case of Edgar's jumbograms.

If you don't have enough windows you can use Ack Always. I'm not sure it necessary to merge both behaviors. For example when you have finish one window round you must collect all the Ack before going to the next round.

Laurent

Laurent

On Fri, Sep 7, 2018 at 11:02 AM <[email-masked]<mailto:[email-masked]>> wrote:
[Changing the subject line to be more accurate]

Hello Laurent,

I read and understood your proposal.
I have one question, though. You say:
> The protocol works even if we loose all the ack, since …
Do you mean it?
What about the following situation (with W now on 2 bits)?

  W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |---------X.  |
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
        |             |
    W = 1 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 2 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 3 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |<------------| 0/1101111
  0/4   |------------>|

What fragment will be re-transmitted ? Do you manage the ambiguity between the first W=0 window and the second W=0 window? Or is this just a rare case that leads to an error (the MIC will be wrong)?
Thanks

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date : Friday 7 September 2018 09:06
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Increasing window size

Hi,

I think we have a very good meeting last Wednesday and we are very close to a global solution for fragmentation.

As I said during the meeting, the w bit should be extended to a window field of variable size (as FCN). This will help to avoid confusion when ack a window. Current Ack on err suffers of this, since we have only 2 windows (0 and 1) the solution fails is 2 donwlink ack are lost.

Lets take W size of 3 bits and FCN of 3 bits.

  W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |---------X.  |
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
        |             |
   W = 1 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
   W = 2 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |----------X  |
  FCN=0 |------------>|
        |<------------| 0/1101111
  0/4   |------------>|
        |<------------| 2/1111101

We have the Ack on error behavior. If a window is full then no ack is send. In the scenario, the first window is acked since one frag is missing. The ack is lost, after a timeout since the sender receives nothing he continues with the next window. The window is well received but since the receiver dodn’t get the missing frag on w=0 it continues to ack it. The ack is lost, then sender continues with w=2. At the end it still ack w=0, it receives the missing frag. The w=1 is full then it acks the w=2 with the missing frag. If w=2 was totally received, the w=2 will not have been acked.

The protocol works even if we loose all the ack, since we still mandate to ack explicitly the All-1 window.

The impact on the header size is not that big. If we take one of the worst case, for instance 8 Byte of payload for frag and a 1500 Byte packet with FCN size of 3.

We need 188 frag. So 27 windows; So 5 bits for w and 3 bytes for FCN, i.e. a Byte. This may be a good solution for Edgar’s jumbogram.

Another good property is that it limits the size of the bitmap. We can so in the future imagine a hierarchical bitmap, as proposed by Carles, if MTU changes.

I didn't do a deep analyze of all the strange cases, but I wanted to have your opinion before going further.

Laurent

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: <[email-masked]>
Date: Wed, 12 Sep 2018 15:30:54 +0000

Hello Nicolas,

You're right, the current Fragmentation/Reassembly mechanism is designed under the assumption that the L2 PDU does not change during the whole transmission of a SCHC Packet.
In –16, this is written as follows (Section 8.1)
"This document also assumes that the L2 data unit size does not vary
   while a fragmented SCHC Packet is being transmitted."

My answer is that, in the situation you describe, the sender has no other choice that aborting the fragmented SCHC Packet transmission and start again with the new L2 PDU size.
This may be better than preventively always fragmenting with the smallest possible L2 PDU.

Having said that, Laurent can probably teach you a few tricks that could solve your issue in a subtle way, but we ruled them out at Montreal by agreeing that the All-0 windows MUST be fully utilised.
If you shout loudly, who knows, the case might be reopened?

Best regards,

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Nicolas Sornin <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 12 September 2018 15:32
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] variable fragment size : Fragmentation problem.

Dear LPWAN contributors.

Nicolas.

From: lp-wan <[email-masked]<mailto:[email-masked]>> On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, September 7, 2018 4:12 PM
To: Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>; BARTHEL Dominique IMT/OLPS <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] Increasing window index size

WARNING - External Email

Regards,

Pascal

Laurent

Laurent

Hello Laurent,

Do you mean it?

  W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |---------X.  |
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
        |             |
    W = 1 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 2 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 3 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
    W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|

Dominique

Hi,

  W = 0 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |---------X.  |
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
        |             |
   W = 1 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |------------>|
  FCN=0 |------------>|
        |   X---------| 0/1101111
        |             |
   W = 2 |             |
  FCN=6 |------------>|
  FCN=5 |------------>|
  FCN=4 |------------>|
  FCN=3 |------------>|
  FCN=2 |------------>|
  FCN=1 |----------X  |
  FCN=0 |------------>|

Laurent

Thank you.