Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS

Lots a food for thought in this thread, I'll pick on one aspect for now:

On Thu, Jun 25, 2020 at 2:52 AM Eric Kinnear <ekinnear@apple.com> wrote:

> I know that one of the reasons to split out into H3 datagrams was to have
> a flow ID present to allow multiple different flows of data to coexist, and
> there was quite lively discussion at the time which was fairly split as to
> the utility vs. dangers of such flow IDs.
>
> The biggest questions in my mind in that area are: How much do we care
> about sharing an HTTP connection that is using HTTP semantics on some
> streams with these other frames? And does that, in turn, mean that we need
> to define HTTP semantics for the datagrams (H3 or H2 or otherwise)?
>
> My personal gut reaction would be (a) yes, we do care and (b) probably not
> necessary as long as we can correctly demux what information is intended
> for what extension/protocol living at the other end.
>

Over on the datagram spec repo [1] we are still discussing the topic of
flow IDs. From that I've been more deeply considering my implementation of
QUIC DATAGRAM and looking ahead to HTTP/3 DATAGRAM, especially how that
layering would work and the API presented by the layers*. So, devil's
advocate, I'm wondering why we need the abstract notion of a flow ID in
HTTP/3 - draft-schinazi-quic-h3-datagram-03 [2] defines the requirement
"Implementations of HTTP/3 that support the DATAGRAM extension MUST provide
a flow identifier allocation service.", which as a library implementer I
struggle to satisfy. It also offers little guidance on things like security
considerations or DoS analysis, which is really where a common definition
would help because it would force the issue of determining if we need to
communicate things such as limiting the number of total concurrent flows,
how to retire a flow etc, how to report limit violations/error, how to
gracefully close an HTTP/3 connection with active flows etc. The closest
parallel for me is HTTP/3's management of server push via push ID, it fixes
an accounting loophole that exists in HTTP/2 and provides explicit guidance
for use with GOAWAY. If HTTP/3 DATAGRAM were to stay generic then IMO it
needs to think about some factors like that. However, if the use of
DATAGRAMs is always required to be defined alongside by an HTTP semantic
then it might be able to play by the rules of that semantic; for example,
consider that we define a tight binding between DATAGRAM and CONNECT-UDP -
an implementation could apply the security considerations and resource
management that it already does for HTTP requests. Thus the number of
concurrent flows is bound by the number of concurrent requests and flow ID
fate fate is tied to request ID fate, which is tied to connection fate.
Furthermore it would support the carriage of per-flow limits expressed as
headers.

So to address the OP, I think we need to fully consider semantics up front:
either true version-independent HTTP semantics or, as the QUIC charter
likes to call them version-specific semantics. The danger is not doing so
is that people start deploying things that we have to retroactively attempt
to describe e.g. "A payload within a CONNECT request message has no defined
semantics;   sending a payload body on a CONNECT request might cause some
existing implementations to reject the request"

Cheers,
Lucas

* in quiche, we present both QUIC and HTTP/3 API layers and document how
applications are expected to use them when using one or both of the layers.

[1] - https://github.com/quicwg/datagram/issues/6
[2] https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-03