Subject: [Masque] Comments on the Interim

From: Martin Duke <[email-masked]>
Date: Thu, 22 Apr 2021 14:40:56 -0700

Hello MASQUE,

After mostly failing to monitor the interim live over a bad phone line, I
was finally able to watch the recording. A few comments/questions as an
individual:

1) I support the consensus to have two layers of identifiers. However, as I
have little grasp of the full range of H3 DATAGRAM applications, I ask if
it is appropriate for both layers to be part of the H3 DATAGRAM, or if the
flow-id/context-id should be specific to streams with CONNECT-UDP? Issue #45
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/45>
implies that the latter might be true.

At the very least, as we've reached apparent consensus here on two layers
in CONNECT-UDP, it would be good to socialize with webtrans and httpbis to
determine general applicability of two labels. If the answer is that it's
not needed, take it out of DATAGRAM.

2) On the unidirectional/bidirectional conversation, I agree with Lucas
that David conflated "unilateral" and "unidirectional" as concepts. I'm
fairly sure we should not do "unilateral" (though if we did, endpoints
would always have recourse to STOP_SENDING the stream). I've filed further
comments in the issue
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/42>.

3) I agree with Jana and others that reliable messages should simply be an
H3 frame (or TLV within DATA frames) in a QUIC stream frame, not something
else that requires a different reliability mechanism.

Martin

---

From: David Schinazi <[email-masked]>
Date: Thu, 22 Apr 2021 18:27:47 -0700

Hi Martin, thanks for your comments! Might I ask you to take a look at
our issue
list
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues>? I
tried to have one issue per topic to avoid fragmentation of the
conversation.

On Thu, Apr 22, 2021 at 2:41 PM Martin Duke <[email-masked]> wrote:

> 1) I support the consensus to have two layers of identifiers. However, as
> I have little grasp of the full range of H3 DATAGRAM applications, I ask if

We shouldn't restrict context IDs to CONNECT-UDP as there are other methods
that will rely on them. For example, CONNECT-IP will.

> not needed, take it out of DATAGRAM.

The existence of a method that doesn't need a feature is not in and of
itself a sufficient argument to remove that feature. The optionality of
context IDs is covered by this issue
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/45>.

> <https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/42>

Perhaps I wasn't clear when I filed the issue. The issue you linked doesn't
discuss consent at all, as that is handled by another issue
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/43>.

> else that requires a different reliability mechanism.

I agree. That said I haven't heard anyone suggest any other option here. I
think in the meeting Jana misunderstood the fact that the RELIABLE_DATAGRAM
frame was an HTTP/3 frame, not a QUIC frame.

David

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Fri, 23 Apr 2021 10:48:47 -0400

On Thu, Apr 22, 2021 at 9:28 PM David Schinazi <[email-masked]>
wrote:

> Hi Martin, thanks for your comments! Might I ask you to take a look at our issue
> list
> <https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues>?
> I tried to have one issue per topic to avoid fragmentation of the
> conversation.
>
> We shouldn't restrict context IDs to CONNECT-UDP as there are other
> methods that will rely on them. For example, CONNECT-IP will.
>
To go further, issue #45 is discussing if we want to allow use cases to opt
into the byte-savings if it knows it will not need a context ID. It is not
specific to CONNECT-UDP, but rather a baseline capability being discussed.
I believe it goes into H3 DATAGRAM.

Sincerely,
-Alex

> .
> Perhaps I wasn't clear when I filed the issue. The issue you
> linked doesn't discuss consent at all, as that is handled by another issue
>> 3) I agree with Jana and others that reliable messages should simply be
>> an H3 frame (or TLV within DATA frames) in a QUIC stream frame, not
>> something else that requires a different reliability mechanism.
>>
>
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 23 Apr 2021 10:54:29 -0400

I'm a strong advocate for making the mechanism optional, but I also think
it'll end up being used by a few applications, so it likely belongs in the
base draft.

If a while from now it becomes obvious this is only needed for a single
other draft, we move it out, but it sounds like there will be at least 2
drafts that use it.

On Fri, Apr 23, 2021 at 10:49 AM Alex Chernyakhovsky <achernya=
[email-masked]> wrote:

>> our issue list
>>> After mostly failing to monitor the interim live over a bad phone line,
>>> I was finally able to watch the recording. A few comments/questions as an
>>> individual:
>>>
>>> 1) I support the consensus to have two layers of identifiers. However,
>>> as I have little grasp of the full range of H3 DATAGRAM applications, I ask
>>> if it is appropriate for both layers to be part of the H3 DATAGRAM, or if
>>> the flow-id/context-id should be specific to streams with CONNECT-UDP? Issue
>>> #45
> To go further, issue #45 is discussing if we want to allow use cases to
> opt into the byte-savings if it knows it will not need a context ID. It is
> not specific to CONNECT-UDP, but rather a baseline capability being
> discussed. I believe it goes into H3 DATAGRAM.
>
> Sincerely,
> -Alex
>
>>
>>
>>> At the very least, as we've reached apparent consensus here on two
>>> layers in CONNECT-UDP, it would be good to socialize with webtrans and
>>> httpbis to determine general applicability of two labels. If the answer is
>>> that it's not needed, take it out of DATAGRAM.
>>>
>>
>> I agree. That said I haven't heard anyone suggest any other option here.
>> I think in the meeting Jana misunderstood the fact that the
>> RELIABLE_DATAGRAM frame was an HTTP/3 frame, not a QUIC frame.
>>
>> David
>> --
>> Masque mailing list
>> [email-masked]