3 ms·

Fundamentally, we wanted an interface to QUIC that we could integrate with our existing server systems. Our servers, naturally, have their own methods of handl

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.

Ralith 8y ago
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.Endpoint.html 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.
dochtman 8y ago
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 https://github.com/djc/quinn/pull/211 and https://github.com/djc/quinn/pull/218 https://github.com/djc/quinn/pull/218).
downsideup 8y ago
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.

Ralith 8y ago

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.Endpoint.html 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.

dochtman 8y ago

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 https://github.com/djc/quinn/pull/211 and https://github.com/djc/quinn/pull/218 https://github.com/djc/quinn/pull/218).

downsideup 8y ago

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.