jiebi/TextFlow huggingface dataset:
Original text:
It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not <del> per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment. </del>  Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown.  4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by

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

Revised text:
It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not  <ins> per-packet) and as such that all packets belonging to the same active QUIC connection get uniform treatment. </ins> Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. <ins> Note that the 5-tuple of a QUIC connnection can change due to migration.  In this case different flows are observed by the path and maybe be treated differently, as congestion control is usualy reset on migration (see also sec-flow-association). </ins> 4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by
Original text:
This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on <del> network operations involving QUIC traffic.  Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. </del>  1.

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

Revised text:
This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on  <ins> network operations involving QUIC traffic.  It is intended as a "user's manual" for the wire image, providing guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. </ins> 1.
Original text:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay (the latter mainly caused by the asymmetric crypto operations associated with the TLS handshake) at both sides. </del>  3.8.2.

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

Revised text:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement  <ins> necessarily includes any transport- and application-layer delay at both endpoints. </ins> 3.8.2.
Original text:
is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system <del> with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network. Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del>  These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

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

Revised text:
is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system  <ins> with a common API for multiple protocols.  This is particularly relevant for QUIC as it addresses the implications of fallback among multiple protocols. Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided.  In general, a application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the
Original text:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay at </del>  both endpoints. 3.8.2. in IPIM. Note that this measurement, as with passive RTT measurement for TCP, <del> includes any transport protocol delay (e.g., delayed sending of </del>  acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) <del> and RTT variance (which approximates jitter as seen by the application). </del>  4.

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

Revised text:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement  <ins> necessarily includes all transport- and application-layer delay at </ins> both endpoints. 3.8.2. in IPIM. Note that this measurement, as with passive RTT measurement for TCP,  <ins> includes all transport protocol delay (e.g., delayed sending of </ins> acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows)  <ins> and RTT variance (which approximates one-way packet delay variance as seen by an application end-point). </ins> 4.
Original text:
flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- <del> QUIC traffic for purposes of network admission control should admit all QUIC traffic regardless of version. </del>  3.

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

Revised text:
flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non-  <ins> QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continious version-based evolution and avoid unnecessary deployment delays. </ins> 3.
Original text:
Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be <del> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, it describes what is and is not possible with the QUIC transport protocol as defined. </del>  This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on

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

Revised text:
Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be  <ins> impermissible on other networks without those requirements.  The presence of a particular practice in this document should therefore not be construed as a recommendation to apply it.  For each practice, this document describes what is and is not possible with the QUIC transport protocol as defined. </ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on
Original text:
QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the <del> Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continuous version-based evolution and avoid unnecessary deployment delays. </del>  3.

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

Revised text:
QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the  <ins> Internet more often than with other commonly deployed Internet- and transport-layer protocols.  Use of the version number field for traffic recognition will therefore behave differently than with these protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows, and completely fail in the near future.  Reliance on the version number field for the purposes of admission control is similarly likely to rapidly lead to unintended failure modes.  Admission of QUIC traffic regardless of version avoids these failure modes, avoids unnecessary deployment delays, and supports continuous version-based evolution. </ins> 3.
Original text:
In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to <del> the load balancers. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server are able to identify and discard packets featuring an invalid MAC. </del>  4.4.

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

Revised text:
In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to  <ins> the load balancers.  Guidance on assigning connection IDs is given in QUIC-APPLICABILITY. </ins> 4.4.
Original text:
known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to <del> specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del>  While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

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

Revised text:
known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to  <ins> specify alternate port numbers.  Other applications (e.g., Microsoft's SMB over QUIC) also use UDP port 443 by default. Therefore, simple assumptions about whether a given flow is using QUIC, or indeed which application it might be using QUIC, based solely upon a UDP port number may not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-
Original text:
An in-network observer assuming that a set of packets belongs to a QUIC flow might infer the version number in use by observing the <del> handshake: for QUIC version 1, if the version number in the Initial packet from a client is the same as the version number in the Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </del>  The negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

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

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