Eingehenden Traffic shapen?

[KiRKman]

Hallöchen! Bei meiner Durchforstung des Forums habe ich leider niemanden finden können, der es mal versucht hätte, auch eingehenden Traffic zu shapen. Ist dies überhaupt möglich, oder ist der Prozessor der Box hierfür prinzipiell zu schwach? Ich meine, wenn ich hier mit 2 MBit ziehe, dann könnte das schon schwierig sein, immerhin muß ja jedes Paket untersucht werden. Das Shapen bei meinem popeligen Upstream scheint die Box schon einige Mühen zu kosten.

Seltsam auch, daß hier immer wieder Leute von der Rule "rtp-fon" in ihrer ar7.cfg berichten. Diese Rule habe ich gar nicht. Ich habe stattdessen eine ganz andere Rule "voip". Diese Rule "voip" finde ich aber auch in anderen Posts. Ich frage mich allerdings, wer nun "rtp-fon" hat und wer "voip", und warum es da so verschiedene Rules gibt. Es ist ja nicht nur der Name unterschiedlich, sondern die ganze nachfolgende Konfiguration.

Aber mein Hauptproblem ist eben, daß bei Nikotel die abgehenden Pakete schön geshaped werden (bei Sipgate klappt dies nicht), aber eingehend wird eben nichts geshaped. So können mich alle schön hören, aber ich muß meine Downloads schleunigst abstellen, wenn jemand anruft. Die meiste Zeit uppe ich rein gar nichts, sondern lade nur etwas herunter. Daher wäre für mich eingehendes Shaping wesentlich interessanter als abgehendes. Nur befürchte ich, daß die Box dieser Datenmenge nicht gewachsen ist, oder? Ich ziehe direkt aus Europa (Amsterdam), daher ist meine Leitung, wenn der Download läuft, auch absolut bis zum Anschlag ausgelastet.

Für Ideen oder Erfahrungen wäre ich sehr dankbar. Meine standardmäßige Rule "voip" sieht übrigens so aus:

name = "voip";
filter = "(udp port 7078 or port 7079 or port 7080 or port 7081 or port 5060)";
priority = 2;
limiters = "default-out";

Diese Rule war von Anfang an in der Box drin und ich habe auch nie etwas daran geändert.

 

[W48]

Hallöchen! Bei meiner Durchforstung des Forums habe ich leider niemanden finden können, der es mal versucht hätte, auch eingehenden Traffic zu shapen.

Aus gutem Grund:

Du hast, im Gegensatz zu den abgehenden Paketen, sowieso keinen Einfluß darauf, was mit welcher Priorität zurückkommt, bevor es bei Deinem border-router aufschlägt. Und was da im einstelligen MBit-Bereich ankommt, riskiert ja nicht wirklich, einen Stau zu verursachen. 8)

Um Dein Problem zu lösen, müsste das download-Protokoll bei der Gegenstelle auch dann nur einen zu definierenden Prozentsatz Deiner Leitungskapazität als Maximalgeschwindigkeit anfordern, wenn prinzipiell mit wirespeed gerarbeitet werden könnte.

 

[KiRKman]

Also das Nadelöhr entsteht bei der Übertragung der ankommenden Daten auf meine ADSL-Leitung? Hört sich irgendwie logisch an. Also würde es wohl auch nichts bringen, aus dem ankommenden Datenbrei die RTP-Stream-Pakete auszusortieren und bevorzugt weiterzuleiten. Eine Priorisierung müßte also schon bei meinem Provider erfolgen. Da muß ich wohl weiterhin meine Downloads abstellen, wenn Anrufe eingehen.

Vielen Dank für die schnelle, nächtliche Info!

 

[olistudent]

Hi,
hast du mal versucht die Rules ein wenig zu ändern?
Wie z.B. hier: http://www.ip-phone-forum.de/forum/viewtopic.php?p=60560#60560

Das mit der voip-Rule könnte aus einer alten Firmware sein? In der aktuellen steht die rtp-fon Rule in den default-Files unter /etc/. Solange der VOIP-Traffic über die geshapten Ports geht, dürfte das ja auch keinen Unterschied machen...

MfG Oliver

 

[KiRKman]

Danke für den Link, habe es sofort ausprobiert. Hat aber leider nichts gebracht, absolut kein Unterschied. Sehr seltsam. Ich stelle meine Rule "voip" gerade mal auf die "neue" Rule "fon-rtp" um. Dann starte ich mal wieder alles neu und probiere nochmal aus!

EDIT: So, gerade nochmal ausprobiert (mit "fon-rtp Rule"). Hat aber auch nichts gebracht. Ich habe jetzt eine ar7.cfg, die aus alten und neuen Versionen zusammengebastelt ist

 

[jemi]

@KIRKman:

Hast Du die aktuelle FW drauf? Bei meinen Tests gab's kaum noch Probleme mit der Qualität. Evtl. solltest DU mal einen anderen DSL Provider versuchen (kannst Dir ja mal von einem Bekannten die Zugangsdaten kurzzeitig ausleihen).

Ich hatte es u.A. getestet mit BitTorrent (ohne ul/dl beschränkung) auf meiner Seite und einem Esel auf der Gegenseite. Jeweils TDSL1000. Provider waren wohl Freenet und 1und1(?). Gespräch war auf beiden Seiten tadellos.

 

[spongebob]

Du hast, im Gegensatz zu den abgehenden Paketen, sowieso keinen Einfluß darauf, was mit welcher Priorität zurückkommt, bevor es bei Deinem border-router aufschlägt. Und was da im einstelligen MBit-Bereich ankommt, riskiert ja nicht wirklich, einen Stau zu verursachen.

Kann ich nicht nachvollziehen. Ich meinte, bei einem FTP Download sehr wohl einen Einfluss auf die Durchsatzrate gesehen zu haben, wenn parallel ein Telefonat geführt wurde. Warum sollte TCP im Download nicht "shapbar" sein? Durch geschickte Verzögerung der ACKs kann die pumpende Gegenstelle doch durchaus ausgebremst werden, oder?

 

[jemi]

Durch geschickte Verzögerung der ACKs kann die pumpende Gegenstelle doch durchaus ausgebremst werden, oder?

Na nicht wirklich.
Du hast bei Dir eine Queue und "dein Provider" hat eine Queue.
Um deine Warteschlange kümmert sich die FBF und priorisiert VoIP hoch und bevorzugt diese Pakete beim Verschicken.

Der "Provider" muß das aber auch vernünftig umsetzen anderenfalls ließe sich eine störungsfreie VoIP-Verbindung nur dadurch aufbauen, das überhaupt kein einziges ack gesendet wird was nix mit VoIP am Hut hat. Ansonsten stehen immer irgendwelche "unwichtigen" Datenpakete in der Warteschlange beim Provider und behindern die wichtigen VoIP/Ack Informationen.

 

[spongebob]

Na nicht wirklich.
Du hast bei Dir eine Queue und "dein Provider" hat eine Queue.
Um deine Warteschlange kümmert sich die FBF und priorisiert VoIP hoch und bevorzugt diese Pakete beim Verschicken.

Der "Provider" muß das aber auch vernünftig umsetzen anderenfalls ließe sich eine störungsfreie VoIP-Verbindung nur dadurch aufbauen, das überhaupt kein einziges ack gesendet wird was nix mit VoIP am Hut hat. Ansonsten stehen immer irgendwelche "unwichtigen" Datenpakete in der Warteschlange beim Provider und behindern die wichtigen VoIP/Ack Informationen.

Mein lieber Scholli, Du kannst eine Menge Nebelkerzen werfen

Siehe, staune und lerne: Anbei ein Screenshot, der mit PERFMON den erzielten Durchsatz in Downloadrichtung wiedergibt. Die Abflachung zwischen "Minimum" und "Dauer" wurde verursacht durch --- tadaa: Ein abgehendes Telefonat über VoIP.

Ergo: Die Box drosselt durch geeignete ACK-Verzögerung (oder was weiss ich, so genau weiss ich das auch nicht) den maximal erzielbaren Durchsatz in Empfangsrichtung, der bei dem von mir verwendeten Server von T-Online locker bei ca. 380 kByte/s liegt. Dass das nicht immer klappt, sieht man an den beiden deutlichen Einbrüchen zwischendrin. Ach so, aufgezeichnet wurde über eine Zeit von 1:40 min im Sekundentakt.


w.z.b.w.

 

[jemi]

TC sollte aber auf der "Bevorzugung" von Paketen und nicht auf dem "verzögern" von Paketen beruhen. Zumindest in der praxisuntauglichen Theorie.

Den Download von allem ausser VoIP kann ich durch das nicht senden der entsprechenden ACKs zwar unterbinden...

Aber dann ginge ja NIX mehr neben VoIP. Sobald ich auch nur ein einziges böses ACK versehentlich loslasse wird ein unwichtiges Paket auf der Gegenstelle in der Warteschlange plaziert. Wenn die Genenstelle jetzt beim Bevorzugen von VoIP Paketen nicht richtig mitspielt wird nichts aus der knisterfreien Verbindung.

Es ist dabei imho nicht wichtig wie groß der Anteil der künstlich verzögerten kommunikation tatsächlich ist (angenommen man würde es durch Verzögerung erwirken). Ich glaube nicht das es ein sinnvolle/geeignetes Mittel ist.

Aber grau ist alle Theorie. Bei mir funktionierts ohne Probleme, ohne Knaser und ohne Echo.

An der FBF kanns also nicht liegen. :wink:

 

[olistudent]

Im log der Fritz stehen bei einem voip-Telefonat unter anderem diese Zeilen:

voipd[334]: bridgelimit: nConnections=1
voipd[334]: number of bridge interfaces 1
voipd[334]: found bridge lan with tiwlan0
voipd[334]: bridge lan set to max 30 packets/100ms

Inwiefern das jetzt Einfluss auf den Traffic hat, weiß ich aber nicht?

Und ich bin auch der Meinung, dass man mit verzögerten ACK's den Download drosseln kann. Der Server wartet ja auf den ACK und sendet das Packet nochmal wenn der nicht kommt. Kannst ja mal probieren was passiert, wenn du den ACK's eine niedrigere Priorität in der ar7.cfg gibst.
Da müsste das Surfen bei vollem Upload spürbar langsamer werden, würde ich meinen?

MfG Oliver

 

[spongebob]

Jemi, diese ganze Trafficshaperei wurde doch nur erfunden, weil die "klassischen" IP Netze keinerlei QoS Mechanismen haben. Da wird dann eben mit allen möglichen Tricks gearbeitet (bis hin zum Droppen von Packets, nur um die andere Seite zum Nachdenken - sprich Pause machen - zu bringen). Erreicht wird das Ziel allemal: Ein bestimmter Stream wird daran gehindert, die komplett z.V. stehende Bandbreite auszureizen (wozu er - siehe mein Fall - sicher in der Lage wäre, aber dann wäre es Essig mit Echtzeit Voice-Übertragung). Und man sieht ja auch am Graphen: Da wird sogar - gewollt oder ungewollt - echt heftig zurückgeregelt: ca. 60 kByte/s. Das sollte für einige Gespräche reichen

However. It works

Grüsse

 

[jemi]

Ich wollte nur zu bedenken geben das TC mehr als ACKs und Prorisierung ist.
Wer sich unter Linux schonmal mit tc beschäftigt hat kann vielleicht die Komplexität erahnen.

Ein Drosseln der Übertragungsgeschwindigkeit bedeutet nicht automatisch eine Möglichkeit latenzlos Gesprächsdaten nebenbei zu übermitteln. Das hängt stark von den verwendeten queues, den filtern die diese befüllen und den sonstigen Umständen ab.

Offensichtlich gibt es aber user die mit der FBF und zusätzlichem traffic keine Probleme haben und wiederum andere, bei denen das Gespräch darunter leidet.

 

[KiRKman]

@Jemi: Jow, ich habe die aktuelle Firmware 06.03.37 druff. Als Internet-Provider habe ich momentan drei zur Auswahl Macht aber absolut keinen Unterschied. Ich habe gehört, daß bei Freenet keine Probleme auftauchen sollen, also denke ich mal, daß ich bei denen auch keine Probleme hätte. Bei mir klappt es absolut einwandfrei mit Nikotel und GMX. Auch Stanaphone habe ich bereits erfolgreich verwendet. Was nicht funktioniert, sind Sipgate und SipSnip. Die Rattern und Knistern total.

Wenn Du auch einen Sipgate-Account hast, würde mich mal interessieren, wie bei Dir die Qualität bei Gesprächen in's Festnetz ist, wenn Du einen Upload laufen hast. Ich höre alles glasklar, aber meine Gegenüber können mich vor Gebrutzel gar nicht verstehen...