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 <[email protected]> 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
