- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 22 Jun 2021 15:58:41 +0100
- To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, QUIC WG <quic@ietf.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, MASQUE <masque@ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
- Message-ID: <CALGR9oZOp5YWMWx61Etq42McOi02LOjxtRLL+xHhDpHKS94ukA@mail.gmail.com>
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 >> >
Received on Tuesday, 22 June 2021 14:59:28 UTC