HFSC zur Zwangspriorisierung bei DSL-Light?

[MReimer]

Hallo,

ich würde gerne einen letzten Versuch wagen, mit DSL-Light einigermaßen zuverlässig VoIP nutzen zu können. Hier im Dorf wird in absehbarer Zeit nichts anders verfügbar sein und wenn das mit der Priorisierung nichts wird, dann bleibt nur der Umstieg auf ISDN.

Ich habe für den Zweck für 10 EUR eine Fritz!Box SL beschafft, die mit OpenWRT laufen müsste. Ziel der Aktion: OpenWRT auf die Schachtel und dann ein tc/iptables Script drauf, welches VoIP via HFSC priorisiert. Das ganze vor die Fritz!Box Fon. Direkt auf der Fritz!Box Fon ist mir zu frickelig. Ich will die ganzen Binärbrocken jetzt aus dem Routing raushaben und alles Open Source haben.

Ich habe ein Script, basierend auf dem schonmal hier diskutierten SipShaper, unten angehängt. Wenn ich HFSC richtig verstanden habe, dann teilt mein Script die verfügbaren 64kbit in einmal 4kbit und einmal 60kbit auf. Wenn das zuverlässig geht und ich ggf. noch den Sprachcodec umstelle, dann sollte bei 60kbit schon ein Gespräch in sauberer Qualität gehen.

Die wichtigste Frage: Was passiert, wenn garkein VoIP genutzt wird? Wird dann der "reguläre Traffic" ständig auf 4kbit reduziert?

Sonst irgendwelche Kommentare zum Script?

#!/bin/sh
#
# Based on SipShaper v0.01beta Written by Udo Schacht-Wiegand
# http://www.ip-phone-forum.de/showthread.php?t=72590

# Set your outgoing interface and upload rate (in kbit/s) here
DEV=ppp0
RATEUP=64

# Reset everything to a known state (cleared)
tc qdisc del dev $DEV root    2> /dev/null > /dev/null

# Flush and delete tables
iptables -t mangle --delete POSTROUTING -o $DEV -j SIPSHAPER 2> /dev/null > /dev/null
iptables -t mangle --flush        SIPSHAPER 2> /dev/null > /dev/null
iptables -t mangle --delete-chain SIPSHAPER 2> /dev/null > /dev/null

# add HFSC root qdisc
tc qdisc add dev $DEV root handle 1: hfsc default 10

# add main rate limit class
tc class add dev $DEV parent 1: classid 1:1 hfsc sc rate ${RATEUP}kbit ul rate ${RATEUP}kbit

# keep it simple: two classes only
tc class add dev $DEV parent 1:1 classid 1:10 hfsc sc umax 1500b dmax 53ms rate  4kbit ul rate ${RATEUP}kbit
tc class add dev $DEV parent 1:1 classid 1:11 hfsc sc umax 1500b dmax 30ms rate 60kbit ul rate ${RATEUP}kbit

# add SIPSHAPER chain to the mangle table in iptables 
iptables -t mangle --new-chain SIPSHAPER
iptables -t mangle --insert POSTROUTING -o $DEV -j SIPSHAPER

# Filter for voip packets
tc filter add dev $DEV parent 1: prio 1 protocol ip handle 1 fw flowid 1:11 

iptables -t mangle -A SIPSHAPER -p udp --sport 5060 -j MARK --set-mark 1   # SIP High
iptables -t mangle -A SIPSHAPER -p udp --dport 5060 -j MARK --set-mark 1   # SIP High

iptables -t mangle -A SIPSHAPER -p udp --sport 4569 -j MARK --set-mark 1   # IAX High 
iptables -t mangle -A SIPSHAPER -p udp --dport 4569 -j MARK --set-mark 1   # "" 

iptables -t mangle -A SIPSHAPER -p udp --sport 10000:11000 -j MARK --set-mark 1   # RTP High 
iptables -t mangle -A SIPSHAPER -p udp --dport 10000:11000 -j MARK --set-mark 1   # ""

 

[stinkstiefel]

@MReimer ich habe mich 2006 auch mal etwas intensiver mit QoS beschäftigt und möchte dir meine Erkenntnisse natürlich nicht vorenthalten. Egal mit welchem Regelwerk ich es versucht habe ich bin auf keinen grünen Zweig gekommen. Ziel war für mich VoIP an einem 384/64 Anschluss so zu priorisieren das nebenbei wenn auch langsamer noch gesurft werden kann und sich dieses surfen nicht auf die Sprachqualität auswirkt. Intermediate Queueing Device habe ich damals auch ausprobiert, hat mich meinem Ziel jedoch nicht näher gebracht. Ich habe mein Vorhaben nach sehr viel lesen und ausprobieren mit funktioniert bei Resourcenknappheit nicht abgehakt. Da wir jetzt 2009 schreiben und sich bezüglich QoS so einiges getan haben wird will ich dich natürlich von nichts abhalten.

 

[MReimer]

Wenn die Chancen schlecht stehen, dann würde ich meine Zeit natürlich lieber anders invenstieren

Wo kann man eigentlich mit den Entwicklern rund um HFSC und Co. in Kontakt treten. Vielleicht hat ja dort jemand einen hilfreichen Tipp...

Bei mir ist es auch 384/64. Wenn sich da keine Lösung finden lässt, dann bleibt nur der Schritt zu ISDN und damit zu höheren Kosten.

 

[stinkstiefel]

Es kommt halt darauf an was du möchtest. Abgehend zu priorisieren, limitieren oder was auch immer stellt eigentlich kein Problem dar. Knackpunkt an der Geschichte ist halt der eingehende Datenstrom. An dieser Stelle kann man so gut wie nicht unterstützend eingreifen weil das eigentlich die Gegenseite, also dein Provider, für dich machen müsste. Type of Service (TOS) bits sind zwar ne feine Sache werden aber nicht konsequent ausgewertet.

 

[MReimer]

Ich glaube nicht, dass der Downstream das Problem ist. Der ist mit 384kbps ja eigentlich auch mehr oder weniger reichlich groß. Kritisch dürfte der Upstream sein, und hier bräuchte ich eben eine möglichst restriktive Regelung, die einen möglichst großen Anteil der schmalen Bandbreite für VoIP freimacht.

 

[stinkstiefel]

Okay nehmen wir dein Script mal auseinander. In der Parentklasse 1:1 garantierst du 64kbit, dass ist eigentlich schon zu viel und die gewählte Servicekurve für Realtimedaten ist auch nicht optimal, naja lassen wir das. Wenn du nicht glaubst das es beim Downstream klemmt probiere einfach mal etwas aus. Lege zwei Klassen mit fest zugesicherter Bandbreite an, eine für Realtime und eine für Bulktraffic. Für VoIP benötige ich bei mir ca. 32 kbit/s lässt sich prima mit bwm-ng messen. Wenn du dann die Klasse für den Bulktraffic auf sagen wir mal 10 kbit im Upload festnagelst mit welchem Speed wird dann etwas heruntergeladen? Ein Download läuft bei mir dann nämlich immer noch mit der vollen zur Verfügung stehenden Bandbreite von ca. 384 kbit/s ab. In diesem Fall schlagen dann aber Realtimetraffic und Bulktraffic gleichermassen bei ppp0 auf (Queuing). Ich hatte damals keine Chance den Bulktraffic schnell genug zu verwerfen um so den Realtimetraffic ungehindert zu empfangen.