Not yet. BBR is on the TODO list though.
Not likely, unless we get a customer ask for it. But when we start accepting external contributions it shouldn't be too hard for someone else to add the support. We already (unofficially) support 3 different TLS…
Just to pile on here, running in kernel mode was the primary reason for using C. Windows kernel does support some limited set of C++ features, but we decided to go with pure C instead because of the confusion of which…
We do work with the Everest team. We have unofficial support on top of miTLS (which they produce). We haven't looked into actually using F* for any of the QUIC code though.
It's definitely on the TODO list. We're looking into it.
Yes, msquic should be a good general purpose transport. We already have usage from SMB (file sharing) and HTTP in Windows. Both are very different and provided good test cases for msquic.
Not yet. BBR is on the TODO list though.
Not likely, unless we get a customer ask for it. But when we start accepting external contributions it shouldn't be too hard for someone else to add the support. We already (unofficially) support 3 different TLS…
Just to pile on here, running in kernel mode was the primary reason for using C. Windows kernel does support some limited set of C++ features, but we decided to go with pure C instead because of the confusion of which…
We do work with the Everest team. We have unofficial support on top of miTLS (which they produce). We haven't looked into actually using F* for any of the QUIC code though.
It's definitely on the TODO list. We're looking into it.
Yes, msquic should be a good general purpose transport. We already have usage from SMB (file sharing) and HTTP in Windows. Both are very different and provided good test cases for msquic.