> On Feb 2, 2022, at 10:23 AM, Murray S. Kucherawy <[email protected]> wrote: > > Hey Tommy, > > On Wed, Feb 2, 2022 at 7:39 AM Tommy Pauly <[email protected] > <mailto:[email protected]>> wrote: > >> >> Section 5: >> >> * I don't understand the two SHOULDs in this section. When/why would you >> ever do otherwise? > > I assume you’re referring to: > > "This frame SHOULD be sent as soon as possible...” > > and: > > “...it SHOULD deliver the data to the application immediately…” > > These are requirements that were added pretty early on, given that there was > a lot of discussion around queueing of data and what layer would be > responsible for determining timing. Note that some frame types don’t get sent > “immediately” always (such as ACKs, etc), and there was confusion early on > about if the QUIC layer would be responsible for more scheduling or queueing. > I think it is important to maintain these to be extra clear (although I agree > that they can seem obvious once you’re in the mindset). > > I figured that's probably what you meant, and I don't object to the > requirement, but it might be good for a neophyte reader to have a hint about > when it's safe to deviate from the requirement, maybe (a bit hand-wavy here): > > "This frame SHOULD be sent as soon as possible, subject to queueing and other > priority messages that need handling." > > ...or something.
Sounds good. I’ve made a PR to change this to: "This frame SHOULD be sent as soon as possible (as determined by factors like congestion control, described below)…” https://github.com/quicwg/datagram/pull/79 <https://github.com/quicwg/datagram/pull/79> Thanks, Tommy > > -MSK
