Beiträge von frank_m

Zitat von rode

Natürlich findet sich die.

TKG § 57 (4) 1

"Abweichungen bei der Geschwindigkeit ... die durch einen von der Bundesnetzagentur bereitgestellten oder von ihr oder einem von ihr beauftragten Dritten zertifizierten Überwachungsmechanismus ermittelt wurden"

Somit gilt eindeutig der Zahlenwert, welcher gegen die Server der BNetzA gemessen wird, und das ist Netto.

Wie du aus der Formulierung darauf schließt, dass Netto-Werte die Grundlage sind, wird sich mir nie erschließen.

Zitat von jan

Das Messverfahren der Breitbandmessung wird durch die Bundesnetzagentur hier konkretisiert. Gemessen werden demnach die TCP-Nutzdaten. Und die MTU ist ja immerhin Teil des Messprotokolls, sodass sich entsprechende Fehlkonfigurationen erkennen lassen.

Ich garantiere dir, dass ich auf Basis dieses Dokumentes nur durch Änderung der Windows Parameter an einem 100 MBit/s DSL Anschluss eine Geschwindigkeitsmessung mit maximal 8 MBit/s durch das BNetzA Tool hinbekomme, ohne dass das Tool das merkt - und auf der physikalischen Verbindung laufen dabei die von der Telekom versprochenen 116 MBit/s (oder was auch immer die da überprovisioniert einstellen).

Zitat von Elemir

Ohne solche Regelungen könnte der Provider machen was er will

Nein, eben nicht. Das ist einer der kritischen Aspekte Machen wir uns doch nichts vor, eine wasserfeste Spezifikation, was die Schicht 2 liefern muss, wäre für den Kunden viel besser. Denn da hat der Provider keine Ausreden, die ihm jetzt zahlreich zur Verfügung stehen (Protokolloverhead etc). Denn bei der momentanen Regelung kann ihn niemand auf eine Bandbreite verhaften, weil die Parameter für die Übertragung nicht geregelt sind. Da kann er sich immer auf einer fehlerhaften Konfiguration rausreden. Wenn man aber sagt, die Schicht 2 (PPPOE oder Ethernet) muss bei MTU 1500 150 MBit/s liefern, dann hat er keine Ausreden mehr. Es ist leicht messbar und reproduzierbar. Heute macht es ja schon einen messbaren Unterschied, wenn man IPv4 oder IPv6 verwendet, weil IPv6 20 Byte mehr Header hat.

Zitat

Speeds should be specified on the basis of the transport layer protocol payload, and not based on a lower layer protocol.

Das ist ne klar Forumulierung, die man so leider im TKG und bei der BNetzA nicht findet. Leider fehlt auch hier die eindeutige Spezifikation, was Transportprotokoll denn nun bedeutet. UDP? TCP? Paketgrößen?

Wenn ich ein solches Pflichtenheft an meine Kunden geben würde, und die soll als Abnahmekriterium für einen Vertrag gelten, schmeißt mein Boss mich raus. Und um nichts anderes geht es hier.

Zitat von mbo77

Stichworte sind: Klare und nachvollziehbare Form, verfügbare Datenübertragungsraten, etc.

Da steht aber auch nicht, auf welcher Ebene diese Datenübertragungsrate zählt. Wie gesagt, schön, das 1&1 die Diskussion mal eröffnet hat.

Zitat von Elemir

MTU 1492 bei PPPoE oder welche Antwort willst Du?

MTU ist ja nur ein Faktor. Die resultierende IP Payloadgröße ist der entscheidende Parameter, und der wird durch viele Faktoren beeinflusst, die irgendwo auf dem Weg vom Kunden zum Server liegen können.

Zitat von Elemir

Kundenrechner direkt am Router und Speedtestserver der BNetzA stehen (zumindest bei großen Providern) im Providernetz. Wer außer dem Provider sollte dann noch beteiligt sein?

Nein, die BNetzA Server werden von einem Dientleister betrieben (zafaco), der Weg führt über die Core Backbone GmbH meistens über den DE-CIX. Die Carrier hängen also dazwischen und haben ebenfalls Einfluss.

Zitat von Elemir

Das Problem ist, dass der Kunde kaum andere Nachweismöglichkeiten hat, der Provider aber schon.

Der Provider aber auch maximal für die Scicht 2. Wie soll er etwas nachweisen können für Verbindungen, deren Endpunkte beide nicht unter seiner Kontrolle liegen?

Zitat von Elemir

Die Speedtestserver der BNetzA sollten bei 1&1 ja wohl im eigenen Netz stehen und somit in dessen Verantwortung fallen.

Nein, siehe Mitteilung der BNetzA. Sie hängen am DE-CIX.

Ich warte noch auf die Ausarbeitung, wie du die Gründe für die Aushandlung der Verbindungsparameter erkennen willst.

Zitat von Elemir

Das ist doch jetzt lächerlich. Wenn ein Kunde da herumspielt, ist das seine Sache. Ebenso, wenn ein Kunde seine Messung über WLAN macht.

Nein, das ist nicht lächerlich, das ist genau der Punkt. Und man muss nicht an der MTU herumspielen, um den Overhead nach oben zu treiben, das kann jede App auch einfach so machen. Niemand zwingt sie dazu, große Pakete zu erzeugen, sie kann auch jedes Byte einzeln verpacken.

Zitat von Elemir

Und doch, das hält einer technischen Überprüfung statt, denn der Overhead fällt nicht vom Himmel, sondern dürfte bei gegebenen Parametern ziemlich genau bekannt sein.

Genau. Bei gegebenen Parametern. Hab ich ja oben auch geschrieben. Nur leider hat die niemand festgelegt.

Zitat von Elemir

Doch, das kann, da die Randbedingungen bekannt sind. Zumindest, wenn keine Netzüberlast oder Fehlkonfiguration vorliegt. Und wenn der Provider das sogar als Minimum angibt, dann hat er das zu liefern.

Der Provider kann nur den Kanal mit einer definierten Bandbreite liefern. Was der Kunde mit welchen Parametern darüber macht, das kann er nicht wissen, und er hat auch keinen Einfluss darauf.

Zitat von Elemir

Die Pakete, deren Inhalt und der Overhead sind ganz genau bekannt.

Ja? Woher? Jetzt bin ich gespannt. Wie willst du die ermitteln, und wie die Ursache dafür identifizieren? Bitte mal ein Beispiel von einem Endkundenrechner über ca. 7 Hops zum Speedtest Server, mit MPLS und allen Details in der Kette.

Zitat von Elemir

Retransmits und Fragmentierung kann man ganz genau zuordnen, ob Provider oder Kunde Verursacher ist.

Falsch. Kannst du nicht. Du siehst den resultierenden Wert, weißt aber nicht, warum der zustande kommt. Der kann auch irgendwo zwischen Provider und Speedtest Server verursacht werden, und damit außerhalb des Einflussbereichs aller Beteiligten.

Zitat von Elemir

Das Infoblatt gibt auch das wieder, bei dessen nicht-erreichen er Beschwerde einlegen kann, und das sind die Netto-Werte, weil nur die der Kunde messen kann.

Technisch kann er gerade das ja nicht. Da - wie gesagt - die Netto Werte massiv vom Overhead abhängen. Verstellt mal euren MTU Wert, führt den Test der BNetzA aus und staunt. Keine Chance, der wird bei jeder Messung Verstöße melden, auch an Telekom Anschlüssen. Und das nur, weil zu wenig Payload in zu viel Protokoll Overhead gepackt wird.

Ich weiß, TKG und irgendwas faseln da was von Netto Raten etc. Das hält aber keiner technischen Überprüfung stand. Da ist es am Ende tatsächlich der Wert, den 1&1 einstellt, der vom Kunden reproduzierbar messbar ist. Diese typischen Überprovisierungen werden mit einem Stoßgebet zum Himmel eingestellt, denn unterm Strich sind sie keine Garantie dafür, dass ein Provider den Vertrag besser erfüllt, als ein anderer. Dann müsste die BNetzA einen harten Wert festlegen und sagen, der muss 20% über der verkauften Bandbreite liegen oder sowas. Aber einfach sagen, der Kunde bekommt Netto das und das kann technisch einfach nicht funktionieren.

1&1 hat ja durchaus ein Standing in dem Bereich. Ich bin gespannt, wo das endet, und ob es dazu führt, dass diese wachsweiche Glückspiel-Regelung in was technisch belastbares umgewandelt wird. Irgendwie bin ich 1&1 direkt dankbar dafür, dass sie das Fass mal aufgemacht haben.

Ja, genau. Die AVM GPON Module haben es drin, und vom AON Modul gibt es 2 Varianten. Ich weiß aber nicht, ob das bei allen ONTs und allen SFP Modulen so ist. Wenn man ein Modul hat, dass über 1550 nm noch empfängt, dann können die TV Signale den Internet Zugang stören. Und deshalb der Hinweis, dass man drauf achten sollte.

Darüber kann man trefflich streiten. Die Bandbreite steht ja zur Verfügung, auf PPPOE Ebene. Für deinen Protokolloverhead kann 1&1 auch nichts.

Und netto steht die Bandbreite auch bei Telekom und Konsorten nur dann zur Verfügung, wenn die Leitung mit großen Paketen effizient ausgenutzt wird. Bei Paketen mit 5 Byte Payload kommst du nicht annähernd an die versprochenen Bandbreiten. Und komm jetzt nicht mit "typische Anwendungen machen aber mehr als 5 Byte Payload".

Dieses "zur Verfügung stehend" bringt mehr Verwirrung, als Klarheit. Wo steht, ob die Bandbreite netto in der IP Payload zur Verfügung stehen muss? Und wenn ja, wie viel % Overhead dürfen die IP-Header ausmachen? Das muss geklärt sein, sonst sind die Aussagen nicht belastbar.

Zitat von mbo77

Ich würde eine Messkampagne bei der BNetzA machen. Dann hast du Gewissheit.

Dann weiß er anschließend auch nur, was netto durch die Leitung geht. Das weiß er jetzt auch schon.

Zitat von mbo77

Da hat sich 1&1 ohne Not ein schönes Ei gelegt.

Kommt drauf an. Es wird natürlich günstiger für die, weil die Tarife langsamer werden. Und wenn sie die Bandbreite niemandem versprechen ... Ja, andere bieten mehr, sind aber dann auch teurer. Man muss halt immer sehen, was man kauft.

Es geht nicht darum, ob das Signal auf dem Coax Kabel ist, es geht darum, ob es auf der Glasfaser ist. Da kann es auch sein, wenn es in eurem Haus nicht benutzt wird. Die Faser geht in viele Haushalte, und solche Signale werden dann in einem ganzen Anschlussbereich verteilt, weil sie für alle Haushalte gleich sind.

Sagen wir mal so: Es gibt einen Grund, warum der ONT einen Coax Anschluss hat, auch wenn er bei euch im Haus nicht verwendet wird. Der Provider wird sich schon was dabei denken, wenn er in eurer Gegend die Version mit Coax in die Häuser einbaut.

Das ist ja auch nicht schlimm, wenn da ein Signal ist. Du musst es nur wissen, denn ein neuer ONT oder ein SFP Modul oder was auch immer muss damit umgehen können.

Zitat von edding27

Habe die PDF nach den Begriffen "Bandbreite" und "Brutto" oder "Netto" durchsucht.

Das steht da auch nicht wörtlich. Da ist dann eher von der physikalischen Verbindung oder auf Protokollebene oder sowas beschrieben. Das wirst du schon ganz lesen müssen, um herauszufinden, wo die Geschwindigkeiten gelten.

Zitat von edding27

Es gibt aber zig Beiblätter und die Tabelle, wo du ja auch siehst, das bei DSL Tarifen sehr wohl die Geschwindigkeiten unterschiedlich sind bei "Minimal", "Normal" und "Maximal".

Ja, da sind aber auch die Grenzen der physikalischen Verbindung ausgereizt. Das ist bei Glasfaser nicht der Fall, deshalb sind die Werte da alle gleich. Das ist aber unabhängig davon, was dir vertraglich zusteht.

Zitat von edding27

Fakt ist: Bei jedem Telekom Tarif mit diesen Bandbreiten (es sind die selben, was die Telekom auch anbietet) wird in der Fritzbox nicht mit 300/150 verbunden sondern eher mit 320/180 und ähnliches.

Ja, die geben eine gewisse Reserve oben drauf. Vielleicht müssen sie das, weil sie vertraglich Netto Bandbreiten garantieren. Vielleicht müssen sie es auch nicht.

Zitat von edding27

Bei mir steht in der Fritzbox EXAKT bis auf das letzte Bit 300/150 - und das versteht ich eben nicht.

Was verstehst du daran denn nicht? Die Situation ist doch einfach: Das sind die Geschwindigkeiten, die 1&1 auf deiner Leitung einstellt. Die führen zwangsläufig dazu, dass netto bei dir weniger ankommt, wegen des Protokolloverheads. Du fragst dich jetzt, ob das ok ist. Die Antwort: Das steht im Vertrag. Finde raus, was du gekauft hast. Dann weißt du, ob es so ok ist. Was andere machen oder ob Minimum und Maximum identisch sind, ist dabei völlig egal.

Zitat von edding27

Das ist alles NETTO gemeint.

Wo steht das?

Diese Information ist für die Frage völlig nebensächlich. Deshalb kann trotzdem das Signal auf dem Kabel sein. Die haben ja nicht nur euer Haus mit Glasfaser versorgt.

Zitat von edding27

Diesen (markiert) habe ich gebucht. Auszug aus den AGBs.

Das ist wieder die falsche Information. Die Bandbreiten kennen wir. Entscheidend ist, wo die Bandbreiten gelten: Ist es Brutto oder Netto? Bei Brutto bist du im grünen Bereich, bei Netto nicht.

Zitat von edding27

Die Meldung oben ist die exakte aus der Fritzbox.

Das ist ja egal. Entscheidend ist das, was im Vertrag steht. Ich weiß nicht, ob das Produktinformationsblatt allein dort genügt. Also checke das noch mal, was du genau gekauft hast.

Die ist wie bei 1 GBit/s Glasfaser über AON. Da ist es auch nur 1 GBit/s auf der Faser, und nicht in der Payload des IP Paketes. Dort sind es nur ca. 930 MBit/s.

Zitat von frerda

Es ist am Koax-Stecker des ONT nichts angeschlossen...

Das heißt ja nicht, dass es bei deinem Nachbarn auch so ist.

Die Frage ist: Ist das Signal auf der Leitung? Dann musst du drauf vorbereitet sein, bzw. dein neuer ONT.

Zitat von edding27

1&1 garantiert ja mittlerweile bei den Glasfasertarifen die Bandbreite bis aufs letzte bit.

Brutto oder netto? Weil die PPPOE Bandbreite ist ja 150 MBit/s, das ist auf der Faser (Brutto) ja sogar mehr, als dir vertraglich zusteht. Netto ist es natürlich weniger, da geht der IP-Protokolloverhead ab.

Zitat von Larzare

Ich gehe (als Laie) gehe davon aus, dass es sich um Peeringprobleme handelt

Das kann sein. Problem: Die können im Einflussbereich der DG auftreten, aber auch im Einflussbereich von Twitch - oder irgendwo dazwischen, worauf niemand deiner Vertragspartner Einfluss hat.

Zitat von Larzare

- Speedtests von versch. Anbietern und zu verschiedenen Zielen sind komplett unauffällig (sowohl Bandbreite als auch Packet loss, sofern die Speedtest das angeben)
- andere Dienste funktionieren problemlos (Netflix, Prime Video, Youtube ...)

Zumindest bei einigen anderen Diensten würde man Probleme erwarten, wenn die Peering Probleme bei der DG auftreten würden. Peering Probleme betreffen immer viele oder sogar alle Ziele, aber nicht nur einen Einzelnen.

Du könntest während der Engpässe versuchen, herauszufinden, von welchen IP-Adressen der Stream kommt und dann (während der Engpässe) mit PingPlotter oder mtr einen Trace dahin machen. Vielleicht kann man was erkennen, ab wo die Probleme auftreten, aber garantiert ist das nicht. Ein kleines ICMP Paket ist was anderes, als ein großes Video Paket.

Nur bei euch nicht oder auch vom Provider nicht? Das hat nämlich sonst ggf. Einfluss auf die Wahl des neuen ONTs, der muss dann nämlich in der Lage sein, das TV Signal rauszufiltern.

Ich hab auch eine Netatmo Wetterstation und diesbezüglich überhaupt keine Probleme. Weder mit dem einspeichern, noch mit dem Auslesen fürs lokale Smart Home System.

Schau mal die absolute Anzahl der Meldungen an: Das sind gerade mal 30 oder 35. Daraus lässt sich wenig bis nichts ablesen. Bei denen weißt du nie, ob die einfach nur den Stecker aus der Wand gezogen haben, oder ob da wirklich was ist. Einige hundert Meldungen braucht man schon, bis es belastbar wird.