Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MsQuic – QUIC Implementation from Microsoft

github.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: MsQuic – QUIC Implementation from Microsoft

#71

Post by nibanks »

profquail wrote: post #65
slowstart wrote: post #4

Please 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...

Have you considered implementing any parts of this in F* (so they can be verified) and extracting back to C, as is being done for TLS? https://project-everest.github.io/

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.

Re: MsQuic – QUIC Implementation from Microsoft

#72

Post by nibanks »

slowstart wrote: post #11
tialaramex wrote: post #9

Earlier quoted context omitted.

Any strong reasons you chose C? Maybe I skimmed too quickly but I didn't see this mentioned in that blog post. Was there a requirement from other teams?

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

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 C++ features were available, especially in an open source environment, where not everyone is familiar with Windows kernel.

As far as what we do to keep quality high, we have a large number of automated test (> 4000 cases per CI run) automated on Azure Pipelines. Our code is deployed on several interop servers used to test with all the other QUIC implementations out there, and we do additional testing and fuzzing internally at Microsoft.

Re: MsQuic – QUIC Implementation from Microsoft

#73

Post by nibanks »

chaz6 wrote: post #37
slowstart wrote: post #4

Please 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?

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 libraries (schannel, openssl, mitls).

Re: MsQuic – QUIC Implementation from Microsoft

#74

Post by gnulinux »

snarfy wrote: post #69
gnulinux wrote: post #64

Earlier quoted context omitted.

I'm just waiting for the sine curve to come down again. Companies who can change from that to this in 10 years because FLOSS became hip and popular, can change the other way around if it increases their profits.

I don't think that will happen as long as Satya is driving.

Maybe, maybe not. CEOs are replaceable as well. But if the society is dependent on Microsoft, we will remain dependent even after Satya. Look, I'm not trying to preach anything. I love this MS as much as the next guy. It's just useful to think that companies can change both ways because ultimately what a company wants is to maximize profits, it's naive to think MSFT is trying to accomplish anything other than this. It's useful to think this for the long-term picture.

Re: MsQuic – QUIC Implementation from Microsoft

#75

Post by fulafel »

dochtman wrote: post #58
tialaramex wrote: post #54

Earlier quoted context omitted.

QUIC outsources this part of the solution to TLS (specifically TLS 1.3) so you just need a way to meet your needs in TLS 1.3 and it'll work in QUIC

Though it has been discussed that future versions of QUIC might allow other authentication/encryption protocols. Noise would be an interesting candidate.

Note that TLS doesn't necessarily imply certs either. TSL-PSK, TLS-SRP, anon DH, etc.

Re: MsQuic – QUIC Implementation from Microsoft

#76

Post by Matthias247 »

JamesNK wrote: post #39
Matthias247 wrote: post #35

Earlier quoted context omitted.

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…

A headers frame before content is just equivalent so „sending headers“, since Http/2 also only allows to send headers once per Stream unless those are informational headers. In the same fashion, sending a headers frame after content is equivalent to „sending trailing headers“ - which are allowed to be sent at most once after the body (which may be empty).

Therefore the fact that there is a frame involved doesn’t really matter.

HTTP/3 doesn’t change the HTTP semantics: Peers are sending 0-N informational headers, 1 set of request headers, a stream of body data, and 0-1 set of trailing headers. Therefore gRPC should run fine over it at long as the underlying HTTP library exposes all those necessary features.

Re: MsQuic – QUIC Implementation from Microsoft

#77

Post by skyde »

slowstart wrote: post #4

Please 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 this be integrated in some rpc framework like gRPC we all can use ?

Re: MsQuic – QUIC Implementation from Microsoft

#78

Post by skyde »

slowstart wrote: post #4

Please 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...

is this using BBR congestion algorithm ?

Re: MsQuic – QUIC Implementation from Microsoft

#79

Post by nibanks »

skyde wrote: post #78
slowstart wrote: post #4

Please 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...

is this using BBR congestion algorithm ?

Not yet. BBR is on the TODO list though.

Re: MsQuic – QUIC Implementation from Microsoft

#80

Post by catalin_hritcu »

profquail wrote: post #65
slowstart wrote: post #4

Please 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...

Have you considered implementing any parts of this in F* (so they can be verified) and extracting back to C, as is being done for TLS? https://project-everest.github.io/

Some work on verifying QUIC packet encryption using F* is happening at Microsoft Research: https://github.com/project-everest/everquic-crypto
Post reply on HN