Skip to main content

Minutes interim-2024-schc-06: Tue 14:00
minutes-interim-2024-schc-06-202404301400-00

Meeting Minutes Static Context Header Compression (schc) WG
Date and time 2024-04-30 14:00
Title Minutes interim-2024-schc-06: Tue 14:00
State Active
Other versions markdown
Last updated 2024-04-30

minutes-interim-2024-schc-06-202404301400-00

Interim SCHC #6 2024

WG info

Meeting Information

Agenda

[16:00] Administrivia [10min]

  • Note-Well, Scribes, Agenda Bashing
  • WG & documents Status
  • Lead by: Delegate Chair

[16:10] Presentation of lab.SCHC [10 min]

  • Presenter: Laurent Toutain

[16:20] Tokenizer-based Compression [10 min]

  • Presenter: Jaime Jimenez

[16:30] Updates on the architecture draft [10 min]

  • Presenter: Ana Minaburo

presented first

[16:40] Forward Error Correction (FEC) for SCHC [10 min]

[16:50] AOB [ QS ]

Minutes

[16:00] Administrivia [10min]

  • Note-Well, Scribes, Agenda Bashing
  • WG & documents Status
  • Lead by: Delegate Chair

  • Pascal introduce the IETF meeting, don't forget about IPRs that need
    to be mentioned and declared.

  • draft-schc-ip-protocol-number, authors have not answered to publish
    a SCHC document
  • new draft version for architecture
  • new version for Zero-energy
  • new also FEC document
  • Milestones: we are late.
    • IP protocol number, problem contact with author.
    • OAM draft is missing one author too. Need to see how to go
      forward

[16:12] Updates on the architecture draft [10 min]

  • Presenter: Ana Minaburo

AM presenting

AM: New version -02 submitted, based on discussions at previous interim
meetings.
AM (p2): Added terminology section, and the concept of stratum for the
SCHC header ("stratum" avoid confusion with (OSI) "layer"). The stratum
icnludes both the SCHC header and the compressed data. Also added the
concept of Set of Rules (SoR) used at a certain stratum.

AM (p3): Showing an example. Upon reception, the SCHC header is noticed;
then, based on the discriminator (e.g., IP address, port number, ...),
the parser understands whether this is about compression or
fragmentation. Decisions are taken also based on the SCHC instance
indicated by the SCHC header.
PT: Can the process on p3 happen several type?
AM: Yes.
PT: "stratum" felt better also to stress independency of operations with
one another, again not to be confused with "layers".
LT: Again on p3, it may look complex, but the implementation is very
obvious. We just need to have a different set of rules at different
strata. Then each of those work on its own. The stratum to use can be
implicit (e.g., in LpWAN) or explicit as indicated by, e.g., an IP
address.

AM (p4): This puts the strata in context with the SCHC architecture. The
slide shows layers, but it's actually strata.

AM (p5): Also specified the format of the SCHC header. It's open and one
can include what needed for the specific stratum. This SCHC header is in
turn compressed by SCHC in a well-known fashion.

AM (p6): Next steps are identification of the set of rules and the
format of the rules.

LT: On p3, we also have to think more about the rules for management,
e.g., by using CORECONF, to change values. That requires a discussion,
the use of CoAP/OSCORE/DTLS, and something simple for identification.
Then we can compress the headers we need and use CORECONF.
AM: Does this have to be in the architecture work, or in a separate
draft?
LT: Not sure, also to be discussed. If it builds on what we have, it can
be in the architecture document. But if it is something new on the
management, something separate also makes sense.
PT: It might well be something separate with dedicated security aspects.

AM: Is it about bootstrapping?
LT: It can be, but not necessarily. In the flow, you can modify the
value of the set of rules, and that's not bootstrapping.
AM: That's the work on access control.
PT: The management can help you find the set of rules.

[16:28] Presentation of lab.SCHC [10 min]

  • Presenter: Laurent Toutain

LT presenting

(Longer presentation available on Youtube, link on p1 of the slideset)

LT (p3): "IPcore" from Actility has met "Open SCHC" from IMT Atlantique.

PT: Is the Open Source of Open SCHC related to the Acklio implementation
going open source?
LT: That refers to the past.

LT (p4): Now we have also lab.SCHC to maintain compatibility between the
commercial IPcore and Open SCHC.

LT (p5): Showing the next steps for the next months of this year. We
want release a first full version of the SDK by the end of June to do
tests, and bring it to the Hackathon of IETF 120 in Vancouver. One
interesting feature to have by then and test is FEC. The full release of
the code is planned for the end of 2024 with all the features of the
SDK. Javier Fernandez can tell more about the features of the SDK.

JF (p6): Running tests on Arm Cortex devices.
JF (p7): More details on the Semtech platform used so far for testing.
JF (p8): Completed compression-only testing using OpenSCHC. Plan to test
soon also fragmentation-and-reassembly.
PT: When you say full SDK, do you mean the original implementation from
Acklio or is it going to be replaced?
JT: It keeps the IPCore code from Actility, ensuring that it is
compatible with openSCHC.
PT: Just wondering if this is good for the community, and if there's any
part that is planned to stay closed.
JT: The plan is fill some gaps and have released as open anything
related to standards.
PT: Great news to have high-quality open-source implementations.
LT: We welcome new people that want to join and contribute to the
project.

JF: We have also set up a website. www.lab-schc.fr
JF: We'll also be at the Hackathon of IETF 120 in Vancouver.

[16:43] Forward Error Correction (FEC) for SCHC [10 min]

GP presenting

GP (p3): the motivation is increasing chances of successful
reconstruction in case of lost packets/fragments.

GP (p4): Recap of the FEC method, also as intra- or inter-frame.

GP (p5): XORFEC relies on FEC and provides redundant information for the
receiver, to detect missing fragments and attempt their recovery.
GP (p6-7): Going through the properties of XORFEC.

GP (p9-16): Showing examples of XORFEC applied to SCHC packets in LPWAN.
Even in No-ACK mode (hence without feedback from the receiver), the
receiver can still successfully reconstruct the packet in the presence
of lost fragments. This also has the side effect to reduce
retransmissions.
PT: It a win anyway, if we can save downstream like you showed.

GP (p17): XORFEC makes a lot of sense, especially in No-ACK mode. We
reduce the number of retransmissions, and we help the downlink. The
limitation is the loss tolerance of 1 missing fragment. It also has
additional costs, for transmitting redundant content.
GP (p17): Next step: means for signaling the presence of redundancy.

LT: Nice presentation and good starting point, this is important.

LT: You're using only XOR, but you have other kinds of FEC existing. Can
they be used here?
GP: Yes, we can study alternatives, we have at least two in mind. This
was a start.

LT: When you do FEC, is it only at the fragmentation layer and then
removed when compressing? At the receiver side, how do you remove what
you introduced on the sender, without misinterpreting as an error?
GP: That's the next step: signaling that it is exactly about redundancy
and to be treated as such.

LT: We may have to check with Sergio, about a possible combination of
streaming and FEC.
GP: Yes, let's do that.

PT: We need a simple default mechanism, then further ones can be defined
in the future. Also playing with the window size can be good.
GP: Yes, good point.

PT: I was talking of implementations, about indicating one simple thing
that they really should support. Other means can be defined as optional.

Tokenizer-based Compression [10 min]

  • Presenter: Jaime Jimenez

Not presented.

[17:00] AOB [ QS ]

PT: Question to EV (SCHC AD): how can we access these recordings?
EV: The link should appear in the Datatracker, in the entry for the
meeting.