**Session Date/Time:** 26 Apr 2023 12:00

# [DETNET](../wg/detnet.html)

## Summary

The DETNET Working Group meeting focused on two main areas: further refinement of the "Enhanced Data Plane Requirements" draft (draft-ietf-detnet-enhanced-data-plane-requirements) and a presentation on "Deadline Based Forwarding" (draft-li-detnet-deadline-based-forwarding). Discussion on the requirements draft centered on clarifying new proposed requirements, separating data plane from control/management plane concerns, and ensuring compatibility with various forwarding mechanisms. The deadline-based forwarding presentation introduced a queuing and scheduling mechanism based on an Earliest Deadline First (EDF) variant, followed by a detailed Q&A session covering its operation, assumptions, and potential issues like packet reordering.

## Key Discussion Points

*   **Meeting Process:** The chairs noted that having one presentation per meeting allows for more thorough discussion, a practice that will continue.
*   **Requirements Draft (draft-ietf-detnet-enhanced-data-plane-requirements):**
    *   **New Proposed Requirements:** Jindong proposed three new requirements for Section 3: handling a large number of hops, tolerating burst accumulation, and tolerating high utilization.
    *   **Requirement 3.7 Clarification:** Discussion arose on whether two paragraphs within the current requirement 3.7 should be considered one or two distinct requirements.
    *   **Requirement 3.8 Split:** A sense of those present indicated that the proposed requirement 3.8 ("tolerate high utilization and scalable network planning and queuing solutions") contained two separate concerns: data plane aspects related to queuing solutions supporting high utilization, and control/management plane aspects related to network planning. It was suggested that network planning material might be better suited for the detnet control plane framework draft (draft-ietf-detnet-control-plane-framework).
    *   **Requirement 4 (Path Selection):** Discussion clarified that this requirement should focus on the data plane's compatibility with various steering solutions (e.g., source routing, hop-by-hop steering) and the interaction of multiple extension headers (e.g., for steering and QoS). The objective is for queuing mechanisms to be applicable to *whatever* steering is in use, rather than being specific to one.
    *   **Header Design Implications:** Participants recognized the need to consider what per-packet information queuing mechanisms require to be carried in headers, without prematurely committing to specific header designs.
*   **Evaluation of Queuing Mechanisms against Requirements:**
    *   **Initial Evaluation Target:** The chairs proposed that for the next meeting, the requirements draft authors begin an initial evaluation of a known queuing/scheduling mechanism against the detnet requirements.
    *   **TSN ATS vs. RFC 2211:** There was a brief discussion on whether to use RFC 2211 (InterServ) or TSN ATS (Time-Aware Shaper/Scheduler) for this initial evaluation. While RFC 2211 is an IETF RFC, TSN ATS was generally preferred as a more relevant and modern mechanism, despite potential challenges in accessing IEEE standards documents (though it was noted that many IEEE standards are free after six months).
*   **Deadline-Based Forwarding Presentation (Xiaofu Li):**
    *   **Mechanism Overview:** The presentation introduced a queuing mechanism that uses an Earliest Deadline First (EDF) variant, maintaining queues based on a "countdown time" (CT) and a "rotation interval" (TI). It described "in-time" (work-conserving) and "on-time" (non-work-conserving, delaying packets until closer to their deadline) modes.
    *   **Schedulability and Bursts:** The draft provides schedulability conditions and discusses how bursty traffic is handled through latency compensation, which acts as a shaper at ingress/transit nodes.
    *   **Buffer Sizing and Admission Control:** The approach considers buffer sizing based on schedulability conditions and relies on admission control at ingress to ensure traffic adheres to its "contribute function."
    *   **Packet Header Fields:** The mechanism relies on packet headers carrying "plant earliest sending time" (D) and "accumulated residence time deviation" (E) values, which are updated per hop. D is calculated by a controller, while E is updated by each node.
    *   **Clock Assumptions:** The mechanism does not require global wall clock time synchronization but assumes that router clocks are frequency-synchronized, meaning their rates of advance are aligned (bounded clock skew).
    *   **Packet Reordering:** It was acknowledged that latency compensation and work-conserving behavior could lead to packet reordering within a flow. Two potential solutions were mentioned: "packet ordering focusing" (from DetNet) or using a "flow/class object" for reordering.
    *   **Comparison to RC EDF:** A participant asked for clarification on the difference between this proposal and Rate-Controlled Earliest Deadline First (RC EDF), noting similarities in using shaping (latency compensation) and EDF scheduling. The presenter clarified differences in per-flow state and queue management.
    *   **Calculus Proof:** The proof for the calculus used in the mechanism is based on existing literature referenced in the draft.
    *   **Header Field Size:** A suggestion for the size of the deadline field in a header was 3 bytes, consistent with some existing IPv6 extension header practices, to accommodate potential long paths and large deadlines.
    *   **"On-time" Mode:** It was clarified that the "on-time" (non-work-conserving) mode, while offering higher priority, does not necessarily guarantee latency bounds and is primarily intended for ingress nodes, not transit.
    *   **IOAM Analogy:** It was noted that IOAM (In-situ OAM) mechanisms also update per-packet fields at each hop, which might offer insights into practical implementations of updating fields like 'E'.

## Decisions and Action Items

**Decisions:**

*   The working group will adopt a practice of focusing on one presentation per meeting to allow for more in-depth discussion and Q&A.
*   Initial evaluation of queuing mechanisms against the detnet requirements will prioritize TSN ATS over RFC 2211 due to its modern relevance.

**Action Items:**

*   **Requirements Draft Authors (Peng, Jindong, et al.):**
    *   Continue discussions on the proposed changes to requirements (especially 3.5, 3.7, 3.8, and 4) via the mailing list.
    *   Revise the `draft-ietf-detnet-enhanced-data-plane-requirements` based on these discussions, clarifying the separation of data plane vs. control/management plane requirements.
    *   For the next meeting, prepare an initial draft matrix evaluating TSN ATS against the requirements specified in the requirements draft.
*   **Xiaofu Li (Deadline-Based Forwarding):** Continue to refine the `draft-li-detnet-deadline-based-forwarding`, particularly addressing the packet reordering issue and providing more detailed descriptions of the calculus and header field usage.
*   **Chairs:** Upload the presentation slides to the working group's document repository, ideally with slide numbers added.
*   **All Participants:** Review the meeting notes in HedgeDoc for accuracy and provide feedback.

## Next Steps

*   Mailing list discussions will continue on the proposed revisions and clarifications for the "Enhanced Data Plane Requirements" draft.
*   The requirements draft authors will work on preparing an initial evaluation of TSN ATS for the next meeting.
*   Work on the deadline-based forwarding draft will continue, with an emphasis on addressing the identified technical considerations.
*   The next working group meeting is planned for approximately two weeks from now.