**Session Date/Time:** 08 May 2024 21:00

# [EDM](../wg/edm.html)

## Summary

The EDM (Extensible and Dependable Middleboxes) session focused on refining the "Greasing in Protocol Design" draft. Key discussions revolved around the document's scope, particularly its intersection with reserved fields and the "must/should" semantics being debated on the working group chairs list. A significant portion of the meeting also addressed the crucial role of observability when deploying greasing or other protocol variations, drawing lessons from recent post-quantum TLS deployment challenges and HTTP/2 rapid reset issues. Participants agreed on the need to expand the document's examples beyond QUIC/TLS and to add a dedicated section on observability. Plans were made for an updated draft and community feedback ahead of IETF 120.

## Key Discussion Points

*   **Draft Status and Scope:** Lucas expressed gratitude for recent draft updates and issue activity. The group discussed needing more diverse examples beyond QUIC and TLS, as the current draft is swayed by his experiences. He also raised the question of when the draft should be considered for formal IAB stream adoption.
*   **Reserved Fields and "Must/Should" Semantics:**
    *   Lucas brought up an active discussion on the IETF working group chairs list regarding reserved fields, particularly whether they "must" be set to zero by senders and "must" be ignored by receivers.
    *   A participant noted the relevance of RFC 9413 (Protocol Maintenance) to this discussion.
    *   The sense of those present indicated that strict "must send zero, must ignore" rules are crucial to prevent collisions and ensure clear protocol extensibility, even if new RFCs might update the behavior for future versions.
    *   The interaction between reserved fields and greasing was noted: greased values are a special type of reserved value that *are* sent and *must* be ignored.
    *   There was a suggestion to provide more explicit guidance or "formulaic" text in the document on how to correctly phrase instructions for reserved fields.
*   **Greasing Frequency and Unpredictability:** Discussion arose about how often grease values should be used. While some implementations (e.g., Cloudflare for HTTP/3) send grease frames on the first request of every connection, the document currently lacks guidance on frequency or the importance of unpredictability to prevent peers from special-casing known greasing patterns.
*   **Observability in Greasing and Protocol Evolution:**
    *   A critical new point identified was the necessity of observing the effects of greasing or other protocol variability. If an experiment carries a risk of breaking something, the ability to observe its effects is paramount for safety and debugging.
    *   **Lessons from Post-Quantum TLS:** Recent issues with post-quantum TLS deployments (e.g., large Client Hellos breaking middleboxes/firewalls) were discussed. The group considered whether more aggressive variability (e.g., randomly sending larger Client Hellos) could have surfaced these issues earlier.
        *   Challenges with detection were highlighted: failures might be statistically lost in general internet noise, and feedback mechanisms are often difficult to implement (requiring telemetry, network error logging, or even relying on user complaints).
        *   The need for more granular error reporting in protocols like HTTP/2 and HTTP/3 was also mentioned.
    *   **Lessons from HTTP/2 Rapid Reset:** An anecdote about reducing HTTP/2 stream concurrency limits to mitigate attacks illustrated the challenges. While seemingly logical, it led to interoperability issues with user agents, which were only detected after a week due to broad, intermittent user reports. This again underscored the difficulty of observing subtle failures and the performance trade-offs involved in variability.
    *   **Risk vs. Benefit:** Deploying variability or greasing involves trade-offs between the benefits of maintaining protocol extensibility and the risks of breaking existing deployments or impacting performance. Participants noted that "greasing" as a concept is hard to "sell" to product managers compared to new features.
    *   **Stopping/Undeploying Greasing:** It was agreed that implementers should have mechanisms to measure the impact of greasing and be prepared to stop or undeploy it if significant issues arise. However, stopping greasing removes the incentive for ossified systems to fix their behavior.

## Decisions and Action Items

*   The draft needs to be expanded to include more rounded examples beyond QUIC and TLS. Solicitation for contributions from individuals like Cullen, Gory, and Dave will be made.
*   A new section on the importance of observability when deploying greasing or protocol variability will be added to the document. Lucas and David volunteered to help draft this text.
*   The discussion around reserved fields and the "must/should" semantics will be reflected in the draft, possibly by providing more explicit phrasing guidance.
*   **Action Item:** Lucas will file a new issue to track the need for text on the importance of observability when deploying variability.
*   **Action Item:** Lucas will reach out to Dave (who previously volunteered) regarding collaboration on the draft, copying David and Chris.

## Next Steps

*   **Draft Update:** Lucas aims to make a significant update to the draft within the next month, well in advance of IETF 120, to allow ample review time.
*   **IETF 120 Meeting:** The group plans to hold a meeting at IETF 120 in Vancouver to discuss the updated draft and continue working through open issues.
*   **IAB Stream Adoption:** Following the draft update and discussion at IETF 120, the chairs will consider initiating the IAB stream adoption process. This would involve a community feedback period on the candidate IAB document. It was noted that this initial community feedback round often generates valuable input.