msquic
msquic copied to clipboard
microsoft
Support ECN on Windows
Describe the feature you'd like supported
Support for ECN on Windows
Proposed solution
This provides similar benefits to using ECN with TCP.
Additional context
msquic.sys will definitely be able to set ECN, but I have no idea if it is possible to set ECN bits from userspace without administrative privileges. In any case, this should be documented.
Is this something that can be done purely in MSquic, or does it need additional changes to Windows?
Edit: If the latter, I can close various feature requests in other QUIC libraries as “can’t fix”.
@DemiMarie-parity this has been on our to do list for a while. Complete support will most likely require some Windows OS changes (which our team owns too) for full user-mode support. We haven't had a chance to completely investigate the required changes to fully support this at the UDP layer yet. We can't make any guarantees on timelines for either the UDP or QUIC layers supporting this, but it's definitely something we'll look into. We'll report back any status updated if/when we have them back on this issue.
@nibanks Is the kernel-mode MsQuic implementation accessible to userspace via an API, and does it have ECN support? If it is accessible, are there advantages to using it over a userspace implementation?
@DemiMarie-parity user-mode and kernel-mode are completely independent implementations. Both instead just rely on the available UDP APIs/layer. Kernel mode drivers that need QUIC rely on msquic.sys and user mode apps/services rely on msquic.dll.
FYI, @Demi-Marie it seems that (though undocumented currently) ECN is working for Windows user mode. I haven't tried kernel mode yet. My latest PR integrates the appropriate usage at the datapath abstraction layer. We still don't use ECN in our congestion controller though.
@nibanks thanks! That should be enough information to implement it for quinn.