[Berlin-wireless] [technix] Bitratenkontrolle, traffic-mengen- und radio-aware routing

[Rolf Pfeiffer]

Am Samstag, 24. März 2007 23:54 schrieb Marco Tidow:
> aehm, schreibst Du das auf meinen beitrag?  zu allem ein klares NEIN.

Hallo Marco - ja, das war die Antwort auf deinen Beitrag. Aber hier sind 
verschiedene Szenarien, reale Probleme, theorethische Betrachtungen usw so 
bunt verknüpft, daß wir völlig aneinander vorbeireden. ZB:

> nö:  eine bitratensteuerung hat das potential, dem routing-daemon selbst
> essentielle links weg-zuoptimieren ;-)
> sie muß deshalb auf die aktuelle routing-konstellation ihrer node
> reagieren, letzteres vermeiden.

Ich rede von Bitratensteuerung per Link, nicht für den Gesamtknoten. Dann wird 
auch nichts wegoptimiert. Im Gegenteil, mit dieser Information könnte ein 
(zukünftiger) Routingdaemon bessere Entscheidungen treffen.

Anders sieht es für die Steuerung der Sendeleistung aus - da kann es durchaus 
Verinselung geben. Was spricht dann gegen eine SOS-Funktion? Wenn ein Knoten 
den Kontakt verliert, ruft er "SOS - ich bin isoliert, aber empfange noch 
Beacons vonn xxx". Dann braucht nur EIN Knoten aus der Wolke aufzudrehen.

Die Sendeleistungsteuerung macht aber nur in "richtigen" Meshes Sinn, die 
zudem noch "dicht" sein müssen.

"Dicht" heisst, das ein Knoten durch Variation der Sendeleistung die Anzahl 
seiner Nachbarn (fast) beliebig beeinflussen kann.

"Richtiges" Mesh heisst eine (überwiegend) maschenförmige Topologie - unsere 
Praxis sieht in weiten Teilen anders aus. Mal etwas überspitzt:

Da gibt es die großen Uplinks, und alle ballern mit Richtantennen drauf. Damit 
zwingen sie die weiter entfernten Knoten, mit noch größeren Richtantennen 
ebenfalls direkt draufzuhalten - weil sie in ihren Rücken nichts weiterleiten 
können. Bestenfallsgibt es noch ein paar lokale Verteiler - die Struktur ist 
dann Stern- oder Baum-förmig - und Maschen gibt es nur als Nebeneffekt.

Für den überwiegenden "Lastfall" Internetnutzung ist das ok - und damit 
erkären sich auch deine Optimierungsansätze: für den Zentralknoten ist 
RTS/CTS Quatsch, da er sowieso von allen gehört wird - und die schiere Anzahl 
Nachbarn macht jede Bitratenautomatik platt. Für die Endknoten wäre es 
einfach sinnlos, ein paar http-Requests per Handshake einzukammern oder in 
der bitrate zu steuern.

Mit dieser ganzen Durchstrukturierung äffen wir bloß die Provider nach, und 
verbinden die Nachteile beider Architekturen. Wollen wir das wirklich?

Ein "richtiges Mesh" sieht anders aus - das haben wir noch gar nicht gebaut! 
Eine ideale Form (um mit einer minimalen Anzahl Links ein bestimmtes Gebiet 
abzudecken) ist ein hexagonales Gitter. Natürlich liegen unsere Knoten nicht 
im Raster - aber auch wenn du das Gitter verzerrst, faltest, zerreisst und 
wieder zusammenklebst bleibt eine wichtige Eigenschaft erhalten:

Alle Knoten (außer am Rand) haben minimal drei Nachbarn, die außerdem keine 
direkte Verbindung miteinander haben!

Wenn wir kein perfektes Mesh wollen, sondern uns mit einem guten 
zufriedengeben, brauchen wir nicht für jeden Knoten, sondern bloss im Mittel 
mindestens drei Nachbarn zu fordern. Aber das heißt auch:

Ein richtiger Meshknoten braucht entweder eine Omni - oder wenn das nicht 
reicht - mindestens drei Richtantennen!

Damit kommen wir unserem Anspruch, uns untereinander zu vernetzen, schon 
näher. Dafür einen Lastfall zu konstruieren wird schon schwieriger - ich gehe 
einfach davon aus, daß jeder mit jedem "telefoniert". Dann ist aber der 
überwiegende Teil des Datenverkehrs Transit - und da gibt es ganz andere 
Optimierungsziele.

Wenn du über einen Knoten Nord-Süd-Transit laufen lässt, geht das ohne RTS/CTS 
noch einigermaßen - wenn gleichzeitig Ost-West-Verkehr läuft, geht ohne 
Handshake nichts mehr. Und wenn du die Sendeleistung fein abstimmst 
profitierst du davon, daß der übernächste Knoten parallel übertragen kann.

Es gibt ein paar papers zum Thema Sendeleistungssteuerung - die fordern als 
Kriterium 6-8 Nachbarn, aber die setzen alle konstante Bitraten voraus. Das 
für variable Bitraten durchzurechnen, wäre eine dankbare Aufgabe für die 
Frauenhofer-Jungs und -Mädels.

Und, mag es nun die Notwendigkeit für ein"richtiges Mesh" geben oder nicht - 
ich setze mich jedenfalls für eine Entwicklung in diese Richtung ein - ob 
beim Ausbau, Optimierung, oder Wunschlisten für zukünftige Routingdämonen.

Und Strukturierung JA - meshen wir richtig auf Dachebene und versorgen die 
Pimmenantennen in den Erdgeschossen per lokalem Netz!

Gruß Rolf



_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin