[lp-wan] Short Review of draft-aguilar-lpwan-schc-streaming

[Alexander PELOV <[e-mail]>]

(chair hat off)

Dear all,

I have done a review of draft-aguilar-lpwan-schc-streaming, which is expired - https://datatracker.ietf.org/doc/draft-aguilar-schc-streaming/
However, I think it is a useful contribution and I think it points to a solution to an important problem for IoT systems - reliability for small data packets.

The issue is the difference of reliability when using SCHC for small VS big packets. 
-> Small means less than the MTU (after compression)
-> Big in the sense of not fitting in a single MTU (after compression)

The difference comes from the fact that if we have a Big packet, SCHC Fragmentation will be applied, and in Ack-Always or Ack-On-Error, we have very strong delivery guarantees. For an individual Small packet, there may be losses because of the radio conditions, and SCHC does not add any level of reliability.


Using the SCHC Fragmentation to provide reliability to both Small and Big packets is of course a very nice thing to have.
-> There is the added benefit that if we use the SCHC Fragmentation carefully, we can have very few downlinks to acknowledge multiple uplinks, which is very beneficial for the downlink budget.

The draft is well written as a whole and even though some details are needed and some clarifications, I think it provides a good basis for further development of the question.

The authors use the DTag, Window and FCNT, as well as Compound-Ack to provide a flow of SCHC Fragments, which encapsulates Big packets, as well as Small packets.

I did not understand how one SCHC Packet is separated from another SCHC Packet? It seems somehow intuitively that one DTag should correspond to one SCHC Packet, but from what I understand from the draft, this is not the case.


Another point I would like to put forward is that as it is described, is the necessary condition of using Compound-Ack. 
>From what I understand, this is for having as less downlinks as possible.
-> I think it could be useful to have a mode where Compound-Ack is not required. I'm thinking of something like Ack-On-Error, with a more liberal use of the Ack message (can be sent at any uplink..), as was discussed during the standardization of RFC8724. 

>From there on I have quite some questions and ideas, but they seem to depend on the way the authors see the above-mentioned questions.

Cheers,
Alexander