public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
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

  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