
Quinn 0.2.0: QUIC protocol implementation in Rust - whoisnnamdi
https://github.com/djc/quinn/releases/tag/0.2.0
======
trishume
I'm really excited about QUIC and Quinn because I think a lot of networking
problems map on to the "many serial streams in parallel" model. QUIC libraries
will make it easier to write those apps than plopping them on top of TCP,
while getting better performance with lower latency.

QUIC makes great progress on so many different networking problems: head of
line blocking, connection establishment latency, connection migration,
multiplexing...

------
bacon_waffle
In case anyone else wasn't familiar with QUIC: it appears to be a Google-
developed protocol that's similar to TCP+TLS+HTTP/2, but lower latency and
with several other advantages, implemented on top of UDP.
[https://www.chromium.org/quic](https://www.chromium.org/quic)

~~~
dochtman
The original version of QUIC was contributed to the IETF by Google, but at
this point many people from outside of Google have contributed. Saying it is
Google-developed is inaccurate at best if you're talking about recent drafts
of the IETF spec.

~~~
mda
Sure, but by far the biggest contributor to the project is Google and it
should take some credit for it.

------
ggm
I maybe have this wrong, but earlier versions of QUIC did PMTU like "tasting"
of the viable MTU inside the protocol to get to big, from small. Thus, working
around the external IP level pMTU blockers.

I think they backed off to a simpler model of just using small inside QUIC.

I kind of liked the former: one day we need to get rid of dependencies on
small packets, and move to Jumbo in the wide.

(dreamer..)

~~~
Ralith
The current draft encourages, but does not require, QUIC implementations to
employ path MTU discovery along those lines; see [https://quicwg.org/base-
drafts/draft-ietf-quic-transport.htm...](https://quicwg.org/base-drafts/draft-
ietf-quic-transport.html#packet-size) for details. Quinn doesn't yet have this
implemented, but it would be pretty cool!

------
gmueckl
I really like the idea of having independent streams in a single connection.
But for some applications I would like to have the ability to have unordered
and optionally unreliable datagram channels in the same conmection as well. I
have my own networking library that does this based on UDP, but I would rather
spend my times on other things than maintaining that.

~~~
petronio
I believe SCTP would fill in for that use case. For server-server
communications there shouldn't be a problem, but I recall there's issues with
client support & firewall rules, and I don't know if that status on that has
changed if you need that. I also recall there being SCTP over UDP, but you
lose some features there.

~~~
90minuteAPI
SCTP over UDP is how WebRTC data channels get their configurable reliability
and ordering.

------
walterbell
Other than Google, who uses QUIC in production?

~~~
baby
Fastly: [https://github.com/h2o/quicly](https://github.com/h2o/quicly)

Facebook:
[https://github.com/facebook/proxygen/issues/127#issuecomment...](https://github.com/facebook/proxygen/issues/127#issuecomment-432457732)

Cloudflare: [https://blog.cloudflare.com/head-start-with-
quic/](https://blog.cloudflare.com/head-start-with-quic/)

Akamai: [https://developer.akamai.com/blog/2018/10/10/introducing-
qui...](https://developer.akamai.com/blog/2018/10/10/introducing-quic-web-
content)

~~~
proyb2
One more missing

[https://www.litespeedtech.com/products/litespeed-web-
server/...](https://www.litespeedtech.com/products/litespeed-web-
server/features/quic-support)

------
bayesian_horse
The problem is not so much the browser implementation, but rather the server
software and network infrastructure like proxies and firewalls. I already ran
into problems with Http 2 or websockets in some cases. QUIC being UDP can only
exacerbate these issues..

~~~
anderspitman
I hear ya, but I'm hopeful this will improve over the next few years as QUIC
gets used more in the wild. It really does bring some nice advantages.

------
mtgx
And here's the (more modern) Noise-based nQUIC version:

[https://github.com/rot256/ninn](https://github.com/rot256/ninn)

~~~
edwintorok
I don't know why you got downvoted, there is a paper about nQUIC [3], "Noise"
here refers to the Noise Protocol[1] and its Rust implementation[2]:

[1] [http://www.noiseprotocol.org/](http://www.noiseprotocol.org/)

[2] [https://docs.rs/snow/0.4.2/snow/](https://docs.rs/snow/0.4.2/snow/)

[3] [https://eprint.iacr.org/2019/028](https://eprint.iacr.org/2019/028)

~~~
tialaramex
> I don't know why you got downvoted

I imagine it got downvoted because it claims an old fork of the same code is
"more modern" because it implements the must less capable Noise as a basis for
QUIC rather than TLS.

We have something akin to CADT in protocol security where a certain type of
person gets very excited about whatever new shiny thing they're convinced will
fix everything and so they want to see it replace everything else immediately,
no questions asked. Recently that's Noise.

Good news for people actually doing serious security engineering with Noise:
In a few years these people will move on to whatever new thing is hot and
leave you behind. Bad news: They will say everything you've done is crap when
they do.

~~~
mtgx
I mean the protocol is the more modern version.

Less capable as in "fewer ways to hit yourself in the foot by forcing you to
use secure cryptosystems", then sure.

WhatsApp and Wireguard have been using Noise for a couple of years now.

------
dogecoinbase
Remember: [https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-
mobi...](https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-
desktop/)

 _In fact, our experiments showed that QUIC always consumes more than half of
the bottleneck bandwidth, even as the number of competing TCP flows
increases._

------
rapsey
Are there any numbers out there how often 443 udp is blocked on wifis?

~~~
LeonM
Why would this port be blocked?

~~~
pingiun
On public wifis they might not want you to do anything weird, so they block
everything except "web ports", i.e. 80,443/tcp

~~~
rapsey
And dns 53/udp otherwise you do not get far.

~~~
icebraining
Sometimes that's blocked too, you're forced to use the local DNS server, which
is the only one authorized to access port 53/udp out.

------
the_other_guy
is GQUIC going to be supported by Envoy any time soon?

------
eeZah7Ux
A reusable library in C would be more useful.

~~~
jononor
You could put a C inferface on top of this. Especially the quinn-proto is
suitable for this, as it does no IO on its own.

------
mbgaxyz
Tangential point... is it accurate for the project to describe itself as a
"pure-Rust implementation of the QUIC protocol" when it uses platform
dependent unsafe code?
[https://github.com/djc/quinn/blob/ce514af89a73f530e1366e79e5...](https://github.com/djc/quinn/blob/ce514af89a73f530e1366e79e5819008ef666648/quinn/src/platform/cmsg.rs)

~~~
wmf
That's still Rust code.

(And speaking as an outsider, arguments about purity seem like the last thing
Rust needs.)

~~~
richardwhiuk
Knowing whether something just links in a C library and adds a wrapper, and
how thick that wrapper around it is useful in knowing how ergonomic the API
will be, and how easy it is to cross target.

For example, if you want to run on musl with a statically linked libc, then a
library which is just a wrapper around a C shared library which depends on
glibc is a non starter.

