Why in Building Protocols, Like Code, Starting Over Is Dumb
Why in Building Protocols, Like Code, Starting Over Is Dumb
Table of Contents
Today, the IETF held the CURRENT BoF,<br>where the goal was to develop a new protocol.<br>That protocol would be substantially like TLS,<br>reusing its record layer and basic structure,<br>but it would drop in MLS for key exchange.
This is somewhere between a pretty bad idea<br>and a horrible idea.
The wholesale replacement of a huge chunk of protocol architectures<br>is a hallmark of a lot of the AI-generated protocol proposals<br>that have flooded the IETF.<br>A small blemish is identified,<br>then the fix is a whole new protocol,<br>or a major piece of surgery.<br>No regard for the wisdom of Chesterton’s Fence<br>or the accumulated knowledge and usefulness embodied in what exists.
Experienced engineers know that rewriting a code module<br>is not something you do lightly.<br>There’s lots of literature out there about why this is a bad idea generally,<br>and some emerging discussion about how AI might just change that.
The reasons not to rewrite a software component still largely apply<br>to a protocol component.<br>The reasons that AI might make it easier to do that safely, less so.<br>Protocols are different.
Wholesale Change Will Miss Use Cases
Just like with a code change,<br>a protocol component that changes will miss use cases<br>that people really care about.
The usual concerns with code apply:
The existing features you know about and can test for<br>can be handled.
The existing problems you know and care about can be fixed.
You inevitably introduce brand-new problems.
The existing features you don’t know about<br>get lost.
Unlike code changes, you probably don’t have a test case<br>for existing features that you didn’t know about.<br>We found that with HTTP/2,<br>where a number of use cases got lost in the process<br>of “upgrading” HTTP.
In HTTP/1.1,<br>performing client authentication<br>in the middle of request was possible.<br>Losing that capability in HTTP/2<br>affected few enough people<br>that it was not badly damaging for the ecosystem.<br>It still sucked.
A lot of work was done to try to find these issues,<br>but we did not learn about these problems until fairly late in the process.
Proposing a protocol change means asking a whole lot of other people,<br>many of whom are not invested in your goals,<br>to do that work.
Changing a protocol by replacing a chunk of it,<br>no matter how much care is taken,<br>either asks the entire ecosystem to change with you.
That means asking everyone to move with you.<br>If they don’t, you are not changing the protocol,<br>you are forking it.
Forking A Protocol Destroys Interoperability
The real value of having a protocol like TLS<br>is that a great many things can all talk to each other.
Forking a protocol –<br>and sometimes profiling a protocol, a subject for another post –<br>destroys that.<br>You now have two ways to achieve the same goal,<br>and a choice to join one of two clubs.<br>You can join both, but that means constantly translating back and forth,<br>something that can only get harder over time<br>as protocol semantics diverge.
And yes, in case you were asking,<br>this applies to the entirety of the IETF IoT sphere,<br>which has parallel HTTP, TLS, and other analogues.<br>Ostensibly, these address the needs of highly constrained hardware,<br>but the cost is an ecosystem cut off from the mainstream.
But Fixing Protocols Is Hard
Yes, existing protocols come with baggage<br>or technical debt.<br>Maybe they aren’t perfectly optimized for your use.
The value that an existing protocol carries<br>is that you are sharing the burden of its maintenance<br>with a great many more people.<br>Fixing it, maybe by adding extensions to support your needs,<br>comes with opportunities to improve the protocol<br>even beyond that immediate need.<br>Every change is a chance to work off some of the accumulated cruft.
Major refreshes, like the TLS 1.3 reworking,<br>cleared out a ton of cruft in the process.<br>You get to benefit from the work that others do to improve that protocol too.
Do the Work
It is hard to be a responsible steward for the fabric of the Internet.<br>We do it because it is worthwhile.<br>Ignoring the lessons of the past is not helpful.
Previous: If you solve this CAPTCHA, you are not welcome here