key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations <del> to mitigate tracking using key configurations. </del>  10.

What do we want to do with this draft? Should we dispatch it and find it a home?
Good question. I wonder if secdispatch would be a good place to ask.
Clients should cache server keys for some time. TTL can be supply in a cache-control header of a ohttp-keys response. Should this be mentioned or is it implied?
The document doesn't really define the key configuration acquisition method, so it can't really cover details like caching (or retention). Getting into specifics with HTTP Cache-Control is out of scope. There is discussion of retention periods in , which are relevant and might be worth pointing to. That document has uncertain status, but we might still use an informative reference.

key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations  <ins> to mitigate tracking using key configurations.  CONSISTENCY provides an analysis of the options for ensuring the key configurations are consistent between different clients. </ins> 10.


their usage to their developers might use oblivious HTTP for some types of moderately sensitive data.  4. A client needs to acquire information about the key configuration of

For and NAME
I recognize that / added some conditions and use cases, but it would help readers like me to have even more. A separate explainer document/readme would be fine too. In the meeting chat today, I heard the suggestion of requesting map tiles as another use case, which makes sense to me: asking for map tiles is itself pretty revealing if connected to the user's identity (it might reveal your current location, or a location where you're going to be) and can be pretty transactional/stateless. Maybe search queries are similar. Safe browsing lookups was also mentioned. Having more example use cases might help in resolving other questions, like whether to support multiple HTTP requests at a time, or non-HTTP message bodies, etc. Ideally, we could explain the conditions under which adoption of ohttp will be useful -- maybe, a privacy need for reducing linkability of multiple requests or of a single request from user identity, and HTTP requests that are typically stateless or single-shot in some way, and frequent or performant-requiring at a certain level.
NAME added some more examples. NAME I think we can safely close this now, so I'm going to go ahead and do that. Please reopen with concrete suggestions if you think the new text is insufficient!

their usage to their developers might use oblivious HTTP for some types of moderately sensitive data. <ins> These are examples of requests where there is information in a request that - if it were connected to the identity of the user - might allow a server to learn something about that user even if the identity of the user is pseudonymous.  Other examples include the submission of anonymous surveys, making search queries, or requesting location-specific content (such as retrieving tiles of a map display). </ins> 4. A client needs to acquire information about the key configuration of


capablities.  Usually application error codes are defined to be applicabile to all three frames. <del> Alternatively, a QUIC connection will be silently closed by each endpoint separately after an idle timeout.  The idle timeout is announce for each endpoint during connection established and should be accessible by the application.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. </del>  9.

One concern I have with short idle timeout is impact on VM live migration. The current guidance with TCP default timeouts allows LM to have a blackout period of under 9 seconds. Do we need any guidance here to not use very low default timeouts?
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
This is related to quicwg/base-drafts and depends on the outcome there.
PR now indicated that the idle timeout could be exposed to the application. However, we should probably say a bit more what to do with it. I guess the minimum would be to say that the keep-alive frequency needs to be clearly smaller than the idle timeout, e.g. half the timeout. Is there anything more we could say? NAME NAME any thoughts? Or text you can provide?
PR provides some more guidance now but it still doesn't discuss suitable value or ranges. What values are used in current implementations? Should we say more?
This is reasonable advice. A little redundant with the advice in the spec, but not overly so, I think.

capablities.  Usually application error codes are defined to be applicabile to all three frames.  <ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated by a transport parameter in the handshake, the idle timeout is announced for each endpoint during connection establishment and the effective value for this connection is the minimum of the two advertised values.  An application therefore should be able to configure its own maximum value as well as have access to the computed minimum value for this connection.  An application may adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.2.2 of QUIC.  See resumption-v-keepalive for further guidance on keep- alives. </ins> 9.


on-path devices that a flow has ended is that packets are no longer observed.  Stateful devices on path such as NATs and firewalls must therefore use idle timeouts to determine when to drop state for QUIC <del> flows. </del>  3.6. either through timers or through least-recently-used eviction, depending on application requirements.  The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the

But how long...?
For discussion: should the manageability draft advise that idle timeouts should be longer for flows inferred/detected to be QUIC flows? I think the answer here is "it depends": for NATs, yes, state at the edge is not all that scarce anymore. For firewalls? Maybe not so much. Are there other applications to consider here, and is there any generalized advice this document could give? If so, is there any generalized advice for how long the timeout should be?
PR is an attempt to address this issue but doesn't provide much concrete guidance...

on-path devices that a flow has ended is that packets are no longer observed.  Stateful devices on path such as NATs and firewalls must therefore use idle timeouts to determine when to drop state for QUIC  <ins> flows, see further section sec-stateful. </ins> 3.6. either through timers or through least-recently-used eviction, depending on application requirements. <ins> RFC4787 recommends a 2 minute timeout interval for UDP, however, often timer are lower in the range of 15 to 30 second.  In constrast RFC5382 recommends a timeout of more than 2 hours for TCP, given 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 and 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 handshake needs to be observed in order to understand whether the


balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet <del> to a different server in that pool. </del>  10.

References to quic-load-balancers and RFC5077 (due to lack of a better reference) added
I thought the plan was to have a dependency on the load balancing draft rather than merging this part into the applicability draft. However, I would also be fine to add more text here and only have an informational reference, if some is willing to provide text!
... in the applicability statement? I mean one example mechanism maybe...
Can anybody help with that?
URL
The 5077 construction is pretty outdated (it's not even AEAD), unfortunately.
NAME is there somewhere else we should look for current best practice, or do we need to invent something new here?
I'll find a stuckee for up-to-date crypto language here at the Zurich interim.
closing for now, couldn't find any takers.
...actually, it's in the LB draft. Reference it.
PR proposed to address this issue...
Are you prepared to take a dependency on QUIC-LB?

balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet  <ins> to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB. RFC5077 Section 4 describes an example approach for constructing TLS resumption tickets that can be also applied for validation tokens, however, the use of more modern cryptographic algorithms is highly recommended. </ins> 10.


attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, <del> which is most rigorously achieved with encryption. </del>  9.2.

…ancers for further algos
The intention was not to encrypt the length (as you say that would not be helpful) but you should probably "grease" the length such that those bit can not be used to identify a certain system. That was the intention here. However, maybe this is too much detail and we should remove that sentence and only refer to the load-balancer draft instead...?
Note in section about CID that as the server chooses the CIDs, it could use some own scheme to embed the length of the CID in the CID itself, instead remembering it, e.g. use the first few bits to indicate which of the sizes that are support was chosen.
can be done together with , referencing the LB draft
PR to address this and reference to load balancer draft
Reading this again, I'm not sure how I would improve the phrasing. Perhaps "embed the length of the connection ID in plaintext ...".

attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers,  <ins> which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 9.2.


4.4. Current practices in detection and mitigation of Distributed Denial <del> of Service (DDoS) attacks generally involve passive measurement using network flow data RFC7011, classification of traffic into "good" (productive) and "bad" (DoS) flows, and filtering of these bad flows in a "scrubbing" environment.  Key to successful DDoS mitigation is efficient classification of this traffic. Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above can be used in this classification step. </del>  Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as <del> the load balancer I-D.ietf-quic-load-balancers. It is questionable if connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del>  4.5.

This is not how it works. A few examples: URL URL
I'm not sure I see support for "this is not how it works" in your examples: SYN cookies on their own are a 1990s technique for end-system DoS prevention, which, while useful at transport-terminating front ends as part of a larger DoS prevention strategy, aren't really usable on their own at scale. The paper you link to here (from ICWET, and itself a decade old) primarily deals with the separation of good from bad flows at layer 7, not necessarily how the front-end handles these flows once classified. But you're definitely right that this is not only how it works: the DoS mitigation landscape is wide and varied (even if at the end of the day the only strategy we have found to work at scale is "eat the DoS". That said, this text could be improved: it discounts detection and classification mechanisms other than based on flow designators derived from passive measurement, does not mention protocols other than IPFIX and the flow model that comes along with it when classifying traffic, etc. The text should also be more applicable to UDP reflection DoS, which is a primary concern in wire image differentiation in QUIC (and which also isn't otherwise addressed in the document or in this issue). Adding a path-observable SYN cookie equivalent to QUIC, while useful, seems difficult to achieve given the working group's history of consensus about path-observable wire image features, so other classification mechanisms are what we'll be left with.
Exactly my point. The passive measurements are generally only useful to prevent the collateral damage to the network infrastructure of an ISP or a datacenter network under an attack. While the infrastructure impact of QUIC is itself an intriguing research topic, DDoS affects not only transit networks but also the endpoints in ways that could not be prevented with any passive flow classification.
The intent of this section is to cover DoS mitigation on the "downstream" segment, all the way from transit to endpoint, with access and front-end networks in between; the further you get from the endpoint the harder classification is, but the larger the impact of filtering operations. AIUI transit networks generally only get involved at the BGP level (i.e., when an affected destination prefix is temporarily announced via a mitigation/filtering network to route traffic for scrubbing), but we shouldn't look at just the endpoint/frontend, either, This document probably shouldn't go all the way down the DoS prevention architecture rabbithole (note to self: check to see whether DOTS has something we can refer to here). But I'll put some effort into making this more general.
This is more of an "e.g." than "i.e.", but fine. I must say this is also a place where the infrastructure could be affected by the HTTP protocol upgrade. E.g. if the risk model assumes large transport layer floods, then the optical links towards the scrubbing center should be upgraded to carry ~22x more traffic.
actually, no; improve section 4.4 as well.
Err. "Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic" No. It generally does not. There are active and passive countermeasures, there are SYN cookies, truncated DNS responses, captchas, etc. The draft is still missing all of those.
I think what is still missing is to note that this document is generally scoped to in-network manageability and therefore does not discuss measures that can be applied directly at the end hosts. Maybe we can clarify this by add one simple word like this: s/Current practices in detection and mitigation/Current in-network practices in detection and mitigation/ ?
No, this is still not fair. Active countermeasures like SYN proxying still belong to the network. Probably the only way to do this properly would be to say that "Current practices in passive detection and mitigation" do whatever they do, and to add later in the section that there are also practices in active mitigation which are not supported by the protocol (the last paragraph basically sums it up) when the endpoint is not cooperating. It'd be also a good idea to highlight the impact of the lack of active mitigation features, and to hint to how the endpoint could cooperate.

4.4. Current practices in detection and mitigation of Distributed Denial  <ins> of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, then differential treatment of this traffic to forward only good traffic, to the extent possible.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Key to successful DDoS mitigation is efficient classification of this traffic in the mitigation environment.  Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </ins> Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as  <ins> the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> 4.5.


6. <del> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  Instead, the same port number is used as would be used for the same application over TCP.  In the case of HTTP the expectation is that port 443 is used, which has already been registered for "http protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of Alt-Svc for HTTP/QUIC discovery which allows the server to use and announce a different port number. </del> In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. <del> However, whenever a non-standard port is used which does not enable easy mapping to a registered service name, this can lead to blocking by network elements such as firewalls that rely on the port number as a first order of filtering. </del>  7. 12. <del> This document has no actions for IANA. </del>  13.

Both documents provide limited guidance on use of ports, however, there was an open question if the applicability statement should maybe say more and e.g. also talk about ALPN.
pending consensus on use of ALPN in -transport
We already have consensus to require ALPN. Unless you meant to refer to URL In that case, yes, you might want to explain how this works for HTTP/3 specifically. That is, the HTTP/3 ALPN refers to QUICv1. For now. We have apparently reserved the right to revise that when we define QUICv2. If you start to explain the controversial aspects of this (does ALPN refer to the layer or the stack as a whole) then you will soon find that you don't have any concrete answers.
Yep, I meant quicwg/base-drafts. This document should provide some advice to application mappings other than HTTP on how/whether to use ALPN, but that advice really will depend on the larger discussion of what ALPN means (is is app-only, a stack designator, or something in between). Having that discussion in this draft is probably not the right thing to do, so holding this issue open until it converges in TLS/HTTP/QUIC.
Probably it would be good to have a more general section on service discovery and point to the HTTP/3 doc as one example.
Create a new section in applicability, and reference the -http draft section 3.1 as an example.

6.  In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs.  <ins> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  For applications with a fallback to TCP which do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications SHOULD define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, 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. Note that given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name may lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </ins> 7. 12.  <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> 13.


1. <del> QUIC QUIC is a new transport protocol currently under development in the IETF quic working group, focusing on support of semantics as needed for HTTP/2 QUIC-HTTP such as stream-multiplexing to avoid head-of-line blocking.  Based on current deployment practices, QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information. </del>  This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This <del> includes general guidance for application use of HTTP/2 over QUIC as well as the use of other application layer protocols over QUIC.  For specific guidance on how to integrate HTTP/2 with QUIC, see QUIC- HTTP. </del>  In the following sections we discuss specific caveats to QUIC's applicability, and issues that application developers must consider 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 without the TCP Fast Open extension does not support 0-RTT session resumption.  TCP Fast Open can be requested by the connection initiator but might no be supported by the far end or could be blocked on the network path. </del>  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is <del> recognized as such by the receiverApplications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, whether PFS is a hard requirement for the application, and/or whether rejected 0-RTT dgitata should be retransmitted or withdrawn. </del>  3.3. binding or other state entry will be expired after just thirty seconds of inactivity.  A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of <del> interactions with no or very short idle periods. </del>  Ensure there are no long idle periods. transmitted over one stream is mapped into frames or how those frames are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize <del> bandwidth consumption and computational costs (see section 8 of </del>  QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or

Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.

1.  <ins> QUIC QUIC is a new transport protocol providing a number of advanced features.  While initially designed for the HTTP use case, like most transports it is intended for use with a much wider variety of applications.  QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </ins> This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This  <ins> includes general guidance for applications operating over HTTP/3 or directly over QUIC.  For specific guidance on how to integrate HTTP/3 with QUIC, see QUIC-HTTP. </ins> In the following sections we discuss specific caveats to QUIC's applicability, and issues that application developers must consider 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. Even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </ins> Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is  <ins> recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: indicate if 0-RTT support is in general desired, which implies that lack of PFS is acceptable for some data; an indication when 0RTT data for both egress and ingress, so that both sender and receiver understand the properties of the communication channel when the data is sent; and/or whether rejected 0-RTT data should be retransmitted or withdrawn. Some TLS implementations may offer replay protection, which may mitigate some of these issues. </ins> 3.3. binding or other state entry will be expired after just thirty seconds of inactivity. <ins> By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation may still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. </ins> A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of  <ins> interactions with no or very short idle periods, or the protocol's resistance to NAT rebinding is sufficient. </ins> Ensure there are no long idle periods. transmitted over one stream is mapped into frames or how those frames are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize  <ins> bandwidth consumption and computational costs (see section 13 of </ins> QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or


the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  2.7. The packet number field is always present in the QUIC packet header; forward the packets to that server without retaining connection state. <del> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. 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 Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </del> 9.2. While sufficiently robust connection ID generation schemes will

addresses issue
Is this something application designers need to think about or manage? I would hope QUIC implementations would handle this transparently. To the extent you have to configure something like QUIC-LB, that's a manageability thing.
Connection IDs are weird, in that they are important to both implementors / deployers (so applicability) as opposed to operators of networks that are not necessarily at the endpoints (so manageability)
There is text about Connection ID in both documents. We can double-check though that the text is well aligned and splitter correctly.
Well, implementors are explicitly out of scope according to the document's introduction. I would hope that apps didn't have to worry about Connection ID properties very much, or at all. Maybe there is knob or two for information exposure, at most, but I'd consider most of this text to be extraneous to the applicabilty draft.
I think we actually put some text in the wrong doc. PR moves this text from applicability to manageability.

the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT. <ins> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. 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 Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 2.7. The packet number field is always present in the QUIC packet header; forward the packets to that server without retaining connection state.  9.2. While sufficiently robust connection ID generation schemes will


7. <del> QUIC supports connection migration.  Even if lower-layer addresses (usually the 4-tuple of IP addresses and ports) changes, QUIC packets can still be associated with an existing connection based on the Connection ID (see also section connid) in the QUIC header, if present.  This supports cases where address information changes due to e.g.  NAT rebinding or change of the local interface.  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and as soon as the new path is validated all traffic will be switched over to the next path.  Of course if an endpoint decided to not use the Connection ID in short packets (Zero-length Conn ID) for a certain connection, migration is not supported for that direction of the connection. </del>  8. Note that the Connection ID in the short header may be omitted.  This is a per-connection configuration option; if the Connection ID is not <del> present, then the peer omitting the connection ID will use the same local address for the lifetime of the connection. </del>  9.1.

addresses (partially at least)
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
We should probably make it clear what the application can do here (SPA for servers; maybe intentional migration for clients?) I'm not sure if migration is transparent to client applications or not.
The client application might have some knowledge if it's behind a NAT or not and as such might want to indicate to use Conn ID or not. We can make that more explicit in the text.
I did some small edits on the text in the connection migration section but NAME maybe you had something more in mind and want to propose more text?
This whole section should then also be moved to after the Conn ID section.
I like the move of text to the manageability draft. If it were me, I'd move "Server-Generated Connection ID" as well, as I don't think apps need to worry about it, but it's not a big deal. I think adding text about server preferred address is probably more important for this draft.
Added some more text in
NAME we think the current state of the draft addresses this issue; could you check and close this issue if so?

7.  <ins> QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an existing connection based on the Connection ID (see also connid) in the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic can be switched over to that new path.  Path validation means that the other endpoint in required to validate the new path before use in order to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset on path migration.  Therefore migration usually has a performance impact. As long as the new path is not validated only probing packets can be sent.  However, the probing packets can be used measure path characteristics as input for the switching decision or the congestion controller on the new path. </ins> 8. Note that the Connection ID in the short header may be omitted.  This is a per-connection configuration option; if the Connection ID is not  <ins> present, then the peer omitting the connection ID needs to use the same local address for the lifetime of the connection and connection migration is not supported for that direction of the connection. </ins> 9.1.


Version Negotiation (see version, and Section 17.2.1 of QUIC- TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation <del> packet. </del>  source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field based application identification impossible through passive measurement.  3.4. The QUIC Connection ID (see rebinding) is designed to allow an on- 7.  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.

This PR adds a new section on extracting the SNI. I also copied (most of) the pseudo code from Davids document into the appendix. We need to decide if we want to keep this and if so, potentially add some more explanation there. Also we could further strengthen the point out that both the 5-tuple and conn ID can change (as in David's doc). There is already text directly following the new SNI section on "flow association". If we want stronger text there, maybe we can capture that in a separate issue though.
I don't think that you should include the entirety of David's code. There are ways in which that will contribute to ossification. Indeed, I don't think that it is helpful to list draft versions here either.

Version Negotiation (see version, and Section 17.2.1 of QUIC- TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation  <ins> packet.  QUIC versions that start with 0xff are IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents, for example the QUIC version 1 is expected to use version 0x00000001. </ins> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field based application identification impossible through passive measurement. <ins> 3.3.1. If the SNI is not encrypted it can be derived from the QUIC Initial packet by calculating the Initial Secret to decrypt the packet payload and parse the QUIC CRYPTO Frame containing the TLS ClientHello. As both the initial salt for the Initial Secret as well as CRYPTO frame itself are version-specific, the first step is always to parse the version number (second to sixth byte of the long header).  Note that only long header packets carry the version number, so it is necessary to also check the if first bit of the QUIC packet is set to 1, indicating a long header. Note, that proprietary QUIC versions, that have been deployed before standardization, might not set the first bit in a QUIC long header packets to 1.  To parse these versions example code is provided in the appendix (see sec-google-version), however, it is expected that these versions will gradually disappear over time. 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 Client Destination Connection ID needs to be extracted to calculate 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 itself. To determine the end of the header and find the start of the payload further the packet number length, the source connection ID length, as well as the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described in section 17.2. of QUIC-TRANSPORT.  The source connection ID length is specified in the byte after the destination connection ID.  And the token length, which follows the source connection ID, is a variable length integer as specified in section 16 of QUIC- TRANSPORT. Finally after decryption, the Initial Client packet can be parsed to detect the CRYPTO frame that contains the TLS Client Hello, which then can be respectively parsed similar as for all other TLS connections.  The Initial client packet may contain other frames, so the first byte of each frame need to be checked to identify the frame type and the skip over the frame.  Note that the length of the frames is dependent on the frame type.  Usually for QUIC version 1, the packet is expected to only carry the CRYPTO frame and optionally padding frames.  However, padding which is one byte of zeros, may also occur before or after the CRYPTO frame. </ins> 3.4. The QUIC Connection ID (see rebinding) is designed to allow an on- 7. <ins> Thanks to Martin Thomson and Martin Duke for contributing by reviewing and providing text proposals. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement. <ins> 8. This appendix uses the following conventions: array[i] - one byte at index i of array array[i:j] - subset of array starting with index i (inclusive) up to j-1 (inclusive) array[i:] - subset of array starting with index i (inclusive) up to the end of the array 8.1. This section contains algorithms that allows parsing versions from both Google QUIC and IETF QUIC.  These mechanisms will become irrelevant when IETF QUIC is fully deployed and Google QUIC is deprecated. Note that other than this appendix, nothing in this document applies to Google QUIC.  And the purpose of this appendix is merely to distinguish IETF QUIC from any versions of Google QUIC. Conceptually, a Google QUIC version is an opaque 32bit field.  When we refer to a version with four printable characters, we use its ASCII representation: for example, Q050 refers to {'Q', '0', '5', '0'} which is equal to {0x51, 0x30, 0x35, 0x30}. Otherwise, we use its hexadecimal representation: for example, 0xff00001d refers to {0xff, 0x00, 0x00, 0x1d}. QUIC versions that start with 'Q' or 'T' followed by three digits are Google QUIC versions.  Versions up to and including 43 are documented by <https://docs.google.com/document/d/ 1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/preview>.  Versions Q046, Q050, T050, and T051 are not fully documented, but this appendix should contain enough information to allow parsing Client Hellos for those versions. To extract the version number itself, one needs to look at the first byte of the QUIC packet, in other words the first byte of the UDP payload. 8.2. </ins>


3.3. Because QUIC is encapsulated in UDP, applications using QUIC must <del> deal with short idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry will be expired after just thirty seconds of inactivity. </del>  By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. <del> A QUIC application has three strategies to deal with this issue: </del>  Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is <del> responsible for keeping the application alive.  Note that sending PING frames more frequently than every 30 seconds over long idle periods may result in a too much unproductive traffic and power usage for some situations. </del>  Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a 8. <del> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </del>  An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead

"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by

3.3. Because QUIC is encapsulated in UDP, applications using QUIC must  <ins> deal with short network idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though there is not evidence of widespread implementation of this guideline in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity.  Section 3.5 of RFC8085 further discusses keep-alive intervals for UDP: it requires a minimum value 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 address rebinding after a timeout.  However, some QUIC connections firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client.  <ins> A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is  <ins> responsible for keeping the application alive.  While Hatonen10 suggests that 30 seconds might be a suitable value for the public Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a 8.  <ins> QUIC connections are closed either by expiration of an idle timeout, as determined by transport parameters, or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </ins> An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead


location of fields used in the version negotiation process is invariant QUIC-INVARIANTS. <del> This document is focused on the protocol as presently defined in QUIC-TRANSPORT and QUIC-TLS.  Non-invariant parts of the wire image as described herein and in those documents cannot be used to identify QUIC as a protocol, and cannot be relied upon to infer behavior of future versions of QUIC. </del>  2.1.

It might be the case that this is true for the whole draft and we should just state this at the beginning but better to double-check!
we will leave this issue open to double-check at the end

location of fields used in the version negotiation process is invariant QUIC-INVARIANTS.  <ins> This document describes only version 1 the QUIC protocol, whose wire image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Note that features of the wire image described herein and in those documents may change in future versions of the protocol, and cannot be used to identify QUIC as a protocol or to infer the behavior of future versions of QUIC. sec-google-version provides non-normative guidance on the identification of QUIC version 1 packets compared to other deployed versions at the date if publication. </ins> 2.1.


Multiple QUIC packets may be coalesced into a UDP datagram, with a datagram carrying one or more long header packets followed by zero or one short header packets.  When packets are coalesced, the Length <del> fields in the long headers are used to separate QUIC packets.  The length header field is variable length and its position in the header is also variable depending on the length of the source and destination connection ID.  See Section 4.6 of QUIC-TRANSPORT. </del>  2.3. secrecy (PFS). Data in the first flight sent by the client in a connection <del> established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </del>  idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily <del> expose stream identifiers to the application (see e.g.  QUIC-HTTP section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </del>  4.1. has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- <del> specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </del>  capablities.  Usually application error codes are defined to be applicabile to all three frames. adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open <del> for longer than the announced timeout, it can send keep-alives </del>  messages, or a QUIC implementation may provide an option to defer the <del> time-out to avoid unnecessary load, as specified in Section 10.2.2 of </del>  QUIC.  See resumption-v-keepalive for further guidance on keep- alives. 9.1. QUIC supports a server-generated Connection ID, transmitted to the <del> client during connection establishment (see Section 6.1 of QUIC). </del>  Servers behind load balancers may need to change the Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support

The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.

Multiple QUIC packets may be coalesced into a UDP datagram, with a datagram carrying one or more long header packets followed by zero or one short header packets.  When packets are coalesced, the Length  <ins> fields in the long headers are used to separate QUIC packets; see Section 12.2 of QUIC-TRANSPORT.  The length header field is variable length, and its position in the header is also variable depending on the length of the source and destination connection ID; see Section 17.2 of QUIC-TRANSPORT. </ins> 2.3. secrecy (PFS). Data in the first flight sent by the client in a connection  <ins> established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </ins> idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily  <ins> expose stream identifiers to the application (see, for example, QUIC- HTTP, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </ins> 4.1. has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application-  <ins> specific error codes (see, for example, QUIC-HTTP, Section 8.1).  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code. Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </ins> capablities.  Usually application error codes are defined to be applicabile to all three frames. adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open  <ins> for longer than the announced timeout, it can send keep-alive </ins> messages, or a QUIC implementation may provide an option to defer the  <ins> time-out to avoid unnecessary load, as specified in Section 10.1.2 of </ins> QUIC.  See resumption-v-keepalive for further guidance on keep- alives. 9.1. QUIC supports a server-generated Connection ID, transmitted to the  <ins> client during connection establishment (see Section 7.2 of QUIC). </ins> Servers behind load balancers may need to change the Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support


1. QUIC QUIC is a new transport protocol providing a number of advanced <del> features.  While initially designed for the HTTP use case, like most transports it is intended for use with a much wider variety of applications.  QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </del>  This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This 1.1. <del> The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document.  It's not shouting; when these words are capitalized, they have a special meaning as defined in RFC2119. </del>  2. <del> QUIC uses UDP as a substrate for userspace implementation and port numbers for NAT and middlebox traversal.  While there is no evidence of widespread, systematic disadvantage of UDP traffic compared to TCP in the Internet Edeline16, somewhere between three Trammell16 and five Swett16 percent of networks simply block UDP traffic.  All 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.  This fallback SHOULD provide TLS 1.3 or equivalent cryptographic protection, if available, in order to keep fallback from being exploited as a downgrade attack. In the case of HTTP, this fallback is TLS 1.3 over TCP. </del>  These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the 3.1. <del> 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. Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption- v-keepalive. </del>  Applications must be slightly rethought in order to make best use of <del> 0-RTT resumption.  Most importantly, application operations must be 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 idempotence either explicitly or implicitly. </del>  3.2. Retransmission or (malicious) replay of data contained in 0-RTT <del> resumption packets could cause the server side to receive two copies of the same data.  This is further described in HTTP-RETRY.  Data sent during 0-RTT resumption also cannot benefit from perfect forward secrecy (PFS). Data in the first flight sent by the client in a connection established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: indicate if 0-RTT support is in general desired, which implies that lack of PFS is acceptable for some data; an indication when 0RTT data for both egress and ingress, so that both sender and receiver understand the properties of the communication channel when the data is sent; and/or whether rejected 0-RTT data should be retransmitted or withdrawn. Some TLS implementations may offer replay protection, which may mitigate some of these issues. </del>  3.3. entirely. By using a Connection ID, QUIC is designed to be robust to NAT <del> address rebinding after a timeout.  However, some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation may still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </del>  Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to <del> lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </del>  Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is <del> idempotent. </del>  The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should

These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.

1. QUIC QUIC is a new transport protocol providing a number of advanced  <ins> features.  While initially designed for the HTTP use case, it provides capabilities that can be used with a much wider variety of applications.  QUIC is encapsulated in UDP.  QUIC version 1 integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </ins> This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This 1.1.  <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.  <ins> QUIC uses UDP as a substrate.  This enables both userspace implementation traversal of middleboxes and NAT without requiring updates. While there is no evidence of widespread, systematic disadvantage of UDP traffic compared to TCP in the Internet Edeline16, somewhere between three Trammell16 and five Swett16 percent of networks simply block UDP traffic.  All 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, this fallback is TLS 1.3 over TCP. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further downgrades to older TLS versions might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation ALPN 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 3.1.  <ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view of the application using it.  Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. </ins> Applications must be slightly rethought in order to make best use of  <ins> 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </ins> 3.2. Retransmission or (malicious) replay of data contained in 0-RTT  <ins> packets could cause the server side to receive two copies of the same data. Application data sent by the client in 0-RTT packets could be processed more than once if it is replayed.  Applications need to be aware of what is safe to send in 0-RTT.  Application protocols that seek to enable the use of 0-RTT need a careful analysis and a description of what can be sent in 0-RTT; see Section 5.6 of QUIC- TLS. In some cases, it might be sufficient to limit application data sent in 0-RTT to that which only causes actions at a server that are known to be free of lasting effect.  Initiating data retrieval or establishing configuration are examples of actions that could be safe.  Idempotent operations - those for which repetition has the same net effect as a single operation - might be safe.  However, it is also possible to combine individually idempotent operations into a non-idempotent sequence of operations. Once a server accepts 0-RTT data there is no means of selectively discarding data that is received.  However, protocols can define ways to reject individual actions that might be unsafe if replayed. Some TLS implementations and deployments might be able to provide partial or even complete replay protection, which could be used to manage replay risk. </ins> 3.3. entirely. 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. Some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation could still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. A QUIC application can adjust idle periods to manage the risk of timeout (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC), but then there are three options: </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to  <ins> lower network and computational load. Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices.  Additionally, time-outs shorter than 30 seconds can make it harder to handle transient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is  <ins> idempotent.  Using resumption in this way also assumes that the protocol does not accumulate any non-persistent state in association with a connection.  State bound to a connection cannot reliably be transferred to a resumed connection. </ins> The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should


QUIC provides an interface that provides multiple streams to the application; however, the application usually cannot control how data transmitted over one stream is mapped into frames or how those frames <del> are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize bandwidth consumption and computational costs (see section 13 of QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or dynamically adjusted based on the observed sending pattern of the application.  If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Alternatively, if the application expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundle frames into a packet. Similarly, an appliaction has usually no control about the length of a QUIC packet on the wire.  However, QUIC provides the ability to add a padding frame to impact the packet size.  This is mainly used by QUIC itself in the first packet in order to ensure that the path is capable of transferring packets of at least a certain size. Additionally, a QUIC implementation can expose an application layer interface to specify a certain packet size.  This can either be used by the application to force certian packet sizes in specific use cases/networks, or ensure that all packets are equally sized to conceal potential leakage of application layer information when the data sent by the application are not greedy.  Note the initial packet must have a minimum size of 1200 bytes according to the QUIC specification.  A receiver of a smaller initial packet may reject this packet in order to avoid amplification attacks. </del>  6. demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes <del> connect" RFC6335.  Note that the assumption that an application can be identified in the network based on the port number is less true today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. </del>  As QUIC is a general purpose transport protocol, there are no <del> requirements that servers use a particular UDP port for QUIC in general.  For applications with a fallback to TCP which do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications should define an alternate endpoint discovery mechanism </del>  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 </del>  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, this approach allows unambiguous agreement between the endpoints on the protocol stack in use. <del> Note that given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name may lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </del>  7. 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 based on the Connection ID (see also connid) in the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used.  As such if the client is known or likely to sit behind a NAT, use of a connection ID for the server is strongly recommended.  A non-empty connection ID for the server is also strongly recommended when migration is supported. </del>  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic least one RTT and congestion control will also be reset on path migration.  Therefore migration usually has a performance impact. <del> As long as the new path is not validated only probing packets can be sent.  However, the probing packets can be used measure path characteristics as input for the switching decision or the congestion controller on the new path. </del>  Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a <del> different address after the handshake, e.g. to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </del>  8. application layer and therefore no additional data is expected from both sides. <del> An immidate close will emit an CONNECTION_CLOSE frame.  This frames </del>  has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- <del> specific error codes (see, for example, QUIC-HTTP, Section 8.1).  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that </del>  can be used to append human-readable information to an error code. <del> Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar capablities.  Usually application error codes are defined to be applicabile to all three frames. </del>  Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated by a transport parameter in the handshake, the idle timeout is announced for each endpoint during connection establishment and the <del> effective value for this connection is the minimum of the two advertised values.  An application therefore should be able to configure its own maximum value as well as have access to the </del>  computed minimum value for this connection.  An application may adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory <del> more quickly.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alive messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.1.2 of QUIC.  See resumption-v-keepalive for further guidance on keep- alives. </del>  9. for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header exposes at most only a single Connection ID. Note that the Connection ID in the short header may be omitted.  This is a per-connection configuration option; if the Connection ID is not present, then the peer omitting the connection ID needs to use the same local address for the lifetime of the connection and connection migration is not supported for that direction of the connection. </del>  9.1. <del> QUIC supports a server-generated Connection ID, transmitted to the </del>  client during connection establishment (see Section 7.2 of QUIC). <del> Servers behind load balancers may need to change the Connection ID </del>  during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support <del> stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. </del>  9.2. Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. <del> The third stage completes the process by enabling validation of the negotiation version as though the new version were disabled. </del>  The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse.

Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.

QUIC provides an interface that provides multiple streams to the application; however, the application usually cannot control how data transmitted over one stream is mapped into frames or how those frames  <ins> are bundled into packets. By default, many QUIC implementations will try to maximally pack packets with one or more stream data frames to minimize bandwidth consumption and computational costs (see section 13 of QUIC).  If there is not enough data available to fill a packet, an implementation might wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre- configured or dynamically adjusted based on the observed sending pattern of the application. If the application requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Alternatively, if the application expects to use a specific sending pattern, it can also provide a suggested delay to QUIC for how long to wait before bundle frames into a packet. Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a 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. </ins> 6. demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes  <ins> connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. </ins> As QUIC is a general purpose transport protocol, there are no  <ins> requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. Applications could define an alternate endpoint discovery mechanism </ins> to allow the usage of ports other than the default.  For example,  <ins> HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN </ins> 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, 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 ports that cannot easily be mapped to a registered service name might lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </ins> 7. 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 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 indication in the handshake of the server for a preferred address to be used. Use of a non-empty connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-empty connection ID is also strongly recommended when migration is supported. </ins> Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic least one RTT and congestion control will also be reset on path migration.  Therefore migration usually has a performance impact.  <ins> Probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </ins> Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a  <ins> different address after the handshake.  For instance, this could be used to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </ins> 8. application layer and therefore no additional data is expected from both sides.  <ins> An immediate close will emit an CONNECTION_CLOSE frame.  This frames </ins> has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application-  <ins> specific error codes (see, for example, QUIC-HTTP, Section 8.1). The CONNECTION_CLOSE frame provides an optional reason field, that </ins> can be used to append human-readable information to an error code.  <ins> Note that QUIC RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string.  Application error codes are expected to be defined from a single space that applies to all three frame types. </ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated by a transport parameter in the handshake, the idle timeout is announced for each endpoint during connection establishment and the  <ins> effective value for this connection is the minimum of the two values advertised by client and server.  An application therefore should be able to configure its own maximum value as well as have access to the </ins> computed minimum value for this connection.  An application may adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory  <ins> more quickly. If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alive messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.1.2 of QUIC.  See resumption-v-keepalive for further guidance on keep-alives. </ins> 9. for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and  <ins> connection IDs), the short header exposes at most only a single connection ID. Aside from the Destination Connection ID field of the first packets 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 packets with a zero-length Destination Connection ID.  The endpoint 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 could mean that the endpoint is unable to match datagrams to connections successfully if these values change, making migration effectively impossible. </ins> 9.1.  <ins> QUIC supports a server-generated connection ID, transmitted to the </ins> client during connection establishment (see Section 7.2 of QUIC).  <ins> Servers behind load balancers may need to change the connection ID </ins> during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support  <ins> stateless load balancing. Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently 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 further QUIC-LB. </ins> 9.2. Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay.  <ins> The third stage completes the process by enabling authentication of the negotiated version with the assumption that the new version is fully available. </ins> The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse.


Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a <del> unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. </del>  Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a

This text in is incorrect. When you have sent that much data, the connection flow control limit cannot be increased further. Consequently, though many additional streams can be opened when a stream hits this limit, you cannot send any bytes on any of those streams. I recommend striking this sentence or replacing it with a note about this fundamental limit applying to all data conveyed in streams.
Happy to take a PR :-)
Pretty good. Thanks.

Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a  <ins> unidirectional stream can send data on it. Due to encoding limitations on stream offsets and connection flow control limits, both streams and connections can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, a new connection would need to be established. </ins> Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a


close either the ingress or egress direction; these actions are fully independent of each other. <del> If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </del>  Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be

after discussion with NAME we probably do want to keep the information that "all streams are equal" here. Reverse the order of the sentences here to not bury the lede.
I think that the text on can be removed. This was an interesting discussion in HTTP/3, but I'm not sure that the applicability statement needs to concern itself with this detail.
The intention was, given it was an interesting discussion in H3, it might worth mentioning as other application may have the same "problem". I think it doesn't hurt to keep it. Or is there any concern that the term "critical stream" is maybe not well enough defined?
This reads better for sure, aside from an odd bit of phrasing.

close either the ingress or egress direction; these actions are fully independent of each other.  <ins> QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually reset the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be


9.2.  While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination

launches right into discussion of how linkability protections might be inadequate without really establishing what the requirements are or why they exist. This needs an introduction paragraph.
Note sure how much more we want to say here or can say at this point in time.... NAME if you have a more concrete idea what we should say here, can you give it a try and propose a PR?
Something like: Then launch into the existing discussion.
Sounds good to me. I can add that after you PR landed or you can add it to your PR.

9.2. <ins> QUIC requires that endpoints generate fresh connection IDs for use on new network paths.  Choosing values that are unlinkable to an outside observer ensures that activity on different paths cannot be trivially correlated using the connection ID. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination