Traffic Shaping mit Linux

[Masamune2]

Ich habe folgende Anforderung:

In einem LAN befinden sich ca. 500 Clients die alle gern ins Internet wollen. Die Internetleitung hat 50Mbit und es ist leider nicht möglich große Downloads zu verhindern, sprich die Leitung ist ziemlich schnell dicht.
Jetzt habe ich mir überlegt dem Router Traffic Shaping bei zu bringen um jedem Client eine mindest Bandbreite von 100kbit zu sichern. Wird diese nicht von jedem genutzt dürfen andere dafür mehr ziehen.

Habe mir hier schon "tc" angesehen steige jedoch noch nicht ganz durch. Ist hier jemand fit und kann mir genau bei dem Szenario helfen?

 

[master_0815]

Hallo,
Ich stand schon einmal vor dem gleichen problem mit meinen mitbewohnern in meiner wg.
Ich habe keine lösung gefunden. das problem ist, das dein downstream schon dicht ist, bevor du ts anwenden kannst. Den upstream zu kontrollieren wäre hingegen kein problem.

Wurde mich freuen, wem jemand mir widersprechen und eine lösung präsentieren könnte, aber ich glaube leider die wird es nicht so geben wie du die das vorstellst...

Viele grüße

 

[IceMatrix]

500 Clients mit 50Mbit ist schon ziemlich grenzwertig. Fraglich ob du das mit Traffic Shaping noch nennenswert optimieren kannst.

 

[Masamune2]

Naja rechnerisch bleiben für jeden User etwa 100kbit übrig wenn es gleichmäßig verteilt würde und das reicht aus.
Es geht hier nur darum auch dann noch zocken zu können wenn die Leitung durch Downloads dicht gemacht wird. Das über QoS und die Spieleports zu regeln ist leider keine Alternative da z.B. Steam sinnvollerweise zum Zocken und Updaten den gleichen Port verwendet.

 

[IceMatrix]

Zocken ist damit auch nicht mehr sinnvoll möglich. Ich denke mal du hast VDSL 50k, dann ist der Uplink 10k, d.h. da wären es rechnerisch nurnoch 20kbit/s pro Maschine. Und das reicht zum stabilen Zocken nicht mehr aus!

 

[Masamune2]

Nein, ich hätte 50mbit symetrisch....

 

[master_0815]

Eine Idee: Du benutzt keine Ports sondern die Protokolle für QoS!

Alle Spiele, bei denen es auf Reaktionszeiten ankommt nutzen in der Regel das UDP Protokoll, da hier eher ein Packetloss akzeptiert wird als eine Lange Antwortzeit bis das ACK Paket zurückkommt ^^

Daher mein Vorschlag alle UDP Pakete bevorzugt zu behandeln - technisch kein Ahnung wie - aber es muss gehen!

Zu dem Problem des Trafficshapings noch einmal etwas genauer:

Wie läuft das ganze denn Ab? Den meisten Traffic verursacht doch idR http(s). Ein User stellt eine Anfrage - das sind wenige byte outgoing traffic worauf hin der Server anfängt dir die Daten zu senden (unter Umständen viele GB)!

In diesem Fall musstest du halt mittels TrafficShaping den Upstream nicht anfassen, da er nahezu unausgelastet ist - der Server auf der Gegenseite pumpt nun aber deine Leitung voll mit Daten, ohne dass du überhaupt was shapen kannst.

Der Flaschenhals ist nunmal nciht dein Router sondern der DSL-Anschluss davor!

Klar - in dem Fall, dass die Leitung voll ist, könntest du einfach ACK-Pakete unterdrücken - dann würde der Server auf der Gegenseite noch einige Male Pakete erneut senden und dann aufhören -> Er geht davon aus, dein PC ist nicht mehr da... Das würde aber Surfen und Downloaden stark beeinträchtigen.

Eine weitere Möglichkeit wäre, durch den Einsatz eines HTTP-Proxys zu versuchen möglichst viel zu Puffern! Mittels eines Proxys könntest du auch Requests manipulieren die nach draußen gehen und hier Bandbreiten mit den Servern "vereinbaren" bzw. einzelne Anfragen kontrollieren.

Nur TS alleine wird Dir wohl nicht helfen!

Ergänzung (28. September 2011)

IceMatrix - du hast das Problem noch nicht verstanden

Und ich hoffe immernoch jemand findet eine Lösung - ich habe letztes Jahr dann ohne Erfolg "aufgeben müssen"

 

[c0mp4ct]

Das sollte sich mit MasterShaper regeln lassen. Dort kannst du service level anlegen und eine Bandbreite zuweisen. Ebenso lässt sich Bandbreite für Ports gesondert behandeln, so das Port x Bandbreite zu 100% nutzen darf und Port y nur zu 10%. Die Konfiguration ist jedoch sehr umfangreich.

 

[Masamune2]

Die Unterscheidung nach UDP und TCP ist ne sehr gute Idee (verdammt warum bin ich da nicht selbst drauf gekommen?^^), das werd ich mir mal genauer anschauen. Downloads durch HTTP sind kein Thema, das ist eh gesperrt.

Schlimm ist wirklich die Steamgeschichte, denn sobald die Ports offen sind die zum Spielen nötig sind ist auch die Möglichkeit gegeben Updates zu ziehen.

 

[master_0815]

Aber auch zum MasterShaper der Hinweis aus den FAQ:

Q: I often read that shaping is only really useful in combination with IMQ devices. Do I really need it?
A: Yes and no.
Like you know (from reading the MasterShaper documentation Wink ) the traffic control functions are very useful for outbound traffic - not for inbound. The reason is, because you are sitting on the false site of the network stream. For inbound you have only the change to slow down/drop/reject traffic.
But people wanted the some shaping possibilities for ingress like egress traffic. To make this possible, some guys wrote the Intermediate Queueing Device (IMQ).
Let's say you have a webserver with only one network interface. If you want to limit the inbound traffic (ftp uploads for example) you need IMQ to make shaping on this single network interface possible.
If you are on a gateway (one interface for WAN, one for LAN), you can also do the job without IMQ. Shape the outbound internet traffic on the WAN interface - the inbound internet traffic on the LAN interface - Because there inbound internet traffic is outbound!
But remember, that you can't shape traffic which is directly flowing to your gateway (http proxy on it...) - because shaping is only done on the internal interface.

 

[Masamune2]

Mastershaper sieht auch recht einfach aus, jedoch kann ich jetzt keine Möglichkeit erkennen pro IP im LAN eine bestimmte Bandbreite fest zu legen.

Wenn ich die Doku von "tc" richtig verstehe müsste ich für jeden Client im LAN eine Queue erzeugen und mit iptables dann anhand der Quell-IP auf die entsprechenden Queues verteilen. Die Frage ist ob das vom Kernel noch halbwegs gescheit abzuarbeiten ist wenn die Config dann über 1000 Zeilen enthält.

 

[master_0815]

Und wie gesagt - du kannst keinen Incoming Traffic Shapen Und das ist wohl die kritische Stelle

 

[Masamune2]

So einfach nicht, es müsste aber möglich sein die Download-Verbindungen mit RST Paketen zu unterbrechen wenn das ratelimit erreicht ist.

 

[IceMatrix]

Ergänzung (28. September 2011)

IceMatrix - du hast das Problem noch nicht verstanden

Doch, ich habe das Problem verstanden!

Und wie gesagt - du kannst keinen Incoming Traffic Shapen Und das ist wohl die kritische Stelle

Im Falle von TCP kannst du das schon tun, indem du dem remote Peer Congestion vorgaukelst. Das geht z.B. über die Window Size bei den ACK Paketen. So zwingst du den Peer langsamer zu senden.


@Masamune2: Mit RST kannst du gar nix unterbrechen, weil die Verbindung dann komplett tot ist. Das wäre bei HTTP fatal und kann zu fehlerhaften Übertragungen führen, ohne dass der Browser das merkt!

 

[Masamune2]

Richtig, aber HTTP ist mir egal, das ist eh gesperrt. Hauptsache Downloads werden unterbunden und zocken ist weiterhin möglich.

 

[IceMatrix]

Du hast glaube ich noch nicht verstanden, dass das Problem nicht alleine "echte" Downloads sind. Wenn ein paar Clients gleichzeitig im Web surfen, dann kommen große Trafficspitzen rein. Und genau die sind es, die das Zocken blockieren und Lags verursachen. Ziel deines Shapings sollte es sein dieses Verhalten zu blockieren, indem die Bandbreiten von _allen_ Transfers direkt beschnitten werden um Peaks zu vermeiden.

 

[Masamune2]

Nochmal für dich:

Es wird nicht gesurft! HTTP ist dicht!

Die einzigen Spitzen die überhaupt auftreten können ist durch den Download von Spielupdates. Wenn ich diese mit TCP RST Paketen torpedieren kann ist mein Ziel erreicht.

 

[IceMatrix]

Download von Spieleupdates via STEAM kannst du nicht ohne weiteres shapen, weil die Protokolle proprietär sind und über UDP laufen.

 

[Masamune2]

Ok dann hat sich der Punkt auch wieder erledigt...

 

[master_0815]

Falsch!

STEAM-Updates sind immer TCP-Traffic - alles andere wäre Quatsch! UDP wäre nicht sinnvoll!

TCP 27014 to 27050 inclusive (Steam downloads)

Quelle: https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711

Ergänzung (28. September 2011)

Sorry - klär mich auf - schick mir nen Link @IceMatrix

Im Falle von TCP kannst du das schon tun, indem du dem remote Peer Congestion vorgaukelst. Das geht z.B. über die Window Size bei den ACK Paketen. So zwingst du den Peer langsamer zu senden.

=> So wie ich das verstehe verwirft man am Router dabei Pakete oder bestätigt diese nicht D.h. die Leitung ist zu diesem Zeitpunkt schon dicht.... bereits vorher schon erklärt!

Bitte schick mir doch mal einen Link, wo ich das erklärt bekomme, konnte in 10 Minuten nichts passendes zu Peer Congestion finden! Auch die Window Size kann mir imho nicht weiterhelfen

Ergänzung (28. September 2011)

Es hat mich wieder aufs neue fasziniert:

Aber egal - es gibt "noch" keine praktikable Lösung um incoming traffic zu shapen

We want to limit our inbound traffic to avoid filling up the queue at the ISP, which can sometimes buffer as much as 5 seconds worth of data. The problem is that currently the only way to limit inbound TCP traffic is to drop perfectly good packets. These packets have already taking up some share of bandwidth on the ADSL modem only to be dropped by the Linux box in an effort to slow down future packets. These dropped packets will eventually be retransmitted consuming more bandwidth. When we limit traffic, we are limiting the rate of packets which we will accept into our network. Since the actual inbound data rate is somewhere above this because of the packets we drop, we'll actually have to limit our downstream to much lower than the actual rate of the ADSL modem in order to assure low latency. In practice I had to limit my 1.5mbit/s downstream ADSL to 700kbit/sec in order to keep the latency acceptable with 5 concurrent downloads. The more TCP sessions you have, the more bandwidth you'll waste with dropped packets, and the lower you'll have to set your limit rate.

Quelle: http://www.ibiblio.org/pub/Linux/do...e/ADSL-Bandwidth-Management-HOWTO.html#AEN149

Man kann diesen Traffic begrrenzen - senkt aber damit ebenfalls die netto-Bandbreite um einen noch größeren Betrag!