News Low-Latency-DOCSIS: Vodafone will die Latenz im Kabel-Internet senken

Seit meinem letzten Umzug vor wenigen Monaten habe ich DOCSIS bei Vodafone, weil die Telekom nur 175 Mbit/s vermarktet. Aber oh Wunder, im selben Gebäude hat eine Nachbarin 250 Mbit/, Sync sind eher 270-280 Mbit/s.

Hätte ich das gewusst, würde ich bei der Telekom bleiben.

Abends ist der Upload laut FritzBox hier im Segment im Schnitt zu 90% ausgelastet, gelegentlich gibt es abends auch mal Paketverluste.

Wenn dann die Kunden hier immer mehr hochladen + Tarifupgrades machen sehe ich schwarz hier vor Ort was DOCSIS betrifft.

Ich verstehe nicht warum Vodafone so ein Sauhaufen schon seit vielen Jahren ist.

Noch zu Unitymedia Zeiten (oder damals in NDS auch Kabel Deutschland) war DOCSIS einfach nur ein Traum!

Naja die Antwort ist ganz einfach: Überbuchung, zu wenig Investitionen in das Netz und Provisionstechniker… würg.
 
Dark_Soul schrieb:
Wie kommst du darauf?
Zitat aus dem Artikel:
Technisch steckt hinter dem Latenz-Booster der Übertragungsstandard Low-Latency DOCSIS, bei dem speziell gekennzeichnete Datenströme im Netz bevorzugt transportiert werden.
Ich kann mir jetzt aber auch eher schwer vorstellen, das der Router da bspw. Videokonferenzen kennzeichnet, damit die flüssiger transportiert werden.
 
Ja gut, aber das ist ja workload bezogen, nicht kundenbezogen. Sprich, quality of service, für Workloads wo es Sinn macht.
 
Ah und vergessen zu erwähnen: Low Latency gilt für den Downstream-Bereich, Upload wird (wenn ich mich nicht irre) nicht möglich sein. Im Upload soll High-Split notwendig sein (wegen Proactive Grant Scheduler), was Vodafone auch seit gefühlt 100 Jahren ankündigt aber nicht hinbekommt.
 
Zuletzt bearbeitet:
Computerfuchs schrieb:
Ist das in Hinblick auf Netzneutralität überhaupt zulässig?
Ja, es geht bei der Netzneutralität nicht unbedingt darum, dass alle Datenpakete vollkommen gleich behandelt werden, sondern nur, dass gleiche Dienste auch gleich behandelt werden. Eine Priorisierung kann durchaus im Sinne des Nutzers sein; das nennt man Quality of Service.

Computerfuchs schrieb:
So wie ich das verstehe, sollen hier bestimmte Daten priorisiert werden, was im Umkehrschluss natürlich bedeutet, dass andere (vermeintlich) weniger zeitkritische Dinge ausgebremst werden.
Nein, das ist ein Trugschluss.

Stell dir vor, du hast zwei Anwendungen, die beide 50 Pakete in einer Sekunde senden, wobei die Leitung auch genau 100 Pakete pro Sekunde schafft.
Zuerst kommt nun aber Anwendung A und packt gleich mal alle 50 Pakete auf die Leitung. Wenn nun (fast zeitgleich, aber eben etwas später) Anwendung B kommt, dann müsste sie ohne Priorisierung erstmal eine halbe Sekunde warten, bis die 50 Pakete von A durch sind, auch wenn B vielleicht erstmal nur ein einziges Paket senden will. Mit Priorisierung von Anwendung B wird Anwendung A vorzeitig unterbrochen, damit B früher schon ran darf. Wenn beide priorisiert sind und beide ihre jeweiligen 50 Pakete auf einen Schlag senden wollen, dann würden sie mit doppelter Priorisierung theoretisch sogar abwechselnd ihre Pakete senden können. In jedem Fall ist der Durchsatz identisch; alle 100 Pakete werden innerhalb der Sekunde gesendet. Keine Anwendung wird benachteiligt.

In der Praxis ist es etwas komplizierter, sonst könnte man einfach immer alles priorisieren und hätte überall niedrige Latenzen (alle sind abwechselnd dran) -- das wäre aber aus verschiedenen Gründen nicht effizient; weil man z.B. ständig die Warteschlagen umsortieren müsste.

Wie genau das über ein ganzes Segment hinweg gestaltet werden soll, ist mir ehrlich gesagt auch unklar. Da müsste man mal die Spezifikation nachlesen. Denkbar wäre, dass grundsätzlich UDP priorisiert wird oder so.
 
  • Gefällt mir
Reaktionen: Dark_Soul und Computerfuchs
Mit KabelBW hatte ich vor 20 Jahren einen fantastischen Ping von 6ms nach Frankfurt.
Dann kam Unitymedia, Ping hat sich mehr als verdoppelt.
Und als ich zuletzt Vodafone Kabel hatte, war der noch schlechter, bei 18ms

Ich bezweifle dass man hier jemals wieder einen einstelligen Ping nach Frankfurt sehen wird.

Zum Zocken ist VDSL die klar bessere Wahl.

Und bevor Vodafone irgendwelche Latenzen verbessern will, sollten sie mal ihre Peerings verbessern bzw. Peering-Engpässe beseitigen die man abends und zu Stoßzeiten zu spüren bekommt und man nicht immer einen VPN braucht.
Vodafone kann ich als ISP nicht mehr Ernst nehmen, der Laden ist einfach nur noch Müll.
 
Hier gibt es noch kein Glasfaser. Bin dankbar für meinen Vodafone Gbit Anschluss. Bei mir liegt zu jeder Zeit die volle Geschwindigkeit an, wohl Glück gehabt. Der Ping könnte besser sein, freue mich auf das neue Feature.
 
  • Gefällt mir
Reaktionen: Ule
Wir haben vor 2 Jahren Glasfaser bestellt was tatsächlich in Form von Leerrohren diese Woche verlegt wurde.
Einen Ping von 35ms und dazu noch ca. 50% verlorene Datenpakete sind wirklich eine Zumutung.
Downloads sind schnell ja, aber das Internet dennoch langsam.
 
Wie unterscheidet Vodafone "Echtzeitanwendungen" von "Nicht-Echtzeitanwendungen" zwecks Priorisierung und wie genau sieht hier die Definition aus, was dazu gehört und was nicht?

Livestreams sind Echtzeitanwendungen, aber On-Demand-Videos gehören nicht dazu?
Live-Game-Streaming gehört zu den Echtzeitanwendungen oder nicht?
Telefonie am Kabelinternetanschluss (z.B. Sipgate) gehört zu den Echtzeitanwendungen oder nicht?
Gaming-Anwendungen mit Sprachchatfunktion (TeamSpeak, Discord etc.) gehören dazu oder nicht?

Anhand der vielen Fragen ist da ziemlich viel unklar.
 
  • Gefällt mir
Reaktionen: Paxter und Web-Schecki
Sehr nice, bin gespannt wann es bei uns hier oben ausgerollt wird.
 
Weyoun schrieb:
was dazu gehört und was nicht
Finde es ebenfalls extrem schade, dass sich ComputerBase an der Stelle nicht von den ganzen anderen Seiten abhebt, die bei einer Websuche nach "low latency DOCSIS" zum Vorschein kommen, und ebenfalls einfach nur die Pressemitteilung abschreibt...

Hier wird ein bisschen mehr erklärt, und da gibt es auch ein kurzes "Whitepaper".
Kurz: Der gesamte Traffic wird in zwei Typen mit zwei Warteschlangen aufgeteilt, und die Pakete werden wie folgt einsortiert:
By default, the traffic within an Aggregate Service Flow is segmented into the two constituent Service Flows by a set of packet classifiers (Figure 3) that examine the Differentiated Services (DiffServ) Field and the Explicit Congestion Notification (ECN) Field, which are standard elements of the IPv4/IPv6 header [RFC3168]. Specifically, packets with an NQB DiffServ value1 or an ECN field indicating either ECN Capable Transport 1 (ECT(1)) or Congestion Experienced (CE) will get mapped to the Low Latency Service Flow, and the rest of the traffic will get mapped to the Classic Service Flow.

The expectation is that non-queue-building traffic sources (applications) will either mark their packets with an NQB DiffServ value or support ECN.
Am Ende wird also der IP-Header angeschaut und anhand verschiedene Felder entschieden, in welche Warteschlange ein Paket kommt. Das DiffServ-Feld hatte ursprünglich mal eine leicht andere Bedeutung und wird etwas zweckentfremdet, um "queue building" und "non queue building" traffic zu unterscheiden. Es gibt dann auch Schutzmechanismen, damit die (typischerweise sehr kurze) Echtzeit-Warteschlange nicht versehentlich geflutet wird, usw.
 
  • Gefällt mir
Reaktionen: Weyoun
Web-Schecki schrieb:
Am Ende wird also der IP-Header angeschaut und anhand verschiedene Felder entschieden, in welche Warteschlange ein Paket kommt.
OK, dann kann es also auch zu "Fehlentscheidungen" kommen, wenn der Header nicht eindeutig zuordenbar ist.
 
@Weyoun Ja, ich könnte es jetzt zumindest mit meinem Wissen nicht ausschließen. Letztlich sollten diese IP-Header gar nicht von einzelnen Anwendungen kontrolliert werden, sondern erst vom Netzwerkstack des Betriebssystems der Maschine, die die Pakete versendet, oder auch erst vom ersten Router - so genau kenne ich mich da ehrlicherweise einfach nicht aus. Tendenziell könnte das ein Router schon ganz gut klassifizieren, würde ich mal vermuten.
Es sollte in keinem Fall schlechter werden als ohne Low-Latency-DOCSIS, das ist vielleicht noch wichtig zu verstehen. Eine falsch zugeordnete Echtzeitanwendung läuft dann eben so wie bisher auch, und alle richtig zugeordneten Echtzeitanwendungen laufen tendenziell deutlich besser.
 
  • Gefällt mir
Reaktionen: Weyoun
Nett. Aber sehe das ganze etwas zwiegespalten. Befürchte, umso mehr Low-Latency Datenströme bevorzugt behandelt werden, umso mehr andere, bisher "normal" schnelle Daten haben das Nachsehen. Lustig wird es, sobald es zum Geschäftsmodell wird und jeder es zubuchen muss, um nicht Schlusslicht zu sein.
Ergänzung ()

Ok. Wurde beantwortet. Ich bin einen Trugschluss anheim gefallen. ;)
 
Der Artikel könnte die genaue Funktionsweise etwas näher erläutern. Priorisierung bestimmter Pakete klingt gleich nach 2 Klassen Internet, 'Überholspur', premium bits und so.
Tatsächlich scheint das aber nur 'normale' queue magic zu sein? Da weiter unten gibts das Whitepaper zu low latency docsis
und
LLD addresses Queueing Delay by allowing non-queue-building applications to avoid waiting behind the delays caused by the
current TCP or its variants. At a high level, the low-latency architecture consists of a dual-queue approach that treats both
queues as a single pool of bandwidth.
klingt jetzt nicht nach 'wir lassen markierte pakete an der schlange vorbei' sondern mehr nach 'wir stellen udp nicht ganz hinten in die warteschlange mit den tcp paketen an'
Habs nur überflogen, für mehr reichts grad nicht.
klingt aber ein wenig so als könnten die genauso einfach die FIFO queue gegen eine stochastic fairness queue austauschen, oder?

sieht zumindest nicht nach einer effektiven benachteiligung von nicht-priorisierten paketen aus, nur besseres 'slicing' und reduktion von bufferbloat effekten.
Dark_Soul schrieb:
Ich habe Kabel über Vodafone. 32€ Im Monat für 280 MBit ist unschlagbar.
pyur hat 500 mbit für 30 € und 1 gbit für 35. klingt für mich als würde das die 280 für 32 schlagen.
wenn der upload besser ist ggf. nicht aber definitiv nicht 'unschlagbar'
 
Bigeagle schrieb:
pyur hat 500 mbit für 30 € und 1 gbit für 35. klingt für mich als würde das die 280 für 32 schlagen.
wenn der upload besser ist ggf. nicht aber definitiv nicht 'unschlagbar'
Ist bei mir nicht verfügbar, daher keine Option. Also doch unschlagbar ;).
 
Mal ein kleiner, schneller Test von meiner Seite: Was bringt mir das Ganze jetzt eigentlich real?

9 ms sind ja schon ein absoluter Spitzenwert. Lässt sich da überhaupt noch was verbessern?
 

Anhänge

  • Screenshot 2026-05-20 223349.png
    Screenshot 2026-05-20 223349.png
    47,9 KB · Aufrufe: 29
Zahle weiterhin für 300 Mbit, bekomme fast Gigabit dank kostenlosem Upgrade. Hatte auch lange keine Unterbrechung mehr. Bin wohl einer der wenigen zufriedenen Kunden.
 
Zurück
Oben