Variable packet dependency chains

[supahero1]

Hello,

I'm using MsQuic with WebTransport for a browser game. After giving it some
thought, I came to the conclusion that the best course of action for me would
be to separate absolutely crucial data, like information about entities being
created or deleted, from data that the client doesn't need to receive instantly
(as in, I don't want to delay the crucial data if this is lost mid flight), like
color information.

The perfect solution would be to "link" crucial packets in a chain with each
other, which corresponds to simply sending them over the same reliable stream,
and then "link" every non crucial packet to it's crucial partner, so that it's
received after the depedency arrives (the crucial packet), but does not delay
other crucial packets, since it's not linked with them in a dependency chain.

I'm yet to figure out if there's any native support from QUIC or MsQuic for that
scenario, or what API enables that. Thus, I came up with a workaround, which
consists of creating a second reliable stream for non crucial packets, and then
buffer them client-side until their respective crucial partner arrives.

Is there any way for me to realize my original idea without this workaround?

Cheers,
supahero1

[nibanks]

I'm using MsQuic with WebTransport

I'm curious if you built this yourself or are getting it from somewhere. I've had others ask for WebTransport and I'd like to be able to help them too.

separate absolutely crucial data, like information about entities being created or deleted, from data that the client doesn't need to receive instantly

This sounds like you want priorities. MsQuic has priorities (not well tested tbh, but should work) at the stream level (QUIC_PARAM_STREAM_PRIORITY). So if your data is on separate streams you can set a higher priority for your crucial data.

I'm yet to figure out if there's any native support from QUIC or MsQuic for that scenario, or what API enables that.

Streams are really light weight. While I'm not as familiar with the WebTransport layer/API, at the MsQuic/QUIC layer you can create new streams as you see fit (even per "link" in the chain). For example, when we measure "requests per second" with MsQuic, each request/response is a single bidirectional stream. We're able to generate over a million per second, back and forth, in our setup.

[supahero1]

Hi, thanks for the response.

I was struggling with WebTransport for the last 5 days or so. 5 days ago was
when I figured out it even existed. So then I had to pick a C QUIC library, and
MsQuic turned out to be my favourite. I got the library to work straight away
with the amazing API documentation you guys have. After that, I tried looking
for some WebTransport projects here on GitHub, but all I found were some very
outdated Go libraries, so I went ahead and read the HTTP/3 RFC 9114 as well as
the WebTransport RFC Draft 05 (officially known as draft02) to come up with some
of my own code. Honestly I couldn't care less about all of the cool things one
can do with HTTP/3, so I went straight for it and hardcoded the packets to send
back to complete the WebTransport handshake, because I don't really care about
checking the headers, anyone can forge them anyway. You only need to send back 2
packets - settings, and the HTTP/3 response, which has to include the specific
header "sec-webtransport-http3-draft: draft02". You also have to enable datagram
support, enable the CONNECT protocol (which is now implicit by default I think),
allow at least 3 unidirectional streams from the client for the needs of HTTP/3
as well as one bidirectional for the request&response exchange, and you are
ready to go. After the scary HTTP/3 stuff is out of the way, the draft says only
DATA frames are permitted, so things get significantly easier and manual parsing
can commence. For each stream that is created, WebTransport sends 3 bytes which
indicate if the stream is supposed to be uni or bi directional, which I find
strange, since QUIC already takes care of that, but whatever. After these 3
bytes, only raw data is received. No shiny package like with WebSockets, no
masking, none of the annoying things.

I wrote a small C program utilizing the nghttp3 C library to help me create the
appropriate packets for settings and the HTTP/3 response indicating WebTransport
support. Currently this hardcoded approach works wonders on Chromium. Firefox
is working on upgrading their outdated, as of now, implementation to the newest
draft02, so I couldn't test my stuff with it. I suppose if one wants more fine-
grained control over the HTTP/3 handshake process of setting up WebTransport,
they could use nghttp3. I think it's the only working HTTP/3-only C library out
there. I did try using it alongside MsQuic, but it seems like they don't really
like each other. I was getting browser errors about invalid responses all the
time, so I just decided to go for the big cheese and get straight to the point.

This works for me, but might not for others. I don't have the need of checking
request headers at all, because I can dispose of bots and annoying people with
my application protocol, which I suspect will be quite a tough challenge for the
unexperienced. If anyone wishes, I can also send my C code for generating the
appropriate packets, so that one can set their own settings and headers. Also
note that my send-back HTTP/3 response was fortunate enough to not include ANY
of QPACK encoder data, so I could ditch that as well, but it wouldn't be hard
even with one, since you just create another unidir stream and send the data.

Regarding the stream priority - what's the default value? The Settings.md file
doesn't specify it, so I can only assume "0".

Also, I'm not sure I understand. If I set higher stream priority for the crucial
data, and then proceed to "quic->StreamSend()" the crucial and non crucial data,
do I have the guarantee that the higher priority one will be sent out first, or
does it also mean the crucial one will arrive first too?

I've also read some of other issues starring you in the replies talking about
streams being very lightweight, which I believe, but I don't know if it's that
useful, since from my understanding, you are getting rid of any dependency
chains, so the packets can arrive in different orders than they were sent in
originally. Or do streams get ordered as well on the QUIC layer? That would
totally make sense then.

Cheers,
supahero1

[nibanks]

MsQuic turned out to be my favourite. I got the library to work straight away with the amazing API documentation you guys have.

Thanks a ton! We work hard on it and it's great to see feedback like this!

I tried looking for some WebTransport projects here on GitHub

While I don't have a WebTransport project (yet) I do have an HTTP/3 one built on MsQuic: https://github.com/nibanks/msh3. It's mostly a side project atm, but I'd like to make it official. If someone was able to either add WebTransport or build it on top of this, that would be amazing...

Regarding the stream priority - what's the default value? The Settings.md file doesn't specify it, so I can only assume "0".

The default is 0x7FFF. From msquic.h:

#define QUIC_PARAM_STREAM_PRIORITY                      0x08000003  // uint16_t - 0 (low) to 0xFFFF (high) - 0x7FFF (default)

do I have the guarantee that the higher priority one will be sent out first

Yes. MsQuic simply has an ordered list of streams to be sent at any time. It uses this priority to sort that list. For things that have the same priority, it's FIFO.

I don't know if it's that useful, since from my understanding, you are getting rid of any dependency chains, so the packets can arrive in different orders than they were sent in originally.

I'd suggest that anything group of data you want to be organized together and arrive in a particular order be put on the same stream. If the data is independent, but it on separate streams.

[supahero1]

Alright, thanks, I will definitely try to tweak the priorities and see what good
I can do with them.

I did in fact see your HTTP/3 C repo during my research, but I immediately left
it after seeing that "TODO" under the "Server" section, haha. I don't really
have time to play around with the game, I want to create IT, not an HTTP/3
server, so I first went for ready solutions that would shave off heaps of time
from the development of something I don't really care about, and once it became
clear that's not going to cut it, I just hardcoded 2 arrays, always send them
over the newly created server connection, and WebTransport is done, without even
a trace of HTTP/3, kind of like what I used to do for WebSockets too. I would
say this is even funnier and better than if I had used an actual HTTP/3 library.
The hacky ways are always ones I'm the most indulged in, even more if they work.

For now, that's the end of the road. Thanks for the replies. Stay safe.

[nibanks]

The TODO server is just a documentation "todo". The server side is supported.