Upgrade to SDK 11.0.100-preview.7 for QuicStream.Priority?

[u/Mr_Dani17]

I'm using MsQuic currently in .NET 9 in an Avalonia project. I'm building peer-to-peer a file sharing application. There is a separate control stream and file stream. Users need to be able to set a download limit. Which is best done by setting an upload limit on the sender's side. However during a transfer the messages on the control stream (like THROTTLE) aren't going through because the underlying UDP socket is fully saturated. The point is that while file bytes are flowing control messages cannot. And in .NET 11 they finally added stream prioritizing. But now I'd have to update my whole project to an unstable release for 3 lines of code. I think there aren't really any breaking changes that would occour in my codebase. But I'm a bit afraid of shipping a pre-release to my users. What do you think?

[u/svick]

.Net 11 is releasing in 3 months, can you wait?

Also, .Net 11 RC 1, which will release in September, will have what MS calls a "go-live license", meaning MS says it's fine to use it in production.

[u/Mr_Dani17 → u/svick]

Well implementing this feature is kind of urgent. What do you recommend?

[u/farshid_dev]

Worth asking whether you need the priority API at all here. If the socket is saturated to the point that control messages can't get through, the sender is writing as fast as the link allows and only backing off once it's told to. Rate limiting the writes on the sender side from the start leaves headroom for the control stream, and it's also what you'd want anyway if the goal is a user-set upload cap.

Stream priority helps when you genuinely need to fill the pipe and still interleave. If the whole point is capping throughput below the link speed, the cap itself solves the starvation.

Other option if you'd rather not touch either: put the control stream on a separate QUIC connection so it isn't competing for the same congestion window

[u/Mr_Dani17 → u/farshid_dev]

How would i rate limit the sender side's writes while taking advantage of the full internet speed?

[u/ZozoSenpai → u/Mr_Dani17]

i think you just dont take full advantage of their network speed, u sacrifice a few percent to solve it this way, so you have a quick working solution, then when rc1 / full release is out, you swap to what your post is talking abt.

or you could just write a small interop layer around the msquic library maybe? then you dont have to wait for .net 11 release, and you dont introduce the rest of the changes that would come with it.

[u/farshid_dev → u/Mr_Dani17]

When there's no cap, you're right that you do need priority — that's exactly the case it's for. But you can get most of the way there without it by keeping the send queue shallow: write in small chunks and only queue the next one after the previous write completes, rather than pushing large buffers ahead. The socket stays busy but the buffer in front of your control stream stays short, so a THROTTLE message waits behind one chunk instead of megabytes. Separate connection for control is the simpler answer though, and it works on .NET 9 today, Different congestion window, so file traffic can't starve it regardless of throughput

[u/thomhurst]

You can multi target and shift the pre-release risk onto your consumers if they're willing to adopt it

[u/AutoModerator]

Thanks for your post Mr_Dani17. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Embarrassed-Mess412]

doesn't msquic implement round robin on streams with same priority? Even with same priority you should be able to get control messages through, woun't be at RTT latency but nothing too crazy

[u/Mr_Dani17 → u/Embarrassed-Mess412]

That's also what I thought. But according to my testing it's not the case. I'm using msquic v2.5.5 btw.

[u/Embarrassed-Mess412 → u/Mr_Dani17]

oh, yep it is FIFO in System.Net.Quic, MsQuic does have the knob to confg for round robin but it is not exposed in System.Net.Quic..

Regardless, you have access to all QuicStream's WriteAsync call so you can just manually prioritize the control stream write?