Maximum datagram size

[martinthomson]

In QUIC, we have the path MTU. We don't have the same in h2, so DATAGRAM capsules can be any size. That's not realistic, so I propose we use a setting to communicate a size limit. There's a bunch of reasons that this is probably not good enough. Mostly, there's no way to ensure that this value accurately reflects the minimum limit that applies to a chain of forwarding hops. That means that an application that really cares will have to do its own probing of the path (and do so continuously, just like with PLPMTUD). But even if this is only used to cap the size to something that is moderately reasonable in terms of memory consumption at the consuming end, we win.

See #123.

[DavidSchinazi]

We would need this for h3 as well, because it's possible to send HTTP Datagrams in capsules over h3 as well

[martinthomson]

For h3, the limits on UDP datagram size ensure that you can limit the HTTP datagram size without this. It's not perfect, but then neither is this. In h2, there's no way to effectively limit HTTP datagram size otherwise. With that in mind, do you think we'd need it in both versions?

[DavidSchinazi]

In h3, HTTP Datagrams can be sent either of two ways:

• QUIC DATAGRAM frames
• DATAGRAM capsules

QUIC DATAGRAM frames are limited in size by the path MTU which should be a sufficient cap for everyone.

DATAGRAM capsules aren't capped though. If we think those should be capped, then we should cap them in both h2 and h3. It would be strange to provide a mechanism for capping it to 2000 bytes in h2 but leave it unlimited in h3.

[LPardue]

I tend to agree with David, I don't like the mismatch between h2 and h3. The use of capsule protocol is a property of the request stream, not a connection. That would imply we should manage datagram sizes at the capsule protocol level (if anything should be done at all). In other words, advertise a datagram capsule limit via a header and allow in-band runtime updates via a new capsule type. That sounds purest but a lot more machinery to add.

If we wanted to pursue that path, we might want to consider to spin it off to an rfc 9297bis (which is an idea we've been tossing about in HTTPbis anyway).

[DavidSchinazi]

Adding a MAX_DATAGRAM_SIZE capsule sounds like an easy fix. The capsule would just contain a varint, and the semantics would be that the sender of the capsule indicates that it will silently drop all received DATAGRAM capsules that are larger than this limit. But yeah that probably doesn't belong in the WebTransport documents.

[martenrichter]

I am thinking of testing it in my implementation, and I am wondering if the flow control window sizes pose a limit that would simply implementations.

[martenrichter]

Here is a prototype implementation for http2:
fails-components/webtransport#375
including a capsule for the value (I need it for my webtransport over websocket flavor).
Also one test is added (inverse direction is missing).
Note, that I included in the server code, code that will reject non stream capsules over a multiple of session window size, as it might be an attack vector.

[martinthomson]

@DavidSchinazi, why do you suggest a capsule? Are you thinking that this needs to be signaled anew for every session? That does address most of the concerns about end-to-end and various dynamics. Should we spin up a new draft just for that?

[DavidSchinazi]

@martinthomson the max datagram capsule size is an end-to-end property of the endpoints (generally based on acceptable receive buffer sizes). Since two capsule requests on the same client---intermediary connection could be handled by two different backends, it makes sense to renegotiate it on each request.

On the topic of where to do this, we could either split it into its own draft, otherwise Lucas and I have been chatting about doing either a followup or a bis to 9297, so we could put this there as well. I'm thinking a 9297bis which adds some new features like this MAX_DATAGRAM_SIZE capsule is probably the best path forward. @LPardue, thoughts?

[martenrichter]

The discussion at W3C looks like they do not care in the moment (see transcript https://www.w3.org/wiki/WebTransport/Meetings2023#WebTransport_Bi-weekly_Virtual_Meeting_#102_late_-_May_20,_2025).

[martinthomson]

That's not how I interpreted that discussion. I suggested that we remove the hard dependency on the protocol gaining a mechanism for signaling this, that's all. This was to allow progress to continue on API specifications, without prejudice to how the protocols continue to evolve. It seems like this is a useful mechanism to be able to signal and @DavidSchinazi's proposal seems like a good way to proceed.

[martenrichter]

Ok, that interpretation sounds better, I am only reading the transcript, and I wanted you to be also aware. And yes, a capsule should work, that's why I made a demo implementation, it should, for most scenarios with proxies, etc, provide a solution.

[DavidSchinazi]

Based on the discussion above, if we solve this we'll want to do it at the capsule layer, so it won't require changes in WebTransport. Based on that, closing this issue with no action.