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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Jan 2018 08:00:31 +0000

Dear LPWAN WG:

We are missing reviews for this document which is critical for our WG. We'll be discussing it tomorrow at the next interim. In the meantime, please spend some time on it and comment!

Happy new year to all!

The chairs

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 22 décembre 2017 17:19
To: lp-wan <[email-masked]>
Subject: [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

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 15 Jan 2018 23:27:21 +0900

Hi,

Here, comments and questions for mainly the fragment part.

## 4.2. Rule ID

Depending on the L2 situation, is it allowed to use different Rule IDs,
but same DTag for the same IPv6 datagram ?
e.g. the 1st fragment uses Rule ID 1. the 2nd fragment uses Rule ID 2.

## 5.1. Overview

Radio Gateways and NGW are connected by the Internet.
Therefore, data unit reordering might happen there.
How about just deleting the following text ?

    "LPWAN networks typically follow a
    the star topology, and therefore data unit reordering is not expected
    in such networks."

## 5.2. Functionalities

- Here, SCHC fragment header and the R bit should be described.

- Could you explain the following text with an example ?

    "The Rule ID in the fragmentation header
    also allows to interleave non-fragmented IPv6 datagrams with
    fragments that carry a larger IPv6 datagram."

## 5.4.  Fragmentation Frame Formats

The format descriptions should be in order of sender and receiver
for readability.

## 5.4.1.  Fragment format

Adding some text about the relationship between the fields depicted
in figure 6 and 4 is very helpful.
Whole the packet including a Rule ID depicted in the figure 4 will be
fragmented and each fragment will be put into the fragment payload ?
Please tell me if I missed the text.

## 5.4.2.  ACK format

Padding is not needed for ACK ?

## 5.4.3.  All-1 and All-0 formats

The last fragment of No ACK option should be placed before 5.4.3
for readability.

## 6.  Padding management

Is it allowed to add padding between SCHC fragment header and payload
to align the byte boundary so as to easily put and take the payload ?

## please define the term

- SCHC header compression
- SCHC compression

Static Context Header Compression header compression sounds a little strange.

## Editorial

- section 4.1, paragraph 1: s/Rule id/Rule ID/
- section 5.1, paragraph 3: s/a the star/a star/
- section 5.4.1, paragraph 3: s/  .$//
- section 5.4.2, figure 10: "C" should be placed into a right place.

On 1/15/18 17:00, Pascal Thubert (pthubert) wrote:
>
> Dear LPWAN WG:
>
>  
>
> We are missing reviews for this document which is critical for our WG. We’ll be discussing it tomorrow at the next interim. In the meantime, please spend some time on it and comment!
>
>  
>
> Happy new year to all!
>
>  
>
> The chairs
>
>  
>
> *From:* lp-wan [mailto:[email-masked]] *On Behalf Of *Pascal Thubert (pthubert)
> *Sent:* vendredi 22 décembre 2017 17:19
> *To:* lp-wan <[email-masked]>
> *Subject:* [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:
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 15 Jan 2018 20:59:55 +0530

Following are my review comments (mainly non-fragmentation part):

1.  Section 4.5 Compression Decompression Actions (CDA)

    "For values between 15 and 255, the first 4 bits sent are set to 1 and
the

    size is sent using 8 bits."

[RJ] First 4 bits means LSB ? Also the size is sent using 8 bits ... does it

include the first 4 bits ?

2.[RJ] I was thinking of a scenario where gw and dev are not in sync for the

SCHC context post an update. Gw thinks that the dev is updated to the latest

SCHC context but it has in reality not been updated. Is there any way to

currently handle this? Point is gw/dev might simply keep receiving the
packets

and decompressing it based on current rule they have. One way i could think
of

to handle this is to change the rule-id when the SCHC context is changed. I

don' know if this needs proper handling or some text in the draft.

3. [RJ] I wonder how wireshark like tool will implement a dissector for SCHC

especially because Rule-ID size is not fixed (possible to be different
within

the same L1/L2 tech as well depending on number of flows etc) and the SCHC

rules might be deployment specific. I understand that dissector work was

already spunned off in IETF97. How does it handle it?

4. [RJ] It should be possible to have multiple rules even in the same flow.
I

do not think that the spec mandates that only a single rule be made use of
for

all the packets in the given flow. Want to confirm this understanding?

5. [RJ] In the appendix is it possible to add actual SCHC compressed byte

payload for the examples given? This will help initial implementers.

6.  Section 3. Terminology

    "Dev: Device. ... Dev may implement"

[RJ] Device has to implement SCHC ... should this be changed to must?

Especially because currently we cannot have mix of SCHC-enabled and
not-enabled

devices in the same network.

7. [RJ] It is possible that a given packet matches multiple rules. Some of
the

rules might result in better compression since it is longest match. May be
it

is implementation specific detail since the gw will be able to decompress

packet compressed using either rule. I just want to confirm that
implementers

might have to handle this?

8. [RJ] Can the actual byte payload be specified along with the rule based

examples in the appendix? I wanted to confirm my understanding with the
actual

byte sequence and such information would be helpful. (Something Similar to
RFC 7400)

Regards,

Rahul

On 15 January 2018 at 13:30, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Dear LPWAN WG:
>
>
>
> We are missing reviews for this document which is critical for our WG.
> We’ll be discussing it tomorrow at the next interim. In the meantime,
> please spend some time on it and comment!
>
>
>
> Happy new year to all!
>
>
>
> The chairs
>
>
>
> 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:
>
> 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
>
>
>

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 18 Jan 2018 14:05:56 +0900

Hi,

> to align the byte boundary so as to easily put and take the payload ?

How do you think the following definition of the fragment header ?

   R bits is the total size of the fragment header.
   R bits MUST be aligned to a byte boundary with padding bits (P1).
   The size of P1 MUST be from 0 to 7.

   Another padding (P2) may be used to align the last byte
   of a fragment with a byte boundary.

P2 was called Padding (P).

As the result, with no bit manipulation, it's easy for the sender
to add the payload into the fragment header, and for the receiver
to take the payload from the frame.

If you don't want to add any padding immediately before the fragment
payload, just set the size of P1 to zero.  The format will be identical
to the format in the current draft.

Thanks,
Shoichi