Is HTTP3Datagram a layering violation?

[marten-seemann]

I started thinking about logging protocols building on top of HTTP/3, such as the various MASQUE flavors and WebTransport.

Keep in mind that a single QUIC server can support multiple of these protocols, even on the same connection: In principle, you could proxy using CONNECT-UDP and serve a WebTransport session at the same time.

This leads us to the question who's logging HTTP3Datagram events:

• Is it the HTTP/3 layer? If so, how does the HTTP/3 layer which application protocol is running on top of the HTTP stream that the datagram was sent / received for?
• Is it the application layer? First of all, this seems wrong, since there might be buffer of received datagrams, leading to delayed logging of that datagram. Second, what if the datagram is never consumed (e.g. the WebTransport session might have closed)?

I'm wondering if we should remove the extensibility of HTTP3Datagram. The HTTP/3 layer would simply log that a DATAGRAM with a respective Quarter Stream ID was received. The application layer would then log further details about that datagram, e.g. the Context ID in the case of MASQUE.

[LPardue]

I dont think it's any more a layering violation than RFC 9297 is. QUIC DATAGRAMS just contain a payload with no demultiplexer. HTTP/3 datagrams are the object that defines the quarter stream ID occurs at the start of the datagram payload.

What protocol is running on any given stream doesn't seem that important. Similar to how we log request or response headers and data without caring what HTTP semantics they are expressing.

[marten-seemann]

I dont think it's any more a layering violation than RFC 9297 is. QUIC DATAGRAMS just contain a payload with no demultiplexer. HTTP/3 datagrams are the object that defines the quarter stream ID occurs at the start of the datagram payload.

This far, no disagreement. Of course the HTTP/3 layer should log the Quarter Stream ID.

My concern is regarding the datagram payload (i.e. HTTP3Datagram), which is currently logged at the HTTP/3 layer, although it is a property of the application layer.

[LPardue]

Oh I think i understand what you're saying, the _created and _parsed event captures the quarter stream ID and then what is the purpose of HTTP3Datagram, since those events have their own raw field.

Are you bumping into this due to the capsule work?

I suspect the current design of HTTP3Datagram was an attempt to try and capture the generic HTTP datagram semantic. But I tend to agree that is presently confusing. Probably easier to just remove it as you suggest.

[marten-seemann]

Are you bumping into this due to the capsule work?

Specifically, I started thinking about qlog support for CONNECT-UDP, and was trying to figure out how I would log the context ID.

I suspect the current design of HTTP3Datagram was an attempt to try and capture the generic HTTP datagram semantic. But I tend to agree that is presently confusing. Probably easier to just remove it as you suggest.

We might want to introduce a DATAGRAM_id (similar to the datagram_id we have at the QUIC layer), to make it easier to follow the path of one DATAGRAM through the stack (from QUIC DATAGRAM -> HTTP/3 DATAGRAM -> MASQUE DATAGRAM). And yes, naming things is hard...