From: Antonio Quartulli <ordex@autistici.org>
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.] any throughput mechanism or plans?
Date: Sat, 31 Mar 2012 23:43:23 +0300 [thread overview]
Message-ID: <20120331204322.GA31423@ritirata.org> (raw)
In-Reply-To: <CAA_JP8UrWSzLYoUEhrzbT1fjeedp28B0dr7dMB_TizLkr+4RNg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On Sat, Mar 31, 2012 at 04:22:06 -0600, dan wrote:
> I can't see anything in my reading on this.
>
> Is there a mechanism to identify throughput between two nodes? or
> between a client and a destination for the purpose of routing through
> the highest throughput path?
>
> For instance, track the maximum throughput on each interface over
> time. Compare it to the current throughput on the interface and send
> what is leftover as 'available throughput' with the TQ each node. Now
> instead of adding up the numbers as with TQ, just take the min. Take
> the lowest throughput along the path and have a node be able to
> utilize the highest throughput path that has acceptable TQ. As a
> node's interface gets loaded up (vs observed maximum) it will inform
> it's neighbors in the same way it informs them of the TQ of each
> interface and then the neighbors can choose to route around if there
> is a good alternate path.
>
> Basically, I'm thinking that TQ isn't the only or most optimal way to
> route simply because available throughput should be considered
> somehow. As far as I can tell, a 56k link with .001% packet loss is
> better than a 54Mb link with .1% packet loss, though both are solid
> interfaces and the 54Mb link should be prefered heavily over the 56k
> link. The 56k link probably will start dropping packets once it is
> saturated, but one client might run up against slow ACKs keeping the
> remote server from sending enough data to saturate the connection so
> the client could be getting a very slow connection while a 54Mb link
> sits virtually unused.
Hello Dan,
there is not such mechanism in batman-adv right now. It is a really good idea
and we already started to think about that during WBMv5. Personally, I'm
applying to the GSOC2012 and I'm proposing something similar.
I also think that packet loss is not the correct way to go.
Regarding your idea, how would you measure the maximum throughput?
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-03-31 20:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 22:22 [B.A.T.M.A.N.] any throughput mechanism or plans? dan
2012-03-31 20:43 ` Antonio Quartulli [this message]
2012-04-01 2:02 ` dan
2012-04-01 2:39 ` Guido Iribarren
2012-04-01 2:53 ` Guido Iribarren
2012-04-01 2:53 ` Dan Denson
2012-04-01 21:35 ` Marek Lindner
2012-04-01 21:32 ` Marek Lindner
2012-04-01 22:23 ` dan
2012-04-02 9:32 ` Marek Lindner
2012-04-02 13:35 ` dan
2012-04-02 15:29 ` Marek Lindner
2012-04-02 18:21 ` dan
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=20120331204322.GA31423@ritirata.org \
--to=ordex@autistici.org \
--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