Path Selection in OpenMPTCPRouter: Master vs. Backup

[Raquel1L]

Hello there!

I have a question about how OpenMPTCPRouter manages path selection between paths designated as master and backup. Could you clarify how the designation of a path as master or backup influences the scheduler's decision-making process?

For instance, when the master path (wan interface) experiences greater congestion than the backup, with the backup path (usb interface) offering slightly higher or more stable bandwidth, does OpenMPTCPRouter immediately redirect traffic to the backup path (considering I am using a scheduler that prioritizes throughput), or does it continue to prioritize the master path until it is nearly failing or loses connectivity?

Thank you for your assistance.

[vempire-ghost]

Based on my experience, when the backup is selected, the scheduler will only route traffic through it if all other paths are unavailable. Even if the other connections are poor, as long as they are still able to transmit data, the backup will not be used. Only when they completely fail will traffic be transmitted through the backup until the primary connections are restored.

Unless you have a significant monthly bandwidth limitation, I don't find using a backup to be very useful.

[Raquel1L]

Thank you so much for your reply!

I appreciate the information, but I'm still a little confused about this situation.

I tested all the schedulers in version 59.1-5.4 of openMPTCProuter.

The redundant and round-robin (RR) schedulers operated correctly by using both the master and backup paths equally. This suggests they ignore the designated master or backup roles.

However, the Earliest Completion First (ECF) and the Blocking Estimation (BLEST) schedulers, which are expected to select the path optimizing throughput and minimizing delay, respectively, did not behave as anticipated. Despite the backup path having better conditions, only the master path was selected for data transmission.

This outcome was unexpected, as the behavior of the redundant and RR schedulers indicated that the master and backup designations should not influence path selection. I am trying to understand why the ECF and BLEST schedulers did not follow this pattern and chose only the master path.

[datapharmer]

Redundant I'd expect to use both - round robin not so much. I'd say if anything is working incorrectly it is RR as the backup generally shouldn't be used except during a down route condition. If you want 'poor conditions' to be considered then using the lowest latency may help or you can treat 'poor conditions' the same as 'down route' by setting additional checks under OMR-Tracker > interface > check link quality

[Raquel1L]

Thanks for the clarification. Can you tell me if the practice of using the backup path only when the master path fails is based on the MPTCP guidelines or is it specific to openMPTCProuter implementations?

[Ysurac]

Backup path are used only when all other path fails. Master path is specific to OpenMPTCProuter, it's the default gateway (in the future name master will be removed to only set a default gateway that can have multipath enabled or not)/

[datapharmer]

So determining if the master path is down or not is determined by OMR-Tracker which would make the route unavailable and override any general routing rules/schedules - functionally the same thing as yanking the plug out. As far as route scheduling when it is up from what I see in the MPTCP documentation and from the developer comment on backup here: https://github.com/Ysurac/openmptcprouter/issues/601 I'd expect the backup to never be used except if the primary subflows are all down - it's possible redundancy is an exception to this but I can't say for sure. If you are seeing otherwise it is likely a bug.

[Raquel1L]

Considering that the master path is always selected by default in the openMPTCProuter implementation, unless it is disabled, how do the schedulers manage path selection under these conditions?

[Ysurac]

Default scheduler is based on latency. Lower latency first.

[datapharmer]

The scheduler wouldn't use the backup at all unless the master is down. If you want the route used for MPTCP select it as enabled, not as backup.

[Raquel1L]

To ensure that both routes are actively used by MPTCP, considering only the scheduler's decisions, should I configure one route as master and the other as active, instead of backup in the openMPTCProuter configurations?

[vempire-ghost]

Thank you so much for your reply!

I appreciate the information, but I'm still a little confused about this situation.

I tested all the schedulers in version 59.1-5.4 of openMPTCProuter.

The redundant and round-robin (RR) schedulers operated correctly by using both the master and backup paths equally. This suggests they ignore the designated master or backup roles.

However, the Earliest Completion First (ECF) and the Blocking Estimation (BLEST) schedulers, which are expected to select the path optimizing throughput and minimizing delay, respectively, did not behave as anticipated. Despite the backup path having better conditions, only the master path was selected for data transmission.

This outcome was unexpected, as the behavior of the redundant and RR schedulers indicated that the master and backup designations should not influence path selection. I am trying to understand why the ECF and BLEST schedulers did not follow this pattern and chose only the master path.

Strange, I’ve been using the redundant scheduler for years with one of the connections in backup mode, and no data is transmitted through it unless the other connections have failed.

To ensure that both routes are actively used by MPTCP, considering only the scheduler's decisions, should I configure one route as master and the other as active, instead of backup in the openMPTCProuter configurations?

Yes, if the goal is to use all connections based on which one is performing best, it's best to keep all of them active. If the goal is resilience over speed, then using redundant mode is good, but you lose the ability to combine speeds with that approach.

[Raquel1L]

Understood, thank you everyone for your assistance!

[Raquel1L]

I apologize for any inconvenience, but I encountered an issue after setting both paths to active, with no designated master. However, after saving the settings, the wlan interface automatically defaults to master, while the other remains as active. Is this behavior expected, or might it be a bug?

Additionally, even under these settings, the system behaves similarly to a master-backup configuration, seemingly overriding the scheduler's decisions.

My goal is for the openMPTCProuter to operate strictly based on the scheduler's decisions, without path roles influencing its behavior. Could you suggest a solution to achieve this?

[datapharmer]

you need to have a master interface configured for it to work, so if you don't set one it will set one for you. How the master is determined under advanced settings.

Do you have the VPS configured? How are you determining that both paths aren't being used? If you don't want the traffic bonded and just want it balanced by a scheduler, then this isn't the project for you - consider openwrt with mwan3 instead.

[Raquel1L]

I'm currently trying to evaluate the impact of different schedulers on MPTCP performance, using both WiFi and 5G. Could you clarify the role of OpenMPTCPRouter in this context? Specifically, if it doesn't handle scheduling decisions, why are scheduling options available and is it possible to configure them?

[kevinh-csalabs]

wifi isn't recommended for lan as the latency is very inconsistent and packet loss is higher etc. you should really try to use a wired connection if at all possible. WIth both 5g and wifi SQM is likely to have a bigger impact than the scheduler selected but default or fast shouldb e fine. I'm not sure if all are tested at this point or not tbh. Congestion control probably has a bigger impact - many have luck with cubic (default) or bbr. Others may be good under different conditions but probably not for 5g/wifi.

If you aren't testing under a load or able to somehow replicate specific packet loss/latency conditions it will be hard to evaluate. There are a lot of variables there but my suggestion would be to find something with performance you find acceptable and don't try to over-tune things if they are working for you!