From: Marek Lindner <lindner_marek@yahoo.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Unterstanding gateway-mode - why do nodes have a "sticky" gateway
Date: Sat, 5 Jan 2013 01:41:04 +0800 [thread overview]
Message-ID: <201301050141.04885.lindner_marek@yahoo.de> (raw)
In-Reply-To: <50E6F17B.1010305@altermundi.net>
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
> One other change that might be interesting would be the addition of a
> setting for how much the advertised throughput affects gw selection.
> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
> do the same on our "main gateway", but maybe it would be better if we
> could actually advertise the real throughput and have a setting to
> control how much the bandwidth difference affects the selection.
Again, feel free to propose something which can be discussed.
Cheers,
Marek
next prev parent reply other threads:[~2013-01-04 17:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-31 1:16 [B.A.T.M.A.N.] Unterstanding gateway-mode - why does node have a "sticky" gateway Jan Lühr
2013-01-01 17:25 ` NicoEchániz
2013-01-02 23:28 ` [B.A.T.M.A.N.] Unterstanding gateway-mode - why do nodes " Jan Lühr
2013-01-03 1:57 ` Marek Lindner
2013-01-03 11:03 ` Jan Lühr
2013-01-03 14:58 ` Marek Lindner
2013-01-03 15:01 ` Jan Lühr
2013-01-03 15:14 ` Marek Lindner
2013-01-04 0:06 ` NicoEchániz
2013-01-04 0:39 ` Marek Lindner
2013-01-04 15:12 ` NicoEchániz
2013-01-04 17:41 ` Marek Lindner [this message]
2013-01-04 18:25 ` Jan Lühr
2013-01-04 18:38 ` Jan Lühr
2013-01-04 23:28 ` NicoEchániz
2013-01-05 4:42 ` Marek Lindner
2013-01-05 9:47 ` Jan Lühr
2013-01-07 15:26 ` Jan Lühr
2013-01-08 6:15 ` Marek Lindner
2013-01-08 16:35 ` NicoEchániz
2013-01-09 6:30 ` Marek Lindner
2013-01-09 11:49 ` Jan Lühr
2013-01-09 17:39 ` NicoEchániz
2013-01-09 22:20 ` Jan Lühr
2013-01-16 1:42 ` NicoEchániz
2013-01-16 11:38 ` Jan Lühr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201301050141.04885.lindner_marek@yahoo.de \
--to=lindner_marek@yahoo.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox