All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.