than those considered in RFC7983.  Second, this feature of the wire image is not invariant QUIC-INVARIANTS and may change in future versions of the protocol, or even be negotiated during the handshake <del> via the use of an extension. </del>  Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the

addresses
NAME started this discussion in the mailing list (URL), which made me think that the distinguishable QUIC version number practice should be written in the applicability draft. would like to know what others think about it.
I don't think that it needs consideration. We haven't talked about sharing ports before, so while QUIC gives us that option under certain narrow conditions, those are special enough that burning text on it is wasteful.
We already have this text in manageability: and
The point about the 1 bit is probably most pertinent to NAME question. And I think that it is sufficient.
Yes, there are some text in the manageability doc but I was asking if we should include some text in the applicability draft as well. The applicability draft is more towards the designer and developers of the applications on top of QUIC which I believe the case for DoQ. "As wire image is not invariant, demuxing based on that ( for example 1 bit for version QUIC 1) will make a deployment very version dependent and that need to be taken into consideration" - saying something like - would be helpful I think. I also see the mailing list discussions are deviating from what is we are saying in the manageability document - coexisting of UDP based protocols on the same port.
I'm not sure we need any additional discussion in the applicability draft. RFC900 has this: I don't think there is anything else that we could say in the applicability draft. For manageability, I create a PR with a reference to draft-ietf-quic-bit-grease
on a second thought, I think we are fine here. Thanks. Hello QUIC, DNS-over-QUIC just requested UDP Port 843, where it would coexist with DNS-over-DTLS. As long as the DNS server is running QUICv1 without greasing the QUIC bit, that should work out just fine. This does lead me to think about how QUIC versions will interact with the port over which they are intended to operate. In RFC 9000, designed explicitly for HTTP/443, we took care to make sure the signature was distinguishable from other things that run there. So, if someone wanted to deploy QUIC over some other UDP port, we might have to roll a new version simply to create a signature that doesn't clash with the protocols already operating over that port. For any given QUIC application, there is therefore a choice between (1) Picking an existing port and making sure that either (a) the other UDP application isn't present, or (b) using only QUIC versions that are distinguishable, or (2) Requesting a new port A few questions: Is my analysis correct? Are we comfortable with having to take up these new versions when they arise (which may not be that often)? Would it be preferable to have a less balkanized QUIC version space and more port allocations? I would like to start thinking through this issue and perhaps issue guidance to the ports team. Martin

than those considered in RFC7983.  Second, this feature of the wire image is not invariant QUIC-INVARIANTS and may change in future versions of the protocol, or even be negotiated during the handshake  <ins> via the use of an extension QUIC-GREASE. </ins> Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the


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 <del> per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment. </del>  Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown.  4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by

Section 4.8 of manageability draft expects that a per-flow basis DSCP and ECMP routing policy is used to ensure same treatment for all the packets belonging to same QUIC connection. I was wondering how does path migration impacts this? As the new path ,potentially via another network, has no idea about QUIC connection insuring all packets belonging to the same QUIC connection get uniform treatment will be difficult. what am I missing here?
During path migration the congestion control is reset and therefore there is no assumption anymore that those packets need to be treated similarly.
Ok then packets belonging to same QUIC connection can be treated differently after path migration. I think it would be good to clarify it.
This is effectively already what the manageability draft says because it says QoS handling should be applied on a per flow basis where a flow is the 5 tuple. If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID.
NAME can we close this issue?
Potentially yes, but would have been better to put a ref. here to the section where this "If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID." is discussed. if things are not discussed or referred in one place then one has to infer the same reasoning/conclusion, which I think not always obvious.
Okay, I added another clarifying sentence and a reference to section 3.5 in PR

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  <ins> per-packet) and as such that all packets belonging to the same active QUIC connection get uniform treatment. </ins> Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. <ins> Note that the 5-tuple of a QUIC connnection can change due to migration.  In this case different flows are observed by the path and maybe be treated differently, as congestion control is usualy reset on migration (see also sec-flow-association). </ins> 4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by


This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on <del> network operations involving QUIC traffic.  Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. </del>  1.

As this document does not use normative language and still makes number of recommendations, I think it is best that the abstract and/or introduction of thid document need some text to clarify how the readers should interpret those recommendations URL
What exactly would you propose?
hmm, the reason for not using normative language would be sufficient I think.
Not sure what to write. There is no requirement that normative language must be used in RFC and moreover this is not a protocol specification. However, these are not something that we should note in the abstract.
Can you make a proposal?
I would simply expect the reason of not using normative language in this document (I remember there was some discussions on it), perhaps best fit in the introduction section.
There is nothing really specific here. If you look at the other issue they don't say much other than that we only provide recommendation and therefore don't need normative language. I would prefer to not say anything as that could rather give a wrong impression.

This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on  <ins> network operations involving QUIC traffic.  It is intended as a "user's manual" for the wire image, providing guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. </ins> 1.


Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay (the latter mainly caused by the asymmetric crypto operations associated with the TLS handshake) at both sides. </del>  3.8.2.

URL, why are we so specific about TLS crypto operations here, it could be anything like later mentioned (waiting for a response to be send) or simply work load in the endpoints. Overall the inclusion of the transport- and application-layer delay in RTT measurements has been described in different ways without mentioning why one matters more than the others in certain context while pointing to same thing. This need to be fixed.
The section you noted, is about the the handshake. As there is no data during the handshake, the main app-layer delay would be the crypto. Yes, there can always be additional random delays due to processing also on the NIC but these are usually smaller and therefore less relevant. Not sure what kind of change would be needed here.
it would be good to refer to same events that may cause application-layer delay, rather giving two different examples for the same application-layer delay.
Still not sure what you would like to see here. Can you make a proposal?
Alternate proposal: remove the example?
would actually work, but there are examples of application-layer delay in that later section, may be you want to bring that up here and only use one set of potential reasons for application-layer delay for the whole section.

Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement  <ins> necessarily includes any transport- and application-layer delay at both endpoints. </ins> 3.8.2.


is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system <del> with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control 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 protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del>  These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

This is a good piece of information. However, I could not put it into the context of this document. Please clarity how this TAPS arch matters here. URL
looks good to me. Now it is more clear that the following paragraph is actually about giving more context to fallback mechanism.

is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system  <ins> with a common API for multiple protocols.  This is particularly relevant for QUIC as it addresses the implications of fallback among multiple protocols. Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided.  In general, a application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control 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 protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the


that the load balancer will redirect the next Client Initial packet to a different server in that pool.  7. Versioning in QUIC may change the protocol's behavior completely,

Add a section about being careful with timing with respect to CID migration if you actually care about linkability.
Linkability across CID changes is in the common case so trivial that protocol features to defeat linkability through other means risk being useless. "Find CID y where delay < d between last packet for CID x and first packet for CID y on 2-tuple {a,p}, given {x,a,p}" is an operation which requires zero additional state and a simple O(kn log n) search for any large on-path (passive surveillance) device that's halfway smart about keeping per-flow state -- i.e., it's basically a free operation, and its utility is baked into the physics of CIDs -- after all, this is what CIDs are for. The ease of this analysis can only be mitigated by increasing the size of the anonymity set: ensuring that for any given delay window d, a minimum number of CIDs x transition on any given {a,p}. This seems like good operational advice for servers with enough traffic to build such anonymity sets (should they have interest in preventing client linkability, of course) -- small servers are probably out of luck though. Applicability should call this out as a problem, manageability should suggest a solution space.
-quic-transport section 6.11.5. begins to address this now, but aside from the following... URL still seems to pretend that coordinated CID migration is sufficient to fix linkability. So I still think we need something in -applicability. Will throw together a PR today.
addressed in

that the load balancer will redirect the next Client Initial packet to a different server in that pool. <ins> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </ins> 7. Versioning in QUIC may change the protocol's behavior completely,


Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay at </del>  both endpoints. 3.8.2. in IPIM. Note that this measurement, as with passive RTT measurement for TCP, <del> includes any transport protocol delay (e.g., delayed sending of </del>  acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) <del> and RTT variance (which approximates jitter as seen by the application). </del>  4.

Using the Spin Bit for Passive RTT Measurement ... Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of [acm] suggest s/any/all/ ... Since the spin bit logic at each endpoint considers only samples from packets that advance the largest packet number, signal generation itself is resistant to reordering. However, reordering can cause problems at an observer by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT estimates, if reordering occurs across a spin-bit flip in the stream. [acm] thanks for mentioning this! ... Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT. RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). [acm] (let's avoid the clocky term "jitter", and clarify) Suggest: (which over-estimates one-way packet delay variance as seen by an application end-point).

Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement  <ins> necessarily includes all transport- and application-layer delay at </ins> both endpoints. 3.8.2. in IPIM. Note that this measurement, as with passive RTT measurement for TCP,  <ins> includes all transport protocol delay (e.g., delayed sending of </ins> acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows)  <ins> and RTT variance (which approximates one-way packet delay variance as seen by an application end-point). </ins> 4.


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

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

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


flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- <del> QUIC traffic for purposes of network admission control should admit all QUIC traffic regardless of version. </del>  3.

lgtm
IMO the PR is clearer (and better reflects the intent / my understanding of WG consensus), so I'd merge it then continue the discussion after the submission cutoff.

flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non-  <ins> QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continious version-based evolution and avoid unnecessary deployment delays. </ins> 3.


2.3. <del> As soon as the cryptographic context is established, all information in the QUIC header, including those exposed in the packet header, is integrity protected.  Further, information that were sent and exposed in previous packets when the cryptographic context was established yet, e.g. for the cryptographic initial handshake itself, will be validated later during the cryptographic handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del>  2.4.  The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, ensuring that related flows are appropriately balanced together; and the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT. <del> 2.5. </del>  The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers. <del> 2.6. </del>  Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided 3.2. Connection establishment uses Initial, Handshake, and Retry packets <del> containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </del>  3.3. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this <del> requires parsing of the QUIC packet header and the cleartext TLS handshake on stream 0. </del>  In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS

The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.

2.3.  <ins> New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed. To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern visible in the UDP datagams containing the QUIC handshake, then examine each of the datagrams in detail. In the nominal case, the QUIC handshake can be recognized on the wire through at least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in fig-handshake. Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and "Handshake" and "1-RTT", which do not).  QUIC packets in separate contexts during the handshake are generally coalesced (see coalesced) in order to reduce the number of UDP datagrams sent during the handshake. As shown here, the client can send 0-RTT data as soon as it has sent its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello. A typical handshake starts with the client sending of a QUIC Client Hello datagram as shown in fig-client-hello, which elicits a QUIC Server Hello datagram as shown in fig-server-hello typically containing three packets: an Initial packet with the Server Hello, a Handshake packet with the rest of the server's side of the TLS handshake, and initial 1-RTT data, if present. The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the client's destination connection ID; they are therefore observable by any on-path device that knows the per-version constant; we therefore consider these as visible in our illustration.  The content of QUIC Handshake packets are encrypted using keys established during the initial handshake exchange, and are therefore not visible. Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The Initial Completion fig-init-complete and the Handshake Completion fig-hs-complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. The Client Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Client Hello message, including any TLS Server Name Indication (SNI) present, in the clear.  The QUIC PADDING frame is present to ensure the Client Hello datagram has a minumum size of 1200 octets, to mitigate the possibility of handshake amplification. The Server Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Server Hello message. The Initial Completion datagram does not expose any additional information; however, recognizing it can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt. Similar to Initial Competion, Handshake Completion also exposes no additional information; observing it serves only to determine that the handshake has completed. When the client uses 0-RTT connection resumption, 0-RTT data may also be seen in the QUIC Client Hello datagram, as shown in fig-client- hello-0rtt. In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets RFC6928. </ins> 2.4. <ins> As soon as the cryptographic context is established, all information in the QUIC header, including information exposed in the packet header, is integrity protected.  Further, information that was sent and exposed in handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. 2.5. </ins> The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, ensuring that related flows are appropriately balanced together; and the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT.  <ins> 2.6. </ins> The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers.  <ins> 2.7. </ins> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided 3.2. Connection establishment uses Initial, Handshake, and Retry packets  <ins> containing a TLS handshake.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </ins> 3.3. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this  <ins> requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS


Negotiation Packet, are both inspectable and invariant QUIC- INVARIANTS. <del> This document describes version 1 of the QUIC protocol, whose wire </del>  image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Features of the wire image described herein may change in future versions of the protocol, except when specified as an invariant QUIC-INVARIANTS, and All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). <del> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec- loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long packet headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </del>  In version 1 of QUIC, the following additional information is exposed: observers cannot reliably use it as an identifier for QUIC. latency spin bit: The third-most-significant bit of the first <del> octet in the short packet header for version 1.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further </del>  details. header type: The long header has a 2 bit packet type field Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or <del> obfuscated in any way.  For other kinds of packets, version 1 of QUIC </del>  cryptographically obfuscates other information in the packet headers: packet number: All packets except Version Negotiation and Retry observers.  The offset of the packet number can be decoded in long headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is <del> cryptographically obfuscated. </del>  key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet to support key rotation.  The <del> Key Phase bit is cryptographically obfuscated. </del>  2.2. A Client Initial packet exposes the version, source and destination connection IDs without encryption.  The payload of the Initial packet <del> is obfuscated using the Initial secret.  The complete TLS Client </del>  Hello, including any TLS Server Name Indication (SNI) present, is sent in one or more CRYPTO frames across one or more QUIC Initial packets. The Server Initial datagram also exposes version number, source and destination connection IDs in the clear; the payload of the Initial <del> packet(s) is obfuscated using the Initial secret. </del>  The Client Completion flight does not expose any additional information; however, as the destination connection ID is server- payload, the packet number length, the source connection ID length, and the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described <del> in Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in </del>  Section 5.4 of QUIC-TLS.  The source connection ID length is specified in the byte after the destination connection ID.  The token length, which follows the source connection ID, is a variable-length

The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...

Negotiation Packet, are both inspectable and invariant QUIC- INVARIANTS.  <ins> This document addresses version 1 of the QUIC protocol, whose wire </ins> image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Features of the wire image described herein may change in future versions of the protocol, except when specified as an invariant QUIC-INVARIANTS, and All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT).  <ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </ins> In version 1 of QUIC, the following additional information is exposed: observers cannot reliably use it as an identifier for QUIC. latency spin bit: The third-most-significant bit of the first  <ins> octet in the short header for version 1.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further </ins> details. header type: The long header has a 2 bit packet type field Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or  <ins> protected in any way.  For other kinds of packets, version 1 of QUIC </ins> cryptographically obfuscates other information in the packet headers: packet number: All packets except Version Negotiation and Retry observers.  The offset of the packet number can be decoded in long headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is  <ins> cryptographically protected. </ins> key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet to support key rotation.  The  <ins> Key Phase bit is cryptographically protected. </ins> 2.2. A Client Initial packet exposes the version, source and destination connection IDs without encryption.  The payload of the Initial packet  <ins> is protected using the Initial secret.  The complete TLS Client </ins> Hello, including any TLS Server Name Indication (SNI) present, is sent in one or more CRYPTO frames across one or more QUIC Initial packets. The Server Initial datagram also exposes version number, source and destination connection IDs in the clear; the payload of the Initial  <ins> packet(s) is protected using the Initial secret. </ins> The Client Completion flight does not expose any additional information; however, as the destination connection ID is server- payload, the packet number length, the source connection ID length, and the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described  <ins> in Section 17.2 of QUIC-TRANSPORT, but is protected as described in </ins> Section 5.4 of QUIC-TLS.  The source connection ID length is specified in the byte after the destination connection ID.  The token length, which follows the source connection ID, is a variable-length


Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be <del> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, it describes what is and is not possible with the QUIC transport protocol as defined. </del>  This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on

Addresses OPSDIR comment discussion.
hi NAME -- does this better clarify language about recommendations in the introduction? PTAL, thanks!!
Looks good to me.
I'm not sure if this is actually fully true. We use the terms "recommended" or "recommendation" multiple times in this document and I don't see a reason to remove it. I think these are the things that the quic group recommends, of course if anybody follows those recommendations is another questions.
so I'm not removing the recommendations elsewhere (modulo ), just changing the language here to say "don't think we think it's a good idea for you just because we wrote it in general), which I think is indeed more true than what was here before...

Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be  <ins> impermissible on other networks without those requirements.  The presence of a particular practice in this document should therefore not be construed as a recommendation to apply it.  For each practice, this document describes what is and is not possible with the QUIC transport protocol as defined. </ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on


QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the <del> Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continuous version-based evolution and avoid unnecessary deployment delays. </del>  3.

Instead of making an explicit policy recommendation with respect to version recognition, clarify the downsides of doing so.
NAME I think this addresses the objection to policy recommendations on version recognition; PTAL. thanks!!
I can live with the latest wording here, thanks! And I didn't imagine that "traditional" was non-inclusive language; traditions are an inexorable aspect of many cultures...
I can see how some uses of the word tradition or traditional are non-inclusive. The occurences here do not strike me that way and the alternatives presented weaken the point of the text. We can proceed with an open mind to whether the term needs to be changed in response to wider review via subsequent review in the process.
My understanding is that "traditional" is also flagged because it's usually not a clear term in technical documents and I think that's the case here as well. There is no tradition about deploying certain protocols. We could just say "older" or "other protocols used so far" or something like this.
If you editors would like to replace it with a different term that conveys your intent, that's fine by me. Perhaps switch traditional for "other commonly used"
s/traditional/most other/g?
other commonly used is also good, but requires a manual rewrap. :)
thanks for addressing the in-solidarity bot

QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the  <ins> Internet more often than with other commonly deployed Internet- and transport-layer protocols.  Use of the version number field for traffic recognition will therefore behave differently than with these protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows, and completely fail in the near future.  Reliance on the version number field for the purposes of admission control is similarly likely to rapidly lead to unintended failure modes.  Admission of QUIC traffic regardless of version avoids these failure modes, avoids unnecessary deployment delays, and supports continuous version-based evolution. </ins> 3.


In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to <del> the load balancers. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server are able to identify and discard packets featuring an invalid MAC. </del>  4.4.

-manageablility has guidelines on how to select ConnIDs at a server, which is really more an -applicability thing. This fixes that.

In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to  <ins> the load balancers.  Guidance on assigning connection IDs is given in QUIC-APPLICABILITY. </ins> 4.4.


known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to <del> specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del>  While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

AFAIK Microsoft's SMB-over-QUIC also uses 443.
Not sure we explicitly need to add that...?
It does underscore the point that HTTP/3 != 443, and 443 != HTTP/3. I think it's useful to add.
The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR

known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to  <ins> specify alternate port numbers.  Other applications (e.g., Microsoft's SMB over QUIC) also use UDP port 443 by default. Therefore, simple assumptions about whether a given flow is using QUIC, or indeed which application it might be using QUIC, based solely upon a UDP port number may not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-


An in-network observer assuming that a set of packets belongs to a QUIC flow might infer the version number in use by observing the <del> handshake: for QUIC version 1, if the version number in the Initial packet from a client is the same as the version number in the Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </del>  The negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

From review by NAME
it’s worth noting that compatible version negotiation can cause the version to change mid-handshake. The true signal is a server-chosen version field echoed in a client packet.
Should this reference the compatible version negotiation piece of QUIC-VN?

An in-network observer assuming that a set of packets belongs to a QUIC flow might infer the version number in use by observing the  <ins> handshake.  If the version number in an Initial packet of the server response is subsequently seen in a packet from the client, that version has been accepted by both endpoints to be used for the rest of the connection (see Section 2 of I-D.ietf-quic-version- negotiation). </ins> The negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection


explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation <del> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or protected in any way.  For other kinds of packets, version 1 of QUIC cryptographically obfuscates other information in the packet headers: </del>  packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet

From NAME review.
This PR now as well.
cryptographically obfuscates An odd term. I see obfuscation to be non-cryptographic and cryptographic transformation to not be as weak as to be seen as obfuscation (but as encryption or secure hashing)
I replied by mail to Paul and explained that the header protection is kind of weak, so cryptographically protected might be too strong and this was his reply: Maybe the only thing is finding a better term for “cryptographically obfuscates”? I understand your reasoning but I still feel a little that this is doing a disservice to “cryptography”. But it was a comment, so I will leave it up to the authors. But maybe we can find a better term...?
Also a related comment on the same section from Eric Vyncke:
Note that PR is also editing this same part of the text.
I would say "protects" instead of "obfuscates". We have an analysis to support this claim (now cited in RFC 9001), we don't need to hedge. We used to be less certain (we did basically just invent this off the cuff at an interim meeting), but we're far more confident in stronger claims now.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...
Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it would be good to way that Retry packets are (forgibly) integrity-protected and that QUIC TPs later authenticate most of the contents of these packets.

explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation  <ins> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted.  Retry packets are (forgibly) integrity protected.  Transport parameters are used authenticate the contents of Retry packets later in the handshake.  For other kinds of packets, version 1 of QUIC cryptographically protects other information in the packet headers: </ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet


14. QUIC version 1 does not specify a version negotiation mechanism in <del> the base spec but I-D.draft-ietf-quic-version-negotiation proposes an extension.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. A server that rolls out a new version of QUIC can do so in three stages.  Each stage is completed across all server instances before moving to the next stage. In the first stage of deployment, all server instances start accepting new connections with the new version.  The new version can be enabled progressively across a deployment, which allows for selective testing.  This is especially useful when the new version is compatible with an old version, because the new version is more likely to be used. While enabling the new version, servers do not advertise the new version in any Version Negotiation packets they send.  This prevents clients that receive a Version Negotiation packet from attempting to connect to server instances that might not have the new version enabled. During the initial deployment, some clients will have received Version Negotiation packets that indicate that the server does not support the new version.  Other clients might have successfully connected with the new version and so will believe that the server supports the new version.  Therefore, servers need to allow for this ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances 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. During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do not.  This state will persist only for as long as any Version Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. The third stage completes the process by enabling authentication of the negotiated version with the assumption that the new version is fully available. The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse. Servers disable validation of the old version, stop sending the old version in Version Negotiation packets, then the old version is no longer accepted. </del>  15.

From NAME review.
Not sure if this is the right approach. The whole point of this document is that we don't want the reader ask to read the spec in details but pre-digest the important bits for the reader.
I'm not going to lie down in the road over this, but maybe there's a middle ground? Instead of punting totally to the VN Draft, maybe we can specifically say that VN has a deployment template in that section?
Feel free to create a PR :-)
per discussion with NAME on 5 July, keep the new text but add a short but useful summary of version negotiation above it. I'll rework this PR.
This entire section appears to be a duplicate of section 5 of the version negotiation draft. I suggest the authors verify that the latter has all the relevant information, and then replace this section with a reference to the VN draft.

14. QUIC version 1 does not specify a version negotiation mechanism in  <ins> the base specification, but I-D.draft-ietf-quic-version-negotiation proposes an extension that provides compatible version negotiation. This approach uses a three-stage deployment mechanism, enabling progressive rollout and experimentation with multiple versions across a large server deployment.  In this approach, all servers in the deployment must accept connections using a new version (stage 1) before any server advertises it (stage 2), and authentication of the new version (stage 3) only proceeds after advertising of that version is completely deployed. See Section 5 of I-D.draft-ietf-quic-version-negotiation for details. </ins> 15.


As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to <del> reflection attacks.  Note that the list above is not exhaustive; other source ports might be considered reflection vectors as well. </del>  9.

Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?

As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to  <ins> reflection attacks.  Note that following the general guidance for client implementations given in RFC6335, to use ephemeral ports in the range 49152-65535, has the effect of avoiding these ports.  Note that other source ports might be reflection vectors as well. </ins> 9.


tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. <del> Some of the properties of the QUIC header used in network management are irrelevant to application-layer protocol operation and/or user privacy.  For example, packet number exposure (and echo, as proposed in this document), as well as connection establishment exposure for 1-RTT establishment, make no additional information about user traffic available to devices on path. At the other extreme, supporting current traffic classification methods that operate through the deep packet inspection (DPI) of application-layer headers are directly antithetical to QUIC's goal to provide confidentiality to its application-layer protocol(s); in these cases, alternatives must be found. </del> 7. This work is partially supported by the European Commission under

The last two paragraphs of the security considerations section were for a (much earlier, probably pre-WG) version of the document. Now that -manageability is basically a wire image users' guide, they don't belong. So let's cut them.

tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant.  7. This work is partially supported by the European Commission under


Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry <del> a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </del>  In version 1 of QUIC, the following additional information is exposed:

clarify why CID is present in all headers but is also optional... see issue
The text appears inconsistent to me: "Short headers contain only an optional destination connection ID""source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ? Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ?

Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry  <ins> a destination connection ID, a variable-length field which, if not zero-length, can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </ins> In version 1 of QUIC, the following additional information is exposed:


version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801). <del> All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). </del>  source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not

Text as proposed by Lars on list.
I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see URL); there is a huge range for experimental versions.
This was discussed on the list and has a proposed resolution; PR to be submitted.
Also this was commented by Eric Vyncke as well:

version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801).  <ins> An IANA registry contains the values of all standardized versions of QUIC, and may contain some proprietary versions (see Section 22.2 of QUIC-TRANSPORT).  However, other versions of QUIC can be expected to be seen in the Internet at any given time. </ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not


3.3. <del> [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] </del>  4.

An alternate approach to , following from NAME comment thereon.
I think the new text is now missing two points: 1) It might make sense to send keep-alives if the application know that is there is new data coming, e.g. an outstating reply or a following request. I think this is what is recommended for http. 2) as meantion in the transport draft we should probably say again that it must be clearly specified which party is performing the active ping-ing Also the text basically "just" explains the situation but doesn't really make any recommendation. Do we maybe what to say more than that?
Yay, unicorns mean that I can't see NAME comments here, though they appeared in email. In response to those, maybe it is OK to point to HTTP/QUIC's recommendations about keep-alives. There, it recommends limiting use of PING for keep-alive to while a request is outstanding.
The transport draft says: "The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection from timing out. An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended. This guidance SHOULD indicate whether it is the client or the server that is expected to send the PING. Having both endpoints send PING frames without coordination can produce an excessive number of packets and poor performance." Probably we should state this in the applicability statement as well...
The transport draft also provides guidance on on the ping interval: "A connection will time out if no packets are sent or received for a period longer than the time specified in the idle_timeout transport parameter (see {{termination}}). However, state in middleboxes might time out earlier than that. Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval, experience shows that sending packets every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows."
That is not intended as guidance, but a caution. This is something that firmly fits in the application space. For instance, in HTTP, sending PING frames to keep the connection alive might be appropriate when a request is outstanding, but it shouldn't be used otherwise.
NAME I added a bit of text in PR . Can you have a look at it?
Resolved by PR

3.3.  <ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry will be expired after just thirty seconds of inactivity. A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods. Ensure there are no long idle periods. Resume the session after a long idle period, using 0-RTT resumption when appropriate. The first strategy is the easiest, but it only applies to certain applications. Either the server or the client in a QUIC application can send PING frames as keep-alives, to prevent the connection and any on-path state from timing out.  Recommendations for the use of keep-alives are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is responsible for keeping the application alive.  Note that sending PING frames more frequently than every 30 seconds over long idle periods may result in a too much unproductive traffic and power usage for some situations. Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a client that wants to send data to a server over a connection idle longer than the server's idle timeout (available from the idle_timeout transport parameter) can simply reconnect.  When possible, this reconnection can use 0-RTT session resumption, reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is idempotent. The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should use keepalives only in circumstances where continued communication is highly likely; QUIC-HTTP, for instance, recommends using PING frames for keepalive only when a request is outstanding. </ins> 4.


a description of how common network management practices will be impacted by QUIC. <del> QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is enforced through integrity protection of the wire </del>  image WIRE-IMAGE.  Encryption of most transport-layer control signaling means that less information is visible to the network than is the case with TCP.

Wire image mutability is more subtle than "is completely immutable", and we get into the details later. New text is sufficient as contrast for TCP.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...

a description of how common network management practices will be impacted by QUIC.  <ins> QUIC is an end-to-end transport protocol; therefore, no information in the protocol header is intended to be mutable by the network. This property is enforced through integrity protection of the wire </ins> image WIRE-IMAGE.  Encryption of most transport-layer control signaling means that less information is visible to the network than is the case with TCP.


to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of <del> acknowledgments. </del>  8.

Section 7 talks about acknowledgment strategy, but it is not actually giving any examples of what the application can do. Since it is kind of a transport layer property and not an application layer property, it is unclear how an application [developer] can replace the "TCP like ack every other packet" functionality. Are there QUIC options to consider that do this? If so, why not mention those here?
I guess there is draft URL but not sure we want to add a reference...?
I guess we should at least add a reference to URL however that is currently expired :-(
I've sent a reply to Paul by email and waiting for a response now.
Unsure why we would specifically reference this rather than other work: draft-li-quic-optimizing-ack-in-wlan/, I expect the correct thing is to reference a WG RFC, and section 2.5 of RFC9065 is one way. Citing the WG ack frequency draft might additionally be useful.
For the record, this is what I replied by mail: "[MK] This is a whole research area of its own... however, I create an issue to see if people think adding some reference might be useful. There is a wg draft in QUIC for an extension to negotiate the ack frequency and there is another individual draft about strategies for WLANs. Still, this is also not really QUIC specific. Similar proposals also exists for TCP. The difference is that with TCP the network can also do ACK thinning which is not possible with QUIC anymore."
NAME but RFC9065 section 2.5 doesn't talk about acks at all... I still propose to add a reference to URL as this is a wg doc at least.

to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of  <ins> acknowledgments.  I-D.ietf-quic-ack-frequency describes an extension to signal the desired delay of acknowledgments and discusses use cases as well as implications for congestion control and recovery. </ins> 8.


application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today <del> due to encapsulation, mechanisms for dynamic port assignments, and NATs. </del>  As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For

The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR

application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today  <ins> due to encapsulation and mechanisms for dynamic port assignments, as also noted in RFC6335. </ins> As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For


is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- <del> ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </del>  Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and

Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded"

is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-  <ins> ordering than typical TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and


specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  14. QUIC version 1 does not specify a version negotiation mechanism in

addresses
-- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? [MK] I guess that is the whole point here and I think the answer is no. You might see new experimental version that come and go quickly and are deployed only by one vendor but I don't think that will give you necessarily much insights about the application within the encrypted payload. Also experimental version are expected to be around for short times only and change quickly, thus you would be very busy to adapt your fingerprinting continuously. That's why the recommendation is to not do it. [Christian Huitema] Application developers will try to evolve the version number. If that cause the packets to be somehow discarded, this will have a very predictable result: all QUIC implementations will set the version number to 1 in the clear text header, while the "real" version number will be negotiated as part of the encrypted payload. If we follow that path, the network managers will not have any usable signal about the QUIC version, and the application developers will have to use more complex software and carry four useless bytes in the initial packets. Truth is, this is most likely what will happen, given natural trends. I don't know whether the text in the applicability statement will be enough to avoid that fate.
I don't think we can say more about not using the version number to identify QUIC. However do we want to mention the risk of fingerprinting? However, I guess that would rather something to add to the spec considerations in the applicability statement?

specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <ins> The QUIC Versions Registry established in QUIC allows for provisional registrations for experimentation.  Registration, also of experimental versions, is important to avoid collision.  Experimental versions should not be used long-term or registered as permanent to minimize the risk of fingerprinting based on the version number. </ins> 14. QUIC version 1 does not specify a version negotiation mechanism in


existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional <del> change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del>  Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-

Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable?

existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional  <ins> change of the local interface, the expiration of a temporary IPv6 address RFC8981, or the server indicating a preferred address Section 9.6 of QUIC. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-


9. <del> This document has no actions for IANA. </del>  10.  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for applications using QUIC, as well. connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 11. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

NAME should probably double-check my work here. This assumes that we take the compatible version upgrade stuff, but if we don't, there's only one sentence to remove. I've tried to keep it abstract enough that the details won't matter.
LGTM. Thank you for writing it down!
Moving this from quicwg/base-drafts to here.
NAME NAME can one of you maybe provide some text?
is probably exactly what needs to be said for this issue.
lgtm

9.  <ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. A server that rolls out a new version of QUIC can do so in three stages.  Each stage is completed across all server instances before moving to the next stage. In the first stage of deployment, all server instances start accepting new connections with the new version.  The new version can be enabled progressively across a deployment, which allows for selective testing.  This is especially useful when the new version is compatible with an old version, because the new version is more likely to be used. While enabling the new version, servers do not advertise the new version in any Version Negotiation packets they send.  This prevents clients that receive a Version Negotiation packet from attempting to connect to server instances that might not have the new version enabled. During the initial deployment, some clients will have received Version Negotiation packets that indicate that the server does not support the new version.  Other clients might have successfully connected with the new version and so will believe that the server supports the new version.  Therefore, servers need to allow for this ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances are able accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do not.  This state will persist only for as long as any Version Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. The third stage completes the process by enabling validation of the negotiation version as though the new version were disabled. The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse. Servers disable validation of the old version, stop sending the old version in Version Negotiation packets, then the old version is no longer accepted. </ins> 10. <ins> This document has no actions for IANA. 11. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for applications using QUIC, as well. connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  <ins> 12. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture


an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream.  5. As QUIC is a general purpose transport protocol, there are no

This provides some advice about flow control and how it might produce deadlocks. This was originally quicwg/base-drafts.
lgtm modulo NAME nitsnits.

an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. <ins> 4.4. Flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or deadlock. Deadlocks in flow control are possible for any protocol that uses QUIC, though whether they become a problem depends on how implementations consume data and provide flow control credit. Understanding what causes deadlocking might help implementations avoid deadlocks. Large messages can produce deadlocking if the recipient does not process the message incrementally.  If the message is larger than flow control credit available and the recipient does not release additional flow control credit until the entire message is received and delivered, a deadlock can occur.  This is possible even where stream flow control limits are not reached because connection flow control limits can be consumed by other streams. A common flow control implementation technique is for a receiver to extend credit to the sender as a the data consumer reads data.  In this setting, a length-prefixed message format makes it easier for the data consumer to leave data unread in the receiver's buffers and thereby withhold flow control credit.  If flow control limits prevent the remainder of a message from being sent, a deadlock will result. A length prefix might also enable the detection of this sort of deadlock.  Where protocols have messages that might be processed as a single unit, reserving flow control credit for the entire message atomically ensures that this style of deadlock is less likely. A data consumer can read all data as it becomes available to cause the receiver to extend flow control credit to the sender and reduce the chances of a deadlock.  However, releasing flow control credit might mean that the data consumer might need other means for holding a peer accountable for the state it keeps for partially processed messages. Deadlocking can also occur if data on different streams is interdependent.  Suppose that data on one stream arrives before the data on a second stream on which it depends.  A deadlock can occur if the first stream is left unread, preventing the receiver from extending flow control credit for the second stream.  To reduce the likelihood of deadlock for interdependent data, the sender should ensure that dependent data is not sent until the data it depends on has been accounted for in both stream- and connection- level flow control credit. Some deadlocking scenarios might be resolved by cancelling affected streams with STOP_SENDING or RST_STREAM.  Cancelling some streams results in the connection being terminated in some protocols. </ins> 5. As QUIC is a general purpose transport protocol, there are no