Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
openmptcprouter
OpenMPTCProuter is an open source solution to aggregate multiple internet connections using Multipath TCP (MPTCP) on OpenWrt
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
> 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?!
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?!?".
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/
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
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
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
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
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/
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.
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.
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.
