Skip to content

Add section on incentives #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add section on incentives #39

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
60b6673
Add section on incentives
tfpauly Jun 5, 2025
ac13a74
Update draft-edm-protocol-greasing.md
tfpauly Jun 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions draft-edm-protocol-greasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,35 @@ cause a new class of interoperability failure. Therefore a label such as
"reserved for greasing" may help to avoid the confusion.


# Deployment Considerations and Incentives for Greasing

Greasing can be used as a tool to improve the active use of existing protocol
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "improve the active use" correct here? ... it seems like this could improve/exercise extensibility or something?

elements (which weren't necessarily designed with greasing to begin with, or
weren't deployed with greasing); or as part of new protocol design and deployments.

When greasing isn't used from the beginning of protocol deployment, starting to use
greasing comes with the risk of triggering failures. These failures might be innocuous,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it just failures, or are these also potential anomolies (i.e., artefacts in logs, triggering operational/management events,...)

but they also might be very impactful and visible to users. This risk creates a
disincentive to deploy greasing in existing systems, since generally the change that
triggers failures is often blamed for the failure.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text in this para is good. However, one clarification point I'd like to make is to confirm what you mean by "existing systems".

One scenario I can think of is where a new entrant comes to the market e.g. a ground-up Web server that employs greasing practices and operates well in isolated testing. Is the Web an existing system in this scenario? I tend to think yes. Lets imagine the new server was operated by a new CDN, as they gather business websites transition to it, the user agent diversity increase and there may be clients unable to deal with grease. The change that triggered failure is not the protocol deployment itself, but the transition of clients to this system.

There are a few outcomes in a scenario like that. The website owner receives the complains and opens a support ticket to their new CDN, who can try to find the root cause and add accommodation for the interop issue (such as disabling grease on a blanket level, or for some subset of the clients that are seeing issues, reaching out to the affected client etc.). That's quite optimistic though. Its equally likely that the website owner or CDN operator can't figure out the problem, and the pragmatic solution is for the owner to switch away from the CDN.

Does that fit in your mental model for this text? or would we need to say something a bit different / in addition?


Some approaches to avoid failures due to greasing include:

- Designing, implementing, and using greasing very early on in protocol development
and deployment. This avoids the risks of adding greasing later.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/risks/ ... are they risk? concern? issues?

- Enabling greasing along with other major protocol feature changes or deployment changes.
For example, when upgrading to a new protocol version that requires implementation updates
on multiple systems, greasing can be added for the new version specifically. This approach
works well for situations where the protocol participants are known and already need
to cooperate (such as within an encrypted protocol between two endpoints). This approach
applies less well for situations where non-cooperating entities (such as middleboxes)
are the source of ossification.
- Using heuristics to disable greasing when errors are encountered. For example,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read this a couple of times and I'm not sure if the intention is to describe dynamic behaviour using heuristics specifically when errors are encounterd, or if static methods / pre-empting failue are covered too.

In other words, I might know apriori that a subset of clients have a known issue with greasing without needing to encounter the problem myself. One approach to avoiding the problem is to partition the "existing system" based on something like a client identifer (ASN, versions exchanged in a handshake prior to when problematic greasing might be encountered, etc.) and special case them for a time period (which might extend to infinity).

if a protocol operation fails multiple times when grease values are used, it can be retried
without any grease values. This reduces the effectiveness of grease values in removing
existing ossification, but can still have benefits for flagging issues in new implementations
when they receive grease values.

# Considerations for Increasing Protocol Variability {#variability}

Greasing can maintain protocol extensibility by falsifying active use of its
Expand Down