Re: Greasing the QUIC Bit

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

On Thu, Jul 2, 2020 at 8:21 AM Brian Trammell (IETF) <[e-mail]>
wrote:

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

Thank you for the important reminder.


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

Before I read this ^ paragraph, I was planning to ask you whether "blocking
QUIC" merited a mention in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, because we
are in the awkward position with HTTP/3 that operators will face less
blowback blocking HTTP/3-QUIC and forcing a fallback to HTTP/2-TCP than
they will face blocking almost any non-HTTP/3 QUIC protocol (with less
clearly defined fallbacks) (see: MASQUE).

ISTM that at a minimum, the "accidental invariants" might be mentioned in
https://tools.ietf.org/html/draft-ietf-quic-manageability-06, which targets
operators.

Does any of that make sense?

Best,

Spencer


> Cheers,
>
> Brian
>
>
>