Subject: Re: [lp-wan] WGLC on SCHC for IPv6 and UDP

From: <[email-masked]>
Date: Tue, 16 Jan 2018 13:55:18 +0000

Hello Pascal, all,

I'm still working on the review of this document.
I'm sorry I've been unable to provide my comment in time.
Can an extension of the deadline be considered?
Say, a few days?
Thanks

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date : Friday 22 December 2017 17:19
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] WGLC on SCHC for IPv6 and UDP

Dear WG:

As discussed during the last interim, we are starting a WGLC on the “LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP” document:

https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/

This is a fundamental work for the WG, so please, DO review the document and DO provide your comments and remarks if you see any issues.

In order to cover the season break, this WGLC will end in three+ weeks, on January 15th, 2018, 23h55 CEST, right before our next interim meeting.

Best,

Pascal and Alexander

_________________________________________________________________________________________________________________________

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: Sun, 21 Jan 2018 16:27:13 +0000

Dear all,

Please find below my comments up to section 4, included.
Authors, I have also issued a Pull Request on GitHub for dozens of suggested improvements to the text. They only address nits, and do not change the intended meaning of the text.
Anything that warrants discussion is reported in the notes below.
I'll be happy to discuss these comments on the mailing list or directly with the authors if anything I write is not clear enough.
Please bear with me as I sort out and type my notes for the remaining sections. This is taking me such a looooong time, I really wish I was done and could move on.
Best regards

Dominique

General suggestions
I suggest we define a term for the "compressed IPv6 packet which still exceeds the L2 MTU size or that could not be compressed for lack of an applicable SCHC rule".
If we introduce a diagram that shows the SCHC compressor on top of the fragmentation machine, that term could appear on this diagram.
That would make some text much more readable.

According to the terminology, SCHC C/D is on the (core) network side. However, several places in the text mention "the SCHC C/D … on both sides". This contradicts the definition in the terminology. In my perception, SCHC C/D is a compressor/decompressor using SCHC, and SCHC is symmetrical in essence, therefore a SCHC C/D exists on both sides. Shouldn't we find a better name for the SCHC C/D that sits on the core network side?

This document should provide a list of all parameters that a technology-specific document shall specify.

I suggest we coin a term (e.g. "Field Description") to designate a line in the rule table, and add it to the Terminology. This would make the text that describes the compression process much easier to read.

I suggest we coin a term (e.g. "compression residue") to describe what is left of a packet header to be carried over the LPWAN, not including the Rule ID. This would make the texte describing the compression, transmission and decompression much easier to read. The ideal compression is to reduce the header to only a Rule ID. In non-deal cases, the compression results in the Rule ID and some "left-over", which I think of as a residue. This is what Figure 4 describes as "Compressed Hdr Fields information", but this term is not currently used elsewhere in the text and is not very accurate ("Header Fields compressed information" would be slightly better).

In the downlink direction, is the SCHC C/D responsible for finding the L2 destination address to be used on the LPWAN, based on the L3 (IPv6) packet header? This is hinted at in 4.5.5.
If this is indeed one of the missions of SCHC C/D, this should be listed in the general description.

Detailed comments, ordered by appearance in the document

In the Terminology section (section 3)

  *   App: why is it described as an LPWAN application? This is confusing because it does not reside in the LPWAN. It leads the reader to think this is the application residing in the Device
  *   the APP-IID definition needs improving.  SUGGESTED: "Second part of the IPv6 address that identifies the application server interface"

In Section 3, SCHC, introductory text
"The SCHC C/Ds on both sides must share the same set of Rules.". This is in contradiction with the terminology : According to the terminology, SCHC C/D is on the (core) network side. Therefore, there is no SCHC C/D on both sides. In my perception, SCHC C/D is a compressor/decompressor using SCHC, and SCHC is symmetrical in essence, therefore a SCHC C/D exists on both sides. Shouldn't we find a better name for the SCHC C/D that sits on the core network side?

In section 4.1
"This Rule ID identifies a rule that matches as much as possible the original". Is there anything as a longest match in SCHC C/D? This sentence might be misleading.

I suggest we capitalise the term "Field Description" to designate a line in the rule table, and add it to the Terminology. This makes the following text easier to read.

"The Rule also describes the compressed header fields which are transmitted regarding their position in the rule which is used for data serialization on the compressor side and data deserialization on the decompressor side." I couldn't make sense of this sentence. I suggest re-phrasing.

Field Length (FL): this description should reiterate that the compressor/decompressor is assumed to know if a field is of fixed or variable length. Otherwise, the reader might be puzzled that this field can have two meanings but there is no explicit indication of which meaning applies, in a given situation.

In section 4.3, Packet processing
"When doing compression in the NGW side the SCHC C/D needs to find the correct Rule to be used by identifying its Dev-ID and the Rule-ID."
I'm not sure what you mean. I understand the SCHC C/D needs to find the correct Rule to be used. Is "by identifying … " the way to find or the consequence of having found?

"In the Dev, only the Rule-ID may be used." Do you mean to the Rule ID is all you need to identify the correct Rule since a Dev only holds rules that apply to itself?

"so the fields that do not correspond to the appropriated DI will be excluded."
If a field is "excluded", what happens? Is the Rule discarded and SCHC proceeds to explore the next Rule? If the rest of the Rule matches, is compression applied without the "excluded" field? If yes, what happens to the content of the field? Is there a requirement that the all field are described in both directions, either through a DI=Bi field descriptor or through a pair of (DI=Up, DI=Dw) field descriptors?

"Once the DI and the FP correspond to the header information, each field's value "
Each Field Description has a DI and FP. Do you mean "If all DIs and FPs of the Field Description correspond to the header, each field's value" ? This is related to question immediately above (If a field is "excluded", what happens?)

"in which case the fragmentation process must be required."
I guess you mean "may be required".

"sending: The Rule ID is sent to the other end followed by the information resulting from the compression of header fields, directly followed by the payload."
See my suggestion in the General comments to coin a term like "compression residue" to ease this description.

"decompression: In both directions, the receiver identifies the sender through its device-id  (e.g. MAC address)"
Some LPWAN technologies don’t have a source address on the downlink, therefore this sentence does not apply.
How about "decompression: the receiver selects the appropriate Rule through the Rule ID. If a source identifier is present in the L2 technology, it is used to select the namespace for the Rule ID."

There is some text related to padding just before Fig 4. There should be a forward reference to the section "Padding Management".

Section 4.4, Matching operators

"both SCHC C/D"endpoints. Contradicts the terminology section which states that SCHC C/D in on the network side.

MSB(length): why does MSB need a parameter? If the TV can be of any type, such as structured data, why can't the MSB operator compare a number of bits of the TV equal to the TV length? After all, the match-mapping operator compares the field value with all values in the TV (which is a list), without needing the length of the list as a parameter.

Section 4.5, introductory text

In the table of Figure 5, regarding LSB action, do you really want an OR operator in the decompression action? If TV is exactly of size length as I suggest above, then you don't need the parameter to the LSB action, and you want a concatenation operator. I understand an OR makes sense if TV is the size of the header field. But then you need to specify some masking as well, otherwise a TV value with non-zero bits on the LSB part will alter the bits transmitted (the lsbs). I suggest that TV is defined to be of exactly size length, then the decompression action is simply: TV + received value (where + is the bit-concatenation operator). This is mostly an implementation issue, but it also changes slightly the way the specification can be written, and also the way TV value is represented in the rule modelling language.

In the table of Figure 5, regarding the LSB action, the length parameter is not the same of the length parameter of the MSB Matching Operator above.
In section 4.5.4, I understand that the length parameter of the LSB action is not necessarily equal to original field size – length of the MSB MO.
If this is true, use different names such as length1 and length2. Otherwise, write "LSB(original field size – length)" in the table.

"Compression is done in the rule order and compressed values are sent in that order in the compressed message."
If we define the terms "Field Description" and "Compression Residue" as I suggested in the general comments above, this sentence could become:
"Compression is done in order that Field Descriptions appear in the Rule. The result of each compression action is appended to the working Compression Residue in that same order.

"If the field is identified as being variable, then its size must be sent first using the following coding:"
The term "field" is ambiguous. To me, it refers to the field in the original packet header. However, if the text "it size must be first sent using …" means "its size must be sent ahead of its value using …", I understand that the variable size refers to the compression residue of the field, not the original field itself. Does it make a difference? Obviously not for the {value-sent, compute-*, Deviid, Appiid} actions. I suppose that the mapping-sent action has index sizes statically known to both sides. However, for the LSB action, the residue (I.e., the lsb bits being sent) could be of variable length. This would results in "longest left aligned" matching and elision. For not-sent action, having the variable length refer to the original field value could be used to represent "n leftmost bits" from the TV in the context. Can this be useful?

"If the size is between 0 and 14 bytes, it is sent using 4 bits.". Even though it is quite intuitive, rather specify "If the size is between 0 and 14 bytes, it is sent as a 4 bits integer".

"For values between 15 and 255, the first 4 bits sent are set to 1 and the size is sent using 8 bits."
I can think of many ways of encoding the values 15 to 255 on 8 bits. Even if I guess from the next sentence that the 0xFF combination should not be used, this still leaves many possibilities. None of them comes to my mind as obvious.
Or did you mean ""For values between 15 and 254"?
I'm guessing your intention was to represent 15 with 0xf0f and 254 with 0xffe. If so, I suggest to write "For sizes between 15 and 255, the first 4 bits sent are set to 1 and the next 8 bits contain the value of size as an 8 bits integer."

"For higher value, the first 12 bits are set to 1 and the size is sent on 2 bytes."
I suggest: "For higher values of size, the first 12 bits are set to 1 and the next two bytes contain the size value as a 16 bits integer."

Section 4.5.1., not-sent CDA
This text could use the notion of Compression Residue, if adopted, instead of "compressed header".
"The decompressor restores the field value with the target value stored in the matched rule". I suggest to write "The decompressor restores the field value with the target value stored in the rule identified by the Rule ID received", even though it should be the same rule. The rule matching does not happen on the compressor but on the compressor, so my suggested text more accurately describes what happens on the decompressor.

We could allow the variable size feature for the not-sent CDA. See discussion above.
In which case this text should specify that the compressor dose not send any value, but I can send a size.

Section 4.5.4, LSB CDA
"The decompressor combines the value received with the Target Value".
I think we should describe more precisely what "combining" means. See my comment of the OR operator in Figure 5.

"If this action is made on a variable length field, the remaining size in byte has to be sent before."
I can't make sense of this sentence. See my comment above on whether "variable length" applies to the original header field or to the Compression Residue.

Section 4.5.5 DEViid, APPiid CDA
"In the downstream direction, these CDA may be used to determine the L2 addresses used by the LPWAN."
I couldn't make sense of this sentence. Are you talking about the compressor? Figure 5 says it elides this field.
Are you talking about generating an L2 address to be used on the LPWAN based on the L3 DestAddr field? This functionality has not been described anywhere else in the document. If it is an intended function of the SCHC C/D, this should be mentioned in the introduction.

Section 4.5.6 Compute-*
"These classes of functions are used by the decompressor to compute the compressed field value based on received information".
Generally speaking, the decompressor does not compute the compressed field value.
In addition, as is, this sentence is true to all CDAs: they are all used to compute the original field value based on received information.
I suggest to remove this sentence altogether.

"For instance, regarding  the field ID, this CDA may be used to compute IPv6 length or UDP length."
I cannot make sense of the "regarding the field ID," part.

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 16 January 2018 14:55
À : Pascal Thubert <[email-masked]<mailto:[email-masked]>>, lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] WGLC on SCHC for IPv6 and UDP

Hello Pascal, all,

Dominique

Dear WG:

Best,

Pascal and Alexander

---

From: Edgar Ramos <[email-masked]>
Date: Mon, 22 Jan 2018 07:58:19 +0000

Dear all,

I have now finished to go over the whole document and I have some language suggestions and some more particular comments. I will leave the first ones to the end and concentrate in the beginning to the actual content.

Please let me know if something is unclear or you disagree with my observations, Im happy to discuss them.

  *   One general comment is that the text of fragmentation is not very well reflected as one process following the compression. I think somewhere should be well denoted that after compression it is  possible to have fragmentation also (the text mainly refers to fragmentation when the packet cannot be compressed). Also in what step there is a decision to fragment or not which is actually tricky since the L2 rate adaptation functions do not necessarily provide to the application the MTU (especially from the network perspective).
  *   Another comment is related to the structure of several sections. I think mixing functionality with fields description is quite confusing and makes the document more difficult to read for implementers. I would recommend to have separate sections for header fields and for actual functions (like timers).
  *   The actual abstraction of the compression decompression entities is not very clear, in some cases I cannot say if I would need one entity or more depending of the characteristics of the LPWAN technology. May be it would be good to clarify in the document the scope of one instance ?

Cheers

Edgar

Page number

Text Scope

Comments

/Page:1

This document describes a header compression scheme and fragmentation
   functionality for very low bandwidth networks

I think it should be more specific to LPWAN, may be: …functionality targeting very low bandwidth wireless networks.

/Page:1

Fragmentation is
   mandatory for IPv6 datagrams that, after SCHC compression or when it
   has not been possible to apply such compression, still exceed the L2
   maximum payload size.

I understand that you want to highlight the need for fragmentation when the maximum payload size of an radio access technology  is reached, but the sentence is very confusing with respect to the previous, where says that fragmentation MAY be use and here says it MUST be used. Also it is not clear what L2 means,
For NB-IOT , the L2 limits do not matter since it could be handled with its own segmentation functionality, if not transparent mode is used. Even so, I would rephrase to highlight the payload as MTU “supported” by the LPWAN technology and avoiding talking about L2.

/Page:4

1.  Introduction

Add mention of specific technologies documents and that general scope of this document (What is expected to be found here and what will be expected in the other documents)

/Page:4

do not support layer two
   fragmentation,

I would prefer to talk about  payload fragmentation, instead of layer two fragmentation.

/Page:4

that data unit reordering will not happen between the
   entity performing fragmentation and the entity performing reassembly.

I think the assumption is that reordering is not needed for the protocol to work, so it is not necessary to have it. The current text seems to imply that reordering is somehow not allowed. Which is not the case for NB-IOT for example

/Page:7

The way the context is learned on both
   sides are out of the scope of this document.

The description of context comes later and this sentence here is confusing for an unacquainted reader. May be an introduction to what is a context before telling that how the context is defined (or learned as in the text)

/Page:8

Radio Network (RG)

The acronym for RG should be open in this sentence or before, otherwise confusing.  (Radio Gateway).

/Page:8

.  These
   flows are compressed by a Static Context Header Compression
   Compressor/Decompressor (SCHC C/D) to reduce headers size.  The
   resulting information is sent to a layer two (L2) frame to a LPWAN
   Radio Network (RG) which forwards the frame to a Network Gateway
   (NGW).

This flow of actions or steps should be better explained, so I would recommend to provide a numerated list of steps or at least a more sequential explanation of what happens where. The text address compression and decompression as if they would be one function and then talks about a L2 frame which might cause confusion for some technologies terminologies. I think instead it should talk about compressed packets  and wireless transmissions and compression function and decompression function that are  located in a C/D entity. I don’t really know how is expected to be the abstraction when a device is multiRAT capable and the diagram seems to suggest that there is only one context even if multiple applications are used. In the case of NB-IOT each bearer can be map to a different transmission mode (for example, acknowledged, unacknowledged or transparent) the last one do not have segmentation support, would it then have only one context or would require two context if application data is map to an additional non-transparent transmission type ?

/Page:8

The NGW sends the data to an SCHC C/D for decompression which
   shares the same rules with the Dev.

I think the fragmentation (if required ) and reassembling should be mentioned in this description too.

/Page:8

as much as possible

This wording confuses the definition. I understand that you want to say the closest match, but as it says doesn’t seem to imply that no matches can also happen.

/Page:10

      *  UPLINK (Up) when the field or the value is only present in
         packets sent by the Dev to the App,

      *  DOWNLINK (Dw) when the field or the value is only present in
         packet sent from the App to the Dev and

      *  BIDIRECTIONAL (Bi) when the field or the value is present
         either upstream or downstream.

One possible use case that has been presented for radio technologies is the V2V (D2D) and coverage extension by relaying of radio signals, in 3GPP this is called SIDELINK. I wonder if such value definition would be useful here too for future compatibility reasons

/Page:10

A Target Value (TV) is the value used to make the comparison with
      the packet header field

I got confused when I read this first time because the target Value has somehow a different definition in the terminology section.  There is mentioned to be used for matching and here is for comparison. Therefore It is expected operators for comparison which is not only the case. Also I think the text should be more explicit that then initial terminology definition so it is more clear what is for, it could be with a more detailed example. The same applies to the matching operator.

/Page:10

o  A Matching Operator (MO) is the operator used to make the
      comparison between the Field Value and the Target Value.  The
      Matching Operator may require some parameters.  MO is only used
      during the compression phase.

Which operators? Where are they defined ? May be mention the number of functions defined or at least mention that they are defined in the document later

/Page:10

   o  A Compression Decompression Action (CDA) is used to describe the
      compression and the decompression process.  The CDA may require
      some parameters, CDA are used in both compression and
      decompression phases.

Reference to the list of actions. May be mention the number of functions defined or at least mention that they are defined in the document later

/Page:10

   Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for
   different header compression.  To identify the correct Rule ID, the
   SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to
   find the appropriate Rule.

What would be the case for multirat devices ? would they have a different set of rules per radio access technology?

/Page:10

   The compression/decompression process follows several steps:

Numerate the steps to make it easy to follow, and may be get the steps a bit more granular. In one step seems to happen many things which makes the understanding of the process more complex

/Page:11

If no eligible rule is found,
      then the header must be sent without compression, in which case
      the fragmentation process must be required.

s/must be required/might be required.
In some cases, it might not be necessary. Anyway, here is the only place where fragmentation is mentioned from the compression process. I think the case of requiring fragmentation even after compression it should be mentioned.

/Page:11

      If after using SCHC compression and adding the payload to the L2
      frame the datagram is not multiple of 8 bits, padding may be used.

It should be moved to the sending steps

/Page:12

   o  equal: A field value in a packet matches with a TV in a Rule if
      they are equal.

Consider to rephrase the function
Something like  ..”Results in true if the field value and the TV are equal”.
The current function definitions text takes sometime to understand the actual result

/Page:13

   Compression is done in the rule order and compressed values are sent
   in that order in the compressed message.  The receiver must be able
   to find the size of each compressed field which can be given by the
   rule or may be sent with the compressed header.

Error cases ?  not specified ?, abort package ? deliver to next layer anyway ?

/Page:13

   The compressor does not send any value in the compressed header for
   the field on which compression is applied.

This statement was a bit confusing for me, I suggest
Rephrase:
“No values are sent for the fields that has been compressed.”

/Page:14

The compressor looks on the TV to find the field value and send the
   corresponding index.

s/on the/into

/Page:14

   If this action is made on a variable length field, the remaining size
   in byte has to be sent before.

s/has to/must

/Page:15

If after applying SCHC header compression
   or when SCHC header compression is not possible the entire IPv6
   datagram fits within a single L2 data unit, the fragmentation
   mechanism is not used and the packet is sent.  Otherwise, the
   datagram SHALL be broken into fragments.

If I understand well, fragmentation will be always done if a packet is not fitting a single L2 unit. In NB-IOT this might not always be necessary, but still the compression part of SCHC is of interest. One possibility is to set the MTU to something very large so fragmentation do not happen, or maybe it can be disable by implementation, but shouldn’t be expected by a receiver of the packet.
Another issue is the determination of the MTU of the L2, especially with the current architecture since in some technologies there is and rate adaptation function for some transport channels that set a different MTU in L2 depending of what is the radio channel quality. That would mean that the fragmentation part of the protocol should be done close to the radio gateway from the network perspective and requires hooks from MAC layer to SCHC (also in the devices) in order to know what is  the particular transmission MTU

/Page:15

This specification assumes that reordering will
   not happen between the entity performing fragmentation and the entity
   performing reassembly

May be is better to say that MAY not happen, since it doesn’t really matter if the packets are reordered.

/Page:15

This subsection describes the different fields in the fragmentation
   header frames

Why to call the section functionalities if it is describing the packet fragment packet format ?
May be it should be split ?

/Page:16

The FCN MUST
      be set sequentially decreasing from the highest FCN in the window
      (which will be used for the first fragment), and MUST wrap from 0
      back to the highest FCN in the window.

The document doesn’t have a consistent use of MUST, MAY,SHOULD and CAN. I would be good to align all the sections

/Page:16

The DTag field, if present, is set to the
      same value for all fragments carrying the same IPv6 datagram.

Missing to specify when is not present

/Page:17

The CRC32 as 0xEDB88320 is
      recommended as the default algorithm for computing the MIC.
      Nevertheless, other algorithm MAY be mandated in the corresponding
      technology documents (e.g. technology-specific profiles).

More normative Reference?

/Page:17

Abort message needs to be sent

Reference to abort definition later on so it is clear that is the same than Abort frame

/Page:18

Padding will be used to align the last byte of a
      fragment with a byte boundary.  The number of bits used for
      padding is not defined and depends on the size of the Rule ID,
      DTag and FCN fields, and on the layer two payload size.

This should be technology dependent. Some technologies have their own padding mechanisms and free space could be used for piggy back things in L2

/Page:18

Window mode - ACK always (ACK-Always).

This header is confusing since it doesn’t seem to be two separate things.

/Page:23

The values for R, N, T and M are not specified in this document, and
   have to be determined in other documents (e.g. technology-specific
   profile documents).

s/have to /SHOULD

/Page:23

                       Figure 16: All-1 Abort format

Why the byte boundary is mentioned?. What about if there is no byte alignment there ?

/Page:23

                        Figure 17: ACK Abort format

May be this figure could be introduced in the differences of  format to figure16?

/Page:23

5.5.  Baseline mechanism

Shouldnt also include some text about the transmitter side ??

/Page:24

5.5.1.  No ACK

May be  add a reliability modes section  subheader (?)

/Page:25

5.5.2.  The Window modes

May be this can be moved to the upper section and keep only reliability options in this section

The language suggestions are the following:

/Page:1

Static context means that the stored information does not
   change during packet transmission

Language: A static context implies that the stored information does not change during the packet delivery process.

/Page:1

The context describes the field
   values and keeps information that will not be transmitted through the
   constrained network.

Language: The context describes the field values of one or several protocols headers and keeps……

/Page:1

And also, because with SCHC, in most cases IPv6/UDP
   headers can be reduced to a small identifier called Rule ID.  Even
   though, sometimes, a SCHC compressed packet will not fit in one L2
   PDU, and the SCHC fragmentation protocol defined in this document may
   be used.

Language: In most cases IPV6/UDP headers can be reduced to a small identifier called Rule ID by using SCHC. And SCHC fragmentation defined in the document may be used if a compressed packet wouldn’t fit in one L2 PDU.

/Page:1

This document also specifies a
   fragmentation and reassembly mechanism that is used to support the
   IPv6 MTU requirement over LPWAN technologies

Language: It also specifies……..

/Page:4

Header compression is mandatory to efficiently bring Internet
   connectivity to the node within a LPWAN network

Language:… is a mandatory feature to efficiently….

/Page:4

all the packets follow the
      same path

Language: …all the packets are delivered following ….

/Page:4

where header information is kept in
   the header format order.

Language: …header information is stored in the same order of the packet headers.

/Page:4

The SCHC header compression mechanism is independent of the specific
   LPWAN technology over which it will be used.

Language: …is independent of the specific LPWAN technology deployed.

/Page:8

The main idea of the SCHC compression scheme is to send the Rule id
   to the other end instead of sending known field values

Language:  …. Is to substitute the known header field values of a packet with a Rule-id.
(I noticed that many times the world header is not omitted from the text and I think for clarity it really makes a different to include it. For example the next sentence talks about rules matching packet values, without the world header it can be misleading to think that the matching could happen in some payload values as well, especially when multiple stacks are present and  their headers are in clear format)

/Page:9

The Rule does not describe the original packet format which must be
   known from the compressor/decompressor.

Language: The Rule does not intend to describe the original packet format headers. The packets headers formats must be known by the compressor/decompressor. Instead, the rule just…..

/Page:9

the description of the header field should be performed in the
   format packet order.

Language:   the description of the header fields must follow the same order than the packet headers.

/Page:9

The Rule also describes the compressed header fields which are
   transmitted regarding their position in the rule which is used for
   data serialization on the compressor side and data deserialization on
   the decompressor side.

Language: A Rule also describes the header fields that are compressed. They are transmitted according to the position of the header field  in the rule in use and used for data serialization by the compressor and data deserialization by the decompressor.

/Page:11

This Rule gives the
      compressed header format and associates these values to the header
      fields

Language: The selected rule provides the format of the compressed header to match the headers of the received packet

/Page:13

there is a risk to have a decompressed field value
   different from the compressed field.

Language: …from the compressed field of the original packet

/Page:14

A length can be specified in the rule to indicate how many
   bits have to be sent

Language: …how many bits are being sent.

/Page:16

the apropriate value will be
      defined in the corresponding technology documents

Language: …a suitable value SHOULD be defined by the corresponding ….

/Page:17

The dureation of this timer

Language;: typo …s/dureation/duration

/Page:24

The FCN will be assigned sequentially in
   a decreasing order starting from 2^N-2, i.e. the highest possible FCN
   value depending on the FCN number of bits

Language:  s/will be/MUST be

/Page:24

the last fragment of a packet must contains a
   MIC

Language: s/contains/contain
Check the consistency of MUST. Either in upper case all times or  not.

/Page:27

the Inactitivity Timer
   is set

Typo: s/Inactitivity/Inactivity

/Page:28

it sends an
   ACK and reinitialises the Inactivity Timer.

Typo: s/reinitializes/restart

---

From: <[email-masked]>
Date: Mon, 22 Jan 2018 16:57:53 +0000

Dear all,

Please find below my comments for section 5.
I have also submitted a Pull Request on GitHub to fix many nits in the text.
All questions or suggested changes that might modify the meaning of the text are reported in this mail.
I'll be sending more in the next hours/days.
Best regards

Dominique

General comments
This document still suffers from a poor integration of the fragmentation and compression parts. Besides, the compression part as evolved since the early versions on what to do when compression is not possible (send in extenso vs. drop packet).
I haven't seen in the spec how exactly a datagram is sent when it is neither compressed nor fragmented. Don't we need a Rule ID for that?

We should settle on the use of "option" or "mode" to describe the reliability mechanisms, and use only one. I suggest we use "mode", because it correlates better with the notion of persistent states in the sender and  receiver.
I suggest we remove the term "window mode" altogether and simply consider 3 modes: "no-ACK', "ACK-always" and "ACK-on-error".  When we previously used the term "window mode", just write "ACK-always or ACK-on-error".

no-ACK, ACK-always and ACK-on-error are written with various hyphenation and capitalisations throughout the text. They should be made consistent.
Ditto for All-0 and All-1.

Do we only consider fragment payloads that are an integer number of octets? If so, we should state it somewhere to ease the discussion about padding. If the answer is no, we should also make sure the reader is aware.

In section 5.1 Fragmentation
"the fragmentation mechanism is not used and the packet is sent."
If there is no SCHC compression possible and no fragmentation, is the packet sent "as is"? In this case, how does the receiver know the packet is sent as is?
Don't we need a Rule ID to say that the packet is sent uncompressed and unfragmentated?
This should be part of the general presentation and block diagram.

Section 5.2 Functionalities
"and the different reliability options supported."
I suggest "and the different reliability modes supported."

"also allows to interleave non-fragmented IPv6 datagrams with fragments that carry a larger IPv6 datagram."
This sentence is about interleaving fragments and unfragmented datagrams, "larger" is related but not essential to the point.
I suggest "also allows interleaving non-fragmented IPv6 datagrams and fragments that carry other IPv6 datagrams."

In the FCN description, the reliability modes are used (No ACK, window mode, etc) before they are defined or even introduced.
Add a forward reference.

"DTag MUST must be set sequentially increasing from 0 to 2^T – 1 … "
I suggest "For each new IPv6 datagram processed by the sender, DTag MUST be sequentially increased, from 0 to 2^T – 1 wrapping back from 2^T - 1 to 0."

" However, the sending format of the Bitmap will be truncated until a byte boundary where the last error is given. However, when all the Bitmap is transmitted, it may be truncated, see more details …"
I'm confused about these two sentences. They look like they are two versions of the same description, but not quite.
If they both refer to Bitmap optimisation, I suggest to write "The text above describes the internal representation of the Bitmap. When inserted in the ACK for transmission from the receiver to the sender, the Bitmap may be truncated for energy/bandwidth optimisation (see …)."

"Padding will be used to align the last byte of a fragment with a byte boundary."
Are there other type of packets that fragments that need padding?
I guess ACKs never need padding since byte alignement is part of their semantic (bitmap optimisation).
If this is true, maybe we should enlighten the wondering soul: "ACKs never need padding, since they are constructed to be always byte-aligned (see <forward-ref>)."

Section 5.3 Delivery Reliability options
"modes" instead of "options"?

"A window of fragments is a subset of the full set of fragments needed to carry an IPv6 packet. "
The "window of fragments" is defined in passing in the Ack-always section.
I suggest to write an introductory text to this section.
"There are three delivery reliability modes, namely no-ACK, ACK-always and ACK-on-error. ACK-always and ACK-on-error operate on windows of fragments. A window of fragments is a subset of the full set of fragments needed to carry an IPv6 packet."

"In ACK-on-error, an ACK is transmitted by the fragment receiver after a window of fragments have been sent, only if at least one of the fragments in the window has been lost. The ACK informs the sender about received and/or missed fragments from the window of fragments. Upon receipt of an ACK that informs about any lost fragments, the sender retransmits the lost fragments."
Complement the explanation with the following text: "If an ACK is not transmitted back by the receiver at the end of a window, the implicit meaning conveyed is that all fragments have been correctly received. As a consequence,  if an ACK is lost, the sender assumes that all fragments covered by the ACK have been successfully delivered."

"However, if an ACK is lost, the sender assumes that all fragments covered by the ACK have been successfully delivered, and the receiver will abort the on-going fragmented packet transmission."
I don't immediately get why a receiver would necessarily abort the transmission because the sender has assumed that all fragments have been delivered.
If it is an inevitable indirect consequence and it matters that the reader understands it at this point, spell out the reasoning (and split the text in several sentences).

"One exception to this behavior is in the last window"
I personally know that "this behavior" refers to "only if at least one of the fragments in the window has been lost".
But the paragraph has grown large and several sentences has been inserted between the two pieces of text and the link has been lost.
I suggest: "As an exception to the behavior described above, the receiver MUST transmit an ACK in the last window, , even if all its fragments have been correctly received."

Section 5.4.1
"The fragment payload carries a subset of either a SCHC header or an IPv6 header or the original IPv6 packet data payload."
This sentence should be rewritten, using a predefined term for "either the SCHC compressed-header packet or the original IPv6 packet" that I suggested in the general comments.

"The total size of the fragment header in this format is R bits."
This sentence is useless since the it is also true of the fragment headers in other reliability modes.

Section 5.4.2
"All-0 window" and "All-1 window" are defined in passing is this section about ACKs.
Define them earlier, e.g. in the FCN description where the terms "All-0" and "All-1" first pop up in full text.
Figure 9 does not show padding. If regular ACK can have padding, this should show on the figure.
Figure 9 is not consistent with the text in 5.5.2.1, which states that the ACK does not carry a Bitmap if all fragments were received correctly.
Figure 10 : the C character should be aligned with the corresponding bit in the box. The byte boundary delimiter at the top of Figure 10 does not make sense at this point.
If the ACK to an All-1 window make require padding (which it does, if I'm correct), then Figure 10 should show the padding bits, to be consistent with Fig 6-8.

Section 5.4.3
The figures 11-15 do not contain padding. Is this intentional? Shouldn't they be similar in content to Figures 6-8?
I suggest merging section 5.4.3 into 5.4.1, they both describe fragments.
In any case, section 5.4.3 about ACKs should not be inserted in the middle of the description of fragment frames.

Section 5.4.4
This section describes the Abort message formats (All-1 abort and ACK abort). They do no state what these messages are used for and by whom.
This is not consistent with the sections 5.4.1-5.4.3 which contain short explanations about the usage in addition to the frame formats.

Section 5.5, introductory text.
"An unfragmented packet could be a SCHC compressed or an uncompressed IPv6 packet (header and data)."
This is true, but why is it mentioned here in the middle of the explanation?
Again, we should have a clearly defined term to mean "a SCHC compressed or an uncompressed IPv6 packet (header and data)" and it should appear in the terminology.

"The FCN will be assigned sequentially in a decreasing order starting from 2^N-2"
I understand this is no longer true.

Section 5.5.2.1 ACK-always
"Then, the receiver sends an ACK reporting whether any fragments have been lost or not by setting the corresponding bits in the Bitmap, otherwise, an ACK without Bitmap will be sent, allowing transmission of a new window."
"otherwise" does not refer to any "if" statement ahead in the sentence.
Furthermore, I understand that the bits in the Bitmap only indicate fragments that have correctly been received, and not those that have been lost. This is because, as I understand, a sender might elect no to send a full window. A fragment missing at the receiver might very well not have been transmitted in the first place.
I suggest to write: "The receiver sends an ACK reporting the fragments that have been received by setting the corresponding bits in the Bitmap. If all fragments in the window were correctly received, the ACK is optimised by not carrying the Bitmap at all".
Question: is the "optimisation"mandatory or optional? Would the whole scheme still work with an ACK carrying the Bitmap full f 1's, or is this encoding reused for some other meaning? My suggested text would change slightly based on the answer to this question.
Comment: this explanation of the ACK without a Bitmap in response to an All-0 fragment is not consistent with Figure 9 in 5.4.2.

"During this period, the sender starts listening to the radio and starts the Retransmission Timer, which needs to be dimensioned based on the received window available for the LPWAN technology in use."
Starting the Retransmission Timer is a repetition from the previous sentence in the text. Furthermore, I guess the window mentioned in this sentence has nothing to do with the window of the ACK-always mode. This is confusing.
I suggested some new text in the Pull Request on GitHub.

"If the W bit value of the received ACK is correct, the sender analyzes the received Bitmap."
I understand that the ACK may be optimized and not contain a Bitmap at all.
I suggest: "If the W bit value of the received ACK is correct, the sender analyzes the rest of the ACK message, such as Bitmap and MIC."

"If the receiver receives an All-0 fragment, the sender may send one or more fragments per window. Otherwise, some fragments in the window have been lost."
I cannot make sense of these sentences.

I'm bailing out for this section. Too many paragraphs look like late patches, and they contradict other paragraphs already in place in this same section. I recommend this section be rewritten entirely. I'm willing to work with the authors and to provide a rewrite, at a later time.

Section 5.5.2.2
"(with the exception of the last window, see next paragraph)"
The text alluded to by this sentence is in the same paragraph as this text.

"At the receiver side, when the All-1 fragment is sent"
I guess you mean "received".

"an ACK is also sent to confirm the end of a correct transmission."
I suggest: "an ACK is sent nonetheless, to confirm the end of a correct transmission."

For this section as well, I recommend a full rewriting and I'm happy to work with the authors to that purpose.

Section 5.5.3
"The Bitmap is transmitted by a receiver as part of the ACK format when there are some missing fragments in a window."
This is not quite clear yet. Figure 9 shows a Bitmap being included regardless, even if all fragments were correctly received.

"An ACK message may introduce padding at the end to align transmitted data to a byte boundary."
This should be reflected in Fig 9 and 10.

"The first byte boundary includes one or more complete bytes"
I cannot quite make sense of this text, even looking at Fig 18.

"The Bitmap, when transmitted, MUST be optimized in size to reduce the resulting frame size. The right-most bytes with all Bitmap bits set to 1 MUST NOT be transmitted."
I suggest: "In order to reduce the resulting frame size, the Bitmap is shortened by applying the following algorithm: all the right-most contiguous bytes in the Bitmap that have all their bits set to 1 MUST NOT be transmitted."

"As the receiver knows the Bitmap size, it can reconstruct the original Bitmap without this optimization."
I suggest: "Because the receiver knows the actual Bitmap size, it can reconstruct the original Bitmap even with the trailing 0xFF bytes optimized away."

"Note that the introduction of a C bit may force to reduce the number of fragments in a window to allow the bitmap to fit in a frame."
To reduce: statically, dynamically? Based on what criteria?
I guess I know what you have in mind: "compared to the situation before we introduced the C bit". But this is design history, I think it does not belong here.
Maybe there should be a text somewhere that discusses the maximum window size based on R, T etc. This discussion would state as a fact that the header max size is achieved when there is a C bit in the header.

Fig 20 and Fig 21: "shows an example of an ACK (for N=3),"
At this point, I was no longer sure what N was. Besides, N does not quite matter since it does not show on the figure. What matters is the FCN range (aka window size).
I suggest to write: "shows an example of an ACK with FCN ranging from 6 downto 0,"

Fig 20 and 21 need significant cleaning up. N is not used and does not need to appear in the caption.

Section 5.6
"Note that the same window size MUST be used for the transmission of all fragments that belong to a packet."
Replace "packet" with was is agreed to mean "a SCHC compressed or an uncompressed IPv6 packet (header and data)".

Section 5.7
No significant comment. Suggested fixes to nits in the GitHub Pull Request.

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Sunday 21 January 2018 17:27
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Cc : Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] WGLC on SCHC for IPv6 and UDP

Dear all,

Dominique

General suggestions

In section 4.1

Section 4.5.4, LSB CDA

Section 4.5.6 Compute-*

Hello Pascal, all,

Dominique

Dear WG:

Best,

Pascal and Alexander

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 17:40:14 +0000

Dear all,

Please find below my comments from Section 6 to Appendix E.
I have also submitted another Pull Request on GitHub to fix many nits in the text (150 lines changed in the diff).
All questions or suggested changes that might modify the meaning of the text are reported in this mail.
Best regards

Dominique

General comments
This section on IPv6 IIDs explains that the rule describes the DEV (resp. APP) address fields instead of source and destination address fields, so that a single rule can be used for both directions.
This looks like a similar purpose to what the DI field was invented for. Could we use a single mechanism (presumably, keep the DI field and use it for the addresses)? Would there be a penalty in doing so? Occam's razor.

Section 6 Padding
We need a drawing of a general "SCHC" frame that we can refer to. Right now, we have Figure 4 for compression, Figure 6 for fragmentation, Figures 9, 10 and 17 for ACKs, Figure 16 for All- Abort, etc.
Should the term "SCHC Header" be defined in the terminology, so that it can be referred to later? It would encompass all types of headers that are defined in this document.
Shall we have a MUST in this section to mandate this way of doing padding, or should we describe a way of doing the padding and leave to the technology documents to mandate this was of doing it? The reason why I'm hesitant to mandate padding in this document is if we ever had a LPWAN technology that isn't byte aligned.
Suggested improved text in the GitHub Pull Request.
Please also see my comment on Section 4.3 for redundant text on padding.

Section 7, introductory text.
Before jumping into the gory details, maybe this piece of text should provide a little didactic material such as
- remind people about the tradeoff to be made between many very narrow rules (netter compression)  and less more relaxed rules (less memory usage).
- mention that it is expected to have at least one rule per IP flow, where by flow we mean packets with headers sharing such and such field values ….
A forward reference to 7.7.1, which discusses "[a] rule [that] allows several prefixes", would make sense.

Section 7.2
"If the DiffServ field identified by the rest of the rule"
What does "identified by the rest of the rule" mean? This text describe fields in the packets that are being processed. The Rule does not identify fields. Fields are identified by the compressor before it looks at the rule table.
Apart from that, the text should be restructured. Suggestion in the GitHub Pull Request.

Section 7.3 and Section 7.5
Ditto

Section 7.4
This section talks about yet another padding. There should be an explanation with reference to Section 6. A drawing would be good, too.

Section 7.5 Hop Limit
"The End System is generally a device and does not forward packets."
"End System" is not defined anywhere. It is only used here.
Anyway, this sentence is redundant with the third paragraph.
What does "relatively" constant mean?
I suggest to replace "upstream" and "downstream" with "Uplink" and "Downlink" which belong to the terminology.

Section 7.7 IP6 address field
This section explains that the rule describes the DEV (resp. APP) address fields instead of source and destination address fields, so that a single rule can be used for both directions.
This looks like a similar purpose to what the DI field was invented for. Could we use a single mechanism (presumably, keep the DI field and use it for the addresses)? Would there be a penalty in doing so? Occam's razor.

Section 7.7.1
"In case the rule allows several prefixes, mapping-list must be used."
This is kind of circular logic. The rule will allow several prefixes if is uses mapping-sent (or value-sent).
"mapping-list" is not defined, nor is it used anywhere else.
I suggest: "If the rule is intended to compress packets with different prefix values, match-mapping should be used."

"The different prefixes are listed in the TV associated with a short ID."
So far, I understood that the short ID was automatically provided by the compressor by looking at the list in the TV.
Are you now saying that the rule designer selects the short ID for each value in the list/dictionary?

Section 7.7.2
"Note that the LPWAN technology is generally carrying a single identifier, which corresponds to the DEV."
True, but what point are you trying to make here?
"The SCHC C/D may also not be aware of these values."
What does "also" refer to?

Section 7.8
"No extension rules are currently defined. They can be based on the MOs and … "
Suggested text: "No rule is currently defined that processes IPv6 extensions. If such extensions are needed, their compression/decompression rules can be based on the MOs and CDAs described above."

Section 7.10 UDP length field
See my comments for 7.4

Section 8.1
"Denial of Service may be produced but its arise other security problems that may be solved with or without header compression."
I'm not sure what you mean. Please rephrase.

Appendix B
Figure 25 and following : I suggest writing once that N=3 for all the drawings till Figure 29, and not mention is in each caption or description. The value of N does not show in the drawings, except for the All-1 value of FCN.
Figue 25 is missing the MAX_WIND_CFN information.

Figure 26
Last line: I suggest "         |<---- ACK, W=1 ———|   C=1, no bitmap" , to be consistent with the other drawings.

Figure 27
"Note: in Window mode, an additional bit will be needed to number windows. "
What is this additional but? Where does it show on the Figure?
Why is this sentence here among the examples?
Why the future tense? If it's in the spec, it is now.

Figure 29 and following
"Note that, since a single window is needed for transmission of the IPv6 packet in this case, the example illustrates behavior when losses happen in the last window. "
Well, Figure 28 also illustrates a behaviour where losses happen in the last window. I suggest to remove this sentence.

In all figures illustrating ACK-on-error and ACK-always:
CFN appears at some places instead of FCN.
I suggest showing the MIC on the arrow between sender and receiver. The drawings can be made a little wider if need be.
I suggest harmonising the words we use to describe the result of MIC checking. Currently we have "checked", "checked: success" and "checked: right" to indicate success. And "checked: failed" and "checked: wrong" to indicate error.

The last drawing is missing its caption and is incorrectly referenced as Appendix C.

Appendix C (fragmentation state machine)
Figure 35:
One arrow is bidirectional. "Wait End" state has intersecting conditions for two arrows.

Fig 35 and 37:  The ABORT part at the bottom of the drawing is not clear to me.

Many nits in the drawing. In general, I'll provide suggestions to make the drawings better in a separate mail.

Appendix D
"A set of Rule IDs are allocated to support different aspects of fragmentation functionality as per this document. The allocation of IDs is to be defined in other documents."
I suggest: "A set of Rule IDs has to be allocated to support different aspects of fragmentation functionality as per this document. The actual allocation of IDs is to be defined in other documents."

"one ID or a subset of IDs to identify"
I suggest: "one ID or several IDs to identify"

Date : Monday 22 January 2018 17:57

Dear all,

Dominique

General comments

Section 5.4.1

Section 5.4.2

Section 5.4.3

Section 5.4.4

Section 5.5.2.2

Section 5.5.3

Section 5.6

Section 5.7

Dear all,

Dominique

General suggestions

In section 4.1

Section 4.5.4, LSB CDA

Section 4.5.6 Compute-*

Hello Pascal, all,

Dominique

Dear WG:

Best,

Pascal and Alexander