Re: Invariants draft

[Martin Thomson <[e-mail]>]

Thanks for the comments Christian.  I think that this is one of the
most important points to reach agreement on, mainly because we get
stuck with the outcome for a long time.

On Fri, Dec 1, 2017 at 3:46 PM, Christian Huitema <[e-mail]> wrote:
> As far as the general approach is concerned, your draft leaves me
> somewhat uneasy. I understand the concern to beat ossification, and to
> ensure that future developers can easily define and use extended
> versions of QUIC. But at the same time, I am concerned with the tension
> between "focusing on extensibility" and "ensuring interoperability".

I don't think that this dichotomy is - as you make it - as serious as
that.  It's a reflection of a design philosophy.

The philosophy reads like this: It's easier to design a protocol
without extensibility points.  Designing good and usable extensibility
is really hard.  So you invest your effort into designing a
replacement strategy and only add the extensibility you know that you
need.  No matter how much of the protocol you mess up, as long as you
can replace the entire protocol, you are never stuck.

When we did HTTP/2, we had ALPN.  We could have added a *lot* more
extensibility to HTTP/2 than we did, but we didn't because we knew
that HTTP/3 was always a possibility.  That raised the bar for
extensibility mechanisms, and I think we produced a better result,
more quickly for it.

For QUIC, this doc attempts to define that pivotal mechanism.  That
doesn't mean that QUIC version 2 will be substantially different.  On
the contrary, I expect that we'll make new versions with only modest
changes.  But those changes might *appear* to be significant.  The
hope is that significant changes will be possible because the protocol
won't be so ossified as to make them impossible.

You might think that this is familiar to Adam Langley's views on
extensibility.  That is "have one joint and keep it well oiled" --
<https://www.imperialviolet.org/2016/05/16/agility.html>.  That's not
coincidental.  I happen to agree, see
<https://datatracker.ietf.org/doc/html/draft-thomson-use-it-or-lose-it>.

This is part of the defense against ossification, but it's not
complete.  As Brian will point out, the actual wire image of a
protocol is what ossifies, not what we say that the wire image is.
But as you observed, we're working on improving that too.