Add section on incentives #39
Conversation
| greasing comes with the risk of triggering failures. These failures might be innocuous, | ||
| 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. |
There was a problem hiding this comment.
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?
| 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, |
There was a problem hiding this comment.
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).
| @@ -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 | |||
There was a problem hiding this comment.
Is "improve the active use" correct here? ... it seems like this could improve/exercise extensibility or something?
| 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, |
There was a problem hiding this comment.
Is it just failures, or are these also potential anomolies (i.e., artefacts in logs, triggering operational/management events,...)
| 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. |
There was a problem hiding this comment.
/risks/ ... are they risk? concern? issues?
Co-authored-by: Lucas Pardue <[email protected]>
An attempt at addressing #32