**Session Date/Time:** 06 Nov 2025 18:00

# EDM

## Summary

The EDM session focused primarily on two main topics: the status and progression of the greasing document, and a debrief from a recent "Why not more QUIC?" side meeting. For the greasing document, attendees discussed the large number of open issues, strategized on issue assignment and resolution, and considered the process for merging changes and initiating an IAB adoption call. The debrief on QUIC highlighted current deployment statistics, perceived impediments to wider adoption, and areas for potential technical work or community education, though no direct EDM action items emerged from this discussion.

## Key Discussion Points

### Greasing Document Status and Progress
*   **Current State**: Several Pull Requests (PRs) from Dave were merged, and the document has been published in its current form. There are currently 15 open issues.
*   **Key Areas for Improvement**:
    *   **Protocol Versions**: Discussion around issue #50, which asks about the cost and implications of greasing version negotiation in various protocols (e.g., TLS, QUIC) and data formats. Dave volunteered to take this on, noting it's not just about versions but also crypto algorithm negotiation.
    *   **Security Considerations**: Identified as anemic (issue #49). Tommy offered to take a first pass at drafting these. The IAB stream does not strictly require security considerations for workshop reports, but for this technical guidance document, it was generally agreed they are appropriate.
    *   **Greasing at Multiple Layers**: Issue #6, raised by Gorry, exploring whether greasing concepts apply beyond HTTP, QUIC, and TLS to lower or higher layers. Dave volunteered to consider this.
    *   **Wire Image and Ossification**: Discussion of issue #53, suggesting an example in the introduction about upload vs. download could be expanded to discuss the "wire image" of protocols (referencing RFC 9546) and how it ossifies beyond just code points. Martin provided examples from QUIC implementations deliberately randomizing extension order or splitting initial packets to combat ossification. Martin volunteered to work on this, incorporating the idea of performance costs associated with wire image variations.
*   **Issue Triage and Assignment**:
    *   A sense of the room indicated that open issues should be assigned and actively worked on.
    *   The approach would be to grab issues, with the understanding that an initial assessment might lead to closing them if they don't make sense to include.
    *   Specific assignments:
        *   Tommy: Issue #49 (Security Considerations).
        *   Dave: Issue #50 (Protocol Versions / Greasing version negotiation cost), Issue #6 (Greasing at multiple layers).
        *   Martin: Issue he just added (editorial, structural). Also issue #53 (Wire Image/Ossification).
        *   Lucas: Will review his currently assigned issues, potentially offloading some he doesn't fully understand (#53 was specifically mentioned as one he'd prefer someone else take). Lucas affirmed he will address his assigned issues or seek further input if stuck.
        *   Issue #21 (discouraging ossification in middleboxes) was reviewed and deemed potentially covered by existing text in section 3.1. Tommy to confirm and propose closure.
        *   Issue #19 (SIP/RTP examples) was discussed; a sense of those present indicated that unless these examples introduce new technical points not already covered, they might not be necessary. Tommy volunteered to review Colin's related post and propose closure if no new technical points are found.
        *   Issue #5 (QUIC bit) was noted as an interesting example of greasing, and will be referenced in other sections rather than being a standalone issue.
*   **Document Process and Timeline**:
    *   The question of a clear process for merging PRs (e.g., number of approvals, unresolved comments) was raised but not definitively decided.
    *   There is a desire to move the draft towards publication, potentially aiming for an IAB last call before the current IAB term ends in March.
    *   **IAB Adoption Call**: Discussion shifted to formalizing the document as an IAB work item. It was noted the document is currently still an individual program item, not formally adopted by the IAB. A call for community review and IAB adoption needs to be initiated.

### "Why not more QUIC?" Debrief
*   **Context**: A side meeting at IETF 118 discussed the plateauing of QUIC adoption (reported ~30-50% of requests/connections in Firefox) and reasons for this.
*   **Observed Impediments**:
    *   Lack of developer desire to transition, especially from HTTP/1.1 directly to HTTP/3.
    *   Concerns about server-side resource utilization.
    *   **Multi-CDN Use**: Mismatch between browser expectations and DNS-based load balancing in multi-CDN deployments.
    *   **Middlebox/Enterprise Proxies**: User agents (Chrome, Firefox) often don't allow QUIC in these environments, causing "annoyance" for network scanners.
    *   **Lack of Killer App**: Difficulty in measuring performance improvements for HTTP use cases; QUIC "kind of works the same way" as other HTTP versions from an end-user perspective.
    *   **Application Adoption**: Non-browser applications (e.g., Electron apps, IDEs) lack incentives or clear paths to adopt QUIC libraries.
*   **QUIC's True Success Metric**: Martin argued that QUIC's success shouldn't be measured by 100% deployment (bytes or requests), but by its ability to provide degrees of freedom for application developers to build new features (e.g., MASQUE, EPP over QUIC). This shift in enabling new technical designs, rather than ubiquitous traffic, is the key value.
*   **Implementation Plurality and Education**:
    *   The multitude of QUIC implementations, while a blessing, is also a curse: not all are well-tuned, leading to poor performance comparisons.
    *   Congestion control is a complex area that needs to be "gotten right" by all implementations.
    *   Lack of good introductory explanations for QUIC streams and their lifecycle, leading to developer misunderstandings based on specific library APIs.
    *   QUIC is increasingly being taught in graduate university courses, but may not be as foundational as TCP yet. There's a need for updated reference materials (e.g., Stevens' books).

## Decisions and Action Items

*   **Greasing Document Issue Triage**: Attendees collectively agreed to triage and assign open issues for the greasing document.
    *   **Dave**: Take on issues #50 (Protocol Versions / Greasing version negotiation cost) and #6 (Greasing at multiple layers).
    *   **Martin**: Take on his recently opened editorial issue and issue #53 (Wire Image/Ossification).
    *   **Tommy**: Take on issue #49 (Security Considerations). Review issue #21 (discouraging ossification in middleboxes) and propose closure if already covered. Review issue #19 (SIP/RTP examples) and propose closure if no new technical points are added.
    *   **Lucas**: Review assigned issues; will work on them or seek input/offload if progress is blocked.
*   **IAB Adoption Call**: John will initiate the process for the greasing document to be formally adopted as an IAB work item and for a community review. This will likely involve a message to the architecture-discuss mailing list.

## Next Steps

*   **Issue Resolution**: Assigned individuals will work on their respective greasing document issues, aiming for resolution by the end of the year if possible.
*   **IAB Adoption**: John will proceed with the IAB adoption call and community review for the greasing document.
*   **Documentation Process**: The EDM program should clarify its process for merging PRs and approving changes to the greasing document.
*   **Community Education (QUIC)**: While not a direct EDM action item, the debrief from the "Why not more QUIC?" session highlighted a need within the broader IETF community for better introductory material on QUIC streams and for continued focus on robust QUIC implementations and congestion control.