[Wien] missing QOS bzw.: Warum torrents auf backfire vienna router so "stören" - war: Re: brenner 2stunden

[Markus Kittenberger]

2011/12/8 gerhard poller <(spam-protected)>

>  brenner 2 stunden nachdem auch lan_olsr route lauft,
> und alles ihmo optimiert wurde
>
ALLES ? (-;

> lauft schon wieder einer mit torent, 5mbit bis 500 udp adressen zugleich
> um vernunft bittent ist eine mail an demjenigen  schon unterwegs
>
was vmtl momentan eh der zielführenste ansatz,..  (evt. in kombination mit
freiwilligen 'zapp' oder dergleichen am lan interface)
(aber bitte nit im forward)

>
> andere haben dadurch anstatt lq 0.7 NUR mehr lq 0.2
>
also diese auswirkung liegt an der (für mesh einsatz) noch "unfertigen"
backfire vienna firmware (auf atheros hardware),..

----
Ursachen:

da diese firmware(s) weder 1. die vorhandene bandbreite irgendwie unter den
usern aufteilen,
2. noch OLSR pakete
noch 3. DNS requests bevorzugen
(gäbe noch weitere sinnvolle QOS rules (wie tcp acks bevorzugen, u.s.w)

zerlegt sich unter last das "netz" schnellmal,..

denn:

1. erlaubt es den torrents überdurchschnittlich viel bandbreite zu
belegen,.. (d.h. andere z.b. surfende user sind schonmal etwas
benachteiligt, aber es wäre vmtl noch recht ok oder zumindest benutzbar)

2. führt dann (weil olsr pakete genauso oft wie torrent pakete weggeworfen
werden) zu schwankenden (und grundsätzlich niedrigeren) lq werten als bei
keinem traffic.
dies führt dann potentiell laufend zu routing flaps, die es für surfende
user schon ziemlich fad machen können, weil dabei mitunter (alle paar
sekunden) etliche sekunden (gefühlt evt. permanent) einfach garnix
"geht",..

(wirklich garnix wenn der lq (des einzigen brauchbaren links) unter 0.1
gedrückt wird (-;)

übrigens: wäre das (durch torrents ausgelöste 'überlastungs') problem nit
am brenner (der selber nen tunnel direkt zum uplink hat) und an dem viele
user hängen die selber "nur" den brenner sehen, und somit wenig flap
alterniven haben, wären die konsequenzen noch viel katastrophaler,..

3. führt dazu das dns udp pakete gleich wie die des torrents behandelt (und
bei vollaufen der txqueue (auf jedem backfire node am weg) eben weggeworfen
werden)
da dns clients/forwarder idr den unterschied zwischen "domain existiert
wirklich nicht", und "dns server antwortet nicht" nicht sonderlich gut
'kennen'/'kapieren'
führt das dazu dass webseiten/etc. dann (bis der lokale dns (not found)
cache eintrag wieder verworfen wird) überhaupt nicht mehr "aufgehen",..#3

ok genug der (mit QOS vermeidbaren) ursachen für "internet geht nix mehr"

(es gäb noch die eh schon in anderen mails gründlich angesprochenen
conntrack overflows (vergleichsweise trivial vermeidbar), und auch
airtime/noise auf lq rückkopplungen mit sleben abr idr deutlich schwächer
ausgeprägten konsequenzen wie in 2.,...)

----
Lösungen:

leider ist es eben bei "neuen" geräten (mit ath9k (oder auch ath5k)) nicht
mehr so "trivial" QOS zu machen als auf den alten broadcoms (linksys,
etc.),.. #1 (sonst wärs ja wohl acuh schon längst gemacht)
(und (hauptsächlich deswegen) empfehle ich persönlich eben keine neuen
geräte bzw. die firmwares dafür,.. #0)

allerdings ist es eigentlich auch bei verwendung von z.b. ath9k #2 moeglich
(z.b. mit tc oder iptables) die pakete vorzukategorisieren, so dass der
treiber in den eigenen queues die dann entsprechend behandelt,

eigentlich wollte ich mich dem themas schon lange selber annehmen, aber mir
fehlt immer noch die zeit dafür,..
(aber evt. lasst sich da nächstes jahr was machen *g)

und/aber zumindest NOTRACK zwischen olsr interfaces sollte in den backfire
vienna firmwares mal rasch eingebaut werden!

lg Markus

#0 obwohl auch meiner ansicht nach, die neuen geräte (bzw. jedfalls deren
hardware und in vielen punkten auch die treiber) unumwunden
besser/preiswärter/etc. als die alten sind,..

d.h. auf privaten strecken (mit nur meinem eigenen traffic *G) würd ich sie
empfehlen/selber verwenden, aber für meshtauglich halte ich sie halt
nicht,.. (da ist lahme und auch taube hardware mit
zuverlässigen funktionierendem forwarding mit QOS, imho noch immer die
bessere wahl)

#1 da jegliche auf backpressure angewiesene QOS setups (idr) nicht
funktionieren, weil diese wifi treiber keien (komplette) backpressure
"aufbauen")

#2 dieser hat intern im gegensatz zu alten/simplen wifi treibern mit kurzen
fifos) eigene lange queues und kategorisierungs/priorisierungs rules für
traffic

#3 dagen hiilft eintragen von mehreren dns server zwar ein bißchen, (und
dns im mesh über tcp statt udp abzuwicklen ein bißchen mehr,..)
aber am sinnvollsten ist es auf jeder node QOS zu haben das dns requests
schützt/bevorzugt, und nur im äussersten 'notfall' wegwirft,..

manche haben auch sogut wie keine verbindung mehr
>
leider nicht verwunderlich,..

auf der nortwest brenner
>
> *GRUML
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20111209/d6470d30/attachment.htm>