Wie: Priorisierung downstream

ohjagut

Neuer User
Mitglied seit
5 Sep 2005
Beiträge
41
Punkte für Reaktionen
0
Punkte
6
Hallo,

im Forum habe ich einige Themen zu Priorisierung gefunden. Dabei scheint es jedoch immer um den Upstream zu gehen - so verstehe ich auch AVMs Hilfetexte zu Prioriesierung. Mir aber geht es um den Downstream:

==============================
So ist die Lage:
An der FB hängt ein Rechner über LAN, beide Funkkanäle (2.4/5 GHz Band) sind aktiv, mehrere WLAN Clients.

Ein Gerät am 5er-WLAN soll priorisiert werden: Es ist ein Rechner mit LibreElec/Kodi, der Mediathek Inhalte auf dem TV darstellt.
Dieser Rechner erhält als Netzwerkgerät immer die gleiche IP, hat den Namen LibreElec und ist unter der Einstellung Priorisierung sowohl unter "Echtzeitanwendungen" wie "Priorisierte Anwendungen" als Gerät konfiguriert.

Trotzdem, wenn zb. auf einem anderen WLAN-Netzwerkgerät (z.b Tablet) oder dem LAN-Gerät ein größerer Download läuft, bricht die Datenrate auf LibreElec ein, die Wiedergabe stockt.

==============================
Das ist die Frage:
Wie konfiguriere ich die FB, so dass das gewünschte Gerät nicht von Netzwerkaktivitäten anderer Geräte beeinflusst wird?


Weiß jemand eine Antwort?


Fb 7490, aktuelle Firmware
 
BandSteering AUS (?) !

Fester Kanal, KOexistenz, Radar, ....
Da ist mehr zu bedenken, als nur die Prio, also die Settings FB-WLAN per Screenshot bitte ...
 
IMHO: das Priorisieren im Bereich Ethernet macht üblicherweise der Sender; bei Upstream kann die Fritzbox dies übernehmen, bei Downstream wird das für Fritzbox wohl schwierig.
 
Die FRITZ!Box bietet trotzdem (zumindest theoretisch) wohl auch die Möglichkeit, Downstream-Traffic zu "bremsen" ... zumindest behauptet das AVM selbst:
info.txt schrieb:
NEU - Gesicherte Datenrate für Heimnetzgeräte trotz intensiv genutztem Gastnetz
Dabei soll ein Parameter "ds_weight_min" für eine QoS-Queue gesetzt werden ... ich wollte das zwar gerne mal testen, aber das funktioniert (zumindest bei mir) nicht einmal im GUI richtig, diese Funktion unter "Internet -> Filter -> Priorisierung" einzurichten.

Solange da keine Queues (als "regulation_queue") existieren, läßt sich lt. Lua-Code nicht einmal das "regulation_enabled" auf "1" setzen (weil "homenet" und "guest" nicht gesetzt sind) ... aber selbst wenn man das von Hand macht, ergibt das noch nicht automatisch (z.B. beim Start des "dsld") irgendwelche "regulation_queues" (auch nicht nach einem kompletten Neustart der Box).

Es besteht natürlich immer die Gefahr, daß ich meine Boxen total verkonfiguriere bei irgendwelchen Untersuchungen (oder meinetwegen "Experimenten"), aber auch bei einer Box in Werkseinstellungen ließ sich (zumindest beim letzten Test, bei der 06.83 habe ich es nicht erneut versucht - die "trafficprio.lua" sind identisch bei beiden Versionen) über das GUI dort nichts einschalten.

Wenn die FRITZ!Box da tatsächlich den Downstream drosseln sollte, wäre das zumindest mal ein Ansatz (den man dann ggf. manuell um weitere Queues ergänzen könnte, wenn es wirklich funktionieren sollte) ... aber sie kann das ja nur zusätzlich verzögern und darauf setzen, daß andere Maßnahmen - z.B. das Congestion-Management vom TCP - dann auf diese zusätzlichen Verzögerungen oder gar mutwillige Paketverluste reagieren und sich beim Senden "herunterregeln".

Ansonsten wäre der DSLAM bzw. der dort vorgelagerte Router ja dafür zuständig, welcher Traffic jetzt bevorzugt zum Kunden über die TAL gesendet wird - das kann ich mir max. noch anhand von TOS-Flags o.ä. vorstellen, wobei ich mir nicht sicher bin, welcher Provider das auf seinen Core-Routern überhaupt auswertet und wie sich das dann in Richtung Peripherie "ausdünnen" mag. Ohne diese Flags zu berücksichtigen, kippt der vorgelagerte Router halt das in die DSL-Leitung, was bei ihm der Reihe nach in der Queue steht und wenn da 90% für andere Clients sind und nur 10% für den "Stotterer", dann müssen trotzdem diese 90% auch erst einmal über den Kupferdraht, bevor die FRITZ!Box sie ihrerseits verwerfen kann.

Wenn dieser zusätzliche Traffic also mit Protokollen erzeugt wird, die selbst keine Flußkontrolle unterstützen, dann kann auch die FRITZ!Box dagegen nichts mehr machen ... ein solches Beispiel wäre ein RTP-Stream auf UDP-Basis - da kommen die Daten eben kontinuierlich herein und irgendwelche Verzögerungen machen sich als Jitter bemerkbar, den eine Applikation i.d.R. durch Pufferung abmildern möchte. Es gibt aber keine Quittungen und auch der Absender solcher "Echtzeitdaten" kann seinerseits die Datenrate nur dadurch "herunterregeln", daß er entweder besser komprimiert oder die Abtastrate verringert - beides i.d.R. zu Lasten der Qualität.

Erst wenn da anstelle von UDP z.B. DCCP ins Spiel käme, könnte man eine "Staukontrolle" auch für UDP realisieren und die Box konnte durch die Simulation so eines Staus dann regulierend eingreifen - das wird aber m.W. kaum verwendet. Andere "datagram"-basierte Protokolle verwenden dann ggf. noch einen zweiten Steuerkanal, um irgendeine Flußsteuerung zu realisieren ... blöd nur, wenn diese Pakete ebenso wie die eigentlichen Daten behandelt werden und ggf. das Opfer von absichtlichen "drops" werden, weil das so ein "Ventil" nicht unterscheidet (und es vielleicht gar nicht kann).
 
Die FRITZ!Box bietet trotzdem (zumindest theoretisch) wohl auch die Möglichkeit, Downstream-Traffic zu "bremsen" ... zumindest behauptet das AVM selbst:

Vielen Dank für die ausführiche Antwort! Es scheint also geringe Hoffnung zu bestehen.

Technisch verstehe ich allerdngs nicht, warum die FB das Drosseln anscheinend so leicht nicht selbst erledigen kann: Ein Anwendungsprogramm (Downloadmanager, Torrent-Client, Browser etc) kann doch sehr wohl mit limitierter Bandbreite laden.

Dank und Gruß
 
Ich würde dem betreffenden Rechner ein eigenes VLAN geben und das über einen der Fritzbox nachgeschaltetem konfigurierbarem Switch (kleiner Procurve oder so) priorisieren.

HTH
 
Technisch verstehe ich allerdngs nicht, warum die FB das Drosseln anscheinend so leicht nicht selbst erledigen kann:
Programme mit solchen "Drosselmöglichkeiten" kommunizieren direkt mit dem anderen Endpunkt und können i.d.R. auch dann nur etwas bremsen, wenn da ein Protokoll mit einer Flußsteuerung zum Einsatz kommt und der Empfänger damit dem Absender sagen kann: "Mach' mal langsamer." - ohne diese Möglichkeit im Protokoll kann man auch nichts drosseln.

Die Aufgabenstellung ist hier ja auch nicht, einen einzelnen Downstream-Client auf eine vorherbestimmte Rate zu begrenzen (das machen diese erwähnten Programme dann halt), sondern eine unbestimmte Anzahl von möglichen Verbindungen auf ein vordefiniertes Limit zu begrenzen und das möglichst auch noch so, daß der "Rest" zu den möglichen 100% Durchsatz nicht ständig brachliegt, auch wenn er von dem anderen Gerät (für das er reserviert sein soll) gar nicht benötigt wird.

Wie bei jedem QoS muß man dabei ganz genau überlegen, was man an Verzögerungen (Latenzen) zu akzeptieren bereit ist (das geht auch nicht unendlich, weil sogar so eine "Pufferung" entsprechende Ressourcen braucht) oder auch, ob man wirklich bereits übertragene Pakete (die also den Downstream schon einmal "verstopft" haben) einfach so "droppen" will, damit man solche Limitierungen durchsetzen kann - und das auch noch ohne jede Garantie, daß der davon betroffene Client dann tatsächlich "herunterregelt", wenn er die verworfenen Pakete erneut empfangen (und beim Absender anfordern) muß. Wenn ich das richtig sehe, will AVM da auch nur in der Richtung "ran", daß man den Clients im Gastnetz dann eben ein "schlechteres Erlebnis" zumutet ... da würden dann wohl auch Pakete verworfen in der Hoffnung, daß das einen Effekt auslöst - zumindest würde ich das aus den sichtbaren Ansätzen, den Verkehr für das Gastnetz zusätzlich mit 0x20000 zu "taggen", ableiten; auch wenn da noch nichts weiter zu sehen ist als diese "ingress"-Queue mit den zwei (Tagging-)Filtern für IPv4 und IPv6-Pakete.

Das ist eigentlich auch immer eine "Einzelfallentscheidung", weil es sehr stark vom Nutzungsszenario abhängt und von den eigenen Anforderungen, was da nun limitiert oder priorisiert werden soll. Bei dem einen sollen Video-Streams die allerhöchste Priorität haben und beim nächsten (in der WG) soll ein "Dauergucker" so limitiert werden, daß er anderen nicht ständig den Löwenanteil der verfügbaren Bandbreite stiehlt - und das heutzutage, wo adaptives Streaming (das sich an die gerade verfügbare Bandbreite anzupassen versucht) eigentlich die Regel ist. Da muß dann eben so ein Client wirklich dauerhaft limitiert werden und damit geht dann für den auch nichts mehr schneller, wenn die anderen die reservierte Bandbreite gar nicht brauchen. Solche Anforderungen sind da aber eben recht individuell und wollen wirklich gut durchdacht sein - dazu braucht es dann eben das Verständnis, wie so etwas funktioniert und das ist mit einem einfachen Schieberegler in der Regel auch nicht getan.

Das wird dann recht schnell so unhandlich, daß man es eben in einem "Consumer-Gerät" vermutlich nur noch dann anbieten kann, wenn man es explizit aus dem Support ausschließt, weil ansonsten problemlos Heerscharen von Support-Mitarbeitern damit beschäftigt werden könnten (und für den gebotenen Support wird AVM ja immerhin überwiegend gelobt), die Fehler der Kunden wieder auszubügeln. Schon für jemanden, der das so halbwegs durchschaut, ist so etwas recht kompliziert zu bedienen bzw. einzurichten und wenn das dann noch der "weniger netzwerk-affine Kunde" machen soll, geht das vermutlich (mit Ansage) nach hinten los.

Wer sich mal einen Eindruck verschaffen will, wie so etwas in der Konfiguration dann aussehen könnte (und wer dabei gleich noch überlegen will, ob das wirklich etwas ist, was (ab Werk) in das FRITZ!OS gehören sollte), der kann ja mal nach "Gargoyle" schauen oder auch nach Tomato, wo es einige Forks gibt, die sich ein besseres QoS auf die Fahnen geschrieben haben.

Aber das sind eben auch (beides) Projekte, die einiges an Verständnis beim Router-Admin voraussetzen und auch entsprechendes Engagement jenseits von "setup&forget" - das geht schon bei der Information/Suche, welches nun die beste Version für die eigenen Bedürfnisse wäre, los. Das ist nun aber nicht das typische Verhalten der FRITZ!Box-Besitzer, sonst hätten wir (sofern die Zahlen stimmen) mehr als 10 Mio. Hobby-Admins in Deutschland, die ihre Home-Netzwerke mit eigenen, an den tatsächlichen Bedarf angepaßten, QoS-Regeln ausstatten - das ist schon mit den derzeit vorhandenen Möglichkeiten aber wohl eher nicht der Fall ... selbst hier im IPPF ist QoS bzw. Traffic-Shaping ja eher ein Randthema und die ganze Filterung/Priorisierung wird häufiger unter dem Aspekt der Kindersicherung betrachtet als unter QoS-Aspekten.

@ohrenschmalz:
Wenn ich das in #1 richtig gelesen habe, geht es ja darum, Inhalte aus dem Internet auf dem LibreELEC-Gerät anzuzeigen ... mit dem vorgeschlagenen Switch (und einer Priorisierung dort) kann man ja den "Flaschenhals" des DSL-Anschlusses (bzw. des Internetanschlusses allgemein, wenn da nicht tatsächlich mehr ankommt, als im Netz verteilt werden kann) nicht beeinflussen.
 
Ein Gerät am 5er-WLAN soll priorisiert werden: Es ist ein Rechner mit LibreElec/Kodi, der Mediathek Inhalte auf dem TV darstellt.
Dieser Rechner erhält als Netzwerkgerät immer die gleiche IP, hat den Namen LibreElec und ist unter der Einstellung Priorisierung sowohl unter "Echtzeitanwendungen" wie "Priorisierte Anwendungen" als Gerät konfiguriert.
.....
.....
Das ist die Frage:
Wie konfiguriere ich die FB, so dass das gewünschte Gerät nicht von Netzwerkaktivitäten anderer Geräte beeinflusst wird?
Gar nicht.
Denn beim WLAN, und das verwendest du ja, ja, jeder Client, auch aus anderen Netzen, fröhlich funken, wenn er die genutzte Frequenz für 'frei' hält.
Da kann, da WLAN ein 'shared' Medium ist, die F!B, als Empfänger, nichts dran drehen.

Eine garantierte Geschwindigkeit kann man nur per Kabel einstellen, wenn das zu garantierende nicht höher als die maximal machbare Geschwindigkeit ist.

----
NEU - Gesicherte Datenrate für Heimnetzgeräte trotz intensiv genutztem Gastnetz
betrifft (meiner Meinung nach) nur die Nutzung gegen das Internet.
Diesen Verkehr kann die F!B ausgehend regulieren, indem sie einfach dem Gastnetz weniger Zeit zuweist.
 
@ohrenschmalz:
Wenn ich das in #1 richtig gelesen habe, geht es ja darum, Inhalte aus dem Internet auf dem LibreELEC-Gerät anzuzeigen ... mit dem vorgeschlagenen Switch (und einer Priorisierung dort) kann man ja den "Flaschenhals" des DSL-Anschlusses (bzw. des Internetanschlusses allgemein, wenn da nicht tatsächlich mehr ankommt, als im Netz verteilt werden kann) nicht beeinflussen.

Ich les das so, das wenn der ELEC-Rechner "allein" läuft, alles gut ist und nur wenn andere Rechner parallel ziehen, gehts in die Hose. Stünde jetzt die DSL-Rate in der Signatur, könnte man mehr sagen :rolleyes:
 
QoS: Benutze es als Allgemeinen Begriff für alles was mit Netzwerk Paketen zu tun hat und deren Handhabung. So einzurichten das es immer lag frei bleibt und jeder machen kann was er will ist nicht einfach.
Fast eine kleine Doktor Arbeit wenn man andere nicht Ärgern will. ;)
Mit Standard SOHO Routern wird man nichts machen können. Das wird sich auch so schell nicht ändern.

Das beste einfache System was ich jetzt kenne ist cake das Behebt eines der größten Problem in Netzwerken. Bufferbloat = LAG
Cake ist noch nicht für alle Einsatz Gebiete geeignet aber in ein Heimnetzwerk schon recht gut was LAN Verbindungen angeht.
Denke mal dies wird auch deine Probleme mit dem Media Player beheben aber nur dann wenn dein internes Netzwerk nicht ausgelastet ist.
Es könnte auch sein das muticast Traffic das WLAN beeinflusst überprüfe das mal.

Vielleicht reicht es aus LEDE/Openwrt fähiger Router oder ein Linux Server mit neuen "sch_cake" es sind keine aufwendigen Firewall Regeln erforderlich.
Für lede/openwrt gibt es sogar eine Web GUI für sqm-scripts der cake einstellt mit iproute2 tc command
Für andere Linux System müsste man Iproute2 tc patchen und cake kernel modul selber compilieren.

Was ist "cake LEDE sqm" Mehr infos in English www.bufferbloat.net/projects/codel/wiki/Cake/
LEDE
SQM

Eine Warnung vorweg es braucht CPU Leistung. Also mit billig Router oder raspberry Pi reicht nicht bei z.B. VDSL 100
 
LEDE geht mit sqm. Dazu gibt es ein Paket wo man es per Webinterface einstellen kann. (luci-app-sqm)

Funktioniert auch gut. Auf Consumer-Routern kann es wie oben schon geschrieben Probleme geben. Wenn du unter 50 Mbit/s bleibst kannst du noch Glück haben, sonst brauchst du eher was in die Richtung Banana Pi (mit USB leider auch nicht ideal)
 
DTAG (deutsche telekom) hat in der Regel 1526 byte frames über VDSL2 über PTM Interface 8 bytes für PPPoE Overhead und 26 Bytes für Ethernet (VLAN) & PTM headers.

34 byte "overhead" für vdsl2 sollte ein guter Wert sein für BRAS & BNG Anschluss
 
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.