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

From: John Scudder via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 18:47:42 -0800

John Scudder 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:
----------------------------------------------------------------------

As a rank QUIC neophyte my ability to offer serious technical review of this
document is limited at best. However I do have a few questions that (in the
best case) might reveal lacunae that experts overlooked but which trip up a
neophyte, or (in the worst case) only my own ignorance.

1. In the Motivation section you write,

   *  Applications that open both a reliable TLS stream and an
      unreliable DTLS flow to the same peer can benefit by sharing a
      single handshake and authentication context between a reliable
      QUIC stream and flow of unreliable QUIC datagrams.  This can
      reduce the latency required for handshakes.

This threw me off, considering that in the previous section (Introduction) you
point to UDP/DTLS as a prior way of providing a similar service. In the
quotation above it seems as though you’re using them synonymously… or something.

TBH, I just don’t follow what the quoted text is getting at. :-( I do get (in a
general way) that QUIC makes use of (parts of?) TLS, but that doesn’t allow me
to make sense of it.

2. You’re inconsistent about whether DATAGRAM frames have a type, singular, or
types, plural. Plural seems right to me, but read on. In §3, you refer to “the
DATAGRAM frame types”, plural. But then in §4 you say that the LSB of “the
DATAGRAM frame type” (singular) “is the LEN bit”. Seems to me you should make
up your mind: either you have two types, 0x30 and 0x31, whose semantics differ
with respect to the Length field, OR you have a single type and a flag.

Really I think you have two types (witness the IANA allocation: two, not one)
and the characterization of the LSB as a flag is just a distraction, I would
remove it. Clearly that doesn’t prevent an implementor from taking advantage of
the structure if they want to, but I think it would clean up some awkwardness
in the prose.

3. Further to that, in Section 4 you say,

               The DATAGRAM frame type takes the form 0b0011000X
   (or the values 0x30 and 0x31).

It took me an embarrassingly long time to recognize that the first form you
list means “binary 0011000x, where x indicates ‘don’t care’”. I suppose maybe I
was slow because we use hex notation all the time in our document set, and
binary notation exceedingly seldom in my experience. Possibly I am the only
person who will stumble on this. But possibly not. In any case if you were to
clean up my “is it one type, or two” complaint by collapsing the waveform to
“it’s two”, this problem would also go away.

4. In Section 5 you say,

   When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD
   deliver the data to the application immediately, as long as it is
   able to process the frame and can store the contents in memory.

Isn’t the final clause in the category of “well, duh”? I mean, is there a
situation in which a QUIC endpoint is *not* able to process the frame or *not*
able to store the contents in memory, but still might be expected to deliver
the data to the application? Seems like that’d be a “no”.

I mean, the remark does no real harm, but why bother stating the obvious?

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 2 Feb 2022 09:49:12 +0000

Hi John,

Thanks for your comments.

> On 2 Feb 2022, at 03:47, John Scudder via Datatracker <[email-masked]> wrote:
> 

The quoted text supposed to mean that when a single application want to use both TLS and DTLS (for whatever reason) flows to the same peer, if done separately, they would need to use two handshake and authentication to make that happen. Where as with the QUIC datagram, as QUIC has already support for stream, you can collapse that two one handshake and authentication context. If this is not clear with the current text that can be rephrased. But I am not sure the introduction text is in conflict with motivation or makes things difficult to understand. 
> the structure if they want to, but I think it would clean up some awkwardness

This specification defines two new DATAGRAM QUIC frame types.
> “it’s two”, this problem would also go away.

“Binary” can be explicitly mentioned here.
> I mean, the remark does no real harm, but why bother stating the obvious?

I actually don’t mind stating the obvious, sometimes I feel that we dont mention the things that we often think obvious and that leads to some misinterpretation based on knowledge and experience of the readers.

---

From: John Scudder <[email-masked]>
Date: Wed, 2 Feb 2022 12:10:47 +0000

> This specification defines two new DATAGRAM QUIC frame types.

Yes, I agree… which means speaking of a “type” (singular) and flag doesn’t strictly make sense. 

Thanks,

—John

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Feb 2022 09:36:38 -0800

Hi John,

Thanks for the review! Responses inline.

> On Feb 1, 2022, at 6:47 PM, John Scudder via Datatracker <[email-masked]> wrote:
> 

A good point! I’ve reworded things to make this clearer (please see https://github.com/quicwg/datagram/pull/78 <https://github.com/quicwg/datagram/pull/78>).

The new text is:

- Applications that want to use both a reliable stream and an unreliable flow
   to the same peer can benefit by sharing a single handshake and authentication
   context between a reliable QUIC stream and flow of unreliable QUIC datagrams.
   This can reduce the latency required for handshakes compared to opening both
   a TLS connection and a DTLS connection.

> the structure if they want to, but I think it would clean up some awkwardness

The one inconsistent spot was the datagram frame definition. I’ve updated it to refer to the singular Type field, which is what STREAM frames do in RFC 9000.

The new text is:

The Type field in the DATAGRAM frame takes the form 0b0011000X (or the values 0x30 and 0x31).
The least significant bit of the Type field in the DATAGRAM frame is the LEN bit (0x01), whic
 indicates whether there is a Length field present: if this bit is set to 0, the Length field is absent
and the Datagram Data field extends to the end of the packet; if this bit is set to 1, the Length
field is present.
> “it’s two”, this problem would also go away.

The text is now consistent with STREAM frames in RFC 9000. Since that uses the same notation, I’d like to keep things aligned.

> I mean, the remark does no real harm, but why bother stating the obvious?

It’s stated because it was a matter of WG discussion, and some people did need to clarify this specifically for implementations. Glad it sounds obvious, but it bears repeating!

Best,
Tommy

---

From: John Scudder <[email-masked]>
Date: Wed, 2 Feb 2022 18:36:53 +0000

> On Feb 2, 2022, at 12:36 PM, Tommy Pauly <[email-masked]> wrote:
> 

Thanks. Clearer now. Agreed that given the “flag” thing is how RFC 9000 does things, consistency is worthwhile.[*]

—John

[*] I can’t resist pointing out that RFC 9000 has three, presumably orthogonal, flags, which means that document’s presentation is clearer that way since it doesn’t have to have a table or something, listing the behavior of the eight different type codes — but in your case you just have one flag so there’s no actual savings in presentation. Still, conceded that taken in context of RFC 9000, your point stands.