Hello,
Am 04.01.2013 um 18:41 schrieb Marek Lindner:
On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
Selection class 3 and beyond do change the gateway when a better one becomes available. But as you correctly pointed out these selection classes don't consider the announced bandwidth for the simple reason that nobody cared. In most wireless scenarios (the main playground for batman-adv) the path towards the gateway turned out to be more critical than the gateway's pipe to the internet.
Feel free to propose something if you care about having this option. The necessary code shouldn't be too hard to add. Backward compatibility will be more difficult to achieve.
I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again.
If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time.
You misread my statement. Nobody needs to be convinced of the usefulness of such a feature (at least for what concerns myself). Somebody needs to come up with a solid proposal which then needs to be implemented. That is what I meant by saying "Feel free to propose something [..]".
Note that switching immediately as soon as a better gateway comes around isn't the best solution. Imagine a case in which a gateway announcing the highest bandwidth in your network barely is visible for your gateway client. It will keep switching between gateways, thereby breaking all your stateful connections such as: ssh, vpns, video & music streams, etc
Thanks for being open minded. Imho there are a few "tweaks" for doing so.
For our networks, it's not important, that all clients choose the gateway with the highest data rate. Basically, we have 3 gateway-types -> Regular Gateways, that should be used if they are reachable (above a certain TQ threshold) -> Backup Gateways - Gateways, that should be used if no regular Gateway is available. -> Test Gateways - Just for testing purpose - should be used if no Backup-Gateway is available.
Imho others may have more / or less classes. basically what is needed here is a positive gateway ("route priority") - imho the already existing gateway-class may be used for doing so.
In order to prevent "switching immediately as soon as a better gateway comes around", we may can go this way: gw_mode client may have three parameters: 1st: Switching threshold based on TQ (Like today, eg 20: late switching) 2nd: Switching threshold based on Gateway Class). GC-Thresh 3rd: LQ-Threshold for GW-class-switch GC-TQ-Thresh
Meaning: Switch gateway to same / better class, if there is a Gateway having TQ xx-Times bigger (traditional late switching with xx) Switch gateway to a better class, if a Class is GC-Thresh times better, and LQ is above TQ-GC-Thresh Switch gateway to a worse class, if all existing gateway of same or better class have LQ < GC-TQ-Thresh
However, this is quite complex and I don't know if everybody will be happy with this - However, I'll be so.
For backwards compatibility, old configurations can be detected by counting the number of parameters and react according old defaults.
If you like thinks to be more complex - Different thresholds for blocking DHCPDISCOVER / DHCPREQUEST ;-)
Thanks, Keep smiling yanosz