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

  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