[VFKD] Low Latency DOCSIS - Wann?

[petertxt]

Harmonics Queue Management System soll wohl Q1/2021 fertig sein.
Damit wird man wenigstens den Jitter in griff bekommen bei Latenz Kritischen scenarien.
Die haben da wohl was im Petto das sie Queue von NON-Queue Building Traffic unterscheiden könne ohne das die Anbieter diesen Markieren müssen

Wie soll sowas denn mit der Netzneutralität vereinbar sein, die Netzbetreiber verpflichtet, alle Daten gleich zu behandeln? Wenn der Kunde die Regeln auf beiden Seiten selbst konfigurieren könnte, wäre es vermutlich möglich. Aber, dass der Anbieter selbst unterschiedliche Queues einrichtet und nach eigenen Kriterien die Daten zuordnet, benachteiligt bestimmte Anwendungen des Kunden und Diensteanbieter, was so nicht sein soll.

Nur die eigenen Anwendungen von Vodafone, die das Netz von Vodafone nicht verlassen, wie z.B. VoIP und IPTV Multicast zählen zu erlaubten Ausnahmen.

[robert_s]

Harmonics Queue Management System soll wohl Q1/2021 fertig sein.
Damit wird man wenigstens den Jitter in griff bekommen bei Latenz Kritischen scenarien.
Die haben da wohl was im Petto das sie Queue von NON-Queue Building Traffic unterscheiden könne ohne das die Anbieter diesen Markieren müssen

Wie soll sowas denn mit der Netzneutralität vereinbar sein, die Netzbetreiber verpflichtet, alle Daten gleich zu behandeln?

Da sehe ich keinen Konflikt, denn es wird ja nicht nach der Herkunft der Daten entschieden, sondern nach ihrem Typ. Dadurch, dass man "Interaktive" Datenpakete an der Warteschlange für "Download" Datenpakete vorbeiführt, bringt man den Kunden ja nicht dazu, einen anderen Diensteanbieter zu nutzen. Eher im Gegenteil verbreitert man für den Kunden das Angebot an nutzbaren interaktiven Diensten.

[denunge]

The operator can create custom rules, but other than that it is up to the application to mark the low latency traffic.

CableLabs has some code examples on github... https://pingspikeskill.com

[sch4kal]

Harmonics Queue Management System soll wohl Q1/2021 fertig sein.
Damit wird man wenigstens den Jitter in griff bekommen bei Latenz Kritischen scenarien.
Die haben da wohl was im Petto das sie Queue von NON-Queue Building Traffic unterscheiden könne ohne das die Anbieter diesen Markieren müssen

Wie soll sowas denn mit der Netzneutralität vereinbar sein, die Netzbetreiber verpflichtet, alle Daten gleich zu behandeln? Wenn der Kunde die Regeln auf beiden Seiten selbst konfigurieren könnte, wäre es vermutlich möglich. Aber, dass der Anbieter selbst unterschiedliche Queues einrichtet und nach eigenen Kriterien die Daten zuordnet, benachteiligt bestimmte Anwendungen des Kunden und Diensteanbieter, was so nicht sein soll.

Nur die eigenen Anwendungen von Vodafone, die das Netz von Vodafone nicht verlassen, wie z.B. VoIP und IPTV Multicast zählen zu erlaubten Ausnahmen.

Wird bei xDSL schon lange so gemacht.

[3rik]

Wie hoch bzw. niedrig ist eure Latenz?
Bei mir liegt es fast immer zwischen 20-27ms, was eigentlich relativ hoch ist. (bei speedtest.net)
Zu google.com ist es ungefähr 32ms.

[petertxt]

Hier etwa 50 km weg von München sind die Latenzen zu Google die folgenden. Die DNS Server von VF liefern für Google mal die Adressen der Server aus München, Frankfurt oder Prag:
MUC 10 ms
FRA 19 ms
PRG 26 ms

[robert_s]

Wie hoch bzw. niedrig ist eure Latenz?
Bei mir liegt es fast immer zwischen 20-27ms, was eigentlich relativ hoch ist. (bei speedtest.net)
Zu google.com ist es ungefähr 32ms.

Das hängt ja nicht nur an der Latenz auf der DOCSIS-Strecke, sondern auch vom Peering sowie dem jeweiligen Anbieter ab. Hier in Berlin wurde einst vieles über den BCIX geroutet, entsprechend waren die Latenzen schön kurz. Dann meinte Vodafone, das nicht mehr nötig zu haben, und die Latenzen zu zuvor lokal erreichbaren Zielen schnellten um ca. 20ms in die Höhe, weil (fast?) alles den pauschalen Umweg über Frankfurt/Main nehmen musste.

Jetzt hat Vodafone den Fehler immerhin teilweise wieder zurückgenommen und peert wieder lokal am BCIX, allerdings nicht wieder zu allen Zielen. So geht es ins DFN (Universitäten und Forschungseinrichtungen) immer noch nur über Frankfurt/Main, und auch der "kurze Weg" zu Amazon und Apple ist nicht wiederhergestellt. Immerhin geht es jetzt zu www.berlin.de wieder mit <1ms vom CMTS zum Server.

Der Punkt ist: Low Latency DOCSIS bringt gar nichts, wenn Vodafone es netzseitig verbockt: Zu lange Strecke vom Remote-PHY zum vCMTS, schlechte Vernetzung, kein lokales Peering - da bleiben leicht deutlich mehr Millisekunden auf der Strecke, als man sie auf dem DOCSIS-Anteil überhaupt einsparen kann.

[sch4kal]

Wie hoch bzw. niedrig ist eure Latenz?
Bei mir liegt es fast immer zwischen 20-27ms, was eigentlich relativ hoch ist. (bei speedtest.net)
Zu google.com ist es ungefähr 32ms.

Das hängt ja nicht nur an der Latenz auf der DOCSIS-Strecke, sondern auch vom Peering sowie dem jeweiligen Anbieter ab. Hier in Berlin wurde einst vieles über den BCIX geroutet, entsprechend waren die Latenzen schön kurz. Dann meinte Vodafone, das nicht mehr nötig zu haben, und die Latenzen zu zuvor lokal erreichbaren Zielen schnellten um ca. 20ms in die Höhe, weil (fast?) alles den pauschalen Umweg über Frankfurt/Main nehmen musste.

Jetzt hat Vodafone den Fehler immerhin teilweise wieder zurückgenommen und peert wieder lokal am BCIX, allerdings nicht wieder zu allen Zielen. So geht es ins DFN (Universitäten und Forschungseinrichtungen) immer noch nur über Frankfurt/Main, und auch der "kurze Weg" zu Amazon und Apple ist nicht wiederhergestellt. Immerhin geht es jetzt zu www.berlin.de wieder mit <1ms vom CMTS zum Server.

Der Punkt ist: Low Latency DOCSIS bringt gar nichts, wenn Vodafone es netzseitig verbockt: Zu lange Strecke vom Remote-PHY zum vCMTS, schlechte Vernetzung, kein lokales Peering - da bleiben leicht deutlich mehr Millisekunden auf der Strecke, als man sie auf dem DOCSIS-Anteil überhaupt einsparen kann.

Ich bin da auch mal gespannt, wir haben jetzt auch mal einen Peeringrequest am DE-CIX in FRA gestellt, weil wir damals noch das AS-KDG Peering hatten. Mal gucken ob sich AS3209 nun so verhält wie AS3320...

[why_]

Wie hoch bzw. niedrig ist eure Latenz?
Bei mir liegt es fast immer zwischen 20-27ms, was eigentlich relativ hoch ist. (bei speedtest.net)
Zu google.com ist es ungefähr 32ms.

Das hängt ja nicht nur an der Latenz auf der DOCSIS-Strecke, sondern auch vom Peering sowie dem jeweiligen Anbieter ab. Hier in Berlin wurde einst vieles über den BCIX geroutet, entsprechend waren die Latenzen schön kurz. Dann meinte Vodafone, das nicht mehr nötig zu haben, und die Latenzen zu zuvor lokal erreichbaren Zielen schnellten um ca. 20ms in die Höhe, weil (fast?) alles den pauschalen Umweg über Frankfurt/Main nehmen musste.

Jetzt hat Vodafone den Fehler immerhin teilweise wieder zurückgenommen und peert wieder lokal am BCIX, allerdings nicht wieder zu allen Zielen. So geht es ins DFN (Universitäten und Forschungseinrichtungen) immer noch nur über Frankfurt/Main, und auch der "kurze Weg" zu Amazon und Apple ist nicht wiederhergestellt. Immerhin geht es jetzt zu www.berlin.de wieder mit <1ms vom CMTS zum Server.

Der Punkt ist: Low Latency DOCSIS bringt gar nichts, wenn Vodafone es netzseitig verbockt: Zu lange Strecke vom Remote-PHY zum vCMTS, schlechte Vernetzung, kein lokales Peering - da bleiben leicht deutlich mehr Millisekunden auf der Strecke, als man sie auf dem DOCSIS-Anteil überhaupt einsparen kann.

Ich bin da auch mal gespannt, wir haben jetzt auch mal einen Peeringrequest am DE-CIX in FRA gestellt, weil wir damals noch das AS-KDG Peering hatten. Mal gucken ob sich AS3209 nun so verhält wie AS3320...

Halte uns bitte darüber hier auf dem laufenden, sollten die wirklich den Telekom way of life gehen kündige ich da und geh zu O2.

[StevenK]

Halte uns bitte darüber hier auf dem laufenden, sollten die wirklich den Telekom way of life gehen kündige ich da und geh zu O2.

Das ist sehr unrealistisch, denke ich. Sie sind ja jetzt wieder beim BCIX, nehmen Peering-Requests auch an (auch, wenn es bei ihnen ein bisschen dauert). Und sie schieben ihre Nutzer nicht in ein Tier-1-ASN und wollen dir dann ihren Transit andrehen. Und über CW (und da über andere x-beliebige Tier-1), Level3, Core-Backbone, ... kann man sie auch sehr einfach erreichen.

Jetzt hat Vodafone den Fehler immerhin teilweise wieder zurückgenommen und peert wieder lokal am BCIX, allerdings nicht wieder zu allen Zielen. So geht es ins DFN (Universitäten und Forschungseinrichtungen) immer noch nur über Frankfurt/Main, und auch der "kurze Weg" zu Amazon und Apple ist nicht wiederhergestellt. Immerhin geht es jetzt zu www.berlin.de wieder mit <1ms vom CMTS zum Server.

Amazon Cloudfront (CDN) ist seit Monaten über Berlin via PNI erreichbar (alles andere nimmt den Weg über Hamburg, teilweise geht auch ein bisschen nach München, Frankfurt oder Amsterdam).
Wer weiß, ob sich was beim DFN ändern wird. Das private Peering da ist jetzt erst recht frisch und von daher wohl so gut dimensioniert, dass es keinen Bedarf gibt, das nach Berlin auszulagern.