[Wien] missing QOS

[Petr Koval]

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