Warum Trafficshaping nicht klappt bei VoIP!

traxanos

Mitglied
Mitglied seit
15 Jul 2004
Beiträge
486
Punkte für Reaktionen
0
Punkte
0
Ich möchte heute mal erläutern weshalb herkömmliche Trafficshaper im VoIP Bereich leider immer wieder Probleme bereiten. Dabei möchte ich erläutern weshalb diese Trafficshaper nicht funktionieren können.

Ich habe es die Tage schon einmal erklärt und möchte dies nun in einem vernünftigen Beitrag mit vernünftiger Überschrift tun ;)

Hier der alte Beitrag:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=13879

QoS ist mehr als eine Trafficshaper. Ein Trafficshaper hat eigentlich zur Aufgabe dafür zusorgen das Down- und Up-Stream nicht zusammen brechen bei großer Belastung. Hier drauf werde ich gleich aber noch genauer drauf eingehen.

Schauen wir jetzt den SFQ an. Dieser Scheduler ist ganz rechte etwas für VoIP. Er legt 127 Bänder an und verteilt jedes Paket auf diese Bänder. Durch seinen Algorithmus sorgt er, dass alle Verbindungen gleich behandelt werden. Doch leider gibt es einen großen Haken: eMule, das böse Haustier. Diese P2P – Programme erzeugen mehrere hunderte sogar bis tausende Verbindungen gleichzeitig. Und wenn nun alle Verbindungen gleich behandelt werden, stehen die VoIP Verbindungen nicht gut dar.

Der Token Bucket Filter (TBF) dabei sorgt dabei das jede Klasse eine bestimmte bzw. die gleiche Anzahl von Tokens bekommen. Sendet eine Klasse mehr als sie eigentlich kann, müssen die Pakete warten bis wieder Tokens verfügbar sind. Sendet eine Klasse weniger als Sie könnte kann Sie Tokens weiter geben. Aber warum kann man den bei Trafficshapern Prioritäten vergeben? Diese dienen lediglich dazu um zu entscheiden wer zuerst die Tokens erbt die eine andere Klasse nicht benötigt.

Sie sehen ja selbst, hier wird lediglich die Bandbreite verteilt. Trafficshaper, verwenden diesen Scheduler gerne, da man gleichzeitig dafür sorgt, dass die Leitung immer für Bestätigungspakete freigehalten wird in dem man die maximalen Werte der Leitung nicht überschreitet.

Nehmen wir uns den Hierarchical Token Bucket (HTB) zur Brust ;) Dieser basiert auf dem TBF und beinhaltet auch die gleichen Optionen zur Steuerung. Allerdings verteilt er die Tokens etwas anders. Dieser Scheduler kann etwas besser eingestellt werden und wird hauptsächlich für Trafficshaper verwendet. Ich möchte euch gerne eine Beispiel aus dem Linux-Magazin zeigen um zu verdeutlichen weshalb dieser Scheduler nichts für VoIP ist:

Angenommen jedes zu sendende Paket ist 1500 Byte groß und alle Klassen senden mit maximaler Kapazität. Aufgrund der Leitungskapazität von 1000 KBit/s dauert es 12 Millisekunden, um ein Datenpaket zu versenden: 11.500 Byte/Paket * 8 Bit/Byte / 1.000.000 Bit/s = 12 ms/Paket. Sendet die VoIP-Anwendung mit 100 Kbit/s, dann sind das bei 1500-Byte-Paketen etwa acht Pakete pro Sekunde: 1.000.000 Bit/s / ( 1500 Byte/Paket * 8 Bit/Byte) = 8,33 Pakete/s. Um die garantierte Rate von 100KBit/s für diese Klasse einzuhalten, muss die QDIsc (ich habe Sie Scheduler genannt) spätestens alle 120 Millisekunden ein Datenpaket der Klasse versenden: 1 Paket / 8,33 Pakete/s = 0,12s. Daraus ergibt sich eine Maximalverzögerung von etwas 130 ms pro Paket. (120+12)

Das Beispiel illustriert die enge Verflechtung von Bandbreite und Verzögerungszeit.

Ich denke ich muss hier nicht weiter eingehen. Man sieht, dass die meisten Trafficshaper eigentlich überhaupt nicht VoIP tauglich sind. Man sollte aber auch beachten Trafficshaper QoS Scripte die eigetnlich nur dafür sorgen, dass die Leitung nicht überlastet wird und damit die Verbindungen und deren Leistungen einbrechen.

AVM benennt Ihre QoS-Scripte als Trafficshaping weshalb das Wort im eigentlichen Sinne missverstanden wird. Es hat schon seinen Grund warum es das Wort QoS und Trafficshaper gibt.

Allerdings möchte ich einen Scheduler nennen der die Lösung für VoIP bietet: HFSC. Ich selber aber hatte noch keine Zeit gefunden mich mit diesem Scheduler genauer zu befassen. Glücklicherweise hat Udosw hier im Forum sogar meinen Hinweis genutzt (glaub ich:D) und hat sogar schon ein vorhandenes Script angepasst an HFSC.

Hier der Link zum Thread:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=14148

Ich hoffe, dass das Script von Ihm euch helfen wird die Probleme mit QoS zu lösen. Evtl. werden auch paar Hersteller von Routern bald diese HFSC Scheduler unterstützten und VoIP wird dann noch mehr Spaß machen, als es das schon macht.
 
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
 
Ich wollte kein Allerheilmittel geben. Ich wollte mal grob erklären, warum ein normaler Trafficshaper immer Probleme macht. Ich selbst verwende kein QoS und bei mir klappt VoIP auch.

Allerdings nutze ich meine Leitung anders. Und wenn du sagst das die FBF 1A klappt warum gibt es jeden Tag einen beitrag dazu weil irgendwer Probleme hat. Und die sind nicht immer Codec abhäning, auch wenn die Probleme durch einen anderen Codec nicht auftreten.

Ich bin auch weder ein Journalist der hier 1a Texte liefert, noch ein Student der hier eine Dokterarbeit liefert. Dieses Thema könnte aber eine komplette Doktorarbeit füllen.

Ich hoffe anderen wird es helfen zuverstehen warum
es immer wieder Probleme gibt beim Thema QoS.
 
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. :-(
 
Ich verstehe das Problem. Allerdings kenne ich keinen Router der Sich wirklich 100% für VoIP eignet. Man braucht ja HFSC o.ä. damit es klappt.
Wer wirklich auf nummer sicher gehen will baut sich nen LinuxRouter.
Ich selbst verwende die Astarofirewall und versuche gerade eine möglichkeit zu finden HFSC auf Ihm zum laufen zu bringen. Das wäre ja dann die Lösung ;)
 
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.

Welche Konfiguratioen sollte man denn vornehmen ?
 
Leitungsverzögerung und QOS

Anonymous schrieb:
Welche Konfiguratioen sollte man denn vornehmen ?
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. :confused: ) 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:
Code:
  0 
/ \ \
1 2 3
|
4
Der einfachste Fall ist eine Unterebene mit 2 Queues, eine für VoIP und eine für den Rest.
Code:
   0 
 / \
/   \ 
1     2
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....:phone:
 
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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.