Subject: Murray Kucherawy's No Objection on draft-ietf-quic-datagram-08: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 21:45:16 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-quic-datagram-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3:

* "... transport parameter greater or equal to ..." -- s/greater/greater than/  (two instances)

Section 4:

* I also tripped on the thing John pointed out.

Section 5:

* I don't understand the two SHOULDs in this section.  When/why would you ever do otherwise?

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Feb 2022 07:39:54 -0800

Hi Murray,

Thanks for the review!

> On Feb 1, 2022, at 9:45 PM, Murray Kucherawy via Datatracker <[email-masked]> wrote:
> 

Good point! I’ve opened a PR to fix this nit here:
https://github.com/quicwg/datagram/pull/77 <https://github.com/quicwg/datagram/pull/77>

> * I also tripped on the thing John pointed out.

Thanks. We’ll follow up in the reply to John.

> * 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).

Best,
Tommy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Feb 2022 10:23:26 -0800

Hey Tommy,

On Wed, Feb 2, 2022 at 7:39 AM Tommy Pauly <[email-masked]> wrote:

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

-MSK

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Feb 2022 11:31:22 -0800

> On Feb 2, 2022, at 10:23 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Hey Tommy,
> 
> On Wed, Feb 2, 2022 at 7:39 AM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> Section 5:
>> 
> 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