4g consumption when used as backups

[pablodnaarg]

Hi!

First and foremost, excellent work on this project.

I am using OpenMPTCProuter for a streaming operation of approximately 12 hours.

I would use an ADSL or Fiber Optic ISP as the primary (master) and five or more 4G/LTE modems as backups.

The idea is that if the primary connection fails, the streaming would continue seamless thanks to OMR's link aggregation.

My question is, do the modems consume data inevitably during the period they are "inactive," due to sending redundant information, or do they only consume data when they are actively used? Has any testing been done on this? Is there any calculation I can use to estimate consumption?

Is there anything else I should keep in mind for an operation like this?

Thanks!

[vempire-ghost]

If you set the 4G links with the backup flag, even if you use the redundant scheduler (only available in kernel 5.4), the OMR will not transmit data through the link unless the others fail. However, keep in mind that there may be a delay between the main link failure and the path manager directing traffic through the backup.

Still, there will be some data consumption on the link. In my configuration, I keep one link as a backup, and it consumes a few MB even if it hasn't been effectively used because it needs to establish the subflow and maintain it, which generates some minor traffic, but it doesn't reach 1% of the amount transmitted on the main connection.

[pablodnaarg]

If you set the 4G links with the backup flag, even if you use the redundant scheduler (only available in kernel 5.4), the OMR will not transmit data through the link unless the others fail. However, keep in mind that there may be a delay between the main link failure and the path manager directing traffic through the backup.

Still, there will be some data consumption on the link. In my configuration, I keep one link as a backup, and it consumes a few MB even if it hasn't been effectively used because it needs to establish the subflow and maintain it, which generates some minor traffic, but it doesn't reach 1% of the amount transmitted on the main connection.

Hello! Thank you for such a prompt response. I am not aware of the "redundant scheduler". I don't know which version of the Kernel I am using (I am on a Raspberry Pi 4). What are its benefits?

I understand what you're saying, and I ask you: is there a way to configure one or more of the backup links to work at the same time as the main link, to avoid such "jump"? Obviously, knowing that this modem will consume the same amount of data as the main one.

Since I'm here, I also ask if there is any specific guide on the modes of OMR. To be honest, I'm a bit lost with the terminology of the options that appear. I understand "Master" and "Backup", but the other options I do not.

Thanks!!

[vempire-ghost]

You can see the Kernel version on the dashboard screen in this line here.

If you're using Kernel version 6.1, you'll only have the option of the default scheduler; the redundant option is only available in version 5.4. The configuration you exemplified can be done precisely with the redundant scheduler. All the links you set as Master or Enabled on the MPTCP screen will send data simultaneously, thus consuming equal bandwidth on each link. The packet that arrives first is used, and the others are discarded. This ensures that if one connection fails, another one is sending data simultaneously. As for the links defined as Backup, they will remain idle until all the other links become unavailable. Only then will they start transmitting data.

Configuration for redundant scheduler.

Here you configure your connections as enabled or backup.

Remember that in this mode, each connection will carry all data redundantly. So, if you transfer 1GB, 1GB will be transferred on each connection that is set as Enabled or Master.

If you don't have data consumption issues and want to ensure the highest possible resilience, this is the best option. However, if you need to save data or don't mind a small delay (less than 2s), and your primary connection is stable, I recommend using version 6.1, which is more current.

[pablodnaarg]

I don't want to abuse your patience in responding. I would like to ask a couple more questions:

Does the kernel version refer to the version installed on my router or on the server?

You set WAN 1 as Multipath TCP "Disabled" in LAN. I do not see that option on mine.

With Kernel 5.4, could I use both options if I wanted to? Could I choose the Redundancy + Data Consumption configuration, or the backup option with minimal consumption and a micro-cut of approximately 2 seconds? Right?

What does "AP" refer to in the Multipath TCP dropdown menu?

Thanks!!

[vempire-ghost]

Both OMR and VPS need to use the same kernel version. If one is 6.1 and the other is 5.4, MPTCP will not work.

You can configure the MPTCP options on this screen, but LAN will always be disabled by default.

Putting it into Spanish, I noticed that the "Master" option in some situations appears as "AP," so it seems they are the same thing, just a translation discrepancy.

[pablodnaarg]

Thanks! You were very helpfull and now i have a clear visión of how to set my OMR.

El vie, 12 de abr de 2024, 8:37 p. m., vempire-ghost < @.***> escribió:

Both OMR and VPS need to use the same kernel version. If one is 6.1 and the other is 5.4, MPTCP will not work.

You can configure the MPTCP options on this screen, but LAN will always be disabled by default. image.png (view on web) https://github.com/Ysurac/openmptcprouter/assets/132581535/bef7e7ff-5503-4217-884f-def5192b2ff2

Putting it into Spanish, I noticed that the "Master" option in some situations appears as "AP," so it seems they are the same thing, just a translation discrepancy.

— Reply to this email directly, view it on GitHub https://github.com/Ysurac/openmptcprouter/issues/3270#issuecomment-2052697299, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHO5YQ3EBQDJDIMAQRLITP3Y5BV2LAVCNFSM6AAAAABGE2YQC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJSGY4TOMRZHE . You are receiving this because you authored the thread.Message ID: @.***>

[github-actions[bot]]

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