[olsr-dev] Suggestion: more integration layer 2

[Aaron Kaplan]

I know this is against the nice clear separation of networking layers
but...

If we know which routes will generate which RF interference (=same  
channels)
then the "take the route which is fastest but generates the least  
channel blocking"
approach might be interesting. It will allow for better link  
utilization.

For example:

I have a route

A --> channel 1 --> B ---> channel 6 ---> C   (throughput: 1 mbit + 1  
mbit)

   and a route

A --> channel 11 ---> X --> channel 10 ---> C (throughput: 2 mbit + 1  
mbit)

Clearly the first route is better. Even though the second route looks  
better from the perspective of A it is not. Because re-transmission  
at point X slows down A.
Like this: A sends packet to X with 2 mbit. X retransmits, next  
packets collide at
A->X and need retransmission. A->X will be limited by X->C to 1mbit  
anyway _and_ the packets will collide.

So the first route should be preferred IF the total throughput will  
be better.
So the question i guess would be: how can layer 2 give meaningful  
hints to layer 3?
Layer 3 can listen to these hints or not. These hints could be  
flooded so that each node knows the SNR of each other node / link.

Overhead:
Let's estimate that the average edge degree is 10 (20 if you count  
directional edges)
I.e. each node "sees" on average 10 other nodes.
Each node floods these SNR/channel/ssid infos to all other nodes
That flooding info makes (n = number of nodes):
n * 10 * (sizeof(float) + sizeof(char) + sizeof(int))
approx = n * 10 * 16 bytes.

So for a network of 1000 nodes that is 156kB of data that needs to be  
flooded per interval. Quite ok i guess (?)

What can you do with that info?
enhance Dijkstra so that alternate channels (with best SNR) are  
preferred.
I don't have a metric for it yet but maybe a simple weighted sum of  
interesting factors is enough.

just my 2 cents + interested in feedback,
aaron.

PS: the second wish that i have is to send out in parallel.
If there are parallel routes, let's use them. Did somebody research  
into max flow calculations?



On Jan 5, 2006, at 11:17 AM, Bernd Petrovitsch wrote:

> On Thu, 2006-01-05 at 09:19 +0100, Andreas Tønnesen wrote:
> [...]
>> IMO the configuration file you link to is a bit more trivial than the
>> olsrd config file. In our config we have multiple grouped  
>> "subsections"
>> (such as all the per interface options, plugins with parameters  
>> etc.). The
>> way I see it implementing all these options as command line  
>> options will
>> make for a rather big and messy CLI :-)
>
> Yes, and the fun starts if you have more than one interface to be used
> with/by OLSRD.
>
> 	Bernd
> -- 
> Firmix Software GmbH                   http://www.firmix.at/
> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>           Embedded Linux Development and Services
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>