[Wien] missing QOS

[Markus Kittenberger]

1. hab ich nit vor extrem viele QOS rules zu bauen,.. #1
und schon gar keine die src/dst ip-spezifisch sind (ausser über hashes
arbeiten)
und wenn doch wäre das sowieso nur auf 0xff-(src)-ips eingeshränkt,..

2. klar kann man jegliche QOS rules auch wieder missbräuchlich verwenden

ist mir aber erstens relativ wurscht, netzschädliches verhalten ist auch
sonst auf vielerlei weisen möglich, wird aber doch nur verhältnismässig
selten 'praktiziert', und meistens/immer dann eben
versehentlich/unwissentlich,..

und genau diese (versehentlich) daraus resultierende probleme zu
mildern/verhindern ist die ziel für QOS auf den routern,..

und im worst case könnt ma halt nur unsere eigenen DNS server priorisieren,
...
(bzw externe halt nur rate-limitet priorisieren,..)

lg Markus

#1 es ist schon schwer genug basierend auf openwrt && mac80211 irgendwas zu
machen

und im bestcase kann wohl man eh nur die queues des treibers gezielt
befüllen, eigene zu haben spielts eh nit,..

2011/12/12 Petr Koval <(spam-protected)>

> Am 10.12.11 schrieb Markus Kittenberger <(spam-protected)>:
> > 2011/12/10 Petr Koval <(spam-protected)>
> >
> >> Abgesehen von der der Art des QoS sind noch 2 Dinge zu bedenken:
> >>
> >> 1) QoS im Bezug des Transits (reine Transit Router)
> >>
> >> nur FF IP Adressen gegenüber anderen FF IP oder anderen public Adressen
> im
> >> Spiel
> >>
> >> 2) QoS im Bezug der lokalen Klients
> >>
> >> nur lokale (priv IP Adressen/NAT) gegenüber FF bzw. anderen public
> >> Adressen
> >>
> >> 3) kombi von 1) und 2)
> >>
> >> Meiner Meinung nach wäre besser wenn 1) und 2) miteinander
> >> nicht gemischt werden. (keine objektive sondern rein subjektive Meinung)
> >>
> >
> > (hmm nit ganz sicher worauf du raus willst,..)
> >
> > QOS (so wie ichs mir vorstelle) würde interface spezifisch (und nur auf
> > olsrd interfaces) für ausgehenden traffic laufen,.. (-> privaten traffic
> > gibts da keinen)
>
> Hallo Markus,
>
> die Definition/Konfiguratio bezieht sich schon auf die betreffende/n
> Schnittstelle
> der Performance/Speichernutzung Aufwand während des QoS dennoch auf die
> IP Paare der jewaligen Kommunikation/auf das Zielverhalten.
>
> Im Fall von QoS nur im Bezug auf Paare, wo entweder die Source oder
> die Destionation,
> oder auch bedes eine private IP, eine eines lokalen Klients des
> Routers, hat  einen nidrigen Verbindungslimit im Vergleich eines
> Transitpunktes, wo die Mögliche Verbindungsanzahl (Anzahl der
> kommunikation IP Paare) bei einer Volllast sehr hoch und weit über den
> ersten Fall sein kann. Ich sehe es in einem solchen Fall eher als ein
> Problem vom zur Verfügung stehenden Speicher als ein Performance Limit
> der benutzten Prozessoren.
>
> Würden die QoS Warteschlangen für wenigere IPs (nicht mehr als 100)
> ausgelegt sein können, durch so ein IP Anzahl Limit, es wäre
> Transitrouter der mehr als 100 FF interne IPs bedient, dann könnten so
> manche IP Paare gar nicht in die Warteschlange schaffen.
> In einem solchen Fall würde der Router zwar allen benachbarten und
> dahinter benachbarten Routern mitteilen bestimmtes Link Qualty, das
> würde jedoch nicht mehr für alle Kommunikationspaare stimmen. Für
> manche Paare ja, für die anderen wäre die echte Linkquality nicht mehr
> entsprechend.
>
> Deshalb  fehlt mir eine Kopplung zwischen OLSR und dem QoS. Wo eine
> Totalauslasstung von QoS (Warteschlangen) gleichfalls zum erniedrigen
> der Linkquality auf OLSR führen würde, obwohl zu der in der Tat allein
> durch prioritisierten Verkehr des OLSR nicht führen würde.
>
> Ich habe mich mit QoS vor einer Zeit sehr internsiv beschäftigt, als
> wir ebenfalls niemanden einschrenken wollten und dennoch jeder zweite
> diverse Bittorent ähnliche Sachen benutzt hat und wir pro 2-4  Mbit
> Anschlüsse 50-200 Leute versucht haben irgendwie zu bedienenen.
>
> Das letzte Problem was ich gesehen habe, war Benutzung von 53 UDP für
> nicht DNS Zwecke beim gleichzeitigen MAC Missbrauch der benachbarten
> Lokalklients, bei dem man nicht mal mit L7 Filter und MAC Filter
> dagegen kämpfen konnte.
>
> Wir mussten damals ob gewollt oder nicht gesamten externen 53 UDP Traffik
> auf Lokal DNS umleiten, und den externen Traffik des Lokalen DNS stark
> drosseln.
>
> lg Petr
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20111212/a62f53d9/attachment.htm>