[Discuss] [Olsr-core] Babel im Mesh mit IPv6

Hannes Gredler (spam-protected)
Mo Dez 22 11:10:56 CET 2008


noch ein kommentar zum ETX metrik - henning hat im vergangenen jahr
den olsrd so umgebaut dass wir jederzeit auf eine anderes metrik
schema umstellen koennen. derzeit arbeitet henning am ETT metrik
wo aus dem kernel bandbreite pro neighbor rausgelesen werden kann
und wir in zukunft sehr akkurate "airtime" metriken bekommen werden.

/hannes

On Mon, Dec 22, 2008 at 08:41:54AM +0100, Sven-Ola Tuecke wrote:
| Adrian,
| 
| deine Analyse deckt sich ungefaehr mit dem, was ich im Laufe der Zeit gelernt 
| habe. Allerdings kann man das Problem "Packetloss steigt bei 
| Nutzdatenbelastung" mit dem Befehl "tc" entschaerfen. Die 1+1=2-Eigenschaft 
| ist eine Naeherung, die fuer Empfang-Speichern-Weitersenden-Kommunikation 
| ueber ein einzelnes Interface ganz gut passt. Aber leider einen Medienwechsel 
| (oder "andere Leitung im Spiel", "Ethernet under Systembus dazwischen", "2. 
| Wifikarte mit anderem Kanal", [...]) nicht beruecksichtigt. Letzteres waere 
| ein Todo fuer Weiterentwicklungen...
| 
| Die Forderung nach einem updatebaren Testbett kenne ich bereits von der 
| Diskussion bei der B.A.T.M.A.N-Einfuehrung. Gleiches galt + gilt fuer Updates 
| z.B. des olsrd. Im Prinzip klappt es ganz gut, wenn man 2 getrennte 
| IP-Bereiche fuer unterschiedliche Routingprotokolle verwendet. Dann bleibt 
| nur noch die Verwaltung bzw. die Zuteilung von nicht-teilbaren Ressourcen, 
| wie die Default-Route oder das (DHCP+NAT)-Klienten-Zielnetz. Ich koennte mir 
| vorstellen, einen automatischen Lade+Ausfuehrmechanismus fuer 
| Testinstallationen zu machen. Vorausgesetzt, der Eingang wird 
| einigermaszen "bewacht" (Signatur einer Gruppe von Leuten die sich kuemmern) 
| und eine "Auto-Bestrafung" (kill) bei Nutzung von singulaer vorhandenen 
| Ressourcen (Non-Policy-Routes, falscher IP-Bereich, zuviel 
| Mem,CPU,Bandbreite).
| 
| Im Uebrigen hat sich Juliusz offenbar was feines einfallen lassen, um das 
| Problem der Topoinfo-Verbreitung bei unzuverlaessig arbeitendem 
| Transportmedien zu loesen. Das klingt spannend und stand AFAIK u.a. bei 
| Hannes auf einer der erweiterten Todo's fuer den olsrd++. Insofern waeren 
| Praxis-Erfahrungen mit Juliusz Loesung sicher wertvoll. Ich vermute, dass 
| dieses Problem nicht mit einer einzelnen guten Idee aus der Welt zu schaffen 
| ist. Moeglicherweise muss man auch noch den Ursprung der Idee pruefen.
| 
| Achso: Ich darf daran erinnern, dass es ziemlich lange braucht um von einer 
| Idee zu einem in der Praxis einsetzbaren "Produkt" zu gelangen. Da rechnet 
| man besser in Mannjahren (+ nicht in Mann-Wochen). Von daher wuerd' ich Euch 
| empfehlen, das laufende Kern-Netz nicht einfach mal so umzubauen...
| 
| // Sven-Ola
| 
| Am Sonntag 21 Dezember 2008 21:47:48 schrieb Adrian D:
| > wir haben das selbe problem wie mit einem metrik-update bei olsr: wir
| > brauchen einen testm?glichkeit bzw einen update-pfad f?r das netz.
| > adhoc fallen mir zwei varianten ein: ein anderer ip range oder ein
| > anderes vlan ?ber funk. beides hat den nachteil es irgendwann mal eine
| > big-bang-umstellung geben muss - aber vielleicht f?llt uns noch was
| > besseres ein? eines, wo wir routen ?ber die jeweils andere metrik
| > automatisch integrieren k?nnen? hmm..
| > allzu lange werden wir uns davor nicht mehr dr?cken k?nnen.
| >
| >
| > ich war leider nicht bei dem babel-vortrag dabei, hab jetzt nur die
| > folien gesehen und muss sagen: super dass man sich wichtiger nachteile
| > des olsr angenommen hat (zb synchronizit?t bei route ver?nderungen).
| > aber ein zentraler nachteil bleibt: es verwendet ebenfalls die
| > ETX-metrik mit den zwei gravierendsten nachteilen:
| > *) es bewertet einen hop mit 50% packetloss (ETX=2) als besser, als zwei
| > hops mit jeweils nur 1% packetloss (ETX 1.01+1.01=2.02)
| > *) wird ein link tats?chlich belastet, konkurrieren datenpakete mit
| > hellopaketen was den ETX wert ansteigen l??t, und zu route-switching auf
| >  schlechtere routen f?hren kann. zumindest kommt es bei babel beim
| > routswitching nicht zu einstweiligen schleifen und damit zu aussetzern.
| >
| > gibts irgendwo eine liste an verbesserungen die olsr v2 verspricht? das
| > was ich als draft vom juli gesehen habe, verdient meiner ansicht nach
| > nicht die version 2.0.
| >
| > adrian.
| 
| 
| 
| _______________________________________________
| Olsr-core mailing list
| (spam-protected)
| http://lists.olsr.org/mailman/listinfo/olsr-core
| 




Mehr Informationen über die Mailingliste Discuss