Re: Greasing the QUIC Bit

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

> On 2 Jul 2020, at 14:57, Stephane Bortzmeyer <[e-mail]> wrote:
> 
> On Thu, Jul 02, 2020 at 09:01:08PM +1000,
> Martin Thomson <[e-mail]> wrote 
> a message of 7 lines which said:
> 
>> That's a shame, so I wrote a draft explaining how that might not
>> need to be true forever.
> 
> Isn't it the point of draft-ietf-quic-invariants? If it is not an
> invariant, it may change.

Invariants is a normative declaration of what we won't change in the future. This draft is a proof of concept showing that we can keep the "QUIC bit" from being an accidental invariant (i.e., a practical invariant not normatively declared as such).

I continue to fear that the demand for on-path discrimination of QUIC traffic will remain such that if:

- there is no intentional invariant for distinguishing QUIC traffic from non-QUIC traffic by arbitrary on-path devices; AND
- there is a trivially deployable method for blocking QUIC traffic which will result in negligible end-to-end availability risk and low impact on quality of experience, i.e. that blocking will come at no cost to access networks that choose to do so (which given TCP fallback is indeed the case in the majority of networks, unless things have changed since I last looked)

then we remain at risk of a rapid reversal of fortune on deployment. Sorry, hadn't said that at a mic for about a year now, felt a need to repeat it for the record. :)

As this view is incapable of gaining consensus within this working group, I'm fully in support of this approach to greasing the QUIC bit: we should be intentional about our invariants, and back them up with running code. And this appears to be a perfectly reasonable way to do that.

Cheers,

Brian