Interim SCHC #9 2024

WG info

• Charter
• Documents
• ML

Meeting Information

• Date and Time: June 11th, 2024, 7-8am DST, 4pm CEST
• Agenda: on datatracker
• Meeting material: on datatracker
• Meeting link: Meetecho
• Live Minutes: Note-takers Link
• ical: ICS

Agenda

[16:00] Administrivia [5min]

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

[16:05] SCHC for ZE devices: updates to the draft [20 min]

• Presenter: Edgar Ramos

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

• Presenter: Jaime Jimenez

[16:35] SCHC architecture concepts [25 min]

• Presenter: Carles Gomez and Ana Minaburo

[17:00] AOB [ QS ]

Minutes

[16:00] Administrivia [5min]

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

[16:05] SCHC for ZE devices: updates to the draft [20 min]

• Presenter: Edgar Ramos

Presented slides:
https://datatracker.ietf.org/meeting/interim-2024-schc-09/materials/slides-interim-2024-schc-09-sessa-schc-for-ze-devices-updates-00.pdf

ER (p1): Made some changes to the draft (delay friendly optimizations,
SCHC context configuration, ...)
ER (p2): Different topologies considered in 3GPP, focusing mainly on the
first one
ER (p3): Mostly focusing on device of class A and B, as more capable.
ER (p4): The typical features/expecations for this device would take
good advantage of SCHC.
ER (p5): A payload can hardly be transmitted at once, hence
fragmentation is involved. Transmission schedule is unpredictable.
ER (p6): We use SCHC as transfer protocol. Not a packet but instead a
whole object is divided into fragments.
Notification that the whole object has been transfered.
Modification in the way SCHC works, as it is applied to an "object", and
not strictly speaking on a Packet. In some way, you can think of it as a
Jumbo packet.
You can thus consider it as a delay-tolerant way of distributing data.
ER (p7): The SCHC context can be configured out-of-band or through a
dedicated radio control / higher-layer protocol.
ER (p8): A typical configuration consists of expected delay, and
information related to timers, packet size, window size and
retransmission configurion.
LT: In the data model, we define a short or long representation of time.
It shouldn't be a problem here, it's more for implementations to
consider.
ER (p9): Configuration values are highly dependent on contextual,
application-specific information like the time of the day or the current
application events.
ER: the transmission / retransmission can be very related to the energy
capture by the device.
ER: reuse the compression engine used by SCHC for payloads as well.
Example: SenML.

ER: Discuss WG adoption?
PT: I'm in favor of adopting an item like this as a provider of a best
practice. What about delay-tolerant networking in general, even within
the planet? Then you may want to relay the packet, but at the moment we
don't relay fragments in SCHC. How would that work?
ER: that can be relevant for other topologies - e.g. Topologie Nr 2 from
Page 3.
ER: We can start with a simple case, and then introduce an intermediate
work.
PT: Do you agree that this work is a best practice, without changing
SCHC?
ER: Well, we are making the chance of considering an object instead of a
packet.
PT: SCHC is transparent as to what it compresses, it would still see a
"packet".
ER: If that's the case, no problem then.

ER: On the packet size, it's about context configuration, and we can
accommodate different configurations able to handle different packet
sizes on the same machine. In that respect, it's more a best practice.

LT: Do you target one particular fragmentation mechanism or all of them
are possible?
ER: Any should be possible, but ACK on error is more suitable for
cellular.
LT: If you send an ACK to a sleeping device, then the ACK will be lost.

ER: That's something for the devices of class B and C.

LT: What about FEC retransmission of what is not re-requested?
ER: That's also interesting to consider.

LT: We have a PhD student working on a compact way to represent SenML.
Will come back to you.

AP: Started a show of hands for WG adoption. This sounds like targeting
an Informational document. Unless we find out that a number of things
are actually missing in SCHC; in that case, it can be considered to be a
Standards Track document

Show of hands: "Adopt as WG item"
TOTAL PARTICIPANTS: 11
raise your hand: 9
do not raise your hand: 0
no opinion: 0

AP: The show of hands looks interest for WG adoption. We will confirm
this on the mailing list.
PT: ER, to you want to publish a new version before the WG adoption
call?
ER: I will check if something very important is missing.
PT: Please send the Chairs a mail clarifying.
ER: The current content is good to start the WG Adoption Call. Any
feedback/comment will trigger changes.
ER: For the time being, relays are not considered.
PT: Then we start the WG Adoption Call considering the current version.
The details in the document format are not a concern.

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

• Presenter: Jaime Jimenez

Presented slides:
https://datatracker.ietf.org/meeting/interim-2024-schc-09/materials/slides-interim-2024-schc-09-sessa-compression-tokenizer-for-schc-00.pdf

JJ (p2): background on tokenization of strings, as independent of the
used LLM.
JJ (p3): CBOR has limitations; this approach relies on Byte Pair
Encoding (BPE) and builds on a small vocabulary size (30kb), string
pattern matching, and compresses arbitrary strings.
JJ (p4): Showing example.
JJ (p5-p6): Implementation report (Github repo to be shared soon).
JJ (p7): Experienced a 20-30% data compression on synthetic data.
JJ (p8): Graphical comparison of compression rates when using
tokenization instead of vanilla CBOR.
JJ (p9): Open points (mostly trade-offs) and next steps.
JJ (p10): Useful in the IETF? Relevant for SCHC payload compression?

AP: This is interesting. As you said, the origin of the data used to
build the dictionaries (and their size) plays an important role.
LT (on chat): Edgar and Jaime talked of payload compression, maybe this
could be added in the architecture document?
AP: Yes, probably we should do that.
AP: Let's continue the discussion on the mailing list.
JJ: Just reach out any time with questions and comments.

[16:35] SCHC architecture concepts [25 min]

• Presenter: Carles Gomez and Ana Minaburo

Presented slides:
https://datatracker.ietf.org/meeting/interim-2024-schc-09/materials/slides-interim-2024-schc-09-sessa-schc-architecture-concepts-for-draft-ietf-6lo-schc-15dot4-00.pdf

AP: In the interest of time, maybe part of this can come in a next
meeting.

CG: Adapting the architecture for transmitting over 15.4 networks.

CG (p2): Repack of goals and scenarios.
CG: the main problem is the multi-hop operation.
CG: two possible network types: single instance (only one SCHC context),
and multiple instance networks (at least one of the devices can have
more than one SCHC instances). Instance in the sense of SCHC Instance.

CG (p3): Showing an example of multiple-instance networks. This
emphasizes the selection of the right SCHC instance to use for
decompressing and incoming messages, which is the reason for needing a
SCHC header.
CG (p4): Similar case, this time with no need to go through the root.
CG (p5): One more case, and again we need a SCHC header, which cannot be
fully compressed and has to include an ID-like parameter that has to be
unique network-wide.
CG (p6): mesh-under. A similar problem to the example on p5. There may
be ambiguities, even if you know the MAC address of the sender. So , you
still need a non-fully compressed SCHC Header.
CG (p7): The format in the draft needs to be updated by including the
SCHC header. In some scenarios, the SCHC header can be compressed down
to a residue of 0 bits.
CG (p8): as on p7, you may need to add SCHC header.
CG (p10): We expect to extend the draft explaining how the SCHC
architecture is used in 15.4 networks, discussing the different cases.
What is the discriminator? It can be the SCHC dispatch or pointer
dispatch.
CG (p11): A separate new section should also discuss the
multiple-instance case. Same as above about the discriminator.

AP: Time's up, it's better if you continue next time. This is important
to understand and discuss well.

AM: That continues with the stack transition according to the
architecture. We need to discuss the details, but we want to use the new
version of the architecture with 6LoWPAN in mind.

[17:00] AOB [ QS ]