- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Thu, 25 Jun 2020 20:04:00 +0100
- To: Eric Kinnear <ekinnear@apple.com>
- Cc: Ben Schwartz <bemasc@google.com>, David Schinazi <dschinazi.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CALGR9oZO-FdZouCWkfrnKoATARS6HWBUkCtyS63MG+FGPxB-CA@mail.gmail.com>
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
Received on Thursday, 25 June 2020 19:04:25 UTC