UDP Traffic (Gaming)

[unnuetz]

Hi, I am new to the topic and I have some questions regarding UDP traffic.

From what I learned so far, UDP traffic is not aggregated by default because of the limitations of UDP.
I am trying to understand, which line the UDP traffic is handled when I have set up three internet lines.
Can I define that UDP traffic is only pushed through one specific line to the VPS?

In my case, I have 3 internet lines.

One cable line with 30ms latency,
another cable line with 30ms
and one VDSL line with 8ms.

To have a better gaming experience, I would like to only use the VDSL line whenever UDP is used.

Is it a fair understanding, that even UDP traffic will be forwarded to the running vps and this is also the internet breakout point to UDP traffic?

Same questions for ICMP, how would that be handled?

[vempire-ghost]

I use OMR for gaming as well, and I play some games that use UDP. Aggregating the game using xray and the redundant mode works perfectly to create a fully resilient tunnel. I recommend testing this option.
Regarding ICMP, if you have an active VPN, it will always be sent through it. If the VPN is disabled, then OMR will direct it to the master WAN.

[xzjq]

FWIW, "redundant" does not appear to be an option in the 6.1 kernel MPTCP based system, and the 5.4 kernel-based system with the older version of MPTCP is deprecated.

[xzjq]

Perhaps the simplest way to model the default OMR routing is:

1. if the packet from your LAN is TCP, it will be sent via the VPS/MPTCP aggregation.
2. if it is any other type of packet, it is routed by the VPN, which technically can aggregate but ironically can reduce the throughput compared to using your single best WAN (c.f. UDP client traffic exhibits very low performance/does not aggregate #3067).

I get the best performance via only allowing TCP traffic to aggregate, then selecting "none" for VPN (i.e. disabling it), which causes all other traffic to go via my best single WAN which I have selected as master.

BTW, at least for 6.1-based OMR, then regardless of configuration the master WAN is critical. If it goes down, you will lose all internet, even if your other WANs remain online. Bear that in mind when selecting master WAN & planning your UPS/backup generator power configuration.

[vempire-ghost]

FWIW, "redundant" does not appear to be an option in the 6.1 kernel MPTCP based system, and the 5.4 kernel-based system with the older version of MPTCP is deprecated.

In terms of features, the out of the tree version is still much more advanced than the upstream version, even in 6.6, for example, there are no schedulers other than the default implemented in the upstream version.

I don't see any reason to use version 6.1 at the moment because it is just a less complete version, especially for games where speed is not something that is so necessary, but connection resilience is fundamental, and at this point the redundant scheduler is the only way to achieve this .

BTW, at least for 6.1-based OMR, then regardless of configuration the master WAN is critical. If it goes down, you will lose all internet, even if your other WANs remain online. Bear that in mind when selecting master WAN & planning your UPS/backup generator power configuration.

For this issue I made a workaround using a router with load balance and defining my master wan by it, so if a connection drops, it quickly replaces it with another functional one and the omr doesn't even detect that there was a drop.

[ccmks]

For this issue I made a workaround using a router with load balance and defining my master wan by it, so if a connection drops, it quickly replaces it with another functional one and the omr doesn't even detect that there was a drop.

So the topology will be:

Several WANS -----Load Balance Router ------ OMR-----LAN?

If so, how can the aggregate happens with this setup?

[vempire-ghost]

I just applied this workaround for the master WAN; the other WANs still go directly to the OMR.

The topology would be like this for the regular WANs:
WANS ----- OMR ------ LAN "As it usually is."

The topology for the master WAN became like this:
WANS ----- Load Balance Router ------ OMR ------ LAN "Exactly as you suggested, but in this case, the load balancer balances the load of all WANs to the master just to ensure that there is always a path available to initiate a connection."

In this configuration, you have the master WAN as an aggregate of all the WANs you want, and the following WANs being directly connected as it normally happens.
However, this creates a redundancy issue because the same connections would be connected to the OMR twice. I managed to solve this by setting the master WAN with the backup flag. This way, OMR only uses the master to initiate the connection, and as soon as it establishes the connection and subflows, it stops carrying data on the master as long as there is another active and functional MPTCP connection.

But OMR currently does not support by default setting the master WAN as backup. I had to do this by changing some configurations, which worked in my case, but I would not recommend doing it without evaluating the impact on your use case first.

Here the configuration I did:
network.globals.mptcp_force_multipath='0' "Disable the option where OMR actively monitors if the current multipath status matches the one configured in the OMR options. If you don't disable this, OMR keeps changing and removing the backup flag from the master all the time."
*/1 * * * * multipath eth1 backup "And to ensure that the master WAN keeps the backup flag, I configured a cron job with this command to set the backup flag on the master every 1 minute, which in my case is wan1. Even with the configuration network.globals.mptcp_force_multipath='0', OMR will remove the flag in situations where it detects an IP change in that WAN or the addition/removal of the route."

I made a request for the possibility of configuring the master WAN with the backup flag, but Ysurac did not respond whether he could or could not do it. If this configuration were added, I wouldn't have to do all this work above.

[ccmks]

Per my understanding, and also from my experience, if the master WAN went down, the OMR will still work. The only issue I had so far is when the master WAN suffers from degradation, such as packet loss for over 20% which impacting the entire OMR experience.

[Ysurac]

On 6.1/6.6 kernels there is for now a problem when master WAN is down, I'm working on this.
There is, in snapshots, some settings in Services->OMR-Tracker to check link quality that should help to detect when a link is bad.

[vempire-ghost]

Per my understanding, and also from my experience, if the master WAN went down, the OMR will still work. The only issue I had so far is when the master WAN suffers from degradation, such as packet loss for over 20% which impacting the entire OMR experience.

In my daily use on kernel 5.4, when the master WAN has an outage, established connections are not affected, but no new connection can be made until the outage ends.

On 6.1/6.6 kernels there is for now a problem when master WAN is down, I'm working on this. There is, in snapshots, some settings in Services->OMR-Tracker to check link quality that should help to detect when a link is bad.

I tried all configurations in the OMR tracker, and none were satisfactory; the detection was always unreliable. Sometimes it simply doesn't remove the route, and in other instances, it takes minutes to do so. That's why I opted to use specific hardware for this task, and I've had great results since then.

I would just like to request once again the possibility of adding the option for a Master WAN with the backup flag if possible.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days