| |
DMA284 > XROUTER 24.07.23 00:14l 128 Lines 12673 Bytes #999 (0) @ DEU
BID : N7XDBO27400G
Read: GUEST
Subj: XRouter und Netrom Routing
Path: FU0BOX<KS1BBS<DBO274
Sent: 230723/2248z @:DBO274.#NRW.DEU.EU [Lippstadt JO41DQ] obcm1.07b12
From: DMA284 @ DBO274.#NRW.DEU.EU (Marc-Andre)
To: XROUTER @ DEU
X-Info: No login password
TDR -- Time Dependent Routing = Zeitabhängiges Routing
Beschreibung
Konventionelles NetRom trifft Routing-Entscheidungen auf der Grundlage einer ziemlich willkürlichen Metrik, nämlich der "Routenqualität", die von Sysops zugewiesen und in Knoten-Rundsendungen verbreitet wird. Es gibt keinen Standard für die Zuweisung der Qualität, und nicht nur wird jeder Sysop eine andere Vorstellung von der Qualität seiner Verbindungen im Vergleich zu anderen haben, sondern er wird wahrscheinlich auch die Qualitäten dieser Verbindungen im Verhältnis zueinander falsch zuweisen. Dies führt zu Inkonsistenz und verzerrtem Routing.
XRouter enthält zwei Systeme, die versuchen, dieses Problem zu entschärfen, nämlich Automatic Quality Measurement" (Autoqual) und "Time Domain Routing" (TDR). Beide Systeme beruhen auf einer leicht unterschiedlichen Auffassung von der "Güte" einer Verbindung.
In den besser verwalteten Teilen des NetRom-Netzes werden Routenqualitäten in der Regel entsprechend der Baudrate der Verbindung zugewiesen, mit Anpassungen für Wiederholungsraten, Duplex/Simplex und gemeinsam genutzte Kanäle (in den schlechter verwalteten Teilen werden Routenqualitäten einfach 192 zugewiesen, unabhängig davon, wie gut oder schlecht die Verbindung ist). Die Qualität ist auf einen Kompromisswert festgelegt.
Die tatsächliche "Güte" einer Verbindung kann sich jedoch in Abhängigkeit von den atmosphärischen Bedingungen, dem Datendurchsatz, anderen Kanalaktivitäten, QRM usw. ständig ändern. Zu bestimmten Tageszeiten kann es zum Beispiel besser sein, eine andere Verbindung zu nutzen.
Round-Trip-Zeit
---------------
Eine genauere Vorstellung von "Güte" ist einfach die "Round Trip Time" (RTT) für die Verbindung, d. h. die Zeit, die benötigt wird, um ein Paket zu senden und eine Antwort zu erhalten. Dies ist schließlich das, was für die Nutzer *wirklich* wichtig ist. Eine Verbindung, die schnell antwortet (d. h. mit einer niedrigen RTT), wird von den Nutzern als besser empfunden als eine Verbindung, die langsam antwortet. Die RTT gibt Aufschluss über Ãänderungen bei der Wiederholungsrate, der Kanalauslastung usw.
Die RTT kann einfach und konsistent von der Software auf einer kontinuierlichen Basis gemessen werden, so dass die "Qualität" der Verbindung jederzeit genau bekannt ist und alle Router desselben Typs vergleichbare Werte liefern, unabhängig von den Qualitätsvorstellungen des Systemverantwortlichen.
XRouter misst kontinuierlich die RTT und berechnet daraus eine fiktive "Routenqualität". Diese Qualität wird durch den "R Q"-Befehl angezeigt und kann entweder als Richtlinie verwendet werden, um dem Sysop zu ermöglichen, die RQ auf einen vernünftigen Wert festzulegen, oder XRouter kann sie dynamisch verwenden, indem er die Route auf Autoqual einstellt. (Autoqual wird aktiviert, indem ein RQ zwischen 256 und 511 eingestellt wird). Diese Umrechnung von RTT in Qualität ist auf den britischen Qualitätsbegriff zugeschnitten, der etwas niedrigere, aber aussagekräftigere Qualitäten ergibt.
Autoqual ist lediglich ein Hilfsmittel, das den Sysops hilft, konsistente und aussagekräftige Streckenqualitäten festzulegen. Die Qualitäten stehen immer noch unter der Kontrolle der Sysops und sind daher anfällig für Verzerrungen.
Durch die einfache Übertragung von RTT-Werten anstelle von Qualitäten wird jedoch der Einfluss des Sysops beseitigt, und es kann ein Netz geschaffen werden, das auf unbestreitbaren *Zeiten* und nicht auf willkürlicher *Qualität* basiert.
Dies ist ein Netz, das seine Routing-Metrik im Zeitbereich hat, daher der Name "Time Domain Routing". Es kann sich bis zu einem gewissen Grad mit dem Netz im Qualitätsbereich überschneiden, aber die Grenzen können unterschiedlich sein, und die beiden Systeme sind nicht kompatibel. Betrachten Sie sie als unterschiedliche Dimensionen, die im 90-Grad-Winkel zueinander stehen.
XRouter implementiert sowohl zeit- als auch qualitätsbezogene Routing-Schemata und berücksichtigt bei Routing-Entscheidungen Informationen aus beiden Domänen. Für beide Verfahren wird dieselbe Knotentabelle verwendet, da nur die Metrik unterschiedlich ist. In einigen Fällen kann ein Knoten sowohl Qualitäts- als auch Zeitmetriken haben.
Verwaltung
----------
Als Sysop stehen Ihnen mehrere Werkzeuge zur Verfügung, um die Größe und das Gleichgewicht der beiden Bereiche zu steuern. Für den Qualitätsbereich haben Sie QUALITY, das die "Güte" der Verbindungen zu Ihren Nachbarn und die "Herabstufung" der Qualitäten, die sie Ihnen senden, festlegt, MINQUAL, das bestimmt, welche Knoten in die Knotentabelle gelangen und welche ausgeschlossen werden, MINTXQUAL, das bestimmt, wie viele Informationen Sie an Ihre Nachbarknoten senden, und MAXNODES, das die maximale Anzahl der für Sie sichtbaren Knoten festlegt.
Für den Zeitbereich gibt es MAXTT, das den am weitesten entfernten Knoten in "Trip Time" (d.h. RTT/2) definiert, MAXHOPS, das den am weitesten entfernten Knoten in Abhängigkeit von der Anzahl der dazwischen liegenden Knoten definiert, und MAXNODES wie oben.
Sie können diese Parameter anpassen, um eine Domäne gegenüber der anderen zu bevorzugen, eine Domäne ganz auszuschließen oder ein Gleichgewicht zwischen der Anzahl der Knoten herzustellen, die nur in der einen oder der anderen Domäne existieren.
Wenn Sie z. B. MAXTT oder MAXHOPS auf 0 setzen, werden alle Zeitdomäneninformationen ausgeschlossen, und XRouter verhält sich wie ein reiner altmodischer NetRom-Router. Oder Sie können MINQUAL auf 255 setzen, um alle Informationen über die Qualitätsdomäne auszuschließen (z.B. wenn ein nahegelegener Knoten die NetRom-Qualitäten verzerrt), vorausgesetzt natürlich, Sie haben Nachbarn, die in der Lage sind, im Zeitbereich zu routen. Oder Sie möchten die Sichtbarkeit eines Subnetzes von einem Port aus begrenzen (z. B. zu einem fremden Netz), indem Sie einen niedrigen MAXHOPS- oder MAXTT-Wert nur für diesen Port festlegen. Dies gibt Ihnen eine Kontrolle, die bisher nicht möglich war.
Metrische Propogation
---------------------
XRouter verwendet derzeit (siehe jedoch Kompatibilitätsprobleme) das INP3-Protokoll zur Verbreitung von Routing-Informationen im Time-Domain Routing. Im Gegensatz zu NetRom, das im unverbundenen Modus "Broadcasts" an alle Nachbarn gleichzeitig sendet, sendet INP3 im verbundenen Modus Daten an jeden Nachbarn einzeln. Während NetRom-Knoten üblicherweise in Abständen von einer Stunde senden, werden INP3-Updates alle 10 Minuten gesendet, mit zusätzlichen Updates, wenn Ãänderungen auftreten.
Das Zeitbereichsnetz reagiert somit viel schneller auf Ãänderungen als NetRom, aber wenn das Netz unzuverlässig ist (d. h. häufige Ausfälle und variable RTTs), werden viele Aktualisierungen erzeugt. Obwohl INP3-Updates kompakter sind als NetRom-Knoten-Broadcasts, könnten einige Sysops das Gefühl haben, dass die Menge an Routing-Informationen zu viel für eine RF-Verbindung von schlechter Qualität ist. Wenn dies der Fall ist, können Sie INP3 vollständig deaktivieren, indem Sie die MAXTT der Route auf 0 setzen, oder Sie können mit Ihrem Nachbarknoten eine niedrige MAXTT vereinbaren, was das Datenvolumen reduziert.
Sie werden feststellen, dass Knoten, die ausschließlich über INP3 gelernt werden, alle mit einer NetRom-Qualität von 0 gespeichert werden. Dies ist beabsichtigt, da diese Knoten keine Präsenz in der Qualitätsdomäne haben.
Kompatibilitätsprobleme
-----------------------
Obwohl es sich hier um ein Router-Handbuch und nicht um eine Abhandlung über Netzwerke handelt, muss betont werden, dass die Metriken der Zeit- und der Qualitätsdomäne inkompatibel sind und dass Informationen aus der einen Domäne *nie* in die andere "übersetzt" und übertragen werden dürfen. XRouter misst, verwendet und verbreitet sowohl Zeit- als auch Qualitätsmetriken, hält sie aber immer getrennt.
Leider *übersetzt* manche Software (die im Folgenden als "Brand-X" bezeichnet werden soll) Informationen zwischen den Domänen, und Sie sollten sich bewusst sein, dass dies zu Problemen führen kann, wenn sie sich innerhalb des Horizonts einer der beiden Domänen befinden.
Stellen Sie sich im folgenden Diagramm beispielsweise vor, dass ein XRouter-Knoten (Xr) die Reisezeit (TT) zu einem seiner Nachbarknoten (A) mit 1,5 Sekunden misst und der Sysop eine Netrom-Qualität von 180 zugewiesen hat.
180
A ---- Xr ---- Bx
\ /
\ /
C ---- D
XRouter sendet beide Informationen an den Nachbarknoten (Bx), der die Software "Brand-X" verwendet. Diese Software ignoriert die 180 und errechnet stattdessen mit einem völlig ungeeigneten Algorithmus eine Qualität von 253 aus der Reisezeit.
An sich ist dies kein Problem, bis der "Brand-X"-Knoten es an den Knoten (C) sendet, der nur NetRom verwendet. Nun denkt der NetRom-Knoten, dass er über (Bx) eine höhere Qualität zu (A) hat als über (Xr). Daher nehmen die Pakete von (C) nach (A) nun den längeren Weg. Schlimmer noch, (Bx) wird (Xr) mitteilen, dass er eine bessere Route nach (A) kennt, und das Netzwerk wird im Chaos versinken.
Ein vollständig vernetztes Mesh-Netzwerk ist sehr robust, aber die "Brand-X"-Systembetreuer scheinen bemerkenswert zögerlich zu sein, Verbindungen zu implementieren, die zu einem Mesh führen. Vielleicht erklärt das oben Gesagte den Grund dafür!
Ein weiteres Problem tritt auf, wenn die "Brand-X"-Software in die andere Richtung übersetzt, d. h. sie nimmt eine NetRom-Qualität, die eine potenziell unzuverlässige Information ist, und verwandelt sie auf magische Weise in eine Reisezeit und einen Hop Count. Doch weder die Reisezeit noch die Anzahl der Sprünge können aus der Qualität allein abgeleitet werden!
Die Folge ist, dass ein Knoten, der nur in der nicht vertrauenswürdigen Qualitätsdomäne existiert und in dieser Domäne möglicherweise außerhalb unseres Horizonts lag, nun in der vertrauenswürdigeren Zeitdomäne auftaucht, wo er den NetRom De-Rating-Prozess umgehen kann. Die Information könnte dann unschuldig mit einer höheren "Qualität" in das Netrom-Netz zurückkehren, als wenn sie über eine direktere reine Netrom-Route empfangen worden wäre.
Geschichte
----------
Frühe Versionen von XRouter verwendeten ein proprietäres Protokoll, um RTT, Hops, IP-Routing, Position und andere Informationen untereinander auszutauschen. Später wurde beschlossen, XRouter für die INP3-Kompatibilität anzupassen, da man glaubte, dass es eine gute Idee wäre, das Zeitbereichsschema von XRouter mit anderen Arten von Knoten zu verbinden.
Im Nachhinein hat sich dies als Fehler erwiesen, und man ist der festen Überzeugung, dass XRouter und das Netrom-Netzwerk nicht mit anderen Netzwerken verbunden werden sollten, die "Brand-X"-Knoten enthalten, solange die Autoren der "Brand-X"-Software die Fehler nicht korrigieren. Glücklicherweise sind diese Knoten jetzt im Niedergang begriffen, und BPQ setzt sich immer mehr durch. BPQ32 trennt (korrekterweise) die Bereiche Zeit und Qualität.
Nomenklatur
Der Verfasser räumt ein, dass "Time Domain Routing" wahrscheinlich nicht der ideale Name für dieses System ist, aber bisher ist ihm keine Alternative eingefallen.
Es handelt sich um ein Routing, das auf messbaren "zeitlichen" Metriken (RTT - Round Trip Time) und nicht auf abstrakten, einheitslosen, von Menschen erzeugten Metriken ("Qualität") basiert. Vielleicht wäre ein besserer Name "Trip-Time-Routing"?
Wenn neue Ideen in Eile entwickelt und kodiert werden, bleibt der erste Name, der einem einfällt, oft haften. Er wird in Funktions- und Klassennamen, Konfigurationsdateien, Befehlen und Dokumentationen verwendet. Dann wird es zu viel Aufwand, ihn zu ändern.
Das Wort "Domäne" wurde wahrscheinlich deshalb verwendet, weil die trip-time-basierten und qualitätsbasierten Netze zwei getrennte Einheiten sind. Sie haben zwar dieselben Knoten, sind aber unterschiedliche NETZE mit unterschiedlichem dynamischem Verhalten.
Die Knoten in dem einen Netz sind oft anders angeordnet als in dem anderen. Die Netze können sich nicht sehen (oder sollten es zumindest nicht!), als ob sie denselben Raum, aber in unterschiedlichen Dimensionen einnehmen würden. Man kann Trip-Time genauso wenig in Qualität umrechnen wie Zentimeter in Sekunden.
Ãœbersetzung von http://vk2dot.dyndns.org/xrpi/docs/tdr.htm durch https://www.deepl.com
--
55 & 73
Marc-Andre (DMA284)
Lese vorherige Mail | Lese naechste Mail
| |
