Change:
7.9. <del> This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the congestion controller.  Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or another method to limit such bursts to the initial congestion window; see initial-cwnd. </del> <ins> A sender SHOULD pace sending of all in-flight packets based on input from the congestion controller. Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Senders MUST either use pacing or limit such bursts. Senders SHOULD limit bursts to the initial congestion window; see initial-cwnd.  A sender with knowledge that the network path to the receiver can absorb larger bursts MAY use a higher limit. </ins> An implementation should take care to architect its congestion controller to work well with a pacer.  For instance, a pacer might

Discussion:
Also does a bit of cleanup.
NAME : Can you provide some text? Also, shall we make this part of the consensus call?
NAME : I don't think we are missing it. The PR says that you SHOULD pace or limit the burst size to IW at all times. Isn't that what you want -- to limit bursts to IW?
"Implementations MUST either use pacing or another method to limit such bursts to the initial congestion window; see Section 7.2." This precludes use of segmentation offload of sizes greater than IW. Hardware does not pace TSO for TCP or USO for UDP. In datacenters we routinely send bursts that are higher without causing loss. Both Linux and Windows TCP send bursts larger than IW (up to 64k) at higher bandwidths. Higher bursts are required for achieving high data rates. This text should be changed to a SHOULD.
NAME DC requirements are likely to run into more than just this problem -- for instance, the initial window itself might be too small. Since the recovery document was really meant for Internet use, not for DC, I would suggest leaving out DC requirements. Perhaps there's a separate document in order for how to tune QUIC for DC.
As an individual, I agree with Jana. We're not going to be able to ship a specification that is able to accommodate all of the spectrum of network characteristics. The documents should allow implementers to build a QUIC implementation that is safe to deploy on the Internet. As someone less familiar with DCTCP and more general DC considerations, the nuance of making a MUST a SHOULD is likely to be lost on me. A document that takes a more broad look as QUIC in the DC would be super helpful.
Also being discussed
Based on the discussion on the mailing list, I'm proposing that we change the MUST to a SHOULD. See .
Do folks agree with this proposed resolution?
NAME I think it's the right direction, but I'd like to do some more work on the PR. We don't do this, but there is a plan. URL shows the plan that we haven't implemented. The idea is that the TLS stack exports an encryption primitive, which then performs nonce generation within the PKCS module according to the TLS rules. PKCS has the necessary interfaces.

Decryption can't work that way and so doesn't: the caller has to provide the number. I don't know if FIPS insists on anti-replay tracking within the module, but we don't do that (and likely can't).