Prioritizing QUIC DATAGRAMs (was: Re: [Masque] Prioritizing HTTP DATAGRAMs)

Hey Spencer,

Spinning out a new thread that I think is most suited to the QUIC WG.

On Tue, Jun 22, 2021 at 2:57 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Lucas,
>
> On Tue, Jun 22, 2021 at 8:40 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> Hello HTTP and MASQUE,
>>
>> Over the last couple of months, the question about prioritization with
>> respect to HTTP DATAGRAMs has come up first in MASQUE issue # 46 [1] and
>> then HTTP issue #1550 [2], which was also discussed during the recent HTTP
>> interim.
>>
>> Extensible priorities is pretty far along it's journey, which has so far
>> been focused on HTTP message content (and CONNECT tunnel data, see PR #1544
>> [3]). The scheme fulfills the needs of the base HTTP/2 and HTTP/3
>> specifications, and so far hasn't considered extensions. Extensible
>> priorities acts as a replacement for HTTP/2's prioritization scheme, while
>> being the only known scheme defined for HTTP/3. However, there is nothing
>> to prevent alternate schemes being defined or used in the future (although
>> we hope the need for that can be avoided by the extensibility here).
>>
>> Endpoints that send DATAGRAM flows concurrently with other flows or
>> streams have to make scheduling decisions. Therefore, the question about
>> how to prioritize them, and to communicate that via signals, is a good one.
>> However, currently the editors of draft-ietf-masque-h3-datagram and
>> draft-ietf-httpbis-priority (disclosure: I am co-editor on both) feel that
>> linking these two drafts directly is not the best approach for either.
>>
>> On draft-ietf-masque-h3-datagram issue #46 [1], we resolved the
>> discussion by adding text to say that prioritization of HTTP/3 datagrams is
>> not defined by the document.
>>
>> For draft-ietf-masque-h3-datagram issue #1550 [2], the proposed
>> resolution is PR #1559 [4]. The PR adds a clear statement that the document
>> is focused on HTTP content and CONNECT tunnel data. It also makes clear
>> that extensions like DATAGRAM can also use the scheme but punts that to
>> their court.
>>
>> Kazuho and I are seeking some feedback for PR #1559 [4] before landing
>> it. We appreciate that this leaves a gap for DATAGRAM priorities,
>> especially since DATAGRAM says nothing. But the thought process is that
>> another Internet-Draft could fill this gap. This would create an indirect
>> relationship that would allow documents to progress independently. I'm
>> planning to start a draft soon and have it ready by IETF 111. Which WG it
>> should belong to is probably another matter for debate.
>>
>
> What follows is certainly off-topic for HTTPbis, and probably for MASQUE
> as well, but if it's worth talking about, you'd know better where we should
> talk about it.
>
> I believe that
> https://datatracker.ietf.org/doc/draft-hurst-quic-rtp-tunnelling/ was
> bumping up against the desire to use QUIC datagrams for tunneling and the
> recognition that we don't have an agreed-upon way to multiplex (and
> demultiplex) datagrams that are carried in the same QUIC connection.
>
> Do you see any connection between prioritizing datagrams and
> multiplexing/demultiplexing datagrams?
>

Speaking personally. Yes there is a connection. But it only really matters
where there is competition for resources, which typically manifests when
things occur concurrently.

draft-ietf-quic-datagram calls these entities and says [1]

If the application protocol supports the coexistence of multiple
entities using datagrams inside a single QUIC connection, it may need
a mechanism to allow demultiplexing between them.

This really means the problem of defining the demultiplexing is left
as a job to the application,
if it needs it. And I think that is the correct choice because, as
we're finding out in
HTTP/3 DATAGRAM, we're evolving our understanding of demultiplexing requirements
within the context and constraints of HTTP.

I don't know if draft-ietf-quic-datagram needs to say anything
specific about prioritization.
Maybe it could crib some test from RFC 9000 Section 2.3 [2], so that
people builiding
DATAGRAM-based applications are aware of the considerations.

Cheers,

Lucas


[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram#section-5
[2] https://www.rfc-editor.org/rfc/rfc9000.html#section-2.3



>
> Best,
>
> Spencer
>
>
>> Cheers
>> Lucas
>> Wearing co-editor hat for HTTP/3 DATAGRAM and Extensible priorities
>>
>>
>> [1]
>> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/46
>> [2] https://github.com/httpwg/http-extensions/issues/1550
>> [3] https://github.com/httpwg/http-extensions/pull/1544
>> [4] https://github.com/httpwg/http-extensions/pull/1559
>> --
>> Masque mailing list
>> Masque@ietf.org
>> https://www.ietf.org/mailman/listinfo/masque
>>
>