Prioritizing HTTP DATAGRAMs

[Lucas Pardue <[e-mail]>]

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.

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