Session Date/Time: 11 Jun 2024 14:00

SCHC

Summary

This SCHC working group session covered three main topics: an update on the "SCHC for Zero Energy Devices" (ZED) draft, a presentation on tokenizer-based compression for arbitrary strings, and a discussion on aligning SCHC architecture concepts with 15.4 networks. Key points included proposals for SCHC to handle object-level fragmentation for ZEDs and the need for more nuanced SCHC header compression strategies in multihop 15.4 environments. The working group indicated a strong intent to adopt the ZED draft as an informational document.

Key Discussion Points

SCHC for Zero Energy Devices (ZEDs) (Presented by Edgar)
- Updates to the ZED draft include more details on delay-friendly transmissions, architecture, context configuration, and payload compression.
- Focus is on more capable ZEDs (Type C/B) connected directly to base stations, which may have energy storage.
- Proposed using SCHC as a "transfer protocol" for full objects, not just individual IP packets. ZEDs would fragment objects into multiple transmissions due to unpredictable energy availability.
- The architecture needs to allow operators to collect these fragments and present the complete object to applications.
- Context configuration is crucial, driven by expected delays (hours, days, weeks, months) and packet sizes (small, medium, large). This influences timer values (retransmission, inactivity, packet transfer interval).
- Proposal to reuse the SCHC compression engine for payload compression, particularly for simple devices sending repetitive CBOR/CML values.
- A question was raised regarding the potential need for relaying fragments in delay-tolerant networking scenarios (e.g., satellite, Topology 2), but the current focus remains on direct communication.
- Discussion ensued about the nature of the document – likely an informational best practice guide, which could identify gaps for future standard-track work.
Tokenizer-based Compression for Arbitrary Strings (Presented by Hae)
- Explored using Byte Pair Encoder (BPE) tokenizers (common in LLMs) for compressing arbitrary strings, which are often not well-compressed by existing mechanisms like CBOR.
- The tokenizer process requires a shared vocabulary between endpoints. A 30KB vocabulary in tests yielded compression.
- Benefits include string pattern matching on tokenized data and applicability to new strings not used in vocabulary training.
- Test results with synthetic data showed 20-30% additional compression over initial CBOR compression.
- Trade-offs: Training the vocabulary is computationally expensive (done offline), but running the tokenizer on endpoints is light. Vocabulary size impacts compression ratio and memory.
- Future work includes exploring inference on receiving endpoints, optimizing vocabularies, and acquiring real IoT string datasets for training and testing.
- The chair noted the potential for this work, alongside Edgar's payload compression, to contribute to the SCHC architecture document.
SCHC Architecture Concepts in 15.4 Networks (Presented by Carles & Anna)
- The presentation aimed to align the sixlow draft (SCHC over 15.4) with the updated SCHC architecture draft, particularly concerning the SCHC Header concept.
- The main challenge is SCHC header compression in multihop 15.4 scenarios (Routover, Mesh Under).
- Two network types were proposed:
  - Single Instance Networks: All devices use a single SCHC packet instance, and the SCHC header must be fully compressed (zero bits).
  - Multiple Instance Networks: At least some devices use more than one SCHC packet instance, requiring the SCHC header not to be fully compressed to disambiguate instances.
- Examples for Routover (tunnel-based, pointer-based, straightforward) and Mesh Under demonstrated scenarios where a non-fully compressed SCHC header is necessary to determine which rule instance applies.
- Proposed format updates to introduce the SCHC header, sometimes nested within the PRO header for pointer-based Routover to simplify bit pointer logic.
- The document would define discriminators (SCHC dispatch or SCHC pointer dispatch) to indicate the presence of SCHC.
- Anna briefly introduced plans for defining transition protocols to identify UDP/CoAP headers following SCHC compression.
- Due to time constraints, a detailed discussion on this fundamental work was deferred to the next meeting.

Decisions and Action Items

Decision: The working group expressed strong intent to adopt the "SCHC for Zero Energy Devices" draft (draft-edgardiaz-schc-zero-energy-device) as an informational document. A formal call for adoption will be initiated on the mailing list.
Action Item: Edgar (ZED draft author) to connect with Juan Carlos (Wi-Fi work) to explore potential commonalities or collaboration.
Action Item: Edgar to inform the chairs via email if any substantial updates are deemed necessary for the "SCHC for Zero Energy Devices" draft before the formal call for adoption on the mailing list.
Action Item: The chairs noted that both Hae's tokenizer work and the payload compression aspect of Edgar's ZED work could serve as input for future discussions on the SCHC architecture document.

Next Steps

The chairs will initiate a formal call for adoption of the "SCHC for Zero Energy Devices" draft on the mailing list.
The detailed discussion on "SCHC Architecture Concepts in 15.4 Networks" (Carles and Anna's presentation) will be continued at the next working group meeting to allow for in-depth review and questions.
Further discussion and feedback on Hae's tokenizer-based compression work are encouraged on the mailing list.