QUIC is now RFC 9000

• msquic

  8 3,272 9.2 C

  Cross-platform, C implementation of the IETF QUIC protocol, exposed to C, C++, C# and Rust.

  

  > 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

  2 1,552 7.7 Shell

  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?!?".

• SonarLint

  www.sonarlint.org

  sponsored

  Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.

  

• openmptcprouter

  54 1,308 7.5 C

  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

  0 547 6.8 C

  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

  11 7,443 7.6 Rust

  🥧 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

  9 2,711 7.6 Rust

  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

  2 1,601 7.2 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

• InfluxDB

  www.influxdata.com

  sponsored

  Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.

  

• shadowsocks-rust

  11 5,771 8.6 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

  0 167 7.8 Go

  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

  3 3,311 5.3 Python

  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

  0 562 6.6 C

  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

  1 264 9.8 C

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

  

• wg-materials

  0 135 0.0 Python

  Agenda, Minutes, Presentations

  

Suggest a related project