of 15 seconds, but recommends larger values, or omitting keepalive entirely. <del> By using a Connection ID, QUIC is designed to be robust to NAT </del>  address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs. QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an <del> existing connection using the Destination Connection ID field (see </del>  also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an connection IDs), the short header exposes at most only a single connection ID. <del> Aside from the Destination Connection ID field of the first packets </del>  sent by clients, the connection ID can be zero length.  This is a choice that is made by each endpoint individually. An endpoint that selects a zero-length connection ID will receive <del> packets with a zero-length Destination Connection ID.  The endpoint </del>  needs to use other information, such as its IP address and port number to identify which connection is referred to.  An endpoint can choose to use the source IP address and port on datagrams, but this QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new <del> Connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected Connection ID. </del>  This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load <del> balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such </del>  that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB.

We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!

of 15 seconds, but recommends larger values, or omitting keepalive entirely.  <ins> By using a connection ID, QUIC is designed to be robust to NAT </ins> address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs. QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an  <ins> existing connection using the Destination connection ID field (see </ins> also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an connection IDs), the short header exposes at most only a single connection ID.  <ins> Aside from the destination connection ID field of the first packets </ins> sent by clients, the connection ID can be zero length.  This is a choice that is made by each endpoint individually. An endpoint that selects a zero-length connection ID will receive  <ins> packets with a zero-length destination connection ID.  The endpoint </ins> needs to use other information, such as its IP address and port number to identify which connection is referred to.  An endpoint can choose to use the source IP address and port on datagrams, but this QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new  <ins> connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. </ins> This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load  <ins> balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such </ins> that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB.


packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in long <del> headers, while it is implicit (depending on Destination Connection </del>  ID length) in short headers.  The length of the packet number is cryptographically obfuscated. connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore, <del> observing a new Connection ID does not necessary indicate a new </del>  connection. Server-generated connection IDs should seek to obscure any encoding, The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the <del> Connection ID in the Connection ID itself, instead of remembering it. </del>  <del> QUIC_LB further specified possible algorithms to generate Connection </del>  IDs at load balancers. 2.7. server can generally be confirmed by an on- path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet <del> and the Destination Connection ID of the new Initial packet. </del>  3.3. When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bit of the header are both set to 0.  Then the <del> Client Destination Connection ID needs to be extracted to calculate </del>  the Initial Secret together with the version specific initial salt, as described in QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID after the CRYPTO frame. Note that client Initial packets after the first do not always use <del> the Destination Connection ID that was used to generate the Initial </del>  keys.  Therefore, attempts to decrypt these packets using the procedure above might fail. 3.4. <del> The QUIC Connection ID (see rebinding) is designed to allow an on- </del>  path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address indicates the willingness of the server to communicate with the client. <del> The QUIC header optionally contains a Connection ID which can be used </del>  as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has.  However, Connection </del>  IDs may be renegotiated during a connection, and this renegotiation <del> is not visible to the path.  Keying state off the Connection ID may </del>  therefore cause undetectable and unrecoverable loss of state in the <del> middle of a connection.  Use of Connection ID specifically </del>  discouraged for NAT applications. 4.2.

packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in long  <ins> headers, while it is implicit (depending on destination connection </ins> ID length) in short headers.  The length of the packet number is cryptographically obfuscated. connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore,  <ins> observing a new connection ID does not necessary indicate a new </ins> connection. Server-generated connection IDs should seek to obscure any encoding, The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the  <ins> connection ID in the connection ID itself, instead of remembering it. </ins>  <ins> QUIC_LB further specified possible algorithms to generate connection </ins> IDs at load balancers. 2.7. server can generally be confirmed by an on- path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet  <ins> and the destination connection ID of the new Initial packet. </ins> 3.3. When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bit of the header are both set to 0.  Then the  <ins> client destination connection ID needs to be extracted to calculate </ins> the Initial Secret together with the version specific initial salt, as described in QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID after the CRYPTO frame. Note that client Initial packets after the first do not always use  <ins> the destination connection ID that was used to generate the Initial </ins> keys.  Therefore, attempts to decrypt these packets using the procedure above might fail. 3.4.  <ins> The QUIC connection ID (see rebinding) is designed to allow an on- </ins> path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address indicates the willingness of the server to communicate with the client.  <ins> The QUIC header optionally contains a connection ID which can be used </ins> as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the  <ins> connection ID is present and what length it has.  However, connection </ins> IDs may be renegotiated during a connection, and this renegotiation  <ins> is not visible to the path.  Keying state off the connection ID may </ins> therefore cause undetectable and unrecoverable loss of state in the  <ins> middle of a connection.  Use of connection ID specifically </ins> discouraged for NAT applications. 4.2.


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

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

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


6. <del> Supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. </del>  7.

This is a proposal to mention some more things specifically in the security considerations section. At minimum we should add a sentence pointing the reader at the security consideration of the transport and tis drafts. I additionally, more or less, copied some notes from the transport draft that I found particular relevant for reader of the manageability draft. Comments welcome!
NAME any further thought here?
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.

6.  <ins> QUIC is an encrypted and authenticated transport.  That means, once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. However, some information is still observerable, as supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. More security considerations for QUIC are discussed in QUIC-TRANSPORT and QUIC-TLS, generally considering active or passive attackers in the network as well as attacks on specific QUIC mechanism. Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  However, future versions of QUIC that use Version Negotiation packets are require to define a mechanism that is robust against version downgrade attacks.  Therefore a network node should not attempt to impact version selection, as version downgrade may result in connection failure. </ins> 7.


See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for <del> applications using QUIC, as well. </del>  Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee

After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.
Minor editorial nit.

See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for  <ins> applications using QUIC, as well.  Considerations on linkability, replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee


connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  14. This work is partially supported by the European Commission under

to the security considerations section?
Cross protocol attacks, traffic analysis, and migration are discussed as well in the transport draft, so this pointer might not be absolutely necessary. However, we might still want to have it and then I think these are the relevant sections to refer to.
Applicability to me seems to be mostly targeted to non-H3 users of QUIC, so I'm not sure the H3-specific considerations need to be mentioned here.
My thinking was to add that as reference for other applications that might need to consider similar attacks/security issues. At least half of the points in the hhtp/3 sec considerations are really http specific and probably don't have value for other applications but there are a number of points which are more general. Those points are to some extend probably also covered by the transport draft but may be explained in more detail in the h3 draft.

connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <ins> Further QUIC-HTTP provides security considerations specific to HTTP. However, discussions such as on cross protocol attacks, traffic analysis and padding, or migration might be relevant for other applications using QUIC as well. </ins> 14. This work is partially supported by the European Commission under


endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making <del> these connections identifiable based on the usage of the spin bit, it is recommended that all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </del>  When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).

This sentence is rather supposed to explain what's done in QUIC then giving any recommendation, therefore we can simply remove the "recommended" phrasing.

endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making  <ins> these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </ins> When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).


clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly.  4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for

The text is good however I don't understand its placement in the draft fully. Shouldn't this paragraph go into the previous section or even in an own section? I know the issue, that this PR is addressing, was about DDoS but if we want to have it in the DDoS section we need probably some more words explaining how Retry should be used in this case. Currently it comes a bit out of nothing and interrupts the reading flow of the rest of the text...
I am not really sure at all that the existing DDoS guidance is good advice; we have a somewhat more robust plan in quic-lb, which perhaps we should reference?
for that matter, the Retry packet does not make an appearance in this section at all, which seems like an oversight.
Yes to both. Can you provide an PR?
Yes, please assign this issue to me.

clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. <ins> TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for


versions of the protocol, or even be negotiated during the handshake via the use of transport parameters.  3.1.1. An in-network observer assuming that a set of packets belongs to a

which is about "Network-visible information about QUIC flows". They are mentioned once, based on a recent edit, but the text before that does not introduce them or explain what they are. Maybe we can add a few more sentences also making sure that even though they could be observed in the client initial, they cannot be changed nor observed form the server (to understand final negotiation/support).

versions of the protocol, or even be negotiated during the handshake via the use of transport parameters. <ins> Even though transport parameters transmitted in the client initial are obserable by the network, they cannot be modified by the network without risking connection failure.  Further, the negotiated reply from the server cannot be observed, so observers on the network cannot know which parameters are actually in use. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a


A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. <del> Relative tradeoffs between the cost of closing and reopening a </del>  connection and trying to keep it open are different; see resumption- v-keepalive. divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes <del> idempotence either ecplicitly or implicitly. </del>  3.2. streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these <del> streams are not exposed to the apllication. </del>  Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be <del> opened for each chunk/message.  However, a QUIC receiver has a maximum number of concurrently open streams.  If the stream limit is exhausted a sender is able to indicate that more streams are needed, however, this does not automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose this maximum number to the application, or the number of currently still available, unused streams, and make the mapping of data to streams dependent on this information. </del>  Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months, <del> or years), should rather utilize the 0-RTT seesion resumption ability </del>  provided by QUIC, than trying to maintain one connection open. 4.1. maximally pack packets to minimize bandwidth consumption and computational costs with one or multiple same data frames.  If not enough data available to send QUIC may even wait for a short time, <del> trading of latency and bandwidth effeciency.  This time might either </del>  be pre-configured or can the dynamically adjusted based on the <del> observed sending pattern of the application.  If the apllication </del>  requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Or if a certain sending pattern is know by the <del> application, it might also provide valuabe to QUIC how long it should wait to bundle frame into a packet. </del>  4.3. receiver.  Prioritization can be realized by the sender and the QUIC transport should provide an interface for applications to prioritize streams QUIC.  Further applications can implement their own <del> prioritization scheme on top of QUIC: an an (application) protocol that run on top of QUIC can define explict messages for signaling </del>  priority, such as those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the in the transport layer.  QUIC recommends to retransmit lost data before new data, unless indicated differently by the application. Currently QUIC only provides fully reliable stream transmission, and <del> as such prioritization of retransmissionis likely beneficial in most </del>  cases, as gaps that get filled up and thereby free up flow control. For not fully reliable streams priority scheduling of retransmissions over data of higher-priority streams might not be desired.  In this associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. <del> Specificially, an application that has additional information that the client is not behind a NAT and the server is not behind a load </del>  balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a connection ID. 7. <del> Versioning in QUIC may change the the protocol's behavior completely, </del>  except for the meaning of a few header fields that have been declared to be fixed.  As such version of QUIC with a higher version number does not necessarily provide a better service, but might simply

Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)

A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it.  <ins> Relative trade-offs between the cost of closing and reopening a </ins> connection and trying to keep it open are different; see resumption- v-keepalive. divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes  <ins> idempotence either explicitly or implicitly. </ins> 3.2. streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these  <ins> streams are not exposed to the application. </ins> Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be  <ins> opened for each chunk/message.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months,  <ins> or years), should rather utilize the 0-RTT session resumption ability </ins> provided by QUIC, than trying to maintain one connection open. 4.1. maximally pack packets to minimize bandwidth consumption and computational costs with one or multiple same data frames.  If not enough data available to send QUIC may even wait for a short time,  <ins> trading of latency and bandwidth efficiency.  This time might either </ins> be pre-configured or can the dynamically adjusted based on the  <ins> observed sending pattern of the application.  If the application </ins> requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Or if a certain sending pattern is know by the  <ins> application, it might also provide valuable guidance to QUIC how long it should wait to bundle frame into a packet. </ins> 4.3. receiver.  Prioritization can be realized by the sender and the QUIC transport should provide an interface for applications to prioritize streams QUIC.  Further applications can implement their own  <ins> prioritization scheme on top of QUIC: (an application) protocol that run on top of QUIC can define explicit messages for signaling </ins> priority, such as those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the in the transport layer.  QUIC recommends to retransmit lost data before new data, unless indicated differently by the application. Currently QUIC only provides fully reliable stream transmission, and  <ins> as such prioritization of retransmissions likely beneficial in most </ins> cases, as gaps that get filled up and thereby free up flow control. For not fully reliable streams priority scheduling of retransmissions over data of higher-priority streams might not be desired.  In this associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake.  <ins> Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load </ins> balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a connection ID. 7.  <ins> Versioning in QUIC may change the protocol's behavior completely, </ins> except for the meaning of a few header fields that have been declared to be fixed.  As such version of QUIC with a higher version number does not necessarily provide a better service, but might simply


acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying <del> packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. </del>  4.7.

The text says: “and are emphatically NOT RECOMMENDED.” I think I would agree with a strong encouragement to not do this, but I would suggest to not use upper case letters at this point, and I’m not sure “emphatically” is a great word in a RFC :-). I’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address, because QUIC over radio (of various types) can be significantly more expensive or lower performant than TCP, precisely because the control/ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods.
I created an PR to address the first point. Regarding the second point: NAME do you want to propose additional text? However, if I think that would go the into applicability...?
Suggestion for text: On network paths where there is significant asymmetry, the transmission of QUIC ACKs can reduce the efficient use of network capacity or transmission opportunities. This effect occurs when the return capacity is significantly more constrained than the forward capacity, or the cost of transmission per packet is a significant component of the total transmission cost. Reducing the ratio of acknowledgements to data at the QUIC receiver can improve link utilization and reduce link transmission costs.

acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying  <ins> packets based on packet size are likely to fail, and are not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </ins> 4.7.


either through timers or through least-recently-used eviction, depending on application requirements. <del> RFC4787 recommends a 2 minute timeout interval for UDP.  However, timers can be lower, in the range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-defined closure semantics.  For network devices that are QUIC-aware, it is recommended to also use longer timeouts for QUIC traffic, as QUIC is connection-oriented.  As such, a handshake packet from the server indicates the willingness of the server to communicate with the client. </del>  The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC

Sect 4.8: Reducing the timeout on UDP NATs “Reducing the timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding.” so now, I did not understand what was being discouraged here. Is this somehow linked to section 4.6’s discussion of holding state? (perhaps related to issue )
Yes, this is connected to the advise in section 4.1 but I agree this could be clarified. NAME can you have a look at this?
I can certainly write up something here, but I think we should decide what the actual guidance is before I write it. The NAT UDP timeout is traditionally short; should it be (1) even shorter; (2) remain the same; or (3) become longer? A legacy NAT that is not parsing QUIC headers at all can probably leave the timeout as it is; QUIC should be pretty robust to NAT rebindings for several reasons, and we don't want to mess with existing UDP flows. Maybe my "don't use connection ID at all" guidance has an exception? A QUIC-aware NAT that detects QUIC via a consistent CID field could use a even shorter timeout. But ultimately we're somewhat stuck by "QUIC is robust to NAT rebinding but sometimes it isn't." So I would propose that we recommend that UDP timeouts remain the same. I could be convinced that NATs could reduce the timeout even further if they're reasonably sure the flow is QUIC. What do people think?
There is also text about NAT time-outs in section 4.8 (see also issue ), recommending a longer timeout than UDP. If this recommendation is not right, please comment there. I was pinging you (NAME because you wrote the sentence cited here and wanted to see if we can actually better align it with section 4.8.
Shorter NAT timeouts hurt applications where either side can initiate communication, since once the NAT times out, only one side can initiate communication. Hanging GETs are the typical example in HTTP, but I expect this could be a much larger issue in non-HTTP use cases. The only solution is to send packets(ie: PINGs) to keep the NAT active. I think 2 minutes is reasonable. Expecting anything longer without some explicit endpoint-to-path signaling seems overly optimistic to me, but I could be wrong.
NAME I agree the language is inconsistent and I am happy to write it up. I would just like clear consensus on what it should say. I'm registering NAME 's comment as "keep the UDP timeout as it is"
If you look at section 4.1., the problem is that RFC4787 says MUST NOT be less than 2 minutes but in reality it's usually only 30 or 15 seconds. So I think Ian says 2 (or more) minutes are fine but only 30 sec as often used for UDP is not. Therefore I think it's important to make the point that will with QUIC is even more reasonable to use 2 minutes or more because it's connection-oriented and you can be sure that when you see the handshake from both ends that those ends are actually trying to have a valid communication. Please note that I also have created PR to align the language correctly to RFC4787 in section 4.1.. So if you want to change something in section 4.1. please use as starting point.
I agree with NAME point that for QUIC it's even more reasonable to actually use at least 2 minutes because it's connection-oriented. I don't have any evidence the timeout is commonly under 30 seconds, but it is commonly less than 2 minutes. We have seen extremely short timeouts, and it's believed these are NATs that are running close to saturation so the idle timeout shrinks very low. But it's hard to know for sure.
OK so the message here is, "yes QUIC is 'robust' to NAT rebinding but still don't reduce the timeout." This might be sound advice, but it seems like a bit of waste given our effort surrounding NAT rebinding. I have to think about this some more, but I suppose whatever value we recommend here turns into an effective bound on the QUIC idle timeout in real deployments. I'll just wait till lands to make changes.
It would seem OK to motivate suggesting an increase in the NAT timeout, but saying this is "because it's connection-oriented" ... isn't really enough. Other UDP protocols can also be connection oriented and they might also have observable closing packets - to release the NAT state under normal usage. I think the rationale just needs a little explanation, perhaps in terms of the benefits to QUIC of a larger NAT timeout.
I am happy to take this issue but am glad that NAME put this on the agenda to discuss. I guess I'll wait till after 110 to write a PR?
no, if you can propose some concrete text that would be helpful for the meeting. It's only that we won't merge before the meeting.
I am not sure about NAME 's concerns about one endpoint being blocked from restarting the connection. Having throught it through more, I'll make these assertions: There is a tension between the most endpoint-friendly choice (infinite timeouts!) and what implementers are actually willing to do. A ridiculous requirement is likely to be ignored, so being as generous as possible, given QUIC's salutary features, would be wise. Given how hard we've made it for intermediaries, it would be good internet citizenship to give them something that makes their lives easier if it doesn't compromise performance or privacy. We really do need to make sure that (UDP timeout > 3 PTO) for all plausible PTO values, as this is the minimum idle timeout. NAME problem is arguably solved by judicious use of the idle timeout. If we set a reasonably low recommended idle-timeout for clients and servers (which can be different!), and put the recommended UDP timeout above that value, a few things happen: (a) the server can discard state relatively quickly (b) if the server can't handle NAT rebinding, it can set an aggressive idle-timeout (c) in general, it's the client that will try to keep connections alive (d) the client will be aware of the minimum of the two timeouts -- if they want the connection to survive, they will send PINGs when necessary according to 10.1 of quic-transport. (e) IIUC, both client-side and server-side NAT/Firewalls will accept "new" connections if initiated by the client. So I'm recommending the following: The "intermediary UDP timeout" should be the smallest possible value that is always > 3PTO. Someone tell me what the number is! 10 seconds? Clients should set an idle-timeout value that is a bit less than the recommended intermediary UDP timeout unless they are sure they aren't behind a NAT. Servers should set an idle-timeout according to the following principles: (a) if known to not be robust to rebinding (i.e load balanced without QUIC-LB), just below the intermediary UDP timeout. This is true whether the server knows if it is behind a NAT or not (b) otherwise, use any value you want Thoughts? If people agree with this logic, I'll revise the PR or write another one.
I disagree with your suggestion of recommending a NAT timeout smaller than 2 minutes. I'd prefer something along the lines of NAME previous suggestion of really try to use 2 minutes and we can add text about how clients will have to use PINGs if the timeout is too short, if that's helpful. 5 minute long hanging GETs are a common thing today, and WebTransport may make the case where either side initiates communication more common. Longer timeouts aren't hard, they just require state. Special cases for QUIC are more difficult. This is not always good for either application performance or CPU(ie: more handshakes). Agreed, but that's not my concern as much as the server's inability to contact the client. The client doesn't know what the NAT timeout is, which seems like the important thing here. I'm not sure what you mean by server-side NAT/Firewalls? There's no max to PTO, so 3PTO is technically an infinite value. But if you're assuming typical RTTs on the existing internet with a max in the seconds, it's ~9 RTT. 2g has an RTT in the 2 second range, so if we assume RTTs above 4 seconds are uncommon, then you'd be recommending 36 seconds.
Sure, my language was imprecise. The model here is that we propose a standard NAT timeout that they can live with it, and clients can set idle-timeouts based on the assumption that NATs are following it. I'm referring to things devices in the server infrastructure that rewrite the source address and port on inbound packets to make sure all outbound packets are routed correctly. I understand. Although I'm not going to insist on this, a standard on the order of 30-45 seconds would meet the objective quite well.
Sect 4.1 : This contains a statement on the recommendations for middleboxes and NATs, that I can’t understand, and this concerns me. i.e. to me, the present text suggests that the advice in BCP 127 (aka RFC4787) should be changed for QUIC. I don’t recall this being discussed - was it? I don’t actually follow the rationale that says this follows from QUIC being connection-oriented. If the connection close was visible to the device, and it could release state - then this might make sense, but that isn’t exactly what is explained. I’m left unsure how a “QUIC-aware” middlebox is supposed to track this state. I'm also unsure how say a NAPT could know the traffic was QUIC, is this suggesting a port-based change. I think I need to understand this proposal.
Actually we don't change the recommendation of RFC4748 as it says "A NAT UDP mapping timer MUST NOT expire in less than two minutes" However, we cite this wrongly, which is now addressed in PR . The reason for recommending longer time-outs for QUIC is because you can be sure that there is handshake and the other end did confirm its willingness to communicate. Of course having a stopping indication would be better but we don't have it. We don't recommend a specific value, nor do we say one should use equally long timers as for TCP. However, given you know there is valid communication on-going between the two peers a longer timer (of at least a couple if minutes) would probably be useful in a lot of cases. Do we need more text here? NAME do you want to propose something? Or should I? Otherwise we can also discuss this at the next meeting!

either through timers or through least-recently-used eviction, depending on application requirements.  <ins> RFC4787 requires a timout that is not less than 2 minutes for most UDP traffic.  However, in pratice, timers are often lower, in the range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-defined closure semantics.  For network devices that are QUIC-aware, it is recommended to also use longer timeouts for QUIC traffic, as QUIC is connection-oriented.  As such, a handshake packet from the server indicates the willingness of the server to communicate with the client. </ins> The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC


payload data. Moreover, while encryption (in this case TLS) is inseparably <del> integrated with QUIC, TLS negotiation over TCP can be blocked.  In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable. </del>  3.

I think the following sentence has issues: “In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable.” I’m not sure I understand “In case” I’m not sure this should be upper case RFC2119, unless we decide to also make normative recommendations in other places. “allowing”..”unavailable” makes this award to read.
2119 issue also noted in .

payload data. Moreover, while encryption (in this case TLS) is inseparably  <ins> integrated with QUIC, TLS negotiation over TCP can be blocked.  If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </ins> 3.


Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently <del> routes packets to the correct server instance.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  This ensures that there is no need to for servers and infrastructure to coordinate routing information for each connection. See QUIC-LB for more information. </del>  10.2.

Does this make it easier to understand?
NAME is this better?
“Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance. “ could this be: “Server deployments with load balancers and other routing infrastructure that depends on observing the payload of IP packets need to ensure that this infrastructure consistently routes all the QUIC packet belonging to a connection to the same server instance.” Seems like that is helpful. Is there a relevant section in the OPS draft where the reader should be directed?
Not sure if you addition of "that depends on observing the payload of IP packets" is that helpful in the sentence. The whole point here that if you use load balancers with QUIC, looking only at the IP might not be enough. NAME can you have a look how to phrase this?
Is this referring to sec 9.1 of the applicability draft? Why refer to the ops draft when the current reference (QUIC-LB) has everything you would want to know about the subject? I don't understand what Gorry's new clause adds. In fact, the IP address is not in the payload so I don't believe it's even accurate. Are you trying to distinguish between L7 and L4 load balancers here?
I couldn't work out what the current sentence means what does "correctly" mean?
OK, I can reword this.
This is left open as there is a pending rewrite of the NAT section.
looks good to me.

Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently  <ins> routes packets to the server instance that has the connection state, even if addresses, ports, and/or connection IDs change.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  For an example of this technique, see QUIC-LB. </ins> 10.2.


2.3. Applications that have a mapping for TCP as well as QUIC are expected <del> to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </del>  Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the

It seems to me that QUIC is no different to other transports in respect of being able to utilise other port numbers, and it would be worth noting that this is normal. The present text might perhaps suggest this is specific to QUIC. Should the text reference RFC 7605 or something else just to explain ports don't imply specific application behaviour, but could infer this?.
The title of the pull request was cause for a momentary flutter - in that I don't see the port as carrying anything other than a reference to a convention - but the text is very good.

2.3. Applications that have a mapping for TCP as well as QUIC are expected  <ins> to use the same port number for both services.  However, as for all other IETF transports RFC7605, there is no guarantee that a specific application will use a given registered port, or that a given port carries traffic belonging to the respective registered service, especially when application layer information is encrypted.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </ins> Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the


3.7.2. <del> The spin bit provides an additional method to measure per-flow RTT from observation points on the network path throughout the duration of a connection, following the principles of protocol measurability laid out in IPIM.  Endpoint participation in spin bit signaling is optional in QUIC.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit.  Use of the spin bit for RTT measurement by devices on path is only possible when both endpoints enable it.  Some endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </del>  When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT). An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single <del> direction to measure one sample of end-to-end RTT. </del>  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of

Sect 3.7.2 : “is optional in QUIC”. I think it would be helpful to say more about the spin-bit definition for the current version of the specification, and a cross-reference is needed here. Similarly, “An endpoint not participating...” to me this description applies to the current specification, not an invariant of QUIC in general.

3.7.2.  <ins> The spin bit provides a version-specific method to measure per-flow RTT from observation points on the network path throughout the duration of a connection.  See section 17.4 of QUIC-TRANSPORT for the definition of the spin bit in Version 1 of QUIC.  Endpoint participation in spin bit signaling is optional.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit. Use of the spin bit for RTT measurement by devices on path is only possible when both endpoints enable it.  Some endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </ins> When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT). An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single  <ins> direction to measure one sample of end-to-end RTT.  This mechanism follows the principles of protocol measurability laid out in IPIM. </ins> Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of


The spin bit provides an additional method to measure per-flow RTT from observation points on the network path throughout the duration <del> of a connection.  Endpoint participation in spin bit signaling is </del>  optional in QUIC.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit.  Use of the spin bit for RTT measurement by acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying <del> packets based on packet size are likely to fail, and are not </del>  recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. QUIC is deliberately designed to fail rather than persist when the network cannot support its operation.  For HTTP/3, this extends to recommending a fallback to TCP-based versions of HTTP rather than <del> persisting with a QUIC connection that might be unstable.  And I- D.ietf-quic-applicability recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </del>  hinders the use of QUIC's migration function, which relies on the ability to change the connection ID any time during the lifetime of a QUIC connection.

I set the ready to merge label but there are merge conflict, so please don't merge before accepting my suggestions...
[Ding2015] and [IPIM] are in the references of the manageability draft, but aren't actually... referenced anywhere. That suggests either some text is missing or these entries are spurious.
Yes this has been already flagged by and is fixed in (which we will all merge on Monday when Brain is back). Thanks anyway!
Unused Reference: 'Ding2015' is defined on line 1272, but no explicit reference was found in the text Unused Reference: 'IPIM' is defined on line 1293, but no explicit reference was found in the text
Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'.
There are two paragraphs that include 2119-language: RFC 2119 keyword, line 578: '... RECOMMENDED. First, it only provid...' RFC 2119 keyword, line 969: '... NOT RECOMMENDED....' Should these be made lowercase or is a 2119 paragraph needed?
I see what was done. Looks ready to go.

The spin bit provides an additional method to measure per-flow RTT from observation points on the network path throughout the duration  <ins> of a connection, following the principles of protocol measurability laid out in IPIM.  Endpoint participation in spin bit signaling is </ins> optional in QUIC.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit.  Use of the spin bit for RTT measurement by acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying  <ins> packets based on packet size are very likely to fail, and are not </ins> recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. QUIC is deliberately designed to fail rather than persist when the network cannot support its operation.  For HTTP/3, this extends to recommending a fallback to TCP-based versions of HTTP rather than  <ins> persisting with a QUIC connection that might be unstable.  And QUIC- APPLICABILITY recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </ins> hinders the use of QUIC's migration function, which relies on the ability to change the connection ID any time during the lifetime of a QUIC connection.


acknowledgements) 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 <del> application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del>  However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are edge observed in the upstream direction and that observed in the downstream direction, and vice versa.  4. In this section, we review specific network management and

URL must be postprocessed to become metrics.
Waiting for more reviews, e.g. from NAME before we can merge.
The text describes an example for measuring the average RTT. I like that, but I think we should call out a little that the mean RTT is only one metric. When looking at management info, I'm often interested in min/max and variance... So: “A simple linear smoothing... to get a more stable estimate”. Quite so for a table average RTT. I’d prefer it if we could say something about RTT variance at this point. To me it is important that RTT measurements are clear, and we should never assume in a Spec that RTT is something specific, but more generally an estimate that needs to consider the variance.

acknowledgements) 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  <ins> application. </ins> However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are edge observed in the upstream direction and that observed in the downstream direction, and vice versa. <ins> 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). </ins> 4. In this section, we review specific network management and


4.3.  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

Beware those who want to do something else.
Isn't this already covered by the next section on "Flow Control Deadlocks"? If not, what's missing? And can we just add a sentence or two there?
Though the specification does not insist upon it, most implementations will assume that stream data is reliably delivered in order. This means that senders will send until every byte is delivered or they decide to reset the stream (possibly based on STOP_SENDING). And it means that receivers won't make data available until a contiguous span of bytes starting at the last unread offset are available. Implementations might act differently, but variations from this behaviour would need to be agreed by both endpoints.
NAME can you propose text?

4.3. <ins> QUIC streams enable ordered and reliable delivery.  Though it is possible for an implementation to provide options that use streams for partial reliability or out-of-order delivery, most implementations will assume that data is reliably delivered in order. Under this assumption, an endpoint that receives stream data might not make forward progress until data that is contiguous with the start of a stream is available.  In particular, a receiver might withhold flow control credit until contiguous data is delivered to the application; see Section 2.2 of QUIC.  To support this receive logic, an endpoint will send stream data until it is acknowledged, ensuring that data at the start of the stream is sent and acknowledged first. An endpoint that uses a different sending behavior and does not negotiate that change with its peer might encounter performance issues or deadlocks. 4.4. </ins> 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


1. <del> QUIC QUIC-TRANSPORT is a new transport protocol encapsulated in UDP and encrypted by default.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  The design focused on support of semantics for HTTP, which required changes to HTTP known as HTTP/3 QUIC-HTTP. </del>  Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not

This didn't need to say encrypted twice. And it didn't really require changes to HTTP, just an adaptation. (I'm less happy about that part; it could probably use a tweak or two.)

1.  <ins> QUIC QUIC-TRANSPORT is a new transport protocol that is encapsulated in UDP.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  QUIC version 1 was designed primarily as a transport for HTTP, with the resulting protocol being known as HTTP/3 QUIC-HTTP. </ins> Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not


necessarily includes any transport and application layer delay at both sides. <del> QUIC does not expose any acknowledgement or timestamping information in its wire image.  This makes passive measurement of more than one RTT sample per flow, or passive measurement of changes in RTT during a flow's lifetime, impossible in the general case. Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/631. </del>  3.7. 4.2. <del> Extremely limited loss and RTT measurement are possible by passive observation of QUIC traffic; see sec-rtt and sec-loss. </del>  4.3.

This PR takes text from to explain the on-path use of the latency spin bit. It is the manageability draft companion of the new .
I don't think we want to merge this until we have consensus that the spin bit itself is merged?
NAME fbc8490 changes this to point to the experiment (quic-spin-exp), not to the protocol, and to be clear that it's an experiment. It also pretends the VEC doesn't exist, since quic-spin-exp does so as well. If the experiment merges into the protocol, then we update this draft to point to it; if not, then the text changes in a subsequent draft to omit in-flow RTT.
To further clarify, the draft was mentioning that there is a discussion about the spin bit before. This PR mainly only now points to the respective draft. I think it is far to have this pointer in there for now.
Well, as long as you are prepared to possibly remove this, fine
The nice thing about Internet-Drafts is that they are endlessly mutable. :)

necessarily includes any transport and application layer delay at both sides.  <ins> The spin bit experiment, detailed in QUIC-SPIN, provides an additional method to measure intraflow per-flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit described in that document changes value once per round-trip time (RTT).  An on-path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit to measure "upstream" and "downstream" component RTT; i.e, the component of the end-to-end RTT attributable to the paths between the observer and the server and the observer and the client, respectively.  It does this by measuring the delay between a spin edge observed in the upstream direction and that observed in the downstream direction, and vice versa. Application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are much greater than network RTT.  Therefore, the spin bit provides network latency information only when the sender is neither application nor flow control limited.  When the sender is application-limited by periodic application traffic, where that period is longer than the RTT, measuring the spin bit provides information about the application period, not the RTT.  Simple heuristics based on the observed data rate per flow or changes in the RTT series can be used to reject bad RTT samples due to application or flow control limitation. Since the spin bit logic at each endpoint considers only samples on packets that advance the largest packet number seen, signal generation itself is resistant to reordering.  However, reordering can cause problems at an observer by causing spurious edge detection and therefore low RTT estimates, if reordering occurs across a spin bit flip in the stream.  This can be probabilistically mitigated by the observer also tracking the low-order bits of the packet number, and rejecting edges that appear out-of-order RFC4737. </ins> 3.7. 4.2.  <ins> Limited loss measurement and detailed RTT measurement are possible by passive observation of QUIC traffic; see sec-rtt and sec-loss. </ins> 4.3.


applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  In the case of HTTP, <del> this fallback is TLS 1.3 over TCP. </del>  The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications secure protocols. An application that implements fallback needs to consider the <del> security consequences.  A fallback to TCP and TLS 1.3 exposes control </del>  information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions 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 fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the <del> application layer if needed. Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption. Even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). Any fallback mechanism is likely to impose a degradation of performance; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data. </del>  Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable.  3. QUIC provides for 0-RTT connection establishment.  Though the same

Applicability section 2 says: I'm not sure how practical this advice is. Requiring a fallback to TLS 1.3 specifically seems problematic due to the diversity of HTTP versions and TLS versions that are deployed today. (NB: I agree with a general raising of the bar for security, but I don't think this document is the place to state it) We can assume that any HTTP version might learn about HTTP/3 via Alt-Svc or HTTPSVC. This could for example be HTTP/1.1 over TCP port 80. Such a client could fallback to the version it learned about QUIC from, and nothing bad would happen.
This wasn't meant to enforce any restriction. The assumption was simply that if you have implemented QUIC, you might have probably also implemented TLS1.3... however, I guess we can just remove the "1.3" here and only say "TLS over TCP". Okay?
One could argue it should require TLS 1.3, since otherwise there's an easy security downgrade, but I'm not sure that's something we could require.
IMO we need to accommodate disparate support across versions. To give an example, a CDN operator may have QUIC and HTTP endpoints that are configured differently according to customer configuration. With QUIC v1 it is safe to assume only TLS 1.3 so a CDN might not provide configuration for TLS version. However, other HTTP versions could theoretically be configured only to support a maximum of TLS 1.2. Since plaintext HTTP and TLS 1.2 are not prohibited for use on the internet, it seems odd to levy a requirement that prevents them being used in one specific chain of interactions. Mirja's suggestion to say "TLS over TCP" is better but would still not address the plaintext HTTP case. A user agent might see URL, connect to port 80, and get Alt-Svc'd to HTTP/3. If the something goes wrong and TLS is not permitted, then all connectivity might be broken forever.
In the same section later we say I hope that addresses your point about security downgrade, NAME ?
It might be worth saying "likely to impose a degradation on performance and can degrade security;"?
I created a PR and also changed the order of sentences a bit to make the it more clear. NAME is there anything else you think we need to say here?

applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  In the case of HTTP,  <ins> this fallback is TLS over TCP. </ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications secure protocols. An application that implements fallback needs to consider the  <ins> security consequences.  A fallback to TCP and TLS exposes control </ins> information to modification and manipulation in the network.  Further  <ins> downgrades to older TLS versions than used in QUIC, which is 1.3, 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 fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the  <ins> application layer if needed.  Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. <ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data. </ins> 3. QUIC provides for 0-RTT connection establishment.  Though the same


Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a <del> PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, both during the handshake and for connection migration.  Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </del>  6.

“Padding is used by QUIC to ensure” - please add a sentence that DPLPMTUD is another reason why you might expect QUIC Padding of specific packets after connection establishment, and refer to section in QUIC transport - or people may have a surprise when they suddenly see big probe packets in their logs:-)
I thought that this is what the sentence is about? The whole sentence says: "Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, ..." We can add a reference to the right section in the transport draft but sure we need another sentence? However, your point about being surprised to see big packets probably rather belongs into manageability...?
Ah sorry: I was trying to highlight that there are two places where I think QUIC might be expected to use padding... in the initial connection ... to verify the path supports the minimum size, and later whenever DPLPMTUD is invoked, to probe to check for a larger size. Two section refs would likely be useful. ... Yes, it could be mentioned in manageability - since often QUIC packets might be rather uniform in size with occasional DLPMTUD probes?
I created a PR to add references to the respective sections in the QUIC transport draft. Explaining in detail what padding is used for internally in QUIC wasn't really the point here. However, it's probably correct that the sentence should not just omit one usage (PLDMTUD) and reference probably don't hurt. Do we need still something for manageability? Or is that, at least partially, already addressed by ?
Looks good

Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a  <ins> PADDING frame to arbitrarily increase the size of packets.  Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, during the handshake (see Sections 8.1 and 14.1 of QUIC) and for path validation after connection migration (see Section 8.2 of QUIC) as well as for Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see Section 14.3 of QUIC). Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </ins> 6.


4.7.  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 exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. <del> 4.8. </del>  QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding. timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding. <del> 4.8.1. </del>  NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their violates the best common practice to avoid "port overloading" as described in RFC4787. <del> 4.8.2. </del>  Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security to the attacker address and thus allow an observer to break the connection. <del> 4.9. </del>  RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise

addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.

4.7. <ins> Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP messages (e.g., IPv6 Packet Too Big messages).  Given known attacks with the use of ICMP messages, the use of PLPMTUD in QUIC has been designed to safely use but not rely on receiving ICMP feedback (see Section 14.2.1. of QUIC-TRANSPORT). Networks are recommended to forward these ICMP messages and retain as much of the original packet as possible without exceeding the minimum MTU for the IP version when generating ICMP messages as recommended in RFC1812 and RFC4443. 4.8. </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 exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown.  <ins> 4.9. </ins> QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding. timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding.  <ins> 4.9.1. </ins> NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their violates the best common practice to avoid "port overloading" as described in RFC4787.  <ins> 4.9.2. </ins> Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security to the attacker address and thus allow an observer to break the connection.  <ins> 4.10. </ins> RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise


Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, <del> HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and announce a different port number.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del>  Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

It still says ALPN, though. ALPN doesn't have anything to do with using different ports; it has to do with using different protocols on the same port.
Yes, Martin already pointed this out. Fixed now. Do we need to say still more about ALPN?
I think that this refers to Alt-Svc (RFC 7838), which is mentioned in . You might also mention the not-yet-done SVCB record, but that might not be a good idea if you like the idea of publishing this.
SVCB record would just be an informational reference, no? So that shouldn't hold up publication. In this case I'd be okay to provide a pointer.
What do you meant by "ALPN doesn't enable use of other ports"?
The text here says "specifies the use of ALPN for service discovery which allows the server to use and announce a different port number". ALPN is not a service discovery mechanism, it's a protocol selection mechanism. ALPN is completely orthogonal to choice of ports. The purpose of ALPN is for client and server to agree on the protocol that is used. Your change to references in won't fix this issue. It does correctly cite the Alt-Svc sections of HTTP/3, but the surrounding text still says ALPN.

Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,  <ins> HTTP/3 (QUIC-HTTP Sections 3.1.1 and 3.1.2) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of


and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that <del> identifies the packet as a Version Negotiation packet.  Many QUIC versions that start with 0xff implement IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents.  For example, QUIC version 1 uses version 0x00000001. </del>  Operators should expect to observe packets with other version <del> numbers as a result of various internet experiments and future </del>  standards. source and destination connection ID: short and long packet

The first is not true really. There are 16 million versions that start with 0xff and we only published 34 drafts and implemented far fewer than that. The second is no longer true as we removed the reservation from the registry. Maybe just strike these sentences.
Time of publication statements are not generally useful in this context.

and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that  <ins> identifies the packet as a Version Negotiation packet.  Upon time of publishing of this document, QUIC versions that start with 0xff implement IETF drafts.  QUIC version 1 uses version 0x00000001. </ins> Operators should expect to observe packets with other version  <ins> numbers as a result of various Internet experiments and future </ins> standards. source and destination connection ID: short and long packet


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 <del> the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </del>  2.5.

However there are cases where the congestion window can increase when 0-RTT continues to be sent. Some involve packet loss and so probably won't result in a net increase in the window, though the total number of packets might still exceed the initial window size. Others, like TLS HelloRetryRequest or large certificates, involve additional round trips in the handshake. The total amount of 0-RTT is also limited by remembered flow control values, though this is indirect as this counts stream data only and packets might be further padded.
The original text sounds correct - cwnd doesn't limit the total number of packets sent when some of those packets are declared lost - although we might want to clarify how the sender can still "retransmit" new packets in later RTTs.
I read this as saying that if your initial congestion window is 10 packets, then you can't send more than 10 packets of 0-RTT. That is not the case, even if it might commonly be that way. A client can send 0-RTT over multiple RTTs if you consider HelloRetryRequest and large handshake flights. In the extreme, there is no real limit to the amount of 0-RTT packets that can be exchanged.
qualification worksYou can't ACK 0-RTT packets in 0-RTT, so realistically it's probably 10 packets worth of 0-RTT data at most, but one could construct some edge cases so this is likely better.

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  <ins> the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </ins> 2.5.


handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del>  2.6.

This mixes two things: damage to packets that cause integrity protection to fail, and modification of Initial packets. How about:

handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in  <ins> QUIC packets.  Such alterations would cause the integrity check to fail, which results in the receiver discarding the packet.  Some parts of Initial packets could be altered by removing and re-applying the authenticated encryption without immediate discard at the receiver.  However, the cryptographic handshake validates most fields and any modifications in those fields will result in connection establishment failing later on. </ins> 2.6.


An in-network observer assuming that a set of packets belongs to a QUIC flow can infer the version number in use by observing the <del> handshake: an Initial packet with a given version from a client to which a server responds with an Initial packet with the same version implies acceptance of that version. </del>  Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

This is not a declared invariant, but a property of version 1. As this pertains to version numbers, it might be assumed to be invariant. Maybe by scoping this to v1 explicitly here is the right answer.
lgtm

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


Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection <del> migration; however, these flows can be associated with flows for which a version has been identified; see sec-flow-association. </del>  This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of

This implies that the version of QUIC being used in a given flow can be determined simply by linking that flows to one with a handshake. That assumes that all the work we did to make flows difficult to link was for naught. Maybe "can" should be a "might" or something along those lines. I don't really like the implication that the attempt be made to link flows like this either.
In addition to this, the following text from Section 3.4 is not precise enough to be correct: The assumption that the same flow persists might be good in some cases, but this does not necessarily hold in the case that the endpoint address is used by an endpoint that requires non-zero-length connection IDs. This needs to be more precise if the claim is to hold.
Not sure what you mean by your second comment here. Of course if there is no connection ID you cannot associate it to anything...? What's missing? Can you propose something?
On re-reading, it seems to be a little clearer. It seems to be saying that an observer can match a particular connection ID with a flow and then, if the flow changes address at only one end without changing the connection ID, then it was subject to rebinding and can be assumed to be the same flow. However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty.

Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection  <ins> migration; however, it might be possible to associate a flow with a flow for which a version has been identified; see sec-flow- association. </ins> This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of


2.8. <del> Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </del>  Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid

addresses
I don’t have comments on the validity of the discussion text in section 12 and the described procedures, but I do wonder why this is information for an application designer, rather than for managing operations. Is this the correct ID for this information? and if its is, could it be explained a little more to what the app designer needs too know. This section seems rather devoid of useful references. please add some.
The split here was see as applicability is addressed at people who want to use QUIC (application designer but also people deploying QUIC at servers) and manageability for people who have to handle QUIC traffic (mainly network operator incl probably data centre operators). I know the split between the two last categories (deploying servers and managing a dc networks) is not always that clear. It's probably this section and the one about load balancing in manageability. I'm open to discuss where which section belongs. Do we need to bring this to the meeting? NAME what kind of reference are you thinking of?
On what to do in Manageability: I'd suggest we write some text that says: "QUIC provides a version negotiation process, that allows new versions to be introduced. The deployment of new versions is discussed in section 12 of [ID. ietf-quic-applicability]." Maybe even just as the first para of Manageability: Sect: 2.8. I meant add reference to section 6 in QUIC Transport - to both these documents
There is already section 2.8 on "Version Negotiation and Greasing" and section 3.1.1. on "Identifying Negotiated Version" in the manageability draft. Ideally the idea is to not have cross reference between manageability and applicability. I added a reference to section 6 of the quic-transport draft in manageability (see PR ). Not sure we need that reference also in the applicability draft because that section actually doesn't require any knowledge of the internals on how version negotiation works...

2.8.  <ins> Version Negotiation packets are used by the server to indicate that a requested version from the client is not supported (see section 6 of QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </ins> Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid