Original text:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control <del> information to modification and manipulation in the network.  Further downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic </del>  protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. will generally establish state for UDP flows on the first packet sent, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though <del> there is not evidence of widespread implementation of this guideline </del>  in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after 4.1. Streams are meaningful only to the application; since stream <del> information is carried inside QUIC's encryption boundary, no information about the stream(s) whose frames are carried by a given packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network treatment should therefore be carried over different five-tuples (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to provide the necessary credentials), the cost of establishing another connection is extremely low. </del>  4.2. point.  HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow. <del> Instead the client would create a new connection on which to open </del>  further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data <del> should be send out immediately.  Alternatively, if the application </del>  expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundle frames into a packet. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path <del> migration.  Therefore migration usually has a performance impact. </del>  QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a <del> decisions to switch paths. </del>  Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion <del> controller.  Therefore it is not recommended to use different </del>  DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances <del> are able accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. </del>  During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the <del> datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC </del>  connection. 16.

Reviewer comments:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.

Revised text:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control  <ins> information to modification and manipulation in the network. Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic </ins> protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. will generally establish state for UDP flows on the first packet sent, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though  <ins> there is no evidence of widespread implementation of this guideline </ins> in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after 4.1. Streams are meaningful only to the application; since stream  <ins> information is carried inside QUIC's encryption boundary, a given packet exposes no information about which stream(s) are carried within the packet.  Therefore, stream multiplexing is not intended to be used for differentiating streams in terms of network treatment. Application traffic requiring different network treatment should therefore be carried over different five-tuples (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to provide the necessary credentials), the cost of establishing another connection is extremely low. </ins> 4.2. point.  HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow.  <ins> Instead, the client would create a new connection on which to open </ins> further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data  <ins> should be sent out immediately.  Alternatively, if the application </ins> expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundle frames into a packet. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path  <ins> migration.  Therefore, migration usually has a performance impact. </ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a  <ins> decision to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion  <ins> controller.  Therefore, it is not recommended to use different </ins> DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances  <ins> are able to accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. </ins> During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the  <ins> datagram service has an unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC </ins> connection. 16.