Bei (neuen) 1&1 Glasfasertarifen kein Over-Provisioning mehr?

Nein, das ist ziemlich klar. Dazu kannst du dir gerne mal ein Protokoll der Messung ansehen. Das zeigt an, wo ein Verstoß vorliegt.

Für den Kunden ist die Technik dahinter völlig belanglos. Und wenn sich 1&1 entscheidet, die Pakete per Brieftaube zu transportieren und sie dabei Latenz und Bandbreite einhalten, ist alles prima. Ich meine, die BNetzA sieht 150 ms als akzeptabel an.

Alles andere Nebelkerzen helfen auch nicht weiter: Des Messwerkzeug ist definiert. Meinst du das etwas ernst, dass die die Messkampagne mit 5 Bytes Payload durchführen?

Transparenzverordnung, Messwerkzeug und Auswertung sind vorgegeben. Alles andere ist für den Kunden irrelevant.

Das Beste ist: 1&1 hat hier völlig ohne Not einen Bock geschossen. Wenn sich ein paar Leute über die Messkampagne beschweren, werden sie recht schnell selbst ihren Fehler finden.

Wie gesagt, ich würde hier nicht von einer dauerhaften Situation ausgehen. Viel interessanter finde ich, welche Werte sie nach dem geschossenen Bock einstellen werden.

Hängt davon ab, welchen Praktikanten sie dieses Mal mit der Aufgabe betrauen.

Soweit ich weiß, probiert die Fritz!Box selbstständig einige VLAN-IDs durch und horcht auf entsprechende Antworten. Das kommt wohl daher, dass zeitweise der gleiche Provider auf verschiedenen Zugangstechniken verschiedene IDs genutzt hat und weder Support, noch Kunde immer wussten, welche die Richtige ist.

Ich gehe davon aus, dass die Diskussion brutto oder netto belanglos ist, da in Geschäften mit Endverbrauchern immer das gilt, was der Kunde zu bezahlen hat und was er erhält.

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.

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.

Zitat von frank_m

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.

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

Die MTU fällt auch nicht vom Himmel, sondern die ist per Default vom OS für unterschiedliche Netzwerkverbindungsarten vorgegeben. Und wenn nicht einer ganz böse darin herumfummelt, dann wird da auch beim Aufbau einer TCP-IP-Verbindung die MTU angepasst, falls eine Komponente auf dem Weg eine etwas kleinere MTU hat, damit die Rate eben nicht einbricht.

Zitat von frank_m

Ich weiß, TKG und irgendwas faseln da was von Netto Raten etc. Das hält aber keiner technischen Überprüfung stand.

Dann gilt das. 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.

Wenn das nicht mehr passt, dann liegt irgendwo eine Fehlkonfiguration, Überlast oder Störung vor.

Zitat von frank_m

Aber einfach sagen, der Kunde bekommt Netto das und das kann technisch einfach nicht funktionieren.

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.

Zitat von frank_m

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.

Ich auch. Damit klargestellt wird, das Netto gleich Netto ist und klar wird, dass das überhaupt kein Glücksspiel ist. Die Pakete, deren Inhalt und der Overhead sind ganz genau bekannt.

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

Da ich allerdings weiß, was die Telcos auch bei Großfirmenkunden für Mist machen, wundert mich nichts. Erst vor einer Woche wieder einem von unseren einen TCP-Dump um die Ohren hauen müssen, bis er geglaubt hat, dass der Fehler bei ihm liegt. Was wars dann nach 4 Tagen: Fehlkonfiguration auf dem Router. Wenn schon wir so einen "Support" haben, wenn wundern dann solche Spielchen auf Endkundenseite.

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.

Hallo, benutzt Du als ONT das Glasfasermodem 2 bzw. etwas vergleichbares? Hast Du dann mal statt der FRITZ!Box ein Netzwerkkabel direkt an das Glasfasermodem angeschlossen und ausgelesen, mit was für Daten die Verbindung dort zustande kommt? Die Standard IP Adresse des Glasfasermodem 2 wäre 192.168.100.1.

Die BNetzA ist in seiner Definition relativ eindeutig. Lies die Passagen dazu doch mal bitte nach.

Bundesnetzagentur - Transparenzmaßnahmen

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

Eine Bandbreite, die mir aufgrund von technischen Details nicht zur Verfügung steht, kann demnach nicht zur verfügbaren Datenübertragungsrate zählen.

Sich mögliche Probleme auszudenken, ist für mich lediglich dein übliches Rückzugsgefecht und erfahrungsgemäß ziemlich sinnlos.

Die praktische Realität ist, dass die Messkampagne eine konkrete Auswertung vornimmt. Mehr muss dazu eigentlich nicht gesagt werden.

Zitat von frank_m

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.

Das ist Anwendung und damit Kundensache.

Zitat von frank_m

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

MTU 1492 bei PPPoE oder welche Antwort willst Du? Wo soll man da noch drehen können, ohne das es am Kunden liegt?

Zitat von frank_m

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.

Muss er auch nicht. Das läuft wie bei jeder Störung: Provider schickt Techniker, steckt Messgerät direkt an und misst. Wenn dann keine zu niedrige Geschwindigkeit da ist, zahlt der Kunde den Einsatz.

Zitat von frank_m

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.

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? Und wenn der Kunde doch Ursache beim Technikereinsatz war: Rechnung an Kunde.

Zitat von frank_m

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.

Das Problem ist, dass der Kunde kaum andere Nachweismöglichkeiten hat, der Provider aber schon. Also darf der Provider dem Kunden zeigen, dass bei ihm alles stimmt, denn sonst ist der Kunde ausgeliefert. Das ist dann der Kundenschutz.

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

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.

Ich denke ein kurzer Blick in die BEREC-Leitlinien zur Umsetzung der EU-Netzneutralitätsverordnung durch die nationalen Regulierer kann hier nicht schaden.

Im Punkt 140 geht es um die Transparenzangaben (Produktinformationsblatt), und da heißt es:

Zitat

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

Analog dazu in Punkt 166, wo es um das Messwerkzeug (hier Breitbandmessung) geht:

Zitat

Furthermore, speed should be calculated based on transport layer protocol payload.

Euch ist aber schon klar, dass ein Anschreiben wegen 10 MBIT weniger, sowohl bei 1&1 wie auch bei der BNetzA im Papierkorb landet, das sind ja nicht einmal 10% .

Auf die Genexis Web-GUI gibt es keinen Zugriff! Falls dies durch Manipulation gelingt, dann wird es wohl so sein, wie bei allen anderen GPON ONTs dieses Herstellers: die Web-GUI ist nur dann ansprechbar, wenn kein Glasfaserkabel gesteckt ist.