Hacker News new | ask | show | jobs
by ivan4th 1895 days ago
I have recently improved my rural multi-LTE setup by means of OpenMPTCPRouter [1]. MPTCP does a really great job at aggregating multiple paths for better throughput and reliability. Problem is, QUIC can’t do this, and while multipath QUIC exists [2], right now it’s more of a research project.

I’m afraid I’ll have to block UDP/443 at some point to prevent browsers from downgrading to 1/3 of available throughput...

[1] https://www.openmptcprouter.com/ [2] https://multipath-quic.org/
1 comments
avianlyric 1895 days ago
Why would HTTP/3 not work with OpenMPTCPRouter? Looking at the documentation OpenMPTCRouter makes itself the gateway for you network, so all traffic TCP or UDP will get routed to, and over its multipath network, so UDP packets will be encapsulated in TCP, if your using a TCP based multipath layer.

Then on your VPC the UDP packets will be un-encapsulated and sent on as normal.

link
ivan4th 1895 days ago
There are several possibilities of dealing with UDP traffic in OMR.

1) Multipath VPN (glorytun). Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control. The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.

2) UDP-over-TCP. In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]

[1] https://en.wikipedia.org/wiki/TCP_congestion_control

[2] http://sites.inka.de/bigred/devel/tcp-tcp.html

link