Subject: [lp-wan] Ticket #21 C bit in ACK

From: ana minaburo <[email-masked]>
Date: Tue, 17 Apr 2018 11:49:28 +0200

Hello,

The link to this ticket is here:

https://trac.ietf.org/trac/lpwan/ticket/21

The C bit has been introduced to know if the MIC check was correct or not,
and so the last window is 1 bit smaller than the others.

The format of the acks that are not last is different from that of the last
one. In the last one, there is a C bit that signifies if the MIC matched.
So the last ack has one more bit than the previous ones. Is it a problem or
not. It may be on technologies with small L2 payloads.

Two options:
Option 1 (actual solution in draft): not change the behavior, add explicit
warning in the text that, if L2 payload size is the limit to your window
size, developers should remember that the window size needs to be one
fragment shorter than they would think to look at the All-0 ACK format, in
order to accommodate for the extra bit of the All-1 ACK.

Option 2: or we could change the behavior and specify that the last window
always has one fragment less than the other windows This way, the bitmap in
the All-1 ACK has one less bit, and there is always room, by design, for
the extra bit.

Which solution is better for you?

Ana: I prefer option 1, the fragmentation solution is open to the
implementations. The draft does not mandate a possibility.

And you?

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 13:42:35 +0000

Hello all,

Let me restate the issue here.
In a straightforward interpretation of the current draft, for each SCHC Packet, the SCHC ACKs are of equal maximum size for all windows of SCHC Fragments but the last one. The maximum size of the last SCHC ACK is one bit more because of the C bit.

Representing below the maximum size. In many cases, the actually size of the transmitted SCHC ACK will be shorter because of trailing 0xFF bytes trimming.
ACK1 |xxx…xxx|
ACK2 |xxx…xxx|
ACK3 |xxx…xxx|
…
ACK4 |xxx…xxx|
ACK5 |xxx…xxx|
ACKL |xxx…xCxx|

The question is : is this 1-bit bump a problem?
The proposed solutions are described in Ana's mail below.

I prefer Option 1.
I hadn't realised this, but looking at Ana's comment "the fragmentation solution is open to the implementations. The draft does not mandate a possibility.", I understand that the draft as it is now (I.e. Option 1) neither mandates that the last window has less fragments (obviously), nor precludes it, interestingly.
I'll carefully read the draft again to make sure it actually doesn't preclude it.

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 17 April 2018 11:49
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Ticket #21 C bit in ACK

Hello,

The C bit has been introduced to know if the MIC check was correct or not, and so the last window is 1 bit smaller than the others.

The format of the acks that are not last is different from that of the last one. In the last one, there is a C bit that signifies if the MIC matched. So the last ack has one more bit than the previous ones. Is it a problem or not. It may be on technologies with small L2 payloads..

Two options:
Option 1 (actual solution in draft): not change the behavior, add explicit warning in the text that, if L2 payload size is the limit to your window size, developers should remember that the window size needs to be one fragment shorter than they would think to look at the All-0 ACK format, in order to accommodate for the extra bit of the All-1 ACK.

Option 2: or we could change the behavior and specify that the last window always has one fragment less than the other windows This way, the bitmap in the All-1 ACK has one less bit, and there is always room, by design, for the extra bit.

Ana: I prefer option 1, the fragmentation solution is open to the implementations. The draft does not mandate a possibility.

And you?

_________________________________________________________________________________________________________________________

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: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 24 Apr 2018 16:01:29 +0200

Hi everyone,

I also prefer option 1.

In my opinion, restricting the functionality currently supported (in the
context of this ticket) provides no benefit. What option 2 allows is just
a subset of what is allowed by option 1.

Cheers,

Carles

> In a straightforward interpretation of the current draft, for each SCHC
> Packet, the SCHC ACKs are of equal maximum size for all windows of SCHC
> Fragments but the last one. The maximum size of the last SCHC ACK is one
> bit more because of the C bit.
>
> Representing below the maximum size. In many cases, the actually size of
> the transmitted SCHC ACK will be shorter because of trailing 0xFF bytes
> trimming.
> ACK1 |xxx…xxx|
> ACK2 |xxx…xxx|
> ACK3 |xxx…xxx|
> …
> ACK4 |xxx…xxx|
> ACK5 |xxx…xxx|
> ACKL |xxx…xCxx|
>
> I hadn't realised this, but looking at Ana's comment "the fragmentation
> solution is open to the implementations. The draft does not mandate a
> possibility.", I understand that the draft as it is now (I.e. Option 1)
> neither mandates that the last window has less fragments (obviously), nor
> precludes it, interestingly.
> De : lp-wan <[email-masked]<mailto:[email-masked]>> on
> behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
> À : "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> The format of the acks that are not last is different from that of the
> last one. In the last one, there is a C bit that signifies if the MIC
> matched. So the last ack has one more bit than the previous ones. Is it a
> problem or not. It may be on technologies with small L2 payloads..
>
> Two options:
> always has one fragment less than the other windows This way, the bitmap
> in the All-1 ACK has one less bit, and there is always room, by design,
> for the extra bit.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 24 Apr 2018 16:04:00 +0200

Hi,

I'm also in favor of option 1

Laurent

On Tue, Apr 24, 2018 at 3:42 PM, <[email-masked]> wrote:

> De : lp-wan <[email-masked]> on behalf of ana minaburo <
> [email-masked]>
> À : "[email-masked]" <[email-masked]>

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 24 Apr 2018 14:09:18 +0000

+1

I also think that option 1 gives the flexibility needed.

Best, 

Juan Carlos 

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Carles Gomez
> Montenegro
> Sent: April 24, 2018 10:01 AM
> To: [email-masked]
> Cc: [email-masked]; ana minaburo <[email-masked]>
> Subject: Re: [lp-wan] Ticket #21 C bit in ACK
> 
> Hi everyone,
> 
> I also prefer option 1.
> 
> context of this ticket) provides no benefit. What option 2 allows is just a
> subset of what is allowed by option 1.
> 
> Cheers,
> 
> Carles
> 
> 
> > Hello all,
> >
> > In a straightforward interpretation of the current draft, for each
> > SCHC Packet, the SCHC ACKs are of equal maximum size for all windows
> > of SCHC Fragments but the last one. The maximum size of the last SCHC
> > ACK is one bit more because of the C bit.
> >
> > Representing below the maximum size. In many cases, the actually size
> > of the transmitted SCHC ACK will be shorter because of trailing 0xFF
> > bytes trimming.
> > ACK1 |xxxâ€¦xxx|
> > ACK2 |xxxâ€¦xxx|
> > ACK3 |xxxâ€¦xxx|
> > â€¦
> > ACK4 |xxxâ€¦xxx|
> > ACK5 |xxxâ€¦xxx|
> > ACKL |xxxâ€¦xCxx|
> >
> > I hadn't realised this, but looking at Ana's comment "the
> > fragmentation solution is open to the implementations. The draft does
> > not mandate a possibility.", I understand that the draft as it is now
> > (I.e. Option 1) neither mandates that the last window has less
> > fragments (obviously), nor precludes it, interestingly.
> > De : lp-wan <[email-masked]<mailto:[email-masked]>>
> > on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>> Date :
> > Tuesday 17 April 2018 11:49 Ã€ :
> > "[email-masked]<mailto:[email-masked]>"
> > The C bit has been introduced to know if the MIC check was correct or
> > not, and so the last window is 1 bit smaller than the others.
> >
> > matched. So the last ack has one more bit than the previous ones. Is
> > it a problem or not. It may be on technologies with small L2 payloads..
> >
> > Two options:
> > Option 1 (actual solution in draft): not change the behavior, add
> > explicit warning in the text that, if L2 payload size is the limit to
> > your window size, developers should remember that the window size
> > needs to be one fragment shorter than they would think to look at the
> > All-0 ACK format, in order to accommodate for the extra bit of the All-1
> ACK.
> >
> > Option 2: or we could change the behavior and specify that the last
> > window always has one fragment less than the other windows This way,
> > the bitmap in the All-1 ACK has one less bit, and there is always
> > room, by design, for the extra bit.
> >
> ________________________________________________________________
> ______
> > ___________________________________________________
> >
> > 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.