Item — HN Reader

I still don't quite understand why Cloudflare is going their own way rather than joining our Rust implementation (https://github.com/djc/quinn). So far the primary maintainer told me "I quite like how quiche has turned out, and we already started integrating into internal stuff", which I haven't found very satisfying.

Perhaps they just want to strategically own their own stack, but it seems to me aligning with the broader Rust ecosystem and getting features for free from the community would also bring some value.

Initially I thought it was mainly about integrating with BoringSSL rather than ring and rustls, but even the promise of pluggable crypto didn't seem to affect their decision.

Would be nice to have more clarity on this.

(Previously they were happy enough to use Quinn for their Noise experiment, although without crediting our project explicitly in the resulting paper.)

5 comments

Fundamentally, we wanted an interface to QUIC that we could integrate with our existing server systems. Our servers, naturally, have their own methods of handling a wide range of things like: socket addressing; events state; memory management; TLS handshake processing; request and response processing; and we needed our QUIC implementation to be as independent of these notions as possible. Looking at a library like quinn and some other QUIC implementations, we see that these APIs are tied to many of these external notions, and specific implementations of these notions for that matter, one example being the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.

It was obvious from our experience with our first QUIC proof of concept, and from our evaluation of options for our continued QUIC offerings, that existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.

I'm one of the engineers working on QUIC projects at Cloudflare.

This response from jgrahamc just came to my attention. His comments are based on a discussion I had with him about our first QUIC project and then additionally what I knew of quinn. I described how quinn was arranged and that it provided an interface that was oriented towards the tokio IO library. What I seem to have failed to communicate was the IO specific interfaces were not the only interfaces provided by quinn, and that more abstract interfaces do exist. This mistaken impression seems to have been bundled with the multitude of reasons that we did not choose various other QUIC implementations.

I'm sorry that this this mischaracterisation was made against your work, and hope anyone reading this thread does not take away the same impression.

Thank you for openly discussing this. Ralith has mostly responded in terms of the API our quinn-proto offers; it seems like you and/or ghedo may have missed that?

I just also wanted to respond to this:

> nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.

I have a pretty different perspective on this: I've offered opportunities for collaboration from the moment ghedo started quiche in his free time, and explicitly offered to make changes to quinn{,-proto} to be able to do the kind of things that you might need when it was clear Cloudflare would be adopting quiche as well.

As an example, I mentioned making our TLS implementation pluggable, something we started doing anyway over the past week (see https://github.com/djc/quinn/pull/211 and https://github.com/djc/quinn/pull/218).

Thanks for the details!

> the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.

This isn't accurate. The core protocol objects in Quinn are those defined in "quinn-proto", which has absolutely no awareness of how I/O is performed or what event loop is in use: the interface is structurally very similar to Quiche's, with the caller providing data/timeouts by any means and consuming events that result. See https://docs.rs/quinn-proto/0.2.0/quinn_proto/struct.Endpoin... for details.

The high level "quinn" crate interface, which incorporates awareness of UDP sockets and the tokio event loop, is strictly an optional binding; that's why it's a separate crate.

> existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.

Support for this type of flexibility, up to and including allowances for a C API suitable for integration with existing software, has actually been an express design goal of Quinn from the start, and I regret that that wasn't clear.

There are lots of possible reasons.

* They may not like your design choices

* They may not want to be too dependent on outside maintainers

* It may be a poor fit for the rest of their infrastructure

* They may just not like you

> Would be nice to have more clarity on this

They almost certainly do not want to get into a possible public argument and hounding them for answers will have nothing but the opposite effect. Large companies have their own way of doing things and what you or I think is irrelevant.

We are more than happy to get into why we made quiche but the main developer is away and I'd like him to respond. So, we'll have to punt until he's available.

^ parent is CTO of CloudFlare, for those who missed it.

This.

We need more community/company interaction in Rust, especially in the networking space, instead of parallel implementations.

Disagree. This happened with tokio, the most used crate that provides an execution runtime for futures for async programming, and it's fucking awful to use. But, the community rallied behind it and is now stuck with it for better or for worse. There's been barely any effort to provide any documentation, even recently the main developer pawned it off to be crowdsourced and it really shows.

So yea, give me choices.

I used to think that as well, but sometimes different projects have different priorities or philosophies. In that case, you can either be the jerk who complains about free open source code you didn't pay for, try to bend the project to your will and probably fail, or roll your own.

Companies like to own the code they rely on. The more they rely on it, the less they want anyone else to have control over it.

Also Rust being a relatively new and cool language developers just can't resist building something new with it.

I certainly don't think anyone is required to join another implementation.

Definitely not! I'm merely stating that there would be advantages from pooling efforts, and that I haven't seen a compelling reason not to do so.