<div>1. hab ich nit vor extrem viele QOS rules zu bauen,.. #1</div><div>und schon gar keine die src/dst ip-spezifisch sind (ausser über hashes arbeiten) <br>und wenn doch wäre das sowieso nur auf 0xff-(src)-ips eingeshränkt,..<br>
<br></div><div>2. klar kann man jegliche QOS rules auch wieder missbräuchlich verwenden<br><br></div><div>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,.. </div>
<div><br></div><div>und genau diese (versehentlich) daraus resultierende probleme zu mildern/verhindern ist die ziel für QOS auf den routern,..</div><div><br></div><div>und im worst case könnt ma halt nur unsere eigenen DNS server priorisieren, ...<br>
(bzw externe halt nur rate-limitet priorisieren,..)</div><div><br></div><div>lg Markus</div><div><br></div><div>#1 es ist schon schwer genug basierend auf openwrt && mac80211 irgendwas zu machen<br><br>und im bestcase kann wohl man eh nur die queues des treibers gezielt befüllen, eigene zu haben spielts eh nit,..</div>
<br><div class="gmail_quote">2011/12/12 Petr Koval <span dir="ltr"><<a href="mailto:peerco@gmail.com">peerco@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 10.12.11 schrieb Markus Kittenberger <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>>:<br>
<div><div class="h5">> 2011/12/10 Petr Koval <<a href="mailto:peerco@gmail.com">peerco@gmail.com</a>><br>
><br>
>> Abgesehen von der der Art des QoS sind noch 2 Dinge zu bedenken:<br>
>><br>
>> 1) QoS im Bezug des Transits (reine Transit Router)<br>
>><br>
>> nur FF IP Adressen gegenüber anderen FF IP oder anderen public Adressen im<br>
>> Spiel<br>
>><br>
>> 2) QoS im Bezug der lokalen Klients<br>
>><br>
>> nur lokale (priv IP Adressen/NAT) gegenüber FF bzw. anderen public<br>
>> Adressen<br>
>><br>
>> 3) kombi von 1) und 2)<br>
>><br>
>> Meiner Meinung nach wäre besser wenn 1) und 2) miteinander<br>
>> nicht gemischt werden. (keine objektive sondern rein subjektive Meinung)<br>
>><br>
><br>
> (hmm nit ganz sicher worauf du raus willst,..)<br>
><br>
> QOS (so wie ichs mir vorstelle) würde interface spezifisch (und nur auf<br>
> olsrd interfaces) für ausgehenden traffic laufen,.. (-> privaten traffic<br>
> gibts da keinen)<br>
<br>
</div></div>Hallo Markus,<br>
<br>
die Definition/Konfiguratio bezieht sich schon auf die betreffende/n<br>
Schnittstelle<br>
der Performance/Speichernutzung Aufwand während des QoS dennoch auf die<br>
IP Paare der jewaligen Kommunikation/auf das Zielverhalten.<br>
<br>
Im Fall von QoS nur im Bezug auf Paare, wo entweder die Source oder<br>
die Destionation,<br>
oder auch bedes eine private IP, eine eines lokalen Klients des<br>
Routers, hat  einen nidrigen Verbindungslimit im Vergleich eines<br>
Transitpunktes, wo die Mögliche Verbindungsanzahl (Anzahl der<br>
kommunikation IP Paare) bei einer Volllast sehr hoch und weit über den<br>
ersten Fall sein kann. Ich sehe es in einem solchen Fall eher als ein<br>
Problem vom zur Verfügung stehenden Speicher als ein Performance Limit<br>
der benutzten Prozessoren.<br>
<br>
Würden die QoS Warteschlangen für wenigere IPs (nicht mehr als 100)<br>
ausgelegt sein können, durch so ein IP Anzahl Limit, es wäre<br>
Transitrouter der mehr als 100 FF interne IPs bedient, dann könnten so<br>
manche IP Paare gar nicht in die Warteschlange schaffen.<br>
In einem solchen Fall würde der Router zwar allen benachbarten und<br>
dahinter benachbarten Routern mitteilen bestimmtes Link Qualty, das<br>
würde jedoch nicht mehr für alle Kommunikationspaare stimmen. Für<br>
manche Paare ja, für die anderen wäre die echte Linkquality nicht mehr<br>
entsprechend.<br>
<br>
Deshalb  fehlt mir eine Kopplung zwischen OLSR und dem QoS. Wo eine<br>
Totalauslasstung von QoS (Warteschlangen) gleichfalls zum erniedrigen<br>
der Linkquality auf OLSR führen würde, obwohl zu der in der Tat allein<br>
durch prioritisierten Verkehr des OLSR nicht führen würde.<br>
<br>
Ich habe mich mit QoS vor einer Zeit sehr internsiv beschäftigt, als<br>
wir ebenfalls niemanden einschrenken wollten und dennoch jeder zweite<br>
diverse Bittorent ähnliche Sachen benutzt hat und wir pro 2-4  Mbit<br>
Anschlüsse 50-200 Leute versucht haben irgendwie zu bedienenen.<br>
<br>
Das letzte Problem was ich gesehen habe, war Benutzung von 53 UDP für<br>
nicht DNS Zwecke beim gleichzeitigen MAC Missbrauch der benachbarten<br>
Lokalklients, bei dem man nicht mal mit L7 Filter und MAC Filter<br>
dagegen kämpfen konnte.<br>
<br>
Wir mussten damals ob gewollt oder nicht gesamten externen 53 UDP Traffik<br>
auf Lokal DNS umleiten, und den externen Traffik des Lokalen DNS stark<br>
drosseln.<br>
<br>
lg Petr<br>
</blockquote></div><br>