Original text:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP.  Use of the </del>  connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes. is desired.  Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC <del> applications are encouraged to fail over to TCP if early packets do </del>  not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that 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 <del> applications may fail over to TCP.  However, blocking a random </del>  fraction of QUIC packets across 4-tuples will allow many QUIC <del> handshakes to complete, preventing a TCP failover, but these </del>  connections will suffer from severe packet loss (see also sec- filtering).  Therefore, UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow

Reviewer comments:
Per Al Morton's opsdir review, review the use of these three terms and correct where appropriate.

Revised text:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-  <ins> filtering), which potentially triggers TCP fallback.  Use of the </ins> connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes. is desired.  Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC  <ins> applications are encouraged to fall back to TCP if early packets do </ins> not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that 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  <ins> applications may fall back to TCP.  However, blocking a random </ins> fraction of QUIC packets across 4-tuples will allow many QUIC  <ins> handshakes to complete, preventing TCP fallback, but these </ins> connections will suffer from severe packet loss (see also sec- filtering).  Therefore, UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow