"cross-platform" software that only runs on Linux and Windows.
It's MIT licensed, you can port it instead of complaining.
MsQuic – QUIC Implementation from Microsoft
31–40 of 87 posts
Re: MsQuic – QUIC Implementation from Microsoft
#32Please fire away any questions you may have! I lead the team that built this library. This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...
Will BBR congestion control be supported? Without it QUIC performance cannot match that of TCP, in my environment at least.
Re: MsQuic – QUIC Implementation from Microsoft
#33Will there be a Python binding?
Re: MsQuic – QUIC Implementation from Microsoft
#34MIT licensed cross-platform C. Ten years ago I wouldn't have believed it. Today it's not even surprising. I really like this version of Microsoft.
I'm with you on the licensing side.
But C? come on Microsoft.
Re: MsQuic – QUIC Implementation from Microsoft
#35Earlier quoted context omitted.
Sorry, this might be a bit off topic but it's something I've been excited about for a while. From what I've heard Microsoft is sort of getting behind gRPC. Have you tested using QUIC as a transport layer for the gRPC client/server libraries that MS maintains? Are you seeing notable performance benefits with QUIC as the underlying channel?
I'm from the .NET Core team and we've looked at it a little from the HTTP/3 angle but not from a pure QUIC angle. This is because the gRPC RPC protocol is described in terms of HTTP/2 frames today.
gRPC encoded data is actually not tightly coupled to HTTP/2 frames. It's described as a stream of gRPC chunk encoded data on top of a HTTP stream. But the gRPC frames do not necessarily have to align with HTTP/2 data frames boundaries.
See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2....
The specification makes gRPC sound rather tightly bound to HTTP/2 level details, but I don't think it really is. You should be able to speak gRPC just fine over any kind of HTTP. One main pain point for browser support however had been APIs to exchange trailers, which are necessary for gRPC.
Re: MsQuic – QUIC Implementation from Microsoft
#36The feature I most want in a new network protocol is multipath to enable seamless and automatic connection migration between wifi and cellular. I haven't been following QUIC standardization, is that feature in now or postponed to the future?
Connection migration is part of the current Internet-Drafts. The generalized support for multi-path (i.e. usage of more than one path at the same time) is postponed to a future version of the protocol. You can follow the standards work here: https://quicwg.org/
Good to hear, but it seems like using both paths at the same time would be necessary for connection migration to work well, as you're often not sure which connection is actually better. If you have to wait until you're completely sure one connection is gone before switching wholesale to the other, that removes a lot of the benefit of connection migration.
Re: MsQuic – QUIC Implementation from Microsoft
#37Please fire away any questions you may have! I lead the team that built this library. This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...
Will you add support for boringssl?
Re: MsQuic – QUIC Implementation from Microsoft
#38Why everyone is making their own QUIC implementations. There are so many already https://en.wikipedia.org/wiki/QUIC#Source_code
Re: MsQuic – QUIC Implementation from Microsoft
#39Earlier quoted context omitted.
I'm from the .NET Core team and we've looked at it a little from the HTTP/3 angle but not from a pure QUIC angle. This is because the gRPC RPC protocol is described in terms of HTTP/2 frames today.
gRPC encoded data is actually not tightly coupled to HTTP/2 frames. It's described as a stream of gRPC chunk encoded data on top of a HTTP stream. But the gRPC frames do not necessarily have to align with HTTP/2 data frames boundaries. See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.... The specification makes gRPC sound rather tightly bound to HTTP/2 level details, but I don't think it really is. You…
> gRPC encoded data is actually not tightly coupled to HTTP/2 frames.
The headers frame, and the capability to have headers before AND after content is a requirement. gRPC requires trailing headers for the status code of the call. Trailing headers frame is a new concept in HTTP/2.
gRPC-Web supports HTTP/1.1 and browsers. It is able to do that by encoding the status into the end of the response body. However gRPC-Web is a different spec.
If HTTP/3+QUIC supports the same features of HTTP/2 then gRPC should work on it. There might be a HTTP/3 specific spec for details around the management of a HTTP/3 connection, but gRPC headers, message content, and proto contracts shouldn't need to change. Take what I say with a grain of salt because I haven't looked closely at HTTP/3+QUIC yet.
Re: MsQuic – QUIC Implementation from Microsoft
#40Why everyone is making their own QUIC implementations. There are so many already https://en.wikipedia.org/wiki/QUIC#Source_code
Possibly the result of an industry scarred by the experience of depending on a TLS library that everyone thought was secure because “hey everyone is using it”. Now they want to make sure they understand and control critical security infrastructure.
Multiple implementations of a protocol are by no means a bad thing. The opposite is a problem - too few implementations means that the implementations dictate the spec and creating something compatible requires implementing bugs of those implementations too.
That said, I’d be surprised if we still had this many implementations 5 years from now. I think at least some of those will become unmaintained and instead use what Google/Microsoft/Mozilla/Cloudflare have developed.