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

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 16:15:50 +0200

Description
<https://trac.ietf.org/trac/lpwan/ticket/21#comment:description>

The C bit has been added to know if the MIC check was correct or not. But
this C bit consumes one bit of the Bitmap space, this means that the number
of fragments will be reduced to one for the last window.
So the implementations need to calculate the number of fragments taking
this into account.
Changed 0 seconds ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-04-03T07%3A14%3A01-07%3A00&precision=second>
 by ana@…
------------------------------

IETF 101

The ACK format for All-0 is different from the ACK format for the All-1
window. We have introduced the use of C bit which uses one bit from the
Bitmap:

   - ACK FORMAT

<--------- R -------->

<- T -> 1

+---- ... --+-... -+-+---- ... -----+
| Rule ID | DTag |W|encoded Bitmap| (no payload)
+---- ... --+-... -+-+---- ... -----+

   - Padding may be added if needed

   - ACK Format, last window

<---------- R --------->

<- T -> 1 1

+---- ... --+-... -+-+-+
| Rule ID | DTag |W|1| (MIC correct)
+---- ... --+-... -+-+-+

+---- ... --+-... -+-+-+----- ... -----+
| Rule ID | DTag |W|0|encoded Bitmap |(MIC Incorrect)
+---- ... --+-... -+-+-+----- ... -----+

                     C

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.
Ana: Could make the last window shorter than the previous ones.
Dominique:

   - Two options:
      - 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.
      - 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.

Carles: I think it is fine as it is (option 1). Maybe it's connected that I
am the author, but I think we can just rephrase it.
Laurent: I think we should document it, but it seems fine. It is really
rare the case anyway (that the window size would be constrained by the L2
PDU size).
Alex: Could we provide this in tech specific document?
Pascal: We can not leave to tech specific technology documents as there is
not an option provided.
[post-meeeting note by Dominique: Pascal, I now understand what you meant:
we could describe the two behaviors and leave it to the tech document to
decide which one to use. Currently, we specify only one option or the other
and leave no choice to the technology-specific document. I will ask for
feedback from the group.]

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 16:42:05 +0200

Hello,

I like the way is done today, I mean with the option 1, where the
implementation is free to give its solution but that needs to take in
consideration that there is 1 fragment less in the last window. So the last
window is shortest of 1 fragment, so when you divide your packet into
fragments you decide how to do it.

Ana

On Tue, Apr 3, 2018 at 4:15 PM, Ana Minaburo <[email-masked]> wrote:

> 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.
>       - not change the behavior, add explicit warning in the text that,
>       if L2 payload size is the limit to your window size, developers should
>       always has one fragment less than the other windows This way, the bitmap in
> Carles: I think it is fine as it is (option 1). Maybe it's connected that
> I am the author, but I think we can just rephrase it.