[lp-wan] Compound ACK draft - Review

[Sergio Aguilar Romero <[e-mail]>]

Hello Dominique, all,

I have added the WG ML as requested.

Thanks for your review and PR. I have accepted the PR with all changes. The repo with version 05 proposal is here: https://github.com/saguilarDevel/compound-ack-draft <https://github.com/saguilarDevel/compound-ack-draft>

More comments below.

Best regards,

Sergio and Compound ACK authors


> On Jun 3, 2022, at 3:02 PM, [e-mail] <mailto:[e-mail]> wrote:
> 
> Hello Sergio, all,
>  
> I finally took the time to take a deep breath and dive into the compound-ack draft again.
> Congrats for pulling this together, it’s coming up very good, I think.
>  
> Please find below some comments, up to Section 3.1. I have also submitted a PR in a branch on GitHub for most suggestions, please browse the PR and cherry-pick the changes you want or don’t want.
> I’ll work and report on 3.2 and forward soon.
>  
> Finally, shouldn’t we have this conversation in public on the WG mailing list, for the shepherd, AD and all interested, today or later, to follow?
> Feel free to respond to the WG ML, as far as I’m concerned.
>  
> Best regards
>  
> Dominique
>  
> Section 1. Introduction: “It defines a SCHC Compound ACK format and procedure, which is intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC.”
> Just thinking, let’s try to write the SCHC Compound ACK format specification so that it is not tied to the ACK-on-Error algorithm, anticipating that a future “Super-ACK-algorithm” will be able to use the Compound ACK without updating this draft/RFC. This sentence is in the intro and not normative text, so no action is needed here. Just a hint.
>  

Totally agreed.

> Section 1. Introduction: “has the same SCHC ACK format defined in when only one window with losses is reported,”
> Actually, I think this is no longer true, because of the M zero bits that are now sometimes required after the last bitmap of the Compound ACK.
> Suggested action: remove this sentence.
>  

Suggestion taken, thanks for spotting this.


> Section 3. SCHC Compound ACK:
> Although it may seem obvious, I suggest adding a sentence similar to that of RFC8724 8.3.2.
> “The SCHC Compound ACK MAY be used in fragmentation modes that use windows and that allow reporting the bitmaps of multiple windows at the same time, and MUST NOT be used otherwise.”
> As of today, the only such mode is ACK-on-Error as modified by this draft, but others might come in the future.
> Suggested action: Dominique to propose above text in GitHub Pull Request.
>  

Suggestion taken.

> Section 3.1 SCHC Compound ACK Message Format
> “ The SCHC Compound ACK message format is shown in Figure 2.”
> Actually, it seems the message format has two forms which are shown in Figure 2 and 3.
> Suggested action: Dominique to propose text change in GitHub.
>  

Suggestion taken.

> “If more than M padding bits are needed”
> Actually, “if M or more padding bits are needed”. With exactly M bits of padding, you still have an ambiguity: the M bits could be a window number followed by a fully compressed bitmap (of length zero, which can happen). Unless you intend to preclude the fragmentation algorithm (current and future) from sending a bitmap with all 1 bits (before compression) in a Compound ACK? If that is the intention, such a statement is missing from your text.
> Suggested action: write “if M or more padding bits are needed” (Dominique as part of the GitHub PR)
>  

Suggestion taken.

> “the first M bits MUST be 0-padded”.
> MUST be 0’s. Being “0-padded” means more zeroes are appended to the M bits.
> Actually, I suggested that the M zero bits are considered part of the message, and the bits after that are the padding bits. Just a nuance.
> Suggested action: Dominique to propose text change in GitHub.
>  

Suggestion taken.

> “To avoid confusing the M '0s' padding bits with Window number 0, if present in the SCHC Compound ACK, Window number 0 MUST be placed as w1.”
> The normative MUST is redundant with that in Section 3, just above 3.1.
> I suggest to change this MUST into a comment : “Since window number 0, if present in the message, is placed as w1, the M bits set to zero can’t be confused with window number 0, and signal the end of the SCHC Compound Ack”.
> Suggested action : Dominique to provide text in the GitHub PR.
>  

Totally agreed. Suggestion taken.

> “The RECOMMENDED value for the padding bits is 0” and “The RECOMMENDED padding value is 0”.
> I don’t think this is needed any more. It may be needed as part of the schc-over-sigfox profile, but this is a different scope.
> Suggested action: remove these statements. Dominique to provide text update in the GitHub PR.
>  

In RFC8724, section 9, it states that the recommended value for padding bits is 0. Since now padding bis are arbitrary, I thought we should add something similar to this statement of section 9.

If you think is not needed, then we can removed it. Just wanted to let you know why was there.

For now, the statements will be removed.

> “are less than M bits”
> Same discussion as above. I suggest “are strictly less than M bits”.
>  

Agreed.

> “The optional usage of this Compressed Bitmap for the last bitmap MUST be specified by the SCHC technology-specific profile”
> My experience is that this is insufficient guidance for the profile author.
> Is "runtime implementation choice" a valid option for the profile, or must the profile say either YES or NO?
>  

What kind of guidance do you think can be sufficient? For example, we can modify current text to: 

“The optional usage of this Compressed Bitmap for the last bitmap MUST be specified by the SCHC technology-specific profile. For the sake of simplicity, and to avoid interoperability issues, runtime implementation choice MUST NOT be allowed by a profile.” 

We believe that “runtime implementation choice" may overcomplicate the usage of the Compound ACK, and may do interoperability more difficult. As how does a receiver (of the Compound ACK) know whether the last bitmap has been compressed or not? Does the receiver need additional functionality? Moreover, “runtime implementation choice” is not specified in RFC8724. It is better to let the profile say what they are using (LoRaWAN compressed bitmap, Sigfox uncompressed bitmap). If a profile wants to allow or specify the "runtime implementation choice," then that additional functionality needs to also be specified in the profile.

Other guidance may include that, in fixed downlink L2 MTU sizes, the maximum number of windows that can be carried in a single Compound ACK can be calculated. At the end, with fixed downlink L2 MTU sizes, compressing or not the bitmap has little effect in the resulting transmitted frame, as padding will be added anyway. One example of taken into consideration the number of windows is the Sigfox profile, where one ACK-on-Error Mode has 12 tiles per window and up to 4 windows. This combination of values allows a single Compound ACK to carry information of up to 4 windows in a single downlink frame, when error are present in all windows.

> Figures 4 and 5
> I see them as examples. I have proposed some text changes in the description, in the GitHub PR.
>  

Thanks for the PR, the review and all the comments.

> From: Sergio Aguilar Romero [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: 26 May 2022 13:57
> To: BARTHEL Dominique INNOV/IT-S <[e-mail] <mailto:[e-mail]>>
> Cc: Juan Carlos Zuniga <[e-mail] <mailto:[e-mail]>>; Carles Gomez Montenegro <[e-mail] <mailto:[e-mail]>>; Rafael Vidal <[e-mail] <mailto:[e-mail]>>; Sandra Cespedes <[e-mail] <mailto:[e-mail]>>; Diego Wistuba <[e-mail] <mailto:[e-mail]>>; Laurent Toutain <[e-mail] <mailto:[e-mail]>>; Juan Carlos Zuniga <[e-mail] <mailto:[e-mail]>>
> Subject: Re: Compound ACK draft - Receiver-Abort message
>  
> Hello Dominique, hope you are doing fine.
>  
> Have you got time to check the new version of the compound ack draft? 
>  
> I was hoping we can publish a new version by the end of the month, so Alexandre can continue the Shepard process.
>  
> Thanks for your comments and review.
>  
> Best regards,
>  
> Sergio
> 
> 
> On May 16, 2022, at 1:34 PM, Sergio Aguilar Romero <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hello Dominique and all,
>  
> Hope you are doing fine.
>  
> Thanks for all your comments and reviews, they have been really helpful.
>  
> We modified version 04 and proposed a new version 05. 
>  
> The repo of the latest version can be found here:
> https://github.com/saguilarDevel/compound-ack-draft <https://github.com/saguilarDevel/compound-ack-draft>
>  
> The diff between version 04 and version 05 can be found here:
> https://github.com/saguilarDevel/compound-ack-draft/commit/7ef1192f342192bf3b4f516039f7a0af0eaf0fc6 <https://github.com/saguilarDevel/compound-ack-draft/commit/7ef1192f342192bf3b4f516039f7a0af0eaf0fc6>
>  
> Besides from the additions coming from your comments, we have added some examples with the bitmap compression in the last bitmap of the SCHC Compound ACK and some fixes in the figures. 
>  
> Moreover, I have added you to the GitHub repo if you want to commit, or you can do a pull request, thanks again for the review. The latest version of the draft is in the file version 05 xml.
>  
> More comments below.
>  
> Cheers,
>  
> Sergio
>  
>  
> 
> 
> On Apr 4, 2022, at 10:13 AM, [e-mail] <mailto:[e-mail]> wrote:
>  
> Hello Sergio, all,
> 
> Thanks for digging into the matter and coming back to me.
> We have different points here, let me try to address them separately.
> 
> 1.) Distinguishing the Receiver-Abort from the SCHC Compound ACK
> You are totally right, the SCHC Compound ACK has a C bit reset to 0, while the Receiver-Abort has a C bit set to 1, therefore they are distinguishable.
> 
> In RFC8724 Section 8.3.5 (Receiver-Abort), we wrote " The SCHC Receiver-Abort has the same header as a SCHC ACK message" and then we explain why Receiver-Abort is distinguishable based on its greater length.
> It turns out that the SCHC Compound ACK has a the same header as a SCHC ACK message, and it has a greater length. This prompted my question.
> In retrospect, we should have written in RFC8724: "The SCHC Receiver-Abort has the same header as a SCHC ACK message with C=1", and then the SCHC Compound ACK would have immediately stood out.
> 
> Therefore, two options:
> - either you write nothing in schc-compound-ack about this issue, everything is correct, but the reader may have to think a bit (like I did :-) )
> - or you add a note like "Note: the SCHC Compound ACK has a C bit reset to 0, while the Receiver-Abort has a C bit set to 1, therefore they are distinguishable."
> 
>  
> We have added the Note to version 5 and removed any other reference to the Receiver-Abort, other than in the introduction.
>  
> 
> 
> 2.) Value of the padding bits
> Please note that RFC8724 does not mandate the value of the padding bits. The whole text is written with an undefined value for the padding bits, and the specification works for an undefined value of the padding bits.
> Only Section 9 says " A Profile MUST define the value of the padding bits if the L2 Word is wider than a single bit. The RECOMMENDED value is 0."
> 
> If the schc-compound-ack is an extension of RFC8724, is it possible that it is written along the same principle?
> 
>  
> There has been some discussion regarding this subject. We found the following solution: The actual number of padding bits that are required to be 0 is equal to M bits. Therefore, it is only necessary to have M bits with value 0, after, the padding bits may be of any value (undefined value). If there are less than M padding bits, padding bits may be of any value (undefined value). 
>  
> I would like to see your thoughts over this idea, of having M bits with 0 value to signal the end of the SCHC Compound ACK. Based on the idea of the Receiver-Abort, instead of using a complete L2 word with value 1,  we are using M bits with 0 value, when more than M bits are required to be padded.
>  
> This is presented and explained in Figures 2 and 3 of version 05.
>  
> 
> 
> 3.) Profile for Sigfox
> I still need to refresh my memory on the schc-over-sigfox draft.
> However, in the meantime, I have an observation regarding your comment below:
> 
> In the case of the SCHC over Sigfox draft, the Receiver-Abort and the success SCHC ACK are of the same size, as the DL Frame must be of 64 bits.
> In this case, the Receiver-Abort will have 7 or 8 L2 Words (bytes in case of Sigfox) of 1s, depending of the Single or Two-byte header size,
> and the success SCHC ACK will have the same number of L2 words, but with 0-padding.
> Isn't it simpler to just state that, on Sigfox downlinks, the messages are padded to 64 bits and that padding bits are 0's?
> The Receiver-Abort and the "success" SCHC ACK would both end with 0's, but the Receiver Abort would include at least eight more bits set to 1 than the SCHC ACK, therefore there are distinguishable.
> By doing so, you would not be redefining the SCHC message formats, just the padding rule.
> 
> Note that RFC8724 does not rely on the value of the padding bits, but it relies on getting from L2 the length of the SCHC message, which I understand sigfox does not provide for downlinks.
> However, SCHC is asymmetrical in the way it encodes ACKs, trailing 1's are chopped off, not trailing 0's. Therefore, with a padding bit value of 0, a 1-to-0 transition is your end-of-message marker (true for compressed SCHC ACK, but also for Receiver-Abort).
> Therefore, hopefully, whenever there is ambiguity on the length of the SCHC message, we are in the lucky situation where we have a guaranteed 1-to-0 transition at the end of the SCHC message.
> That's the angle with which I would approach the sigfox profile... 
> Looking forward to reading the schc-over-sigfox draft soon.
>  
>  
> We are working on an update of the draft. We have modified the SCHC Receiver-Abort message accordingly.
> 
> 
> 4.) Profile for LoRaWAN
> 
> In the case of the SCHC over LoRaWAN (RFC9011), they already considered that the success SCHC ACK and the Receiver-Abort should be different
> (by adding an extra L2 Word of 1s). Therefore, I think that there should not be any issues with the Receiver-Abort and the Compound ACK for the RFC9011.
> Note that RFC9011 does not change the specification of the Receiver-Abort. It only illustrates in drawings what the same message format looks like, after applying the specific LoRaWAN parameters (size of rule, size of W, etc.)
> 
> 
> the Receiver-Abort message as defined in [RFC8724] and in [RFC9011].
> Again, RFC9011 does not define the Receiver-Abort message.
> If at all possible, this schc-compound-ack draft should not have to refer to RFC9011 whatsoever, it should be written such that RFC9011 *just works* with the new compound-ack.
> 
>  
> We removed the point regarding the differentiation of the Receiver-Abort and SCHC Compound ACK, as mentioned before, they are different and it should work with current profiles.
>  
> 
> 
> 5.) Your proposed actions
> - no proposed change in the Introduction : agreed
> - Section 3.1, proposed new text "...". My proposed new text: “Note: because it has a C bit reset to 0, the SCHC Compound ACK is distinguishable from the Receiver-Abort message [RFC8724], which has a C bit set to 1."
> - in Section 4, remove [the last bullet point]. Agreed
> 
> Also as promised, some nit fixes to come (as PR into GitHub) soon.
>  
> Thanks, I have added you to the GitHub repo. Let me know if you need anything.
>  
> 
> 
> 
> Best regards
> 
> Dominique
> 
> 
> -----Original Message-----
> From: Sergio Aguilar Romero [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: 28 March 2022 12:29
> To: BARTHEL Dominique INNOV/IT-S <[e-mail] <mailto:[e-mail]>>
> Cc: Juan Carlos Zuniga <[e-mail] <mailto:[e-mail]>>; Carles Gomez Montenegro <[e-mail] <mailto:[e-mail]>>; Rafael Vidal <[e-mail] <mailto:[e-mail]>>; Sandra Cespedes <[e-mail] <mailto:[e-mail]>>; Diego Wistuba <[e-mail] <mailto:[e-mail]>>
> Subject: Compound ACK draft - Receiver-Abort message
> 
> Hello Dominique,
> 
> First of all, thanks for all your comments and reviews.
> 
> I have reviewed the subject of the Receiver-Abort and the Compound ACK. I made a mistake, I thought that how to differentiate the Receiver-Abort from the Compound ACK was part of the requirements of Appendix D, but after your comment, I went back to check and found that it is not part of the Appendix D.
> 
> Therefore, I think that what is stated in RFC8724 regarding the Receiver-Abort, and how it should differentiate from the ACK is still valid. RFC8724 states that:
> "The SCHC Receiver-Abort has the same header as a SCHC ACK message. The bits that follow the SCHC Receiver-Abort Header MUST be as follows:¶
>             • if the Header does not end at an L2 Word boundary, append bits set to 1 as needed to reach the next L2 Word boundary.
>             • append exactly one more L2 Word with bits all set to ones.
> Such a bit pattern never occurs in a legitimate SCHC ACK. This is how the fragment sender recognizes a SCHC Receiver-Abort.”
> 
> As the Receiver-Abort has the C bit set to 1, it should differentiate from the success SCHC ACK, which format is not modified by the Compound ACK draft. Moreover, to differentiate the Compound ACK from the Receiver-Abort (besides the C bit value), the Compound ACK is padded with 0, while the Receiver-Abort is padded with 1s and has a fixed size. 
> 
> In the case of the SCHC over Sigfox draft, the Receiver-Abort and the success SCHC ACK are of the same size, as the DL Frame must be of 64 bits. In this case, the Receiver-Abort will have 7 or 8 L2 Words (bytes in case of Sigfox) of 1s, depending of the Single or Two-byte header size, and the success SCHC ACK will have the same number of L2 words, but with 0-padding. The Compound ACK will have the C bit equal to 0, and 0-padding.
> 
> In the case of the SCHC over LoRaWAN (RFC9011), they already considered that the success SCHC ACK and the Receiver-Abort should be different (by adding an extra L2 Word of 1s). Therefore, I think that there should not be any issues with the Receiver-Abort and the Compound ACK for the RFC9011.
> 
> As each LPWAN technology has its own requirements regarding padding and frame sizes, I thought each one should indicate how they differentiate the Receiver-Abort from the Compound ACK, but it really should be, how the Receiver-Abort is different form the success ACK format, which is already stated in RFC8724.
> 
> Below I have added a list of actions to take.
> 
> Actions:
> 
> In the Introduction of the Compound ACK draft is already stated that the Compound ACK is distinguishable from the Receiver-Abort. No action to take.
> 
> 
> Changes in the Compound ACK draft:
> ---------------------------------------------
> In section 3.1 change: “
> Each different SCHC LPWAN technology profile MUST specify how the
>   SCHC Compound ACK is different from the Receiver-Abort message as per
>   [RFC8724], e.g., the Receiver-Abort message is padded with 1s with an
>   extra byte appended at the end, while the SCHC Compound ACK is
>   0-padded."
> 
> To new text (proposal):
> “The SCHC Compound ACK is different from the Receiver-Abort message as defined in [RFC8724] and in [RFC9011]."
> ---------------------------------------------
> 
> In section 4, remove: “
>   *  Differentiation between SCHC Receiver-Abort and SCHC Compound ACK
>      message, e.g., Receiver-Abort message padded with 1s with an extra
>      byte appended at the end, while the SCHC Compound ACK is 0-padded.”
> ---------------------------------------------
> 
> I am not sure if we should go into details of the Receiver-Abort message format, or copy again the text (shown above) of how to make the Receiver-Abort different from the ACK format that is already in the RFC8724.
> 
> Please let me know any comments or feedback.
> 
> Thanks again for all the review and comments.
> 
> Best regards,
> 
> Sergio
> 
> 
> 
> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
>  
> _________________________________________________________________________________________________________________________
> 
> 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.