[Olsr-users] Scaling of olsr with reduced TTL (Aaron Kaplan)

[Andreas Tønnesen]

Did you guys read about ZRP? I don't know if it's still
beeing worked on, but I seem to remember that it had
some interesting points regarding scalability and
using different algorithms/protocols where they are
best fitted.

Here's what I wrote about it all thise years ago :-)
http://www.olsr.org/docs/report_html/node18.html

brg,
Andreas

(spam-protected) wrote:
> Send Olsr-users mailing list submissions to
> 	(spam-protected)
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.olsr.org/mailman/listinfo/olsr-users
> or, via email, send a message with subject or body 'help' to
> 	(spam-protected)
>
> You can reach the person managing the list at
> 	(spam-protected)
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Olsr-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Scaling of olsr with reduced TTL (Aaron Kaplan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 10 Nov 2007 00:18:06 +0100
> From: Aaron Kaplan <(spam-protected)>
> Subject: Re: [Olsr-users] Scaling of olsr with reduced TTL
> To: Jens Nachtigall <(spam-protected)>
> Cc: (spam-protected)
> Message-ID: <(spam-protected)>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
>
> well, dijkstra sort of depends on the whole graph being present, right?
> As opposed to voices in Berlin I however do not believe that this is  
> a bad thing.
> If you calculate how much a 10 000 entry routing table is (in memory)  
> then you find out that it is not so overly much. for IPv6 128 bits, a  
> very rough estimate shows that src,dest,extrainfos (16 bytes x 3) for  
> 10k entries is merely 480kBytes. Nothing. The big issue is how to use  
> scalable algorithms (for example prefix search vs. brute force search  
> etc) AND these algorithms should also be implemented in a *readable*  
> and efficient way.
>
> And yes, I agree: in general the trick will be to calculate as little  
> as necessary.
>
>
> On Nov 9, 2007, at 12:05 AM, Jens Nachtigall wrote:
>
>   
>>> AFAIK there are a few ideas in our heads at the moment: Hannes
>>> mentioned something with incremental (diffs) of TC messages. This
>>> should drastically reduce the load.
>>>       
>> Yes, such things are very nice and put the "point of not scaling- 
>> anymore" into
>> farther regions. However, still you would have such a point. I was  
>> wondering,
>> if such a point at which the network is too large to scale would  
>> not exist
>> anymore, if just the TTL was not 255 but just something like 8. No  
>> artifical
>> network splitting necessary, just one wireless network, and every  
>> few hops a
>> gateway.
>>
>>     
>>> But what you wrote below sounds very much like HSLS aehh...  
>>> "fisheye".
>>> Or did I simply misunderstand you now?
>>>       
>> Somewhat like fisheye, just that the max TTL is permanently reduce,  
>> say 8
>> instead of 255. So a node does not know anything about nodes  
>> further away
>> than 8 hops. I was just wondering if this works with Djikstra, if  
>> the node
>>     
>
> is that good?
> Usually if you want to segment like that, you use BGP.
>
>   
>> only knows its neighborhood and not the whole topology (assuming  
>> the node
>> only wants to talk to this neighboorhoud within which might be an  
>> HNA)?
>>
>> Don't think this is brainfuck, throwing out thousands of nodes  
>> would be
>> nothing for telcos or a government, also not for freenetworks with  
>> some
>> funding.
>>
>>     
> hm, do you mean that freifunk is underfunded and that throwing out  
> thousands of nodes from the routing table solves problems? I just did  
> not really understand the point.
>
> curious about your ideas... :)
> a.
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
> End of Olsr-users Digest, Vol 6, Issue 5
> ****************************************
>