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.] Routing improvement taking into account links bit-rate
Date: Sat, 7 May 2011 19:33:18 +0200	[thread overview]
Message-ID: <201105071933.19780.lindner_marek@yahoo.de> (raw)
In-Reply-To: <BANLkTi=jP-N9wR2TMdB6oDEZcLVpROndUg@mail.gmail.com>


Hi,

> I have called the new metric PCE (Physical Capacity Estimation), which
> is defined for each path as the minimum value of (tq_local * bit-rate)
> among all the link forming it.
> 
> After a quick and dirty modification of the code, I've done some test
> on two simple topologies to verify whether there is an improvement or
> not. From this preliminary test seems that the improvement is
> remarkable.

thanks for posting your paper. I have a few remarks:

* You claim that route flapping degrades performance more than once in your 
paper without providing detailed explanations. Do you have further proofs / 
observations why and how route flapping leads to performance degradations ? In 
your test setup the performance penalty comes from the fact that a suboptimal 
path is chosen, not because the route changed. You would need to equally good 
paths to test the performance influence of route flapping.

* The concept of attaching all hops and their information to the OGM brings us 
dangerously close to the problems other routing protocols suffer from 
(especially Link State): The more a node is away from the source the more its 
information are outdated. Imagine a 10 hop path - how can we rely on this 
information at the end of that path ? Furthermore, by making a decision at the 
end of the path it does not mean the next hop (which has newer information) 
agrees with us on that path. It might send it the packet somewhere else. 
All that depends at which point the bandwidth influences the routing decision. 
Do you mind providing a more precise example how the route switching happens ? 
I hope you thought about loops..

* Taking throughput into the routing equation is an old dream that often 
clashes with reality. Any idea how to solve the following real world issues: 
- Different drivers have different bit-rate APIs (the mac80211 stack is 
supposed to address that but we are not there yet).
- Bit-rates are not a fixed value either - mistrel for example maintains a 
table of 3 different bit-rates. How do you obtain one value ? What about the 
other bit rate algorithms ?
- How to handle interfaces that have no bit-rate (VPN / cable / etc) ?
- Bit-rates are a best guess too which might drop rapidly as soon as you try 
to actually use the link.

Regards,
Marek

  reply	other threads:[~2011-05-07 17:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-07  8:54 [B.A.T.M.A.N.] Routing improvement taking into account links bit-rate Daniele Furlan
2011-05-07 17:33 ` Marek Lindner [this message]
2011-05-08  8:15   ` Daniele Furlan
2011-05-08 12:55     ` Andrew Lunn
2011-05-08 14:55       ` Daniele Furlan
2011-05-08 13:28     ` Marek Lindner
2011-05-08 15:12       ` Daniele Furlan

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=201105071933.19780.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