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.
