Re: Is the invariants draft really standards track?

[Christian Huitema <[e-mail]>]

On 5/27/2020 8:28 AM, Kyle Rose wrote:
> On Wed, May 27, 2020 at 10:34 AM Ian Swett
> <ianswett=[e-mail]
> <mailto:[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.

Interesting. Did they consider using the CID, or a fraction of it? This
looks entirely like the scenario for which we developed stateless retry.

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

This would break the "preferred address" redirection. Preferred address
migration may or may not be spelled out in the invariants.

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


Yes, we do need the invariants for that.

-- Christian Huitema