**Session Date/Time:** 06 Jun 2025 15:00

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

## Summary

The EDM session focused on progressing the "greasing" document towards formal adoption as an active IAB document, which would involve broader community review via the architecture-discuss mailing list. Key discussions revolved around recent proposed changes to the document's abstract, detailed guidance on greasing mechanics, the critical issue of *not special-casing* grease values, and the overarching incentives and disincentives for deploying greasing and variability. Participants debated the optimal frequency of greasing to balance effectiveness with avoiding unintended network alarms and the need for clear protocol specification regarding unknown versus invalid values.

## Key Discussion Points

*   **Document Status and Adoption Goal:** The "greasing" document is currently tracked by the IAB but not formally adopted. The goal is to refine it to a state ready for an IAB adoption call, followed by broader community review.
*   **Purpose and Scope of the Document:** Lucas provided background, emphasizing that the document aims to give *concrete guidance* to protocol designers and implementers, building on higher-level IAB drafts on protocol maintenance. It addresses both active "greasing" (ignoring values) and broader "protocol variability" (breaking assumptions about normal operation).
*   **Abstract and Introduction Refinement:** Proposed changes clarify the document's distinction from prior IAB/EDM work (e.g., "Use It Or Lose It") and position it as offering specific, practical advice on applying greasing and variability mechanisms, including avoiding common pitfalls.
*   **Greasing Mechanics and IANA Considerations:** The document outlines best practices for defining and registering grease values, advocating for large ranges, algorithmic value generation, and clear IANA registration policies.
*   **Unpredictability and Frequency of Grease Use:**
    *   There was extensive discussion about making grease values unpredictable and using greasing unpredictably over time.
    *   Lucas highlighted the difficulty of defining a universal "sweet spot" for frequency, citing QUIC's approach of sending two grease streams at connection start as an "inoculating effect" that eventually becomes normalized.
    *   A sense of those present indicated that too infrequent use might render greasing ineffective as failures would not be observed or reported.
    *   Gory raised concerns about network monitoring systems triggering alarms due to "unusual" traffic patterns generated by greasing, prompting discussion on whether the goal is to avoid alarms or to normalize "differentness."
    *   Miria emphasized that increased frequency, while potentially more effective, could lead to more complaints or alarms, requiring implementers to be prepared for such responses.
*   **Not Special-Casing Grease Values:** Based on an issue raised by Martin Thompson, this section focuses on the pitfall of implementations incorrectly special-casing grease values.
    *   The core principle is that greasing fundamentally relies on the protocol tolerating *unknown* values by default; if a protocol is strict about unknown values, greasing will not be effective.
    *   Miria and Lucas distinguished between *unknown* values (which should ideally be ignored) and *invalid* values (which should strictly cause errors), stressing that protocol specifications must clearly define the handling algorithm for both, possibly with pseudo-code examples.
*   **Incentives for Greasing and Variability:** A new section, based on an issue from Dave Taylor, explores the "why and when" of greasing from a protocol developer's perspective, acknowledging the inherent risks. A taxonomy of approaches was presented:
    *   Greasing from day zero (e.g., QUIC).
    *   Introducing greasing during significant protocol version changes (e.g., TLS 1.2 to 1.3).
    *   Gracefully handling failures by algorithmically turning off greasing when issues are detected, while being aggressive where it succeeds.
    *   Miria suggested renaming this section and moving it earlier in the document to address the fundamental decision of whether to grease at all.

## Decisions and Action Items

*   The "greasing" document will be refined to prepare for an IAB adoption call and subsequent broader community review.
*   The abstract and introduction will be further clarified to explicitly state the document's goals, intent, and target audience (protocol designers and implementers).
*   The section on "Incentives for Greasing" (currently a pull request) will be reviewed for renaming and potential repositioning within the document to better serve protocol developers in deciding whether and when to implement greasing.
*   The document will incorporate discussion on the frequency of greasing, its impact on failure detection, and the potential for raising network alarms, including considering different approaches like "flag days" versus organic, always-on greasing.
*   The document will clarify the distinction between unknown and invalid protocol values, emphasizing that greasing relies on protocols tolerating unknown values by default. Protocol specifications should clearly outline algorithms for handling both, with pseudo-code examples where beneficial.

## Next Steps

*   Tommy will complete an editorial pass on the protocol variability section of the document.
*   Cullen's examples from SIP and RTP (shared on the mailing list in November 2023) will be reviewed for potential inclusion or influence on the document's content to broaden its applicability.
*   Participants are encouraged to provide direct feedback and text suggestions on the open GitHub Pull Requests, particularly for the abstract, introduction, and the "Incentives" section, to address clarity regarding the document's audience and purpose.