Change:
threshold less than 3, to keep in line with TCP RFC5681. Some networks may exhibit higher degrees of reordering, causing a <del> sender to detect spurious losses.  Implementers MAY use algorithms developed for TCP, such as TCP-NCR RFC4653, to improve QUIC's reordering resilience. </del> <ins> sender to detect spurious losses.  Algorithms that increase the reordering threshold after spuriously detecting losses, such as TCP- NCR RFC4653, have proven to be useful in TCP and are expected to at least as useful in QUIC.  Re-ordering could be more common with QUIC than TCP, because network elements cannot observe and fix the order of out-of-order packets. </ins> 5.1.2.

Discussion:
by tweaking the text, but doesn't add a new SHOULD.
Since RFC4653 doesn't seem like it would map to QUIC as readily as the stuff in the RACK draft about reorder-threshold tuning (it seems to be all about extending the Limited Transmit algorithm), maybe RACK is a better reference? URL c.f. "Update RACK reordering window"
I would prefer to reference RACK, but it's not an RFC yet and I'm not sure it will be prior to QUIC shipping. What's the best way to handle that?
The QUIC recovery spec already references the RACK draft in multiple places.
Fair point, I replaced the old reference with the RACK reference. PTAL.
LG!
I don't see any conversation in this PR about it, but I see a commit titled simply "non-normative" reverting the reference from RACK back to NCR. It's not a big deal, but I'm just curious about the reasoning.
There's conversation on the issue(URL) and Jana was concerned about adding another reference to RACK as well as recommending something that we don't have a detailed algorithm(and pseudocode) for. In general, anything we have a SHOULD for has more text(and typically pseudocode) than this, so I accepted that point and adjusted the PR. For example, the pseudocode doesn't detail how to detect spurious losses, since it's expected that could be fairly complex and implementation dependent.
I see, thanks for pointing me to that. But Jana's ask seems to me to be all about SHOULD versus MAY, and orthogonal to referencing NCR vs RACK; if it was a SHOULD, then you'd still have the same incompletely-specified-algorithm problem with NCR. It seems to me that now that SHOULD is removed, Jana would agree that RACK is a better reference since it maps more cleanly to QUIC.
Actually, I'm not so confident that RACK maps all that cleanly either, and Jana made the point that RACK's ReoWnd adjustment algorithm hasn't been closely examined, so I'm going to bow out here- I'm happy with either NCR or RACK.
The RACK draft has this as a SHOULD, and this was worthwhile in our deployment experience, so I think we should change our MAY to a SHOULD. From Section 4 of URL "3.

The RACK reordering window SHOULD leverage Duplicate Selective Acknowledgement (DSACK) information [RFC3708] to adaptively estimate the duration of reordering events."
Another normative dependency on an experimental RFC. And one that isn't in the . Great. This seems fine, but it's a design change.
I would like to not see a dependency on the RACK draft here. If we want this to become a SHOULD, we really need to spell out what an implementation SHOULD do more precisely and not just point to RACK. That said, I'm not convinced that we should do a SHOULD here. I understand that you see an improvement (that might be worth noting in the spec), which is a perfectly good reason encourage others to implement and experiment, but why is a MAY not adequate, given that we have limited experience? I also am not convinced that this is important enough to warrant a design change at this late stage. Do you think this performance impact is significant enough to argue for this change?
As Matt Olson pointed out, we already reference RACK informationally. We could remove all the references to RACK, but I think that's a separate question? We can more clearly explain what this means or re-instate the reference to RFC4653. TCP has been doing this for a very long time, so I don't think the fact we have limited experience in QUIC is as important. In terms of 'new information', the performance improvement from adaptive packet threshold was measurable for both application latency and by reducing the rate of spurious retransmits. And I finally read the RACK draft and noticed it was a SHOULD there. The original intent was to change a MAY to a SHOULD, which is a very small design change, but then I realized the existing text wasn't that clear, so I tried to improve it. We have to do another round of consensus calls in the next few weeks, so though this change is very small, it seems like the right thing to do to me.
I understand that this might have performance benefit that is worth exploring further. I question the need for doing it at this late stage, given that we will find more and more things that help with performance as we gain further experience with the protocol. RACK is currently an informational reference, meaning that it is not required reading for an implementer.

This change would make it a normative reference, and we don't have such dependencies on any TCP document at the moment. (I see that F-RTO is listed as normative, but it isn't really, I'll send a PR to fix that.) This isn't a small change because just changing a MAY to a SHOULD isn't enough. We cannot change a "MAY adapt" to a "SHOULD adapt" without saying exactly what "SHOULD adapt" means for an implementer. At a minimum, this requires changes to the text and to the pseudo-code that include a precise description and an algorithm for adapting. (The RACK draft suggests one, but again, it's not clear to me whether that one is what we should be recommending. I want to try it out for sure though.) On TCP's experience with this: While I understand that RACK has been deployed for a few years, I don't believe we know how much improvement this specific part of it brings, especially given the DSACK dependency in TCP (Praveen can perhaps shed some light on DSACK deployment at clients, but ... this isn't my central argument.). If there is public information about this, I would love to look at it to have a better understanding.
I still intend RACK to be an informational reference(PR uses a ?, not a !), not normative. The intent was to update from an older informational reference(TCP-NCR) to a newer one. This mechanism was deployed in Linux long before RACK. It seems your point is that by changing from MAY to SHOULD, that puts a requirement upon us to fully describe the algorithm in text and pseudocode? I don't see that as a hard requirement, and as you can see in my PR, I didn't intent to do that.
Does it need to be normative at all? What about simply noting that adaptive strategies such as X, Y, and Z have proven to be useful in TCP, and would apply equally to QUIC?
NAME Sure, that could work.
That works for me too, thanks!
My thinking is that "adaptive strategies" would not only "apply equally to QUIC" but be "significantly more important for QUIC". Operators are aware of the havoc that excessive reordering in their networks causes to TCP and have deployed middle boxes for restoring TCP ordering in such networks.

Such network "optimizations" are not possible with QUIC, so QUIC will see more TCP reordering. We've seen such extreme reordering of QUIC in production.
NAME that's a good point. Do you think it warrants adding a statement like "Re-ordering could be more common with QUIC than TCP, because network elements cannot observe and fix the order of out-of-order packets."?
NAME I like this.
NAME do you have a reference of those data? It'd be good to understand how the reordering pattern looks like in the production network.
NAME The public data on this can be found in . Take a look at red "below the line" red dots on the graphs. At the time we thought the red dots represented loss in our observer infrastructure, but additional analysis after the IETF meeting confirmed that the signal was mostly due to very high reordering (more than 31 subsequent packets arrive before an older packet has arrived).

30 packet reordering certainly happens, though it is quite rare. Some other MAPRG I'll update the PR to point out that UDP reordering may be more prevalent, but not add any new normative statements.
Thanks, NAME We were deliberately focusing data collection on both "boring" and "interesting" network locations to get a wide range of scenarios.