QUIC is now RFC 9000

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • Scout APM - Less time debugging, more time building
  • msquic

    Cross-platform, C implementation of the IETF QUIC protocol.

    > Every app has to implement it itself

    No? I'll just link against one of the cross platform libraries that implements it, the same as for any other networking protocol. (Ex https://github.com/microsoft/msquic)

    Also see: https://github.com/quicwg/base-drafts/wiki/Implementations

    > same as for TLS, making fewer apps implement it without a lot of extra work

    ... do you not just link against a relevant networking library at this point? If not, why?!

  • base-drafts

    Internet-Drafts that make up the base QUIC specification

    IETF work is conducted mostly on email lists, hence the "many thousands of emails".

    For some newer work like QUIC, GitHub is used to maintain a more to-the-minute shared view of the documents, and then again as mentioned in the text you quoted, GitHub Issues and PRs are used to manage the document, particularly by the most active participants.

    https://github.com/quicwg/base-drafts - of course raising issues or PRs for them now won't do anything useful for you, because these RFCs were published. But you can see there were thousands of commits, one of the last being Martin Thompson's minor typographical tweaks summarised as "DOES IT NEVER END?!?".

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • openmptcprouter

    OpenMPTCProuter is an open source solution to aggregate multiple internet connections using Multipath TCP (MPTCP) on OpenWrt

    I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance.

    [1] https://www.openmptcprouter.com/

  • quicly

    A modular QUIC stack designed primarily for H2O

    Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully but I got illegal instruction segfault when executing cli.

    https://github.com/h2o/quicly

    There are a few Rust alternatives for QUIC. Anyone tried them and have comments.

    https://github.com/cloudflare/quiche

    https://github.com/quinn-rs/quinn

    https://github.com/mozilla/neqo

  • quiche

    🥧 Savoury implementation of the QUIC transport protocol and HTTP/3

    Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully but I got illegal instruction segfault when executing cli.

    https://github.com/h2o/quicly

    There are a few Rust alternatives for QUIC. Anyone tried them and have comments.

    https://github.com/cloudflare/quiche

    https://github.com/quinn-rs/quinn

    https://github.com/mozilla/neqo

  • quinn

    Async-friendly QUIC implementation in Rust

    Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully but I got illegal instruction segfault when executing cli.

    https://github.com/h2o/quicly

    There are a few Rust alternatives for QUIC. Anyone tried them and have comments.

    https://github.com/cloudflare/quiche

    https://github.com/quinn-rs/quinn

    https://github.com/mozilla/neqo

  • neqo

    Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully but I got illegal instruction segfault when executing cli.

    https://github.com/h2o/quicly

    There are a few Rust alternatives for QUIC. Anyone tried them and have comments.

    https://github.com/cloudflare/quiche

    https://github.com/quinn-rs/quinn

    https://github.com/mozilla/neqo

  • SonarLint

    Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.

  • shadowsocks-rust

    A Rust port of shadowsocks

    2) Even if you use other bonding mode that can spread the flows over several network interfaces, you'll get low throughput due to the aforementioned reordering and also due to the congestion control, more on that below.

    Bonding works well when you have several "equal" links, which is not the case with LTE, where the speed may be quite different across the links and also vary with time.

    Last but far from least, there is congestion control mechanism which is present both in QUIC and (MP)TCP, which makes sure the transfer is as fast as possible without harming other connections on the same link(s). This mechanism as it is used in QUIC and plain TCP is not very good at handling multiple aggregated unequal links, so no matter which way you do the aggregation on L2 (bonding) or L3 (things like glorytun), the performance is going to be suboptimal.

    What MPTCP does is establishing a separate subflow (think TCP subconnection) for each of the available paths, with its own separate congestion control, and spreading the main flow over multiple subflows byte-by-byte in an optimal way. This gives maximum possible utilization of all of the available links, and prevents the congestion in an optimal way, too.

    [1] https://shadowsocks.org/

  • sctp

    A Go implementation of SCTP

    I am sure there are even more implementations that I am not aware of.

    * https://github.com/pion/sctp

    * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct...

    * https://source.chromium.org/chromium/chromium/src/+/main:thi...

    * https://github.com/sctplab/usrsctp

    People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new.

    I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

  • aiortc

    WebRTC and ORTC implementation for Python using asyncio

    I am sure there are even more implementations that I am not aware of.

    * https://github.com/pion/sctp

    * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct...

    * https://source.chromium.org/chromium/chromium/src/+/main:thi...

    * https://github.com/sctplab/usrsctp

    People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new.

    I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

  • usrsctp

    A portable SCTP userland stack

    I am sure there are even more implementations that I am not aware of.

    * https://github.com/pion/sctp

    * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct...

    * https://source.chromium.org/chromium/chromium/src/+/main:thi...

    * https://github.com/sctplab/usrsctp

    People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new.

    I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

  • openssl

    TLS/SSL and crypto library with QUIC APIs (by quictls)

  • wg-materials

    Agenda, Minutes, Presentations

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts