Re: Invariants draft

["Brian Trammell (IETF)" <[e-mail]>]

hi Martin, all,

> On 4 Dec 2017, at 01:49, Martin Thomson <[e-mail]> wrote:

<snip>

> 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.

Thanks for saying this so I don't have to. :)

This document is (1) a very clear description of (2) what seem to be to be the right set of prescriptive invariants. Thanks for putting it together! On "it's the actual wire image that ossifies", I was divided on whether or not this document should attempt to discuss "descriptive" invariants, i.e. those parts of the Version 1 wire image that are less likely to be deployably changeable in Version 2. Having read it, though, I don't think they belong here, and I think we'll actually need some deployment experience with Version 2 before we'll be smart enough to say anything definitive about what's more or less ossifiable. I'm not sure that our experience with TCP will translate very well here, especially if we can turn the crank on a Version 2 by, say, late 2019.

Indeed, I'm still a bit of a pessimist that invariants and greasing will actually work as well as we (the WG) think they will. We don't really have an experiment at Internet scale to demonstrate that greasing works at the level that QUIC proposes to use it, and the threat model it supposes for middlebox deployment behavior is ad-hoc and implicit. IMO the best way to prove all this works quickly would be to define and deploy versions 1 and 2 simultaneously, but I suspect that wouldn't have the impact on the version 1 milestones that the WG and the chairs would like to see. Might I suggest, though, that defining Version 2 milestones now (I'd suggest that "whatever is shippable in late 2019", whether that includes MP, PR, both, or neither, is a good target from a preventing ossification PoV) might make sense in terms of committing the WG publicly to exercising these mechanisms in a useful way?

Cheers,

Brian