openmptcprouter VS base-drafts

I've been looking at this project for a while which may be interesting to you: https://github.com/Ysurac/openmptcprouter.

I recently bought a property where I cannot get a full fibre connection, but I can get 150-400 Mbps using 5G. I've been thinking about using dual 5G connections and tunneling my traffic via mptcp to a VPS to aggregate the connections.

https://www.openmptcprouter.com/

I mentored the port of MPTCP to OpenWRT years ago, and OpenMPTCPRouter took some of this work in their port.

Something which goes further than this, but works very well for my use case and would probably suit others in the WFH crowd: OpenMPTCProuter [1]

This handles failover between connections and also aggregates them using MultiPath TCP to maximize bandwidth & overall reliability at the expense of increased data usage and the cost of running a machine somewhere with a decent connection, even a cheap VPS.

I'm using it to aggregate ADSL, Starlink and 4G, resulting in a stable 250mbps/50mbps connection.

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

You might want to take a look at https://www.openmptcprouter.com/.

I do the same and for the same reason, but I use https://www.openmptcprouter.com/, which is open source. It's game changing!

If you're looking for a bonded type solution similar to Speedify, I've had good success with a raspberry pi, an inexpensive 10 port gig switch, a DigitalOcean droplet and https://www.openmptcprouter.com/.

I get a VPS, preferably with Debian or Ubuntu and set it up as described here

https://www.openmptcprouter.com/ was the inspiration

Then OP could use OpenMPTCProuter to bond the connection, thus actually getting bandwidth benefits out of the multiple carriers.

QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/

Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.

Server connection migration is explicitly forbidden by QUIC:

https://github.com/quicwg/base-drafts/pull/2031

https://github.com/quicwg/base-drafts/issues/253

TL;DR just like HTTP/2, we wanted to avoid friction in deploying these protocols. Having to rewrite URLs because of new schemes is pretty unpalatable, it has major impact. Instead, HTTP/3 can rely on other IETF-defined mechanisms like Alt-Svc (RFC 7838) and the more recent SVCB / HTTPS RR [1] DNS-based methods. The latter has been deployed on Cloudflare a while [2] and supported in Firefox. Other user agents have also expressed interest or intent to support it.

The net outcome is that developers can by and large focus on HTTP semantics, and let something a little further down the stack worry more about versions. Sometime devs will need to peek into that area, but not the majority.

[1] - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...

After lots of hard work, we're excited to open-source [s2n-quic](https://github.com/aws/s2n-quic), a Rust implementation of the [IETF QUIC protocol](https://quicwg.org/). Feel free to ask any questions here in the comments or by [opening an issue](https://github.com/aws/s2n-quic/issues/new/choose). Thanks!

Maybe check out laminar and quinn, which implement custom protocols on top of UDP (quinn implements QUIC), to get an idea on how to do things.

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