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

Discussion:
Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry <del> a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </del> <ins> a destination connection ID, a variable-length field which, if not zero-length, can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </ins> In version 1 of QUIC, the following additional information is exposed:
Change:
Text as proposed by Lars on list.
I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see URL); there is a huge range for experimental versions.
This was discussed on the list and has a proposed resolution; PR to be submitted.
Also this was commented by Eric Vyncke as well:

Discussion:
version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801). <del> All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). </del> <ins> An IANA registry contains the values of all standardized versions of QUIC, and may contain some proprietary versions (see Section 22.2 of QUIC-TRANSPORT).  However, other versions of QUIC can be expected to be seen in the Internet at any given time. </ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not
Change:
Wire image mutability is more subtle than "is completely immutable", and we get into the details later. New text is sufficient as contrast for TCP.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...

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

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

Discussion:
application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today <del> due to encapsulation, mechanisms for dynamic port assignments, and NATs. </del> <ins> due to encapsulation and mechanisms for dynamic port assignments, as also noted in RFC6335. </ins> As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For
Change:
Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded"

Discussion:
is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- <del> ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </del> <ins> ordering than typical TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and
Change:
addresses
-- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? [MK] I guess that is the whole point here and I think the answer is no. You might see new experimental version that come and go quickly and are deployed only by one vendor but I don't think that will give you necessarily much insights about the application within the encrypted payload. Also experimental version are expected to be around for short times only and change quickly, thus you would be very busy to adapt your fingerprinting continuously. That's why the recommendation is to not do it. [Christian Huitema] Application developers will try to evolve the version number. If that cause the packets to be somehow discarded, this will have a very predictable result: all QUIC implementations will set the version number to 1 in the clear text header, while the "real" version number will be negotiated as part of the encrypted payload. If we follow that path, the network managers will not have any usable signal about the QUIC version, and the application developers will have to use more complex software and carry four useless bytes in the initial packets. Truth is, this is most likely what will happen, given natural trends. I don't know whether the text in the applicability statement will be enough to avoid that fate.
I don't think we can say more about not using the version number to identify QUIC. However do we want to mention the risk of fingerprinting? However, I guess that would rather something to add to the spec considerations in the applicability statement?

Discussion:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <ins> The QUIC Versions Registry established in QUIC allows for provisional registrations for experimentation.  Registration, also of experimental versions, is important to avoid collision.  Experimental versions should not be used long-term or registered as permanent to minimize the risk of fingerprinting based on the version number. </ins> 14. QUIC version 1 does not specify a version negotiation mechanism in
Change:
Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable?

Discussion:
existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional <del> change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del> <ins> change of the local interface, the expiration of a temporary IPv6 address RFC8981, or the server indicating a preferred address Section 9.6 of QUIC. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-
Change:
...addressing NAME
Middlebox vendors (and others as well) used to TCP want to assume that the smallest packet might be ack packets. This is not true in QUIC, and manageabiity draft may want to say something about it.
Thanks for writing this up!

Discussion:
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> <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.

4.5. <ins> Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. 4.6. </ins> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on
Change:
Review and update text in -manageability to reflect BKK spin bit consensus: single spin bit is in the protocol spec now endpoints may opt out (discuss why; this is for any reason, not just proxies as suggested in ), endpoints should probabilistically out out to provide cover for endpoints opting out
I am working on this.
NAME what about having a privacy consideration section ?
I'm not sure this fits in the scope of the document: can you say more about what you propose to be in this section? The -manageability document is meant to be an independent user's guide to the wire image, so information on the spin bit here will be more about how to measure it, not additional guidelines on how to generate it and when not to (though such text might belong in -applicability) Please coordinate with NAME who will also be proposing text on spin measurement to bring over from draft-ietf-quic-spin-exp.
see PR
closed by merge of and

Discussion:
every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. <del> latency spin bit: the third most significant bit of first octet. However, the is only used in short packet headers.  There it will be set alternatingly to 0 or 1 by the endpoints such that tracking edge transistions can be used to passively monitor the connection RTT, see spin-usage for further details. </del> <ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further details. </ins> header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages
Change:
This section was still empty so far. This PR also address issue .
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?
See also PR
merged
This is good, modulo typos (all edits as suggestions)

Discussion:
6. <del> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] </del> <ins> 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. An immidate close will emit an CONNECTION_CLOSE frame.  This frames 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- 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 capablities.  Usually application error codes are defined to be applicabile to all three frames. 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. </ins> 7.
Change:
At Gorry's suggestion I put the NAT guidance into a different draft: URL Sorry, I thought the notification went out automatically. Regardless, this change is fine.
The manageability draft should talk a little bit about NATS for QUIC. The laziest thing to do is just continue to have NAT mapping be by 4-tuple, as it is today. This is actually fine. However, someone might attempt to be clever and use the CID as well. For example, client A and client B could share the same serverside address and port and the NAT can initially distinguish between the two because they have different CIDs. This appears to save address space, but doesn't actually work because the server could switch to a new client connection ID. In this case, the NAT won't be able to determine which client to route to.
I think it's also worth mentioning that using just the CID only is similarly broken, the fundamental underlying concept here is that subsequent CIDs are exchanged in a manner that the NAT cannot see -- the only time it's okay to use CIDs is if you're colluding with one of the endpoints, as in QUIC LB.
At least recommend to use longer binding lifetimes for identified QUIC connections?
See PR
Fixed in this doc by
Looks good to me. It might be worth adding a bit more (see my detailed comment).

Discussion:
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 <del> Connection ID is present and what length it has. </del> <ins> Connection ID is present and what length it has.  However, Connection IDs may be renegotiated during a connection, and this renegotiation is not visible to the path.  Keying state off the Connection ID may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  Use of Connection ID specifically discouraged for NAT applications. </ins> 4.2.
Change:
when merged.
See also issue quicwg/base-drafts
Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible. However, if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version (similar as TLS1.3 does); of course there is a performance/overhead trade-off. With the uncertainty about what will happen in respect to ossification, it might not be worth is to try and solve the problem now and pay the complexity up front.
does not appear as though the discussion on the list has converged yet; will wait to see at happens in the base drafts before addressing this one in ops.
Consensus to handle "weak" version ossification via a mechanism in the transport; holding this issue open until that converges, but probably not useful to have text in manageability.
This converged in Singapore to no-action in v1.
Fixed by
My comments left the lines >80 characters, but otherwise LGI'm wondering if we should use even stronger language; not that anything can really enforce it.

Discussion:
routability.  Therefore changing these information will also cause the connection to fail. <ins> QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed in the Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the multi-year timeframe so therefore not recommended. </ins> 3. This section addresses the different kinds of observations and