Glasfaser-NordWest versaut den Ausbau in dem es nur Tarife mit niedriger Bandbreite anbietet (bis 1Gbit)

Zitat von BlackMage2

z.B. höhere Geschwindigkeiten als 1Gbit und damit XGSPON,

Aber fuer 141 Euro bei der Telekom wurdest Du das so oder so nicht buchen, warum dann Eifer es verfuegbar zu haben?

Zitat von BlackMage2

z.B. höhere Geschwindigkeiten als 1Gbit und damit XGSPON, das ist ein exklusives Feature was nur komplett Telekom-eigenen Netzen vorbehalten ist

Ich wiederhole mich: Singapur ist Dein Land.

Bei Dir hat anscheinend alles einen Haken.

Zitat von BlackMage2

Gibt es denn nichts was man in Singapur beachten muss? Ist ja ein komplett anderes Land..

Google oder eine Suchmaschine Deiner Wahl wird Dir helfen.

Zitat von HubeBube

Wer die Autobahn baut, spielt keine Rolle. Jedoch gibt es Mindestanforderungen für das Befahren.

Er baut ja auch nur die Autobahn und jeder darf sie befahren mit welchem Auto auch immer.
Bei unserem Netzausbau müssten die Autoverkäufer erst mal Kooperationsverträge mit dem Autobahnbauer schließen und der bestimmt welche Fahrzeuge fahren dürfen ( Diese muss er beim Autobahnbauer Leasen und darf sein Markennamen draufkleben ) und was das kostet.

Autovergleiche haken immer irgendwie.

Es ging jedoch auch gar nicht um das Auto, sondern um die verschiedenen Fahrbahn(en). Um diese benutzen zu dürfen, müssen bestimmte Anforderungen erfüllt sein. So z.B. Mindestgeschwindigkeit. Dies ist wiederum eine Analogie zur Untergrenze des Bandbreitenkorridors, der von der BNetzA vorgeschrieben wird.

Zitat von BlackMage2

Günstige Internetbandbreite ist doch gut für alle

Es wäre nur gut für die Kunden, nicht aber für die Firmen, die ihre anfänglich hohen Investitionskosten in einer fairen Zeit wieder reinholen müssen. Und leider muss man sagen, kostet so ein Netz im Unterhalt auch und es werden Reparaturen, Neuerungen usw. fällig, auch das ist in den hohen monatlichen Kosten mit eingerechnet - plus natürlich ein Gewinn, der in einer freien Marktwirtschaft nicht nur zum guten Ton gehört.

Wäre das nicht der Fall, dann hat man irgendwann nur noch ein eine marode Infrastruktur, aber niemanden mehr, der diese pflegen bzw. erweitern könnte.

Zitat von mbo77

BGP announcements sind jetzt nicht so geheim.

BGP announcements sind nicht geheim, aber erzaehlen halt nicht die ganze Geschichte... Hier eine Praesentation dazu die zeigt warum BGP keine ausreichende Loesung ist (hier im Kontext von Ingress-Point Detection):

Daily Archives – RIPE 89

https://ripe89.ripe.net/presentations/52-20241028_IPD_Presentation.pdf

"BGP announcement go towards the traffic source

Traffic Flows form the source towards the announcement

Requirement:

● Do not use BGP Prefix sizes"

BENOCS ist ein Spin-off der Deutschen Telekom... Ingress-Point Detection ist uebrigens sehr nuetzlich wenn man vorsaetzliches Unterpeering mit begrenzten Nebenwirkungen umsetzen will...

Und wo ist die Referenz zum Cloud Flare Routing?

Dass Cloud Flare den Traffic von der Telekom gezielt nach London leitet, ist doch wohl unstrittig, oder?

Zitat von mbo77

Und wo ist die Referenz zum Cloud Flare Routing?

Dass Cloud Flare den Traffic von der Telekom gezielt nach London leitet, ist doch wohl unstrittig, oder?

Würde Cloudflare gar nicht müssen, wenn die Telekom mit ihren Eyeballkunden kostenneutral an mehreren Punkten mit ihnen peeren würde.

Zitat von mbo77

Und wo ist die Referenz zum Cloud Flare Routing?

In wie fern ist das relevant? Mit der Frage wie breitbandmessung.de die Peeringqualitaet von ISPs messen koennte hat das nichts zu tun. Und auch mit dem vorsaetzlichen Unterpeering der Telekom hat das wenig zu tun. Das ist gerade mal interessant wenn man sich fragt warum die RTT zu Cloudflares free Tier bei der Telekom hoeher ist als bei vielen Mitbewerbern.

Die Auswirkungen der Unterpeerings sind jedoch andere: erhoehter Paketverlust und Jitter sowie verringerter Durchsatz in der Spitzenlastzeit, das hat mit der path RTT selber nichts zu tun.

Zitat von mbo77

Dass Cloud Flare den Traffic von der Telekom gezielt nach London leitet, ist doch wohl unstrittig, oder?

Keine Ahnung ob das aktuell noch so ist, das ging ja auch mal ueber die Ostkueste der USA. Die Frage ist bei der Konstruktion, warum macht Cloudflare das (ich neige kingpin42s Interpretation) und wenn es dabei zu Ueberlast kommt, liegt das an vorsaetzlich unterdimensionierten Uebergaben der Telekom?

Zumindest im untersuchten Fall lag die Überlast beim propagierten Router in London.

Zitat von mbo77

Zumindest im untersuchten Fall lag die Überlast beim propagierten Router in London.

Unklar, es gab da wenn ich mich recht erinnere, wie so oft keinerlei belastbare Einsicht in den Lastpfad von Cloudglare in London zu den Nutzern... was gezeigt wurde ist, die Wahl des Standortes London liess sich mit BGP Announcements von Cloudflare erklaeren, der Rest war Spekulation.

Zitat

Es sieht also sehr danach aus, als wenn Cloudflare den Traffic (nicht nur) der Telekom absichtlich zu bestimmten Routern und Peerings lenkt. Das ist ja erstmal ganz OK dass sie das machen, aber in dem Fall schicken Sie den Traffic mehr oder weniger absichtlich irgendwohin, wo sie nicht genug Kapazitäten haben.

Das ist halt Spekulation weil er nicht weiss wo der Endpass ist und ob Cloudflare andere nicht ueberlastete Uebergaben zur Verfuegung haette.

Erklaerung, mtr/traceroute koennen immer nur die Hops des Vorwaertspfades identifizieren aber Jitter und Paketverlust koennen durchaus bei spaeteren Hops auf dem Rueckweg entstehen, aber werden als Verlust am Vorwaertshop dargestellt... Etwas erstaunlich, dass der Reddit BGP-Versteher bei der MTR Interpretation so vorschnell vorgeht.

Zitat

Wenn wir auf den MTR vom Anfang schauen sieht man, dass zwischen der Telekom und Arelion (Hop 4 und 5) alles in Ordnung ist – danach, also schon nach der Übergabe von Arelion an Cloudflare, setzen erst hohe Latenz und Packetloss ein, der Engpass liegt also bei Cloudflare.

Ja, das mag naheliegend erscheinen, ist aber eine typische Fehlinterpretation von Traceroute/MTR.

Ein aehnliches Problem ergibt sich auch fuer BGP, auch da fehlt die Analyse was die Telekom an Cloudflare announced. Die Annahme Internetpfade waeren symmetrisch in beiden Richtungen ist zu optimistisch, ja es gibt auch mal symmetrische Pfade aber asymmetrische halt auch und das muss man bei Analysen beruecksichtigen. Dazu Slide 38 hier: https://archive.nanog.org/sites/default/…_Traceroute.pdf

Na, da hat er schon ein bisschen mehr untersucht. Gut, willst du nicht akzeptieren, dann ist die Diskussion hier auch am Ende. Hatten wir schon ein paar mal, da kommen wir nicht weiter.

Aber ich bin ehrlich: Mir sind komplexere Analysen wichtiger als tatsächlich Spekulation und Geunke.

Zitat von pufferueberlauf

auch da fehlt die Analyse was die Telekom an Cloudflare announced

Klar, kann man sich in Summe ansehen. Wenn aber der Pfad Telekom zu Cloudflare zu ist, spielt die (asymmetrische) andere Richtung nur eine kleinere Rolle. ACK kommen einfach nicht mehr verlässlich an. Das war es dann mit der Kommunikation.

Bzgl. traceroute gebe ich dir nur bedingt recht. Einzelne Ausreißer kann man ignorieren. Mehrere Hops in Folge verwerfen nicht jedes, aber viele Pakete? Das ist schon eine andere Hausnummer.

Habe ich irgendwo ausgeschlossen, dass die Telekom hier ein unschönes Spiel spielt? Noch nie. Weise ich darauf hin, dass die Situation komplex ist? Eben dies. Und damit reagiere ich allergisch, wenn immer noch Vodafone, Telekom etc. die Schuldigen sind. Zur Kommunikation braucht es immer beide Partner. Welches Spiel spielt also Cloudflare? Offenbar wird da ja auch sehr aktiv gesteuert.

Zitat von mbo77

Na, da hat er schon ein bisschen mehr untersucht.

Erm, was den Ursprung der Ueberlast angeht hat er exakt ein MTR Trace ausgewertet, und zwar auf die von mir beschriebene Art wie man es nicht machen soll.

Zitat von mbo77

Gut, willst du nicht akzeptieren, dann ist die Diskussion hier auch am Ende. Hatten wir schon ein paar mal, da kommen wir nicht weiter.

Aber ich bin ehrlich: Mir sind komplexere Analysen wichtiger als tatsächlich Spekulation und Geunke.

Warum bist Du dann mit der praesentierten unter-komplexen Analyse des Ueberlast-Ortes einverstanden? Ganz im Ernst, es macht tatsaechlich wenig Sinn weiter zu diskutieren, da Du erkennbar der Meinung bist das vorsaetzliche Unterpeering der Telekom waere irrelevant oder existierte gar nicht.

Zitat von mbo77

Klar, kann man sich in Summe ansehen. Wenn aber der Pfad Telekom zu Cloudflare zu ist, spielt die (asymmetrische) andere Richtung nur eine kleinere Rolle. ACK kommen einfach nicht mehr verlässlich an. Das war es dann mit der Kommunikation.

Es gibt im referenzierten Post nur halt keine belastbaren Indizien dafuer, dass der Pfad von der Telekom zu Cloudflare "zu" waere. Nochmal, Du kannst aus einem MTR-Trace in nur einer Richtung nur bedingt Rueckschluesse auf den Ort einer Stoerung machen. Hier sehen wir gerade mal, dass alle Cloudflare zugeordneten Hops massiv erhoehte Maximal-RTT zeigen (und Paketverlust), aber nicht ob diese Latenzerhoehung bei den Cloudflare Servern selber entsteht, oder irgendwo auf dem Rueckweg von den Cloudflare Servern zur Telekom, das kann z.B. bei der Uebergabe von Cloudflare zur Telekom sein, also exakt die erwartete Auswirkung des vorsaetzlichen Unterpeerings der Telekom. (Es laesst sich noch nichtmal ausschliessen, dass das Problem zwischen 1299 und Cloudflare liegt, aber wahrscheinlich ist das nicht).

Zitat von mbo77

Bzgl. traceroute gebe ich dir nur bedingt recht. Einzelne Ausreißer kann man ignorieren. Mehrere Hops in Folge verwerfen nicht jedes, aber viele Pakete? Das ist schon eine andere Hausnummer.

Ein Missverstaendnis meiner Argumentation, mein Argument ist, dass wir aus dem Trace nicht ansatzweise schliessen koennen, der Engpass laege bei Cloudflare, mein Argument ist nicht es gaebe da keine Probleme. Ich will gar nichts ignorieren, ich will nur vermeiden dass wir den MTR-Trace ueberinterpretieren.

Zitat von mbo77

Habe ich irgendwo ausgeschlossen, dass die Telekom hier ein unschönes Spiel spielt? Noch nie. Weise ich darauf hin, dass die Situation komplex ist? Eben dies. Und damit reagiere ich allergisch, wenn immer noch Vodafone, Telekom etc. die Schuldigen sind. Zur Kommunikation braucht es immer beide Partner. Welches Spiel spielt also Cloudflare? Offenbar wird da ja auch sehr aktiv gesteuert.

Unklar, aber klar jeder Anbieter steuert Datenfluesse, dafuer ist BGP ja da, das ist nicht ehrenruehrig, und es ist nicht direkt das Problem der Telekom wenn Cloudflare ueber London oder Ashburn servieren will, aber was die beobachtet Ueberlast angeht, da ist die Telekom halt immer noch unter den Verdaechtigen. Zumindest fuer die unter uns die Traceroutes lesen und interpretieren koennen

Aber damit will ich hier Schluss machen, ist ja hier im Thread eher OT.

Zitat von BlackMage2

Anders wo klappt es doch auch mit der Finanzierung..

Na ja, wenn man mit geringeren Baukosten (z.B. weil weniger Tiefbau) und hoeherer Nachfrage (z.B. weil der Status Quo ADSL mit bestenfalls ca. 20 Mbps ist) zu einer Zeit anfaengt in der die Zinsen niedrig sind und Anleger auf der Suche nach Plaetzen fuer Ihr Geld die auch nur geringe Rendite versprechen... arbeitet, dann laeuft das halt geschmeidiger als wenn man:

1. auf Tiefbau besteht (wobei der Drops da bereits halb gelutscht war, ohne existierende Masten ist auch oberirdische Verlegung nicht so schnell und billig wie man sich das erhoffen wuerde).
2. erst mal die Masse mit Kabel und VDSL ausreichend mit Zugangskapazitaet versorgt, so dass die eher wenig an FTTH interessiert sind
3. unterlaesst in der Niedrigzinsphase die dann etwas interessierteren Anleger ins Boot zu holen

Zitat von BlackMage2

Muss ja einen Grund das es nur in Deutschland hapert.

Ich finde Du bist da zu harsch, und zu selektiv... so liegt z.B. Belgien beim FTTH AUsbau noch hinter Deutschland (aus aehnlichen Gruenden, auch in Belgien gab es wohl ein relativ gut ausgebautes Kupferbestandsnetz von dem sich die Nutzer ausreichend versorgt fuehlten).