Telekom erhöht Bandbreite bei DSL Ultra Light

[v3zZ]

wow nice.
kommt nur leider mehr als 10 jahre zu spät. :-P

[h00bi]

Zitat von Wechsler

Erklär mir, was bei ADSL2+ knapp zwei Jahrzehnte nicht mehr funktioniert, so daß jetzt ASSIA benötigt wird.

???
ja, man könnte ADSL2+ einfach auf max. Sync laufen lassen. Aber das bringt doch nur dann was, wenn es stabil ist.
Es setzt sich doch keiner bei der Telekom hin und tüftelt da passende Profile aus. Deswegen gab es ja das harte Limit auf DSL Lite.

ASSIA macht jetzt genau das, was ohne ASSIA eine hochqualifizierte person händisch über einen längeren Zeitraum machen müsste.

[Wechsler]

Zitat von h00bi

???
ja, man könnte ADSL2+ einfach auf max. Sync laufen lassen. Aber das bringt doch nur dann was, wenn es stabil ist.

Und genau das hat man bei allen Wettbewerbern der Telekom schon immer so gemacht. Der Incumbent ist und bleibt der einzige, der auf festen Profilen besteht, egal ob per Datenbank oder neuerdings per KI.

Es setzt sich doch keiner bei der Telekom hin und tüftelt da passende Profile aus. Deswegen gab es ja das harte Limit auf DSL Lite.

Und das harte Limit war bei ADSL/ADSL2/ADSL2+ schon immer völlig überflüssig. Ich habe in den letzten 20 Jahren zahlreiche Anschlüsse betreut, die alle unabhängig von Leitungsdämpfung und Störeinflüssen mit einem 7 oder 18-Mbps-Profil liefen, nur nicht auf Telekom-Technik. Wo das ADSL-Modem dann teilweise nur 10 % des Profils ausgehandelt hat und das lief trotzdem völlig stabil. Und meistens drei bis fünfmal so schnell wie mit Telekom-Technik.

Das funktioniert schon, wenn der ISP keinen Schrott kauft.

[wellmann]

Zitat von Wechsler

Und genau das hat man bei allen Wettbewerbern der Telekom schon immer so gemacht.

Schön wärs ...

[fruli]

BT/OPENREACH hat seit 2006 so ein System mit RAMBo ("Rate Adaptive Manangement Box") gefahren, das aber die ASSIA-Patente verletzt hat, wie 2013 entschieden wurde und seit Ende 2014 verzichtet man dort drauf, weil die Lizenzgebühren (ca. 20 Mio Euro jährlich) zu hoch erschienen.

Zitat von Wechsler

Das funktioniert schon, wenn der ISP keinen Schrott kauft.

... und der Kunde ... die anfängliche AVM-CPE-Generation hat ausweislich vieler Forenberichte selbst bei Fixed-384-Anschlüssen versagt. Arcor hatte auch kein glückliches Händchen mit ihren vermarkteten CPEs beim ADSL2+-Rollout, Netzwerkservice hat da hier im Forum ein Geschäftsmodell draus gemacht mit Ersatz durch Speedtouch damals.

[A1B2C3D4]

Die British Telecom setzt ein ähnliches System wie die Telekom ein.

https://www.ispreview.co.uk/index.ph...anagement.html

[fruli]

thx für die Info, hatte das nicht mehr weiter mitverfolgt, dass die sich geeinigt haben später mit Cross-Lizenzierung.

[talk]

Hallo zusammen,

Zitat von Meester Proper

Diese Funktion ist ein Standard-Merkmal eines IMS nach ETSI-TISPAN [...][/url]

Die P-CSCF fragt über das Gq'-Interface das RACS-System ab, siehe PDF-Seite 12: https://www.etsi.org/deliver/etsi_ts...17v080000p.pdf

Vielen Dank für die Links! Das ist ein interessantes Thema...

Damit kann die P-CSCF (quasi "der SIP-Server, der mit dem Kunden kommuniziert") also das Zugangsnetz (BRAS/BNG etc.) gewissermaßen anweisen, den entsprechenden VoIP-Verkehr speziell zu behandeln. Wie die von mir weiter oben verlinkte Diskussion im Telekom-Hilft-Forum zeigt, soll es sich dabei bei der Telekom nicht nur um eine Priorisierung, sondern tatsächlich sogar um eine Reservierung von Kapazitäten handeln.

Das klingt ja alles schon mal ganz gut - und ich finde es auch sinnvoll, daß man sich um das Thema "Quality of Service" für VoIP Gedanken macht - die Frage ist: Resultiert daraus auch tatsächlich eine verbesserte Qualität, z.B. hinsichtlich Jitter und Clock Skew (wenn auf der einen Seite die VoIP-Daten in einem "idealen" 20 ms-Takt eingespeist werden, in welchem Takt kommen sie dann auf der anderen Seite der VoIP-Strecke zum Ziel, wenn der VoIP-Traffic gleichzeitig mit Best-Effort-Datenverkehr gemischt wird)?

Sprich: Müßte in einem solchen IMS zu erwarten sein, daß der mit derartigen Policies behandelte VoIP-Verkehr strikten Vorrang genießt gegenüber anderem Datenverkehr? Sodaß also ein aus dem Netz ankommendes VoIP-Paket im BRAS/BNG automatisch als nächstes Paket auf die Leitung zum Nutzer gegeben wird (egal wie voll die Best-Effort-Warteschlange ist) und es damit höchstens das aktuell bereits zu übertragende Best-Effort-Paket abwarten muß?

Ich habe vor einiger Zeit mal Tests gemacht, bei denen ich an einem Telekom IP-Anschluß (DSL 16000) mit Fritzbox zu laufenden VoIP-Verbindungen teilweise auch noch diversen TCP-/UDP-Traffic über die Leitung geschickt habe. Paketmitschnitte und eine Auswertung derselbigen mit Wireshark haben danach gezeigt, daß der ankommende VoIP-Verkehr (von einer Gegenstelle ohne relevanten Jitter) in diesem Fall dann teilweise einen deutlichen Ansteig bei den "skew"-Werten zu verzeichnen hatte: Die VoIP-Pakete kamen also gegenüber dem regulären 20 ms-"Takt" teils um etliche ms "verspätet" an. Das läßt mich wiederum vermuten, daß entweder diese VoIP-Pakete keine hundertprozentige Priorität gegenüber anderem Traffic hatten oder aber daß man das mit einem solch relativ einfachen Testszenario und einer normalen Privatkunden-Fritzbox gar nicht hinreichend genau messen kann?

cu talk

[Meester Proper]

Zitat von talk

Damit kann die P-CSCF (quasi "der SIP-Server, der mit dem Kunden kommuniziert") also das Zugangsnetz (BRAS/BNG etc.) gewissermaßen anweisen, den entsprechenden VoIP-Verkehr speziell zu behandeln.

Indirekt, es dient hauptsächlich dazu, dass nicht mehr priorisierter Verkehr, sprich Gespräche, angewiesen können, als der Anschluss Upstream-Kapazität (und Downstream natürlich auch, aber aufgrund der asymmetrischen Datenraten ist dies eher selten das Problem) hat. Die Reservierung wird dabei immer für den Codec mit dem höchstem (Datenraten-)Bedarf vorgenommen.

Zitat von talk

Das klingt ja alles schon mal ganz gut - und ich finde es auch sinnvoll, daß man sich um das Thema "Quality of Service" für VoIP Gedanken macht - die Frage ist: Resultiert daraus auch tatsächlich eine verbesserte Qualität, z.B. hinsichtlich Jitter und Clock Skew (wenn auf der einen Seite die VoIP-Daten in einem "idealen" 20 ms-Takt eingespeist werden, in welchem Takt kommen sie dann auf der anderen Seite der VoIP-Strecke zum Ziel, wenn der VoIP-Traffic gleichzeitig mit Best-Effort-Datenverkehr gemischt wird)?

Sprich: Müßte in einem solchen IMS zu erwarten sein, daß der mit derartigen Policies behandelte VoIP-Verkehr strikten Vorrang genießt gegenüber anderem Datenverkehr? Sodaß also ein aus dem Netz ankommendes VoIP-Paket im BRAS/BNG automatisch als nächstes Paket auf die Leitung zum Nutzer gegeben wird (egal wie voll die Best-Effort-Warteschlange ist) und es damit höchstens das aktuell bereits zu übertragende Best-Effort-Paket abwarten muß?

Ich habe vor einiger Zeit mal Tests gemacht, bei denen ich an einem Telekom IP-Anschluß (DSL 16000) mit Fritzbox zu laufenden VoIP-Verbindungen teilweise auch noch diversen TCP-/UDP-Traffic über die Leitung geschickt habe. Paketmitschnitte und eine Auswertung derselbigen mit Wireshark haben danach gezeigt, daß der ankommende VoIP-Verkehr (von einer Gegenstelle ohne relevanten Jitter) in diesem Fall dann teilweise einen deutlichen Ansteig bei den "skew"-Werten zu verzeichnen hatte: Die VoIP-Pakete kamen also gegenüber dem regulären 20 ms-"Takt" teils um etliche ms "verspätet" an. Das läßt mich wiederum vermuten, daß entweder diese VoIP-Pakete keine hundertprozentige Priorität gegenüber anderem Traffic hatten oder aber daß man das mit einem solch relativ einfachen Testszenario und einer normalen Privatkunden-Fritzbox gar nicht hinreichend genau messen kann?

Meines Wissens sind die RTP-Pakete mit DSCP Expedited Forwarding und dem entsprechenden .1p / PCP auf VLAN-Ebene markiert. Im MPLS werden diese Pakete mit der korrespondierenden Traffic Class transportiert.

Das QoS-Konzept ist schon Ende-zu-Ende geplant, aber natürlich nicht perfekt, wie es die Theorie besagt.

Hast du denn im LAN- oder auf der WAN-Strecke gemessen? Nicht, dass die Fritzbox nicht doch noch einen negativen Einfluss hatte...

[talk]

Hallo zusammen,

Zitat von Meester Proper

Indirekt, es dient hauptsächlich dazu, dass nicht mehr priorisierter Verkehr, sprich Gespräche, angewiesen können, als der Anschluss Upstream-Kapazität [...] hat. Die Reservierung wird dabei immer für den Codec mit dem höchstem (Datenraten-)Bedarf vorgenommen.

Wenn ich den von mir oben verlinkten Telekom-Hilft-Thread richtig interpretiere, ging es bei dem Problem "Fritz!Boxen konnten an langsamen DSL-Anschlüssen nur ein Gespräch gleichzeitig aufbauen" darum, daß diese in ihren SDP-Anfragen einen exotischen Codec mitaufführten [vermutlich iLBC?], wodurch die Telekom-Plattform "zur Sicherheit" einen erhöhten VoIP-Kapazitätsbedarf veranschlagte, der eben nur für ein Gespräch ausreichte. Das Problem soll ja inzwischen wohl gelöst sein (wenngleich das 488er-Problemm des Nutzers "Hocker" hier im Thread ähnlich klang)...(?)

Zitat von Meester Proper

Meines Wissens sind die RTP-Pakete mit DSCP Expedited Forwarding und dem entsprechenden .1p / PCP auf VLAN-Ebene markiert. Im MPLS werden diese Pakete mit der korrespondierenden Traffic Class transportiert.

Das QoS-Konzept ist schon Ende-zu-Ende geplant, aber natürlich nicht perfekt, wie es die Theorie besagt.

Laut 1TR112 [9.3.1 "Data Plane für Data und Voice (VoIP) Services] soll der Telekom-VoIP-Traffic auf Ethernet-Ebene im VLAN "7" mit 802.1p-PCP "5" (Voice) versehen werden (alternativ geht wohl auch noch PCP "6" (Internetwork Control), das soll aber offenbar langfristig wegfallen).

Laut 1TR114 [8.4.2 "Traffic Classes in Layer 3"] soll der Voice-Traffic außerdem auf IP-Ebene den DSCP-Wert "101110" bzw. "46" bekommen, was "Expedited Forwarding" entspricht.

Soweit alles nachvollziehbar. Die Frage ist, wie gesagt, wie das QoS dann in der Praxis arbeitet. Wikipedia schreibt zu "Expedited Forwarding" zum Beispiel: "EF traffic is often given strict priority queuing above all other traffic classes. Because an overload of EF traffic will cause queuing delays and affect the jitter and delay tolerances within the class, admission control, traffic policing and other mechanisms may be applied to EF traffic."

Das läßt durchaus einen gewissen Interpretationsspielraum. Ich würde aber eigentlich schon davon ausgehen, daß mit diesen QoS-Maßnahmen gekennzeichneter VoIP-Verkehr in den Warteschlangen des BRAS/BNG an Best-Effort-Verkehr "vorbeigeleitet" werden und entsprechend "Vorfahrt" genießen müßte (die bereits beschriebene Begrenzung von parallelen Gesprächen ist ja quasi auch eine Traffic policy, die eine Überlastung alleine durch VoIP-Traffic verhindert).

Zitat von Meester Proper

Hast du denn im LAN- oder auf der WAN-Strecke gemessen? Nicht, dass die Fritzbox nicht doch noch einen negativen Einfluss hatte...

Es waren Paketmitschnitte auf der WAN-Seite der Fritzbox ("1. Internetverbindung"). Dabei wurde VoIP-Verkehr von an die Fritzbox angeschlossenen Endgeräten (ISDN oder DECT) mit Best-Effort-Traffic aus dem LAN (PCs, die auf das offene Internet zugriffen) gemischt. Der VoIP-Verkehr kam also nicht aus dem LAN, sondern wurde von der Fritz!Box selbst abgewickelt.

Da der eingehende VoIP-Verkehr trotz QoS teils deutliche Ausreißer bei den "Skew"-Werten einzelner Pakete lieferte (so als ob diese im BRAS/BNG erst noch ein paar Best-Effort-Pakete abwarten mußten), war meine Vermutung eben:

Entweder genießt der Telekom-VoIP-Traffic keine strikte QoS-Priorität über Best-Effort-Traffic oder aber dieser Effekt entsteht erst in der Fritz!Box. Ich kann mir aber nicht so recht vorstellen, wie/warum die Fritzbox für den Paketmitschnitt die Reihenfolge eingehender Pakete durcheinander bringen sollte - höchstens, daß da Mechanismen wie die in der Fritz!Box vorhandene "Paketbeschleunigung" eventuell irgendwie eingreifen. Diese müßten aber m.E. den VoIP-Verkehr eher bevorzugen, als benachteiligen (da es sich hier ja um fortlaufende Streams handelt).

Daß die Paketmitschnittfunktion selbst fehlerhaft arbeitet, würde ich eher ausschließen. Auch ohne Paketmitschnitt gibt es Indizien dafür, daß man mit parallelem Internetverkehr den VoIP-Verkehr wohl mehr als erwartet "aus dem Takt" bringen kann - man kann ja über die Daten der Fritz!Box in Erfahrung bringen, inwieweit der Jitter Buffer eingreifen mußte - das ist bei parallelem Datenverkehr deutlich eher der Fall, als bei reiner VoIP-Nutzung.

cu talk