Original text:
4.7. <del> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on Quality of Service (QoS) provided from the network.  QUIC assumes that all packets with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} will receive similar network treatment.  That means all streams that are multiplexed over the same QUIC connection require the same network treatment and are handled by the same congestion controller.  If differential network treatment is desired, multiple QUIC connections to the same server might be used, given that establishing a new connection using 0-RTT support is cheap and fast. QoS mechanisms in the network could also use the connection ID for service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics. Given that QUIC is more tolerant of packet re-ordering than TCP (see packetnumber), Equal-cost multi-path routing (ECMP) does not necessarily need to be flow based.  However, 5-tuple (plus eventually connection ID if present) matching is still beneficial for QoS given all packets are handled by the same congestion controller. </del>  5. 10.  Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared to be invariant QUIC-INVARIANTS.  A version of QUIC with a higher specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 11. </del>  QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted. <del> 12. </del>  This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 13. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 14. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Reviewer comments:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR

Revised text:
4.7.  <ins> It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment.  Using ECMP to distribute packets from a single flow across multiple network paths or any other non- uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance. Depending of the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-ordering than traditional TCP traffic (see packetnumber).  However, it cannot be known by the network which exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. </ins> 5. 10. <ins> QUIC assumes that all packets of a QUIC connection or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} will receive similar network treatment as feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore it is not recommended to use different 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 server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overheads and, more importantly, competing congestion control. 11. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared to be invariant QUIC-INVARIANTS.  A version of QUIC with a higher specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  <ins> 12. </ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted.  <ins> 13. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations.  <ins> 14. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well.  <ins> 15. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture