LAN-WLAN-Bridge: Full Duplex Flow Control (IEEE 802.3x)

[Endorphin]

Momentan kann man ja in den Lancoms nur einstellen, welche Ethernet-Geschwindigkeit (10Base-T, 100-BaseTx, Auto-Negotiation) und welcher Duplex-Modus verwendet wird.

Wie sieht es da mit Full-Duplex Flow Control nach 802.3x (Senden, Empfangen und Reagieren auf PAUSE-Frames) aus?

Aus meiner Sicht wäre es für transparente P2P WLAN-Bridges sehr sinnvoll, Flow-Control zu haben. Dann würden die Switche auf beiden Seiten nicht immer kräftig den jeweiligen AP mit Paketen zustopfen, obwohl schon längst alle Puffer überlaufen und der AP (bzw. die LAN-WLAN-Bridge) kräftig dropped.

Stattdessen könnte die Bridge bei Bedarf (Stau) zum Switch sagen "hallo, meine Puffer sind voll, mach mal ne Pause und versuch's in [n] Sekunden noch einmal". Wenn das auf beiden Seiten des P2P-Links implementiert ist, dann können die Switche sich darum kümmern, die Bandbreite zu handeln, QoS zu machen oder selbst Ports mit Flow-Control einbremsen.

Effekt: weniger Packet loss, die Switche haben wieder die Möglichkeit, selbst zu entscheiden, was gedropped werden soll, und was nicht (QoS) und im theoretischen Idealfall (Layer-2 Flow Control auf der gesamten Strecke) deutlich höhere Dienstequalität.

Wie sieht's also mit Full-Duplex Flow-Control in den Lancoms aus? Oder sind meine Überlegungen falsch?

[alf29]

Moin,

zum einen kann längst nicht jede Gegenstelle Flow-Control, zum anderen ist
das etwas, was die jeweilige Hardware bei Auto-Negotiation ohnehin schon
selber macht. Die Bedingungen, unter denen Pause-Frames geschickt werden,
sind aber dann meist tief in der Hardware des Ethernet-MACs verankert und
nicht wirklich von der Software steuerbar.

Auf aktuellen LANCOMs hat der Ethernet-MAC zwischen 64 und 128 Rx-Paketpuffer,
dazu dann noch zwischen 130 und 600 Paketpuffer im Gerät, die die LAN-WLAN-
Bridge nutzt. Bei LANCOMs mit integriertem Switch hat dieser dann noch einmal
einige hundert KByte Puffer. Mir ist bisher noch kein 'normaler' Betriebsfall
untergekommen, bei dem das nicht gereicht hätte, weil höhere Protokolle wie
TCP schon vorher anhalten. Die einzige Situation, wo ich in einem LANCOM-AP
wirklich verlorene Pakete im LAN sehe, sind Broadcast-Stürme - da kann man aber
so oder so nicht viel machen, irgendjemand muß dann anfangen, Pakete
wegzuwerfen, mit Flow Control passiert's dann nur etwas weiter vorne in der Kette...

Effekt: weniger Packet loss, die Switche haben wieder die Möglichkeit, selbst zu entscheiden, was gedropped werden soll, und was nicht (QoS) und im theoretischen Idealfall (Layer-2 Flow Control auf der gesamten Strecke) deutlich höhere Dienstequalität.

Um das anhand von QoS-Infos entscheiden zu können, müßte erstmal alles durchgängig
im LAN getaggt werden - was üblicherweise nicht der Fall ist...

Gruß Alfred