Warum Trafficshaping nicht klappt bei VoIP!

Dieser Beitrag ist ein "Wichtig" wert.

Dieser Beitrag hat mich - unabhängig davon, ob das AVM TS was taugt oder nicht - überhaupt nicht überzeugt, da er in sich weder schlüssig ist noch besonders in die Tiefe geht und außerdem auch noch schlecht erklärt wird.
Die Theorie mit 12ms und 1500 Bytes Paketgröße mag gut geieignet sein, um besser rechnen zu können, leider war es das auch schon, da in der Praxis viele unterschiedliche Paketgrößen zum Einsatz kommen ( VoIP ~ 335 Bytes, TCP Ack ~ 62 bytes ).Das der AVM Shaper funktioniert, kann man ganz deutlich sehen und hören, selbst bei laufendem Esel ist eine sehr gute Verbindung über z.B. GMX möglich.Bei Benutzung des T-DSL Speedmanagers kann man auch sehen, wie sich Up und Download verändern, sobald eine VoIP Verbindung aufgebaut ist.

Grüße

TWELVE

Schöner Beitrag, traxanos!

Trotzdem drängt sich mir die Frage auf, wie man denn (speziell als Laie) "geeignete" Router finden kann/soll?
Mit dem Muli allein sind ja schon viele überfordert, manche können gar nicht so viele Verbindungen verwalten und hängen sich weg...
Nun auch noch QoS und/oder Trafficshaping obendrauf - weia. :-(

Traxanos,

erstmal danke für den doch sehr informativen Beitrag. Ich selbst habe von
Qos und Trafficshaping bisher kaum Ahnung. Hatte aber vor mich dort ein zu arbeiten, da ich doch ab und zu qualitätsschwankungen beim Telefonieren und Störgeräusche hatte...

Zu dem Thema allerdings folgendes.
Die erste Zeit lief alles wunderbar.
Ein feiner selbstgebastelter Linux Router tat seine Arbeit hervorragend.
Plötzlich fing es dann an mit den Störgeräuschen...
Die haben mich die letzten Wochen eine Menge Schweiß und Nerven gekostet und ließen sich leider doch einfach nicht beheben... und das bei einer dicken Hansenet Leitung mit Fastpath...
Gestern dann habe ich einfach mal unseren Netzwerkswitch vom Strom genommen und neu gestartet....
Oh wunder, alles läuft wieder perfekt...

Dies nur als beispiel wie fehlerhaft Fertiggeräte (gerade günstige Netzwerkhardware) oft arbeiten. Auch günstige DSL Modem's reißen oft ab 800 gleichzeitig offenen Verbindungen die Hufe hoch... Und Hardwarerouter die nicht im Preissegment ab 300 EUR liegen auch. (Ich habe da Erfahrungen mit einem Edonkey Server hinter einem Router... ... no way...)

Ein vernünftig und sicher konfiguriertes Linux System, mit ein klein wenig Leistung wirkt wahre Wunder...
Zur Zeit laufen problemlos zwei Telefonate in astreiner Quali und nebenbei zieht ein Donkey mit über 1000 zugelassenen Verbindungen und 150k downstream...
Qos und Trafficshaping sind da nicht von nöten. Man muss halt sehen, dass die anderen Programme die Leitung nicht voll auslasten.

Hardware Router haben schlicht das Problem, das sie oft ab einer gewissen Anzahl an offenen Verbindungen deutlich langsamer werden... Da Hilft aber halt auch QoS nicht...
-> gute Hardware kaufen... oder gleich einen Rechner als Router aufsetzen.
Ideal eignet sich z.B. www.ipcop.org als Distro für ein solches Gerät.
Und wenn man sich dann noch eine Mini-ITX PC zusammenstellt halten sich auch die Stromkosten bei 60 - 90 Watt in Grenzen...

Gruß, M

empunkt schrieb:

Ein vernünftig und sicher konfiguriertes Linux System, mit ein klein wenig Leistung wirkt wahre Wunder...
Zur Zeit laufen problemlos zwei Telefonate in astreiner Quali und nebenbei zieht ein Donkey mit über 1000 zugelassenen Verbindungen und 150k downstream...
Qos und Trafficshaping sind da nicht von nöten. Man muss halt sehen, dass die anderen Programme die Leitung nicht voll auslasten.

Zum Vergrößern anklicken....

Welche Konfiguratioen sollte man denn vornehmen ?

Leitungsverzögerung und QOS

Anonymous schrieb:

Welche Konfiguratioen sollte man denn vornehmen ?

Zum Vergrößern anklicken....

So hart es klingt, aber um die bestmögliche VoIP-Verbindung, d.h. niedrigste Verzögerung, zu erhalten, darf nichts anderes parallel senden. Das Problem sind andere Pakete die die Leitung blockieren.

Nehmen wir Folgenden Fall: VoIP + ftp-upload
Bei einer (idealen!) Leitung mit 128MBit im Upstream braucht ein maximal großes Paket mit 1500 Byte mit ca 61ms bis es durch die Leitung durch ist. (im Orginalposting rechnet das Linuxmagazin mit 11500Byte, wie die darauf kommen ist mir schleierhaft. ) Da ein Paket bei DSL nicht teilbar ist wird es auch immer ganz übertragen, sobald die Übertragung gestartet wird. Kommt jetzt ein VoIP-Paket so muß es im Schlimmsten Fall 61ms und im Mittel 30,5ms warten.
Jetzt sind wir allerdings erstmal auf dem ersten Router unseres Providers, fürs Internet rechne ich mal einfach 10ms, dann kommen noch 1-6ms an der Gegenseite dazu.(ich nehme mal auch DSL an).
Ein VoIP-Paket selbst hat im Normalfall ca. 10-30ms Sprachdaten. Also kommt noch die Zeit im Telefon dazu, um das Aufzunehmen und zu verarbeiten, rechnen wir mal mit 20ms+2*5ms in jedem Telefon um es zu verpacken/entpacken. Damit haben wir insgesammt 76,5ms im Mittel, wenn alles optimal läuft und immer genug Bandbreite zur verfügung steht.
Ohne einen parallelen Download fällt zwar die 30,5ms Paketverzögerung weg, aber das interleaving hängt nochmal im Mittel 20ms an. Maximal kommen 40ms dazu, was sich auf einer leeren DSL-Leitung mit einem einfach Ping überprüfen lässt.

Alle noch dabei? Gut, weiter gehts.
Das Problem bei der Sache ist jetzt, das wir den Buffer (oder auch Queue) in unserem DSL Modem/Router nicht beachtet haben. Ist er leer kommt ein neues Paket nur kurz rein und wird sofort weitergeschickt, normalerweise mit einer Verzögerung unter 1ms. Ist er aber fast voll, so müssen erst alle anderen Pakete aus dem Buffer raus. Selbst bei einem 10 Pakete großen Buffer sind das schon 10*61ms=610ms! Meiner Erfahrung nach ist der Buffer im Router/Modem wohl eher 20-30 Pakete groß.

Und jetzt kommt endlich das Trafficshaping ins Spiel.
Um zu vermeiden, daß die VoIP-Pakete in der Queue hängen bleiben begrenzt das Trafficshaping die Datenrate auf einen Wert knapp unter dem Maximum. Somit haben wir immer nur ein Paket in der Queue und damit die 76,5ms Verzögerung. Den selben Effekt erreichen wir natürlich auch, wenn die anderen Anwendungen wie z.B P2P einfach soweit begrenzt wird, das angeforderte Bandbreite immer ein gutes Stück unterhalb der Leitungskapazität liegt.

Der Haken bei der Sache
So einfach ist das ganze natürlich nicht, denn bis jetzt sind wir davon ausgegangen, daß unsere IP-Pakete immer angenommen werden und auch noch direkt als nächstes weggeschickt werden. Hätten wir unseren Ideafall von einem 1-Paket großen Buffer für eine möglichst geringe Verzögerung, dann könnte es passieren, das der Buffer noch voll ist und das Paket verworfen wird. Unser Buffer sollte also schon etwas größer sein.
Das zweite Problem ist, das nicht alle Programme konstant senden sondern unter Umständen in sogenannten "Bursts", im Gegensatz zu VoIP, daß eine sehr konstante Datenrate hat und vorallen immer in regelmäßigen Abständen sendet. Im Schlimmsten Fall nutzt ein Programm seine gesammte Übertragungskapazität pro Zeiteinheit gleich am Anfang aus und schickt ermal soviele Pakete wie möglich los. Damit hat es zwar im Schnitt eine geringere Datenrate, der Buffer ist aber trotzdem voll und unser VoIP-Paket muß im Buffer warten bis die anderen Pakete weg sind oder geht sogar verloren.

Erweitertes Trafficshaping mit HTB-Queues (Linux)
Beim Hierarchical Token Bucket Filter gibt es nicht nur einen Buffer/Queue sondern mehrere, die man noch, wie der Name schon sagt, hierarchisch anordnen kann:
Der einfachste Fall ist eine Unterebene mit 2 Queues, eine für VoIP und eine für den Rest.
Nach bestimmten Regeln wird nun jedes ankommende Paket in eine der beiden Queues einsortiert. Beim Auslesen wird nun nachgesehen welche der beiden Queues die höhere Priorität besitzt und dann von dort ein Paket entnommen, falls diese Queue noch genug Bandbreite übrig hat.
Mit HTBs lassen lassen sich also 2 Probleme auf einmal lösen:
1) Bregrenzung der Bandbreite, um lange Queues im Modem oder im Router des ISPs zu vermeiden.
2) Priorisierung von Paketen, um damit die VoIP-Pakete schnellstmöglichst weitergeleitet werden

:!: Zusammenfassend kann man sagen, daß man immer eine vom Netzaufbau und der DSL-Bandbreite abhänige Grundverzögerung hat, die man sich durch viel Traffic beliebig verschlechtern kann. Trafficshaping versucht Queues zu vermeiden und/oder zeitkritische Pakete daran verbeizuschieben.

Links:
http://luxik.cdi.cz/~devik/qos/htb/
http://www.lartc.org/

Hi, HFSC achtet auf die Latenzzeiten und schickt zeitkritische Pakete direkt weiter auf Kosten der anderen Klassen.

Also bei mir funktioniert das hervorragend, aber auch ich habe alle 2 Tage mal einen kurzen Aussetzer. Damit kann ich leben....hone:

Für einen Router mit eingebautem VoIP kann das doch eingentlich nicht so schwer sein ?!
Die Firtz!Box weiss ja, welche Pakete VoIP sind und welcher Codec wieviel Bandbreite braucht.
Also muss die Fritz!Box doch nur die Bandbreite für alle Nicht-VoIP Pakte runtersetzten. Und das ohne Berücksichtigung auf optimale Ausnutzung (Nicht-VoIP wird zur Sicherheit mehr langsam als nötig).

Problem der Firtz!Box ist ja eher, das nach beendetem Gespräch der Shaper die Bandbreite nicht raufsetzt.

Moin,

bei Lancom funktioniert es ohne Probleme und sehr zuverlässig.



Thorsten

Mein Thomson SpeedTouch Router macht QoS und ich telefoniere inzwischen absolut problemfrei über VoIP. Wie im ersten Beitrag schon geschrieben wurde: QoS ist eben mehr als Traffic Shaping.

Thanks for the post. Some of the problems encountered is the quality of VoIP phone calls suffered when it is used to downloading or uploading anything.

Ich habe jetzt auch schon 3 verschiedene Router durch, bis hin zu OpenWRT und bei keinem war es möglich das neben P2P noch Voip 100% stotterfrei lief wenn die Leitung knallvoll war (DSL3000). Gerade auch beim Download sind viele Implementierungen gar nicht aktiv. Mit intserv statt diffserv sowieso nicht.