I reviewed the spec and makes sense to have this kind of QoS feature in the code.
But IMO the spec is adding an extra complexity in the L3 agent code (for example, FIPs for groups of addresses), instead of handling the problem from the QoS perspective.
Although this is something that should be tested first, I suggest to use the tc-ct module. That means, the traffic control conntrack module to handle marked traffic. My suggestion is to mark the traffic (an IP or a group of them), mark this traffic a tracked and then apply a different filter in the interface qdisc.
As said, this is just an idea and should be tested first. But this architecture does no need the use of FIPs or additional GWs.
Hello:
I reviewed the spec and makes sense to have this kind of QoS feature in the code.
But IMO the spec is adding an extra complexity in the L3 agent code (for example, FIPs for groups of addresses), instead of handling the problem from the QoS perspective.
Although this is something that should be tested first, I suggest to use the tc-ct module. That means, the traffic control conntrack module to handle marked traffic. My suggestion is to mark the traffic (an IP or a group of them), mark this traffic a tracked and then apply a different filter in the interface qdisc.
As said, this is just an idea and should be tested first. But this architecture does no need the use of FIPs or additional GWs.
Regards.