Hello,
Am 04.01.2013 um 19:25 schrieb Jan Lühr:
> 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
> TQ is above TQ-GC-Thresh
> Switch gateway to a worse class, if all existing gateway of same or better
> class have TQ < GC-TQ-Thresh
Switch gateway to a worse class, if TQ is xx times better - imho there is no
reason to stick at a unreachable but fast gateway. TC-GC-Thresh just prevents
using big gateway with worse TQ.
But we can argue about that.
Keep smiling
yanosz
