Re: Is the invariants draft really standards track?

[Kyle Rose <[e-mail]>]

On Wed, May 27, 2020 at 10:34 AM Ian Swett <ianswett=
[e-mail]> wrote:

> I was agreeing with MT, but I'm happy to see some more MUSTs added if
> people feel that'd be helpful.
>

Coincidentally, we were just talking about this internally at Akamai
yesterday. IMO, an invariants document isn't really helpful if it isn't
normative, and for it to be normative it (or a related practices doc for
operators) really needs to spell out clear boundaries for operators with
MUSTs.

The example that came up yesterday was around operators filtering QUIC in
the event of a DDoS: one recommendation based on some conversations going
back at least to Prague 2019 was to hash packets on 4-tuple and filter
those below a hash value chosen for a desired ingress limit instead of
doing what most operators do with UDP today, which is to cap UDP throughput
and just drop packets randomly or tail drop.

This recommendation certainly imposes some constraints on future protocol
development that motivate new invariants: for instance, it would preclude
sharding a connection across multiple source ports (not that there is
necessarily a reason to do this; it's just an example). But more
importantly, it goes beyond invariants: it's one among many practices
compatible with the current set of invariants, some reasonable and some
terrible.

Operators are going to do things to QUIC traffic, so it would be good to
offer them recommendations that are compatible with broad deployability.

Kyle