increase WebTransport error code space

[marten-seemann]

The current draft specifies that there are 256 error codes that applications running on top of WebTransport can use. That's a very small number, and I'm currently struggling with mapping some application protocols onto WebTransport, because this space is way too small.

I'd like to explore if we can increase this space. 16 bit would be the absolute minimum, 32 bit would be nice, but maybe we can even achieve the full 62 bit that QUIC gives us.

The draft says:

Since WebTransport shares the error code space with HTTP/3, WebTransport application errors for streams are limited to an unsigned 8-bit integer, assuming values between 0x00 and 0xff.

There's a few problem with that statement:

• It's questionable if WebTransport really shares the error code space with HTTP/3. Arguably, WebTransport takes over the stream from HTTP/3 after the header of the WEBTRANSPORT_STREAM (for bidirectional streams), and after the unidirectional stream type (for unidirectional streams), although technically the respective frame stretches to the end of the stream.
  • This is even more true once we resolve Stream resets can leave streams half-closed indefinitely #77, such that stream resets wouldn't end up in limbo when reset before the session ID was read by the receiver.
  • This would allow us to use the entire 62 bit space.
• Even if WebTransport did share the error code space with HTTP/3, it's not clear why this would limit it to an 8-bit integer. HTTP/3 itself uses the the full 62 bit space allowed by QUIC, so it doesn't seem excessive to reserve more than 8 bits out of that space for WebTransport. Even if we consumed 32 bits out of that space, this would barely make a dent in the number of unclaimed HTTP/3 error codes.

One thing to keep in mind is that when mapping WebTransport onto HTTP/2, we only have access to 32 bit error code space. It might be desirable to use the same error code space both mappings of WebTransport.

[LPardue]

The QUIC application error code space is shared between stream and connection level errors. Similar for H2 stream and goaway. There's no way to detangle those. The application protocol is H2 or H3, and WebTransport is squatting over the top.

Given that H2 and H3 get by with ~20 error codes each, I'm struggling to understand why something over the top needs more than 256. Grabbing a huge swathe of the available space for WebTransport-only usage can't really be undone. I'd want to see stronger motivation or use cases that cannot be solved some other way by a WebTransport application

[marten-seemann]

The QUIC application error code space is shared between stream and connection level errors. Similar for H2 stream and goaway. There's no way to detangle those. The application protocol is H2 or H3, and WebTransport is squatting over the top.

This is subtle. You can regard WebTransport streams as being layered on top of HTTP/3 streams, or you can view WebTransport as "taking over" an HTTP/3 stream. While the draft in its current form is more likely to be read as the former, I think that most implementations (including my own) implement the latter.

You raise a good point here though. Currently, WebTransport never sets / sends CONNECTION_CLOSE frames, but with the resolution to #89 that I proposed, it would. This would necessitate sharing an error code space with HTTP/3, regardless of your views on layering.

Grabbing a huge swathe of the available space for WebTransport-only usage can't really be undone.

I disagree that taking a 32 bit space out of 62 bits qualifies as a huge swathe. It's roughly 1 billionth of the available space.

Given that H2 and H3 get by with ~20 error codes each, I'm struggling to understand why something over the top needs more than 256.

Happy to give more context here. I'm trying to layer libp2p / IPFS on top of WebTransport, thereby giving browsers an easy option to participate in the network. libp2p / IPFS is composed of a large number (dozens) of sub-protocols that are run on top of streams. Each of these sub-protocols would like have their own error code space. It's really easy to exhaust the tiny space of 256 error codes.

[LPardue]

Thanks for the extra information. Does each sub-protocol use more than 256 errors? If not, and the problem is that the sub-protocols have to share a restricted space, that seems like a problem the libp2p / IPFS mapping can and should solve. E.g you'll know what streams belong to which sub-protocol?

[marten-seemann]

Introducing another mapping layer would complicate things quite a bit. Error reporting and monitoring would be much easier if error code were unique.

I’m not sure how we ended up with 8 bits here, usually IETF protocols that specify a stream multiplexer use a much larger space: 32 bits in the case of H2, and 62 bits for H3.

In my use case, assigning unique error codes would be trivial if the error code space was 32 bit, and probably still doable if it was 16 bit.

As I’ve argued above, there’s no real reason to limit ourselves to 8 bit, given the vast size of the underlying QUIC error code space.

[LPardue]

But earlier we've said that the error space is shared for GOAWAY and CONNECTION_CLOSE. And if WebTransport can be pooled with conventional HTTP/2 and HTTP/3, then there doesn't seem to be anyway to disambiguation the error codes when they are used for that.

[vasilvv]

I agree in general that 8 bits is somewhat suboptimal for application error codes.

Since we're currently trying to figure out how to make sure that resets of WebTransport streams have the session ID associated with them, would it make sense to use the same mechanism to associate an application reset error code as well?

One thing to keep in mind is that when mapping WebTransport onto HTTP/2, we only have access to 32 bit error code space. It might be desirable to use the same error code space both mappings of WebTransport.

Since we're not re-using HTTP/2 streams as WebTransport streams for WT over HTTP/2, the error space there is actually 62 bits as well.

[DavidSchinazi]

Chair: discussed in editor's meeting, we're blocked on the upcoming "reliable reset" draft in the QUIC WG since the details of that will impact what we do here

[marten-seemann]

Why is this blocked on reliable resets? Reliable resets only protect the beginning of the stream, containing the WebTransport session ID. The error code is part of the RESET_STREAM frame, and never serialized onto the stream to begin with.

[DavidSchinazi]

@vasilvv can you answer that please?

[vasilvv]

It's blocked because if we adopt quicwg/reliable-stream-reset#2, we can add the full 62-bit error code into the reset payload; if not, we'll have to find an alternative workaround.

[marten-seemann]

I see, you don't want to use the RESET_STREAM error code. My objection would be that this makes building a general-purpose API very complicated, but let's keep the discussion on that PR.

[DavidSchinazi]

Chair: discussed at IETF 116. Consensus in room to expand the error code space taken by our current “de-GREASE algorithm” from 8 bits to 32 bits, where all values would be in the varint 8-byte portion of the IANA registry.