[Berlin-wireless] HNA 0/0 Auswahl - was: Qualität Internetanbindung Bouchestr.

[Marco Tidow]

On Tue, Jan.24. 13:28 +0100, Sven-Ola Tuecke wrote:
> [...] und ein bisschem mehr Verkehr fuer anderen 
> Gateway-Betreibern waer sicher auch was feines...

moinmoin et-al,

diese Bemerkung Sven-Ola's bringt mich mal wieder dazu,
über die "Nicht-Auswahl" des default-gateways nachzudenken,
will sagen, das im wahrsten Sinn nächste HNA 0/0 anouncende
Funk-Vehikel muß herhalten, aber leider nicht immer das "beste",
und schon garnicht alle nach ihren Möglichkeiten.

Wenn ein HNA 0/0 mit 8Mbit Inet-bandbreite nur einen hop "hinter"
dem ersten HNA 0/0 mit nur 1Mbit existiert, bleiben die 8Mbit von Inet-
traffic komplett verschont...

Beispiele dieser Konstellation gibt es schon mehrere, z.B. pennt
der node 104.130.1.14 mit lokaler DSL nur rum, weil unmittelbar "vor"
ihm andere (104.129.29.x ?, 104.129.43.x ? topologie.dot sagt, im Moment
gibt's gar kein HNA 0/0 ...) selbst exklusiv Inet-gateway spielen.

(o.k., "pennt" ist relativ, cpu-Last liegt trotz fisheye bei 60-80%,
aber eigentlich sollte ein Funk-Router primär was anderes als purer
olsrd-Prozessor sein, sorry @Sven-Ola u.a. ;-)



"Ideal-Lösung" sähe so aus, einen "pool" der verfügbaren Inet-Bandbreite
zu haben, den sich clients symmetrisch teilen, während die Last auf
die gateways aber proportional zu ihrer downstream-Kapazität verteilt
wird.

Stichworte, die mir dazu in den Sinn kommen,
("Leitungen" währen in diesem Fall IP-tunnel, keine Ahnung ob bonding
überhaupt auf tun/tap funktioniert, hat das schon mal jemand probiert?
ja ich weiß, mein Freund heißt google, der Abend ist ja noch lang)

jeder ff-router macht

  "ingress-shaping" auf tun/tap Tunnel-Enden

    hierfür müßte info über die jeweilige Inet-Anbindung
    der erreichbaren HNA-0/0-nodes, ggfs. Auslastung etc. ermittelbar sein

    abhängig davon würde man laufend das lokale shaping nachstellen
    (tricky, damit announce-te fake-Monster-gateways nicht real-existierende
     abschnüren, DoS oder normale win$-user, etc.)

kombiniert mit

  device-bonding der ge-shape'ten Tunnel-Enden

    schon mit wired 100Mbit benutzt, weiß aber nicht, ob
    und wie das mit verschieden "dicken" Leitungen skaliert

    IMHO ist es aber eigentlich für dedizierte links zwischen zwei
    Endpunkten konzipiert, nicht für "congested-segments", wie
    Funkstrecken, ggfs. dasselbe Problem wie mit manchen traffic-
    shaping algos, die eine konstante Bandbreite vorraussetzen (e.g. SFQ)

    einen simplen Test werde ich mal zuhaus mit bonding einer 100Mbit und
    einer 10Mbit ethernet machen, habe zwischen mehreren Kisten noch beides
    parallel laufen, congestion läßt so sich leicht simulieren :-)

default-gateway device wäre dann z.B. "bond0"


in allen Szenarien, die mir einfallen, gibt es dann aber das

  "Problem der Gegenseite":

e.g. zwei (oder mehr) über verschiedene ISP's laufende outbound (ins Inet)
Anbindungen wieder zusammenzufassen, setzt einen server im Inet vorraus,
der das übernimmt und "masqueraded", ergo traffic-Kosten :-( .

Notwendig, damit session-orientierte Protokolle nicht wegen dauernd
wechselnder src-IP-Adressen abreissen, etc.
(Leider auch nicht auf genau diese beschränkbar, so daß der bulk-
traffic z.B. direkt vom/zum beliebigen DSL-gateway <-> Inet ginge,
da hakt es wieder mal am NAT-ing der DSL-router)

Auch fraglich, ob ein kommerzieller Provider mitspielt; vielleicht über
eine Uni/Hochschule, den DFN?


Hat jemand Lust, solch ein Szenario mal zu testen, vielleicht mit
einer Gegenseite bei Brande (vorrausgesetzt das ginge) ?

marco


P.S. dieses Stichwort scheint mir dann doch zu fett oder auch am Ziel
     vorbei u gehen:

"IPVS (IP Virtual Server)
  implements transport-layer load balancing
  inside the Linux kernel, so called Layer-4 switching"


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