**Session Date/Time:** 03 Jun 2024 14:00

# [QUIC](../wg/quic.html)

## Summary

The QUIC Working Group met to discuss several key issues related to explicit path IDs, focusing on simplifying the protocol, improving interoperability, and resolving ambiguities introduced by recent changes. Three main topics were on the agenda: the even/odd path ID split, path closing procedures, and connection ID allocation strategies. A sense of those present indicated a preference for simplicity and avoiding immediate changes that introduce additional complexity without compelling use cases. Concrete action items were assigned to authors for drafting PRs to address path closure and connection ID allocation recommendations.

## Key Discussion Points

*   **Overall Agenda Overview:** Mia presented three main discussion topics:
    1.  Deconfliction of Path IDs, specifically the even/odd split proposal, in the context of potentially allowing server-initiated paths (Issue #292).
    2.  Refinement of the path closing and retirement procedure (Issues #313, #366).
    3.  Clarification of the connection ID (CID) allocation strategy for new paths (Issue #338), especially concerning the `MAX_ACTIVE_CONNECTION_IDS` parameter (Issue #332).

*   **Path ID Deconfliction and Even/Odd Split (Issue #292):**
    *   The discussion revolved around whether to implement an even/odd split for Path IDs to prevent conflicts, particularly if server-initiated paths (Issue #47) were allowed.
    *   **Arguments against the split:** Mia proposed doing nothing, noting that existing mechanisms might cover deconfliction (e.g., client treating server-initiated validation as migration, or handling same 4-tuple with different Path IDs). It was argued that if server-initiated paths require new transport parameters, the split could be defined as part of that future extension. Christian agreed, highlighting the intricacy of PRs for symmetric setup and preferring to avoid "guesswork" now.
    *   **Arguments for the split:** Quenton initially proposed the split for clear ownership of path creation. Michael Ericson also saw value if server-initiated paths were adopted, drawing parallels to stream IDs.
    *   **Resource Control and `MAX_PATHS`:** Concerns were raised by Magnus about `MAX_PATHS` creating an attack surface, but Mia and Christian clarified that `MAX_PATHS` primarily controls the local endpoint's ability to send CIDs, and bidirectional Path IDs require both ends to issue CIDs for a given Path ID for a path to open. Martin highlighted ambiguity in the draft's phrasing of `MAX_PATHS`.
    *   **Sense of the room:** There was a stronger leaning towards *not* adopting the even/odd Path ID split at this time. Participants felt it introduced undue complexity without a clear, compelling use case, and that a simpler approach was preferable for now. It was acknowledged that if issues arise later, the decision could be revisited. The long-standing Issue #47 (allowing server-initiated paths) will remain open for future discussion.

*   **Active Connection IDs Parameter (Issue #332):**
    *   The `MAX_ACTIVE_CONNECTION_IDS` transport parameter, originally a global limit in RFC 9000, was changed in the latest draft to apply *per-path*. This change prompted the introduction of `MAX_PATHS` to limit Path IDs.
    *   **Mia's proposal:** Revert `MAX_ACTIVE_CONNECTION_IDS` to a *global* limit for the entire connection, thus potentially eliminating the need for the `MAX_PATHS` parameter. She argued that the true resource to control is the CID, and without `MAX_PATHS`, implicit control of active paths is still possible by not issuing CIDs for new Path IDs. This would simplify the protocol.
    *   **Counter-arguments/Concerns:** Yanmai argued for `MAX_ACTIVE_CONNECTION_IDS` *per-path* to align with per-path CID sequence numbers and prevent endpoints from exhausting CIDs on old paths, potentially hindering new path creation. Christian expressed concern about re-evaluating fundamental design choices, noting that current implementations work. Magnus raised concerns about load balancer semantics requiring CIDs to be tied to specific network entry points, which Martin echoed, suggesting a need to bind CIDs to addresses. Lucas (chair) deemed the load balancer discussion tangential to Issue #332.
    *   **Sense of the room:** While Mia's proposal aimed for simplicity, there was no strong consensus to change the current design, which already functions in implementations. The prevailing sentiment was to keep the current specification where `MAX_ACTIVE_CONNECTION_IDS` is per-path and `MAX_PATHS` provides a global limit.

*   **Path Closing Procedure (Issue #313):**
    *   The previous path closure procedure was ambiguous. It involved sending `PATH_ABANDON`, waiting 3 PTOs, then retiring CIDs.
    *   **Proposal for change:** Require a symmetric `PATH_ABANDON` from both sides. When both sides have sent `PATH_ABANDON`, the path is considered closed, and all associated connection IDs (and other path state) are implicitly retired. This simplifies the process by removing the explicit `CONNECTION_ID_RETIRE` for paths and leverages the availability of other paths for ongoing communication. Christian advocated for this, highlighting that laziness would otherwise lead to memory leaks if CIDs weren't implicitly retired.
    *   **Discussion on timers and reordering:** Martin and Mike raised concerns about reordered packets around `PATH_ABANDON` frames, potentially leading to stateless resets being generated. Christian suggested a "draining period" for the path, similar to connection draining, ending when the other side's `PATH_ABANDON` is received.
    *   **Sense of the room:** There was agreement to simplify the path closure procedure with symmetric `PATH_ABANDON` frames and implicit CID retirement.

*   **Requiring PATH_ABANDON on Timeout/Failure (Issue #366):**
    *   The draft currently states that `PATH_ABANDON` *should* be sent on path timeout.
    *   **Proposal:** Change this to a `MUST`, and also require it when path validation fails or when an endpoint no longer intends to use a Path ID. Yanmai supported this for a clear signal.
    *   **Sense of the room:** General agreement to change `SHOULD` to `MUST` for sending `PATH_ABANDON` in these scenarios. This change is expected to be part of the PR for Issue #313.

*   **Continuous Path IDs (Issue #318) and CID Allocation Strategy (Issue #338):**
    *   The potential for deadlocks was discussed, where endpoints issue CIDs for non-overlapping Path IDs (e.g., one for Path ID 3, another for 5), preventing new paths from opening.
    *   **Recommendations proposed:**
        1.  Endpoints should provide CIDs for the *minimum* of their advertised `MAX_PATHS` values.
        2.  Endpoints should use and provide Path IDs in *continuous and ordered* fashion (e.g., 0, 1, 2...).
        3.  Allow abandoning of Path IDs for which no CIDs were received (i.e., paths that never fully opened) to free up the space.
    *   Christian stressed that practical recommendations for continuous Path IDs would facilitate interoperability and avoid "crazy" allocation schemes. Yanmai noted that while full enforcement is difficult due to reordering, clear recommendations are important.
    *   **Sense of the room:** There was clear interest and agreement on the need for better recommendations in the draft to improve interoperability and prevent allocation deadlocks.

## Decisions and Action Items

*   **Issue #292 (Even/Odd Path ID Split):** A sense of those present indicated no strong desire to implement an even/odd Path ID split at this time. The issue will be reflected in the notes and put to the mailing list for a consensus call to close with no action.
*   **Issue #332 (Active Connection IDs Parameter):** A sense of those present indicated no strong desire to change the current design, where `MAX_ACTIVE_CONNECTION_IDS` is per-path and `MAX_PATHS` is a global limit. The issue will be reflected in the notes and put to the mailing list for a consensus call to close with no action.
*   **Issue #313 (Path Closing Procedure):**
    *   **Decision:** The path closing procedure will be updated to require a symmetric `PATH_ABANDON` from both endpoints, leading to implicit retirement of all associated CIDs and path state. A draining period will be considered to handle reordering.
    *   **Action Item:** Christian will draft a PR for these changes. Mike volunteered to review this PR.
*   **Issue #366 (Requiring PATH_ABANDON):**
    *   **Decision:** The `SHOULD` for sending `PATH_ABANDON` on path timeout/failure will be changed to `MUST`. This will be incorporated into the PR for Issue #313.
*   **Issue #338 (CID Allocation Strategy) / Issue #318 (Continuous Path IDs):**
    *   **Decision:** The draft will include clearer recommendations for CID allocation strategies, specifically encouraging endpoints to:
        *   Issue CIDs for a number of paths up to the minimum of the `MAX_PATHS` values advertised by both endpoints.
        *   Use Path IDs in a continuous and ordered fashion.
    *   **Action Item:** Quenton volunteered to draft a PR for these recommendations. Mia also offered to contribute to this PR.

## Next Steps

*   **PR Development:** Authors assigned action items will proceed with drafting the respective Pull Requests.
*   **Mailing List Consensus Calls:** The chair will send an email to the QUIC mailing list summarizing the outcomes of the interop meeting, particularly for Issues #292 and #332, to allow for wider feedback and initiate consensus calls for closing these issues.
*   **Draft Publication:** Authors plan to cut a new draft reflecting the agreed-upon changes before the next IETF meeting.
*   **Next Interop:** An interop event targeting the next draft is planned before the next IETF meeting.