Re: [lp-wan] Fwd: I-D Action: draft-ietf-lpwan-schc-over-nbiot-08.txt

[Edgar Ramos <[e-mail]>]

Hi Sergio,

Thanks a lot for the thorough review, below some replies to your concerns

Equally that replied to Carles, the section 4.3.2 applies to the fragmentation from End-to-end, which implies that it is done at application layer and the parameters should be optimized in application level and there is no need for defaults for the radio layer. The recommendations of the values provided are mainly values that optimize to avoid additional overhead or inefficiencies.

The recommendations of values that refers to transport block sizes are meant to be used in case 3gpp decides to adopt SCHC as part of the internal architecture and do not apply to the end to end case, since the application servers do not have visibility of the transport block sizes that will be used by the radio layer.  The values are recommendations that makes sense for optimal operation and 3GPP could use in case it is adopted as part of the radio protocol stack.

There is no fragment figures because fragmentation is only recommended in the end-to-end case meaning that is at application layer and therefore the reference normative spec applies.

with reference to what is missing from  Appendix D, is missing:
- RulesIDs for the different Fragmentation modes. --> There is no fragmentation other than in application layer

- WINDOW_SIZE, M and N for No-ACK mode.  --> according to application needs, not need to be specified for this specific LPWAN technology

 - How the to differentiate the All-0 from the SCHC ACK REQ, and the All-1 from the Sender-Abort, for ACK-on-Error and No-ACK --> this follows the regular implementation meaning that the context has to be negotiated in advance in the application layer, not by the radio technology.

- if the last tile must be in the All-1, or be a L2 word less --> from the radio technology this is irrelevant and it is up to the application negotiated context.

- when to listen to ACKs (not sure if you have to send an uplink message to receive a downlink, if so, appendix F must be taken into account). --> The acks are just regular transmissions and they are scheduled following DRX and DTX patterns, there are not uplink driven like LORA, although a UE should do an schedule request in order to transmit uplink, meanwhile downlink just happen in the DRX timeouts. 

- size and method of the RCS. -->From the application layer that can be negotiated also during the context setup. Mobile network packets has their own checksum for packages, but there is no way currently to include that as part of SCHC since it is calculated at transmission time (chicken and egg problem). 

- recommendation on padding bits value --> The recommendation is not to use any padding in SCHC since the radio protocols of NB-IoT will do byte alignment anyway and padding will be added when needed automatically. Only recommendation is to consider such byte alignment when specifying values of fields that are part of headers or packet sizes.

With relation to :
"If fragmentation is required, for example, for a SCHC Packet of 1500 bytes, with a tile of 8 bits, 1500 tiles are required, for a tile of 4 bits, 3000 tiles, and 6000 tiles for 2 bits, without considering the number of windows and M size. "

This requirements would come from the  application and not from the radio, since the radio will apply its own segmentation function, the problem with MTUs that are greater than 1358 is not that cannot be handled, is that they generate additional protocol overhead to handle the segmentation in radio layers. 

Best Regards

Edgar


-----Original Message-----
From: lp-wan <[e-mail]> On Behalf Of Sergio Aguilar Romero
Sent: Friday, 20 May 2022 2:05 PM
To: Ana Minaburo <[e-mail]>
Cc: lp-wan <[e-mail]>
Subject: Re: [lp-wan] Fwd: I-D Action: draft-ietf-lpwan-schc-over-nbiot-08.txt

Hello Ana, Edgar, 

I have reviewed the draft and I have the following comments, mostly regarding SCHC Fragmentation.

In section 4.3.2: 

There are two fragmentation modes, No-Ack (for SCHC Packets larger than 1358 bytes) and ACK-on-Error for transfer blocks of up to, and larger than, 300 bits. However, there are no configuration values for No-ACK. 

The tile size is in the order of bits, from 2 bits to 16 bits, to avoid padding in transfer blocks. The recommend values for 300 bit transfer block are M = 1, and N = 3, therefore, 2 windows of 7 tiles, for a total of 14 tiles. Considering a tile of 8 bits, the MAX_SCHC_PACKET is 114 bits, and 224 bits for an 16 bits tile, below the 300 bits. 

For more than 300 bits, and M of 3 bits, i.e., 7 windows, and 7 tiles per windows (N = 3), the MAX_SCHC_PACKET is 392 bits for a tile of 8 bits, and 784 bits for a tile if 16 bits. I wonder if these values are meant to be bytes. Also, if the 7 windows are to have more downlink opportunities i.e., more All-0? 

There no fragment figures, as there is in the LoRaWAN and Sigfox documents. 

From RFC8734 Appendix D, is missing:
- RulesIDs for the different Fragmentation modes.
- WINDOW_SIZE, M and N for No-ACK mode. 
 - How the to differentiate the All-0 from the SCHC ACK REQ, and the All-1 from the Sender-Abort, for ACK-on-Error and No-ACK.
- if the last tile must be in the All-1, or be a L2 word less.
- when to listen to ACKs (not sure if you have to send an uplink message to receive a downlink, if so, appendix F must be taken into account).
- size and method of the RCS.
- recommendation on padding bits value.

Another detail is that the L2 word is defined as 8 bits. In ACK-on-Error, the tile size MUST be at least the size of the L2 word. Therefore, 2 bits and 4 bits are not possibles tile size values. Moreover, tiles sizes are missing for No-ACK mode. 

Note that if the MTU is 1358 bytes, the optimal tile size in terms of ACK size is the largest one, 1357 or 1356 bytes depending on the header size. If fragmentation is required, for example, for a SCHC Packet of 1500 bytes, with a tile of 8 bits, 1500 tiles are required, for a tile of 4 bits, 3000 tiles, and 6000 tiles for 2 bits, without considering the number of windows and M size. The bitmap, in a 1358 bytes MTU, and using compound ACK, can be up to 10000 bits, but the device energy consumption and processing time increases with the number of tiles, at least in my experience, as every tile must be processed before building the SCHC Fragment. Moreover, with a tile of 1356 bytes you need 2 tiles and 1 window. In both cases only two SCHC Fragments are needed.

Let me know if I missed any detail in the document. I can collaborate with fragment figures if needed.

Best regards,

Sergio

> On May 20, 2022, at 7:37 AM, Carles Gomez Montenegro <[e-mail]> wrote:
> Hello Ana, Edgar,
> 
> Many thanks for taking my comments into consideration!
> 
> I just have the following remaining comments:
> 
> - Section 4.3 is entitled "End-to-End Compression". However, it also 
> defines how to use fragmentation (in 4.3.2), so probably the title 
> should be updated.
> 
> - Regarding the fragmentation parameters in 4.3.2, I understand that 
> default values for the following parameters would need to be specified 
> as
> well:
> 
>    - MAX_ACK_REQUESTS
> 
>    - WINDOW_SIZE
> 
>    - RCS size
> 
> 
> Thanks,
> 
> Carles
> 
> 
> 
> 
>> Hello,
>> 
>> Here you will find the last version of the draft-SCHC over NBIoT, 
>> this version includes the inputs from Carles.
>> Please review the file and send comments.
>> 
>> Thank you for your inputs
>> Ana & Edgar
>> 
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Thu, May 19, 2022 at 6:55 PM
>> Subject: [lp-wan] I-D Action: draft-ietf-lpwan-schc-over-nbiot-08.txt
>> To: <[e-mail]>
>> Cc: <[e-mail]>
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IPv6 over Low Power Wide-Area 
>> Networks WG of the IETF.
>> 
>>        Title           : SCHC over NBIoT
>>        Authors         : Edgar Ramos
>>                          Ana Minaburo
>>        Filename        : draft-ietf-lpwan-schc-over-nbiot-08.txt
>>        Pages           : 20
>>        Date            : 2022-05-19
>> 
>> Abstract:
>>   The Static Context Header Compression and Fragmentation (SCHC)
>>   specification describes header compression and fragmentation
>>   functionalities for LPWAN (Low Power Wide Area Networks)
>>   technologies.  The Narrowband Internet of Things (NB-IoT)
>>   architecture may adapt SCHC to improve its capacities.
>> 
>>   This document describes the use of SCHC over the NB-IoT wireless
>>   access and provides use-cases for efficient parameterization.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-nbiot/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-nbio
>> t-08
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-nbiot-08
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>> 
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
> 
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lp-wan