Subject: [lp-wan] All-1 empty

From: Bart Moons <[email-masked]>
Date: Thu, 13 Sep 2018 17:12:23 +0200

Dear lpwan-ers,

While implementing the fragmentation scheme, I came across the following situation, where the all-1 empty format is used.
Imagine the following situation with MAX_WIND_FCN = 6 and N = 3:

sender FCN BM receiver
SEND 6 --------------> 1 RECV_W
5 --------------> 11
4 --------------> 111
3 --------------> 1111
7 -------x------> 11110
WAIT_BM
timer expires
WAIT_BM 7 --------------> 11111 (*) RECV_W

(**) 7 <-------------- mic = 0, bm = 11111, fcn = 7
all-1 && mic == 0 &&
local bitmap = bitmap
ERROR

(*) here the sender will send an all-1 empty fragment without the original payload.
the receiver will set the bitmap, since an all-1 fragment was received
however, since the original payload is missing, the mic is incorrect
(**) the sender will get an acknowledgement with a correct bitmap, but with an incorrect mic
and will abort the connection

I can see that when an acknowledgement is lost, resending the original fragment results in a lot of overhead,
however, aborting the complete packet reception because of 1 missing fragment results in a lot more overhead.
(what if the last packet of a 1500 byte packet would be lost?)

Wouldn't it be better to resend the original packet each time the retransmission timer expires?

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab
iGent Tower - Department of Information Technology
Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium
T: +32 472 42 23 91
E: [email-masked]
W: http://IDLab.UGent.be
W: http://idlab.technology

---

From: <[email-masked]>
Date: Thu, 13 Sep 2018 15:20:43 +0000

Hello Bart,

When receiving an All-x Empty Fragment, the bit must not be set in the Bitmap. An ACK must be sent back.
In your example, the sender will receive the Bitmap with the last bit at 0, so it will send the All-1 (non-empty) fragment and this will conclude the fragmented packet transmission nicely.
We are currently working on rewrite the fragmentation section, we'll make sure this is correctly specified.
BTW, in the next version of the document, the All-x Empty Fragments are going to be called All-x SCHC ACK REQ, so that they are better understood as what they are, ACK requests, not fragments.
Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Bart Moons <[email-masked]<mailto:[email-masked]>>
Date : Thursday 13 September 2018 17:12
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] All-1 empty

Dear lpwan-ers,

sender FCNBM receiver
SEND 6--------------> 1 RECV_W
5--------------> 11
4--------------> 111
3--------------> 1111
7-------x------> 11110
WAIT_BM
timer expires
WAIT_BM 7--------------> 11111 (*)RECV_W

(**)7 <--------------mic = 0, bm = 11111, fcn = 7
all-1 && mic == 0 &&
local bitmap = bitmap
ERROR

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab

_________________________________________________________________________________________________________________________

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.

---

From: Bart Moons <[email-masked]>
Date: Thu, 13 Sep 2018 17:31:33 +0200

Hi Dominique,

Thanks for the clarification and sorry for the bad formatting in the previous mail.
An all-0 empty fragment will be easy to track down, since the sender expects a payload.
However, in some situations the all-1 frame will not carry any payload, since the MIC will not always fit in the previous fragment.
Will there be some way to indicate the received fragment is an empty all-1 in order to conclude the transmission?

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

On Sep 13 2018, at 5:20 pm, [email-masked] wrote:
> De : lp-wan <[email-masked] (mailto:[email-masked])> on behalf of Bart Moons <[email-masked] (mailto:[email-masked])>
> À : "[email-masked] (mailto:[email-masked])" <[email-masked] (mailto:[email-masked])>
> sender FCNBMreceiver
> SEND 6-------------->1 RECV_W
> 5-------------->11
> 4-------------->111
> 3-------------->1111
> 7-------x------>11110
> WAIT_BM
> timer expires
> WAIT_BM 7-------------->11111 (*)RECV_W
>
> (**)7<--------------mic = 0, bm = 11111, fcn = 7
> all-1 && mic == 0 &&
> local bitmap = bitmap
> ERROR
>
> _________________________________________________________________________________________________________________________ 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.
>

---

From: <[email-masked]>
Date: Thu, 13 Sep 2018 15:36:57 +0000

I did not get the last part of your question
> However, in some situations the all-1 frame will not carry any payload, since the MIC will not always fit in the previous fragment.
Can you please describe the situation?
In my understanding, there should be no ambiguity between an All-1 Fragment and an Empty All-1 Fragment (aka All-1 SCHC ACK REQ), but we may have failed to clearly explain why in the specification.
Thank you for helping us improve it.

Dominique

De : Bart Moons <[email-masked]<mailto:[email-masked]>>
Date : Thursday 13 September 2018 17:31
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] All-1 empty

Hi Dominique,

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

On Sep 13 2018, at 5:20 pm, [email-masked]<mailto:[email-masked]> wrote:
Hello Bart,

Dominique

Dear lpwan-ers,

sender FCNBMreceiver

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab

---

From: <[email-masked]>
Date: Thu, 13 Sep 2018 15:39:50 +0000

I think I got your question.
The answer is:
Look at the following text in –16, Section 8.4.2

An All-1 fragment payload MUST be at least the size of an L2 Word.
   The rationale is that the All-1 empty fragment (see Section 8.4.2.1<https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8.4.2.1>)
   needs to be distinguishable from the All-1 fragment, even in the
   presence of padding.  This may entail saving an L2 Word from the
   previous fragment payload to make the payload of this All-1 fragment
   big enough.

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Thursday 13 September 2018 17:36
À : Bart Moons <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] All-1 empty

Dominique

Hi Dominique,

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

Dominique

Dear lpwan-ers,

sender FCNBMreceiver
SEND 6-------------->1RECV_W
5-------------->11
4-------------->111
3-------------->1111
7-------x------>11110
WAIT_BM
timer expires
WAIT_BM 7-------------->11111(*)RECV_W

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab

---

From: Bart Moons <[email-masked]>
Date: Thu, 13 Sep 2018 18:00:51 +0200

The situation I wanted to describe is the following:

RULE_SIZE_BITS = 8
W_SIZE_BITS = 1
DTAG_SIZE_BITS = 0
FCN_SIZE_BITS = 3
MIC_SIZE_BITS = 16

The MTU of the underlying technology is 12 bytes and the last fragment size is 10 bytes

Sending this fragment won't work, since the MIC + FCN + W + RULE consists of more than 3 bytes, thus
a normal fragment is sent, without MIC.
The last fragment will then contain the MIC without any payload.
However, the receiver thinks this is an all-1 empty fragment and thus replies with the last bit set to 0,
which will trigger the retransmission of the all-1 fragment.

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

On Sep 13 2018, at 5:39 pm, [email-masked] wrote:
> An All-1 fragment payload MUST be at least the size of an L2 Word. The rationale is that the All-1 empty fragment (see Section 8.4.2.1 (https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16#section-8.4.2.1)) needs to be distinguishable from the All-1 fragment, even in the presence of padding. This may entail saving an L2 Word from the previous fragment payload to make the payload of this All-1 fragment big enough.
>
> Dominique
>
> De : lp-wan <[email-masked] (mailto:[email-masked])> on behalf of Dominique Barthel <[email-masked] (mailto:[email-masked])>
> À : Bart Moons <[email-masked] (mailto:[email-masked])>
> Cc : "[email-masked] (mailto:[email-masked])" <[email-masked] (mailto:[email-masked])>
> De : Bart Moons <[email-masked] (mailto:[email-masked])>
> À : Dominique Barthel <[email-masked] (mailto:[email-masked])>
> Cc : "[email-masked] (mailto:[email-masked])" <[email-masked] (mailto:[email-masked])>
> On Sep 13 2018, at 5:20 pm, [email-masked] (mailto:[email-masked]) wrote:
> > Hello Bart,
> >

---

From: <[email-masked]>
Date: Fri, 14 Sep 2018 06:53:33 +0000

Helo Bart,

This is exactly what the quoted text is supposed to say.
Don't send the "before last" fragment with 10 bytes. Send it with 9 bytes.
Therefore, you are left with 1 byte remaining for the "really last" fragment, which has the MIC.
Therefore it is distinguishable from an "empty All-1".
Does this make sense ?
Best regards,

Dominique

Date : Thursday 13 September 2018 18:00

  *   RULE_SIZE_BITS  =   8
  *   W_SIZE_BITS         =   1
  *   DTAG_SIZE_BITS  =   0
  *   FCN_SIZE_BITS     =   3
  *   MIC_SIZE_BITS     =   16

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

On Sep 13 2018, at 5:39 pm, [email-masked]<mailto:[email-masked]> wrote:
I think I got your question.
The answer is:
Look at the following text in –16, Section 8.4.2

Dominique

Dominique

Hi Dominique,

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

Dominique

Dear lpwan-ers,

sender FCNBMreceiver

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab

---

From: Bart Moons <[email-masked]>
Date: Fri, 14 Sep 2018 09:22:34 +0200

Hi Dominique,

Understood. Thanks for the clarification!

Regards,
Bart Moons
Ghent University - imec
IDLab

On Sep 14 2018, at 8:53 am, [email-masked] wrote:
> On Sep 13 2018, at 5:39 pm, [email-masked] (mailto:[email-masked]) wrote:

---

From: <[email-masked]>
Date: Fri, 14 Sep 2018 07:29:41 +0000

Great!

Also, while we are at talking about fragments, read this in –16 Section 8.4.1

                 To build the fragment payload, SCHC F/R MUST
   take from the SCHC Packet a number of bits that makes the SCHC
   Fragment an exact multiple of L2 Words.  As a consequence, no padding
   bit is used for these fragments.

Therefore, in your example, for FCN != All-x, the fragment payload Is not 10 bytes, it is 84 bits.

Dominique
Date : Friday 14 September 2018 09:22

Hi Dominique,

Regards,

Bart Moons
Ghent University - imec
IDLab

On Sep 14 2018, at 8:53 am, [email-masked]<mailto:[email-masked]> wrote:
Helo Bart,

Dominique

  *   RULE_SIZE_BITS  =   8
  *   W_SIZE_BITS         =   1
  *   DTAG_SIZE_BITS  =   0
  *   FCN_SIZE_BITS     =   3
  *   MIC_SIZE_BITS     =   16

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

Dominique

Dominique

Hi Dominique,

Regards,
Bart

Bart Moons
Ghent University - imec
IDLab

Dominique

Dear lpwan-ers,

sender FCNBMreceiver

Kind regards,
Bart

Bart Moons
Ghent University - imec
IDLab