**Session Date/Time:** 23 Jan 2024 15:00

# [SCHC](../wg/schc.html)

## Summary

The SCHC working group held an interim meeting to discuss the status of adopted drafts, new adoption requests, and future meeting plans. The primary technical discussions focused on the `draft-ietf-schc-oam` document, particularly its scope and the proposed "action" mechanisms, and a presentation on using SCHC fragmentation to enhance reliability for small data packets. A decision was made not to hold an in-person meeting at IETF 119 in Brisbane.

## Key Discussion Points

*   **Administrativa and Logistics**
    *   The IETF Notewell and IPR policy were reviewed at the start of the meeting.
    *   **Draft Status**: Two documents (`draft-ietf-schc-access-control` and `RFC 8824bis`) are now published as working group drafts.
    *   **Adoption Requests**: Requests for working group adoption have been published for `draft-ietf-schc-oam` and `draft-ietf-schc-ipv6-protocol-number`. Participants are encouraged to signal their support on the mailing list.
    *   **Milestone Discussion (`draft-ietf-schc-oam`)**: Laurent tout Saint Martin indicated that the OAM document has no currently unsolved technical questions, suggesting it could be ready for publication to the IESG before IETF 120 in Vancouver. However, this was noted as an aggressive timeline, and the group will aim for a more realistic target.
    *   **IETF 119 Brisbane Meeting**: A poll of the room and discussion with the AD (Eric Vyncke) indicated that most key participants (chairs, authors) would not be attending IETF 119 in Brisbane, and a virtual meeting would involve significant time zone challenges.
        *   **Decision**: The SCHC working group will **not** hold an in-person meeting at IETF 119 in Brisbane, Australia. The group will continue with its regular interim meeting schedule.
        *   **Action Item**: Chairs to inform the IETF Secretariat of this decision and send an email to the mailing list.

*   **SCHC OAM Draft (`draft-ietf-schc-oam`) Presentation by Laurent tout Saint Martin**
    *   Laurent presented the current state of the OAM draft, highlighting three main components:
        1.  **ICMPv6 Protocol Compression**: Based on RFC 4043, covering error messages and ping. This involves new field IDs in the YANG model for ICMPv6 fields, treating the payload as a compressible field.
        2.  **Generation of ICMPv6 Messages by SCHC**: For indicating SCHC-specific errors.
        3.  **Optimizations for Constraint Networks (LPWANs)**:
            *   **Global Action / Proxy**: Instead of sending messages on the constrained network, the core processes them (e.g., replying to a ping on behalf of the device).
            *   **New Matching Operators and CDAs**: For compressing payloads within ICMP messages.
    *   **YANG Model Augmentation**: The draft introduces "proxy behavior" in the YANG model, allowing for actions like "proxy ping" or "proxy none." Laurent suggested renaming "proxy behavior" to a more generic "action" or "action behavior" with specific values.
    *   **Discussion on Naming and Scope**:
        *   **Eric Vyncke** suggested renaming the draft to focus on "ICMPv6 processing for SCHC" rather than the broader "OAM." Laurent and Dominique concurred, having focused primarily on ICMPv6.
        *   **Dominique Barthel** raised concerns about the generic "action" mechanism, fearing it could open a "Pandora's Box" by introducing stateful behaviors and making the document overly broad and complex to define and understand generically in the long term.
        *   **Laurent tout Saint Martin** clarified that actions are intended for specific uses like keep-alive messages or triggering pre-processing of rules, and are not mandatory. He agreed the scope of "action" needs careful definition.
        *   **Alexander Pelov** suggested introducing specific actions (like ICMP proxying) and, if successful, expanding the framework in future documents.
        *   A sense of those present indicated that the ICMPv6 compression aspects are mature and ready to proceed, while the more generic "action" mechanism may require further refinement or potentially a separate, focused document to avoid open-ended complexity.

*   **Fragmentation for Reliability (building on `draft-santos-schc-streaming-over-lpwan`) Presentation by Alexander Pelov**
    *   Alexander presented a concept building on the ideas from the `draft-santos-schc-streaming-over-lpwan` (which is currently expired), aiming to provide reliability for small packets using SCHC fragmentation.
    *   **Problem Statement**: Current SCHC reliability (via fragmentation modes like Always-ACK or ACK-on-Error) primarily benefits "big packets" (those requiring multiple fragments). "Small packets" (fit in one MTU) often lack comparable reliability, leading to asymmetry, especially for critical control messages.
    *   **Proposed Solution**: Utilize SCHC fragmentation, but instead of segmenting a single large message, treat each small packet as a single fragment within a continuous fragmentation session.
    *   **Use Case**: Water metering, where a device sends small daily readings and an operator needs a guaranteed quality of service (e.g., 4 out of 6 messages per day). The SCHC Gateway could track this QoS and only request retransmissions if the target reliability level is not met, saving downlink resources.
    *   **Key Concepts**:
        *   Streaming of small packets, each treated as a fragment.
        *   Utilize existing fragmentation mechanisms (e.g., windowing, fragment counters).
        *   Configurable reliability level on the SCHC Gateway (e.g., 2/3 packet delivery rate), with retransmissions only triggered if the actual rate falls below this threshold.
        *   Support for in-order or out-of-order delivery.
        *   Potential for combining with Forward Error Correction (FEC) for increased efficiency.
    *   **Discussion Points**:
        *   **Edgar Salvador** confirmed this approach aligns with needs for Zero-Energy devices that also need reliability for full packets.
        *   **Sergiu Santos** clarified that DTAG (Datagram Tag) is used for cycles, not per packet, in the context of `draft-santos-schc-streaming-over-lpwan`, which affects how distinct SCHC packets are identified.
        *   **Dominique Barthel** suggested adding a mechanism to flag specific packets (e.g., debug information, OAM) so they are not counted towards business-critical QoS guarantees. He also noted the potential for mixing with FEC.
        *   **Laurent tout Saint Martin** questioned the necessity of DTAG, suggesting a large window might suffice for recovery in a streaming context. Alexander agreed this needed further investigation.
    *   **Conclusion**: This is a promising direction for enhancing SCHC's utility, especially for applications relying on small, reliable data transmissions. Further investigation and development are needed.

## Decisions and Action Items

*   **Decision**: The SCHC working group will **not** meet in person at IETF 119 in Brisbane, Australia. Interim meetings will continue as scheduled.
    *   **Action Item**: Chairs to inform the IETF Secretariat and the SCHC mailing list about the decision regarding IETF 119.
*   **Decision**: The working group will proceed with the adoption requests for `draft-ietf-schc-oam` and `draft-ietf-schc-ipv6-protocol-number`.
    *   **Action Item**: Working group participants are encouraged to review `draft-ietf-schc-oam` and `draft-ietf-schc-ipv6-protocol-number` and signal their support for adoption on the mailing list.
*   **Action Item**: Laurent tout Saint Martin (and co-authors) to consider renaming `draft-ietf-schc-oam` to a title more focused on "ICMPv6 processing for SCHC," reflecting the current scope.
*   **Action Item**: Laurent tout Saint Martin (and co-authors) to further refine the "action" mechanism within `draft-ietf-schc-oam`, potentially limiting its initial scope or considering how more generic aspects might be developed separately to address concerns about complexity.

## Next Steps

*   Continue active discussion and review of `draft-ietf-schc-oam` and `draft-ietf-schc-ipv6-protocol-number` on the mailing list to facilitate their adoption and progression.
*   Further investigation and development of mechanisms for providing reliability to small packets via SCHC fragmentation, building on the concepts presented by Alexander Pelov. This may involve new or revised drafts.
*   Maintain the rhythm of interim meetings to advance working group drafts.