Re: [Last-Call] Opsdir last call review of draft-ietf-quic-manageability-14

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

I haven't seen anyone else respond to Al's email on this point, so I
thought I'd share an opinion.

On Sat, Feb 5, 2022 at 4:12 PM Al Morton via Datatracker <[e-mail]>
wrote:

> Reviewer: Al Morton
> Review result: Has Issues
>
> Hi Mirja and Brian,
>
> This is the OPSDIR review of
>
>               Manageability of the QUIC Transport Protocol
>                     draft-ietf-quic-manageability-14
>

Snip, down to


> 4.6.  UDP Blocking, Throttling, and NAT Binding
>
> ...
>    Further, if UDP traffic is desired to be throttled, it is recommended
>    to block individual QUIC flows entirely rather than dropping packets
>    indiscriminately.  When the handshake is blocked, QUIC-capable
>    applications may fail over to TCP.  However, blocking a random
> [acm]
> is "fail over" or "fallback" the preferred term?
> (using only one will help)
>
>    fraction of QUIC packets across 4-tuples will allow many QUIC
>    handshakes to complete, preventing a TCP failover, but these
> [acm] ... or "failover" preferred?
>
>    connections will suffer from severe packet loss (see also
>    Section 4.5).  Therefore, UDP throttling should be realized by per-
>    flow policing, as opposed to per-packet policing.  Note that this
>    per-flow policing should be stateless to avoid problems with stateful
>    treatment of QUIC flows (see Section 4.2), for example blocking a
>    portion of the space of values of a hash function over the addresses
>    and ports in the UDP datagram.  While QUIC endpoints are often able
>    to survive address changes, e.g. by NAT rebindings, blocking a
>    portion of the traffic based on 5-tuple hashing increases the risk of
>    black-holing an active connection when the address changes.
>

In my mind,

   - "fallback" makes more sense if we are talking about falling back
   within a single protocol (for example, attempting to use an extension,
   discovering that the other host doesn't support that extension, and
   retrying without the extension - or,, also within a single protocol,
   attempting to use version 9, discovering that the other host doesn't
   support that extension, and retrying with a different version), and
   - "failover" makes more sense if we are talking about starting with one
   protocol (QUIC, in this case) and if that doesn't work, switching to a
   different protocol (TCP, in this case).

I know we've used both terms somewhat interchangeably during discussions
about QUIC (and not just discussions about this document), but if one term
is to be chosen (Al's suggestion, which I agree with), I think what we're
talking about here is "failover".

Other people may have thoughts, of course.

Best,

Spencer