1und1 Glasfaser Vertrag nach Telekom-Ausbau - hat der auch das lahme Telekom-Peering?

[Sebbi]

Dennoch war mydealz immer eins der Negativbeispiele, zumindest bei mir war die Seite einfach immer langsam. Nicht unbenutzbar, aber einfach langsam. Mit VPN und "anständigem" Peering flutschte es.

dann ist aber natürlich auch immer die Frage, ob nicht gerade cloudflare (siehe Post von Bodennebel) dafür verantwortlich ist wie bei pcgh.de, an welchen "Austrittspunkt" von deren Netzwerk die das ausgeben, so das dadurch sehr ungünstige Routen für die Telekom entstehen. Wie eben bei pcgh.de jetzt via London interconnect Richtung ip.twelve99.net

und da sieht das bei mir derzeit so aus:

  3    20 ms    21 ms    21 ms  lon-sb2-i.LON.GB.NET.DTAG.DE [62.154.14.246]
  4   113 ms   114 ms   113 ms  ldn-b2-link.ip.twelve99.net [62.115.50.18]

zudem ist auch die Frage, ob dein VPN nicht da auch einiges an bloatscripten noch rausgefiltert hat, da machen VPN Anbieter ja auch das Versprechen geben, da Werbung und Datenschutzbedenkliche Sachen auszufiltern.

und wenn ich mir anseh, was da bei mydealz von von vornherein versucht wird an Scripten zu laden, läufts mir den Rücken eiskalt runter

denn von htlbid.com scheint nichts gutes zu kommen, selbst wenn man die Domäne direkt aufruft, wird nix geladen. Keine Firma dahinter etc.
Wird wohl eine Domäne sein von einen Werbenetzwerk, wo man aber schon ein mulmiges Gefühl haben sollte, ob die ihre Server auch richtig warten und sichern.

 

[Web-Schecki]

dann ist aber natürlich auch immer die Frage, ob nicht gerade cloudflare (siehe Post von Bodennebel) dafür verantwortlich ist wie bei pcgh.de, an welchen "Austrittspunkt" von deren Netzwerk die das ausgeben, so das dadurch sehr ungünstige Routen für die Telekom entstehen. Wie eben bei pcgh.de jetzt via London interconnect Richtung ip.twelve99.net

Cloudflare hat schlicht kein Interesse daran, ihr Netz in irgendeiner Weise schlecht erreichbar zu machen. Weltweit gute Erreichbarkeit ist deren Geschäftsmodell als CDN. Man benutzt das ja gerade, um nicht einmal um die halbe Welt routen zu müssen, sondern immer einen lokalen Mirror in der Nähe der Anfrage zu haben.

Dass die DTAG nicht direkt mit Cloudflare peert, sondern die Routen Umwege über andere Carrier nehmen müssen, liegt mit Sicherheit nicht an Cloudflare. Diese Umwege kosten Cloudflare Geld, weil sie den Transit bei einem Tier1-Carrier einkaufen müssen. Deshalb werden Kunden von Cloudflare-Premium offembar bevorzugt über teurere aber kürzere Unwege in Anfragenähe angebunden und die anderen dann eben günstiger, also über Großbritannien oder sogar die USA.

Bei so gut wie keinem größeren Provider hierzulande dürfte überhaupt irgendein Umweg nötig sein. Die sind direkt angebunden, in der Regel geht es nicht mal über einen IX. Die Cloudflare-Mirrors stehen sprichwörtlich beim Provider im Keller. Die Latenz dürfte in etwa genauso gut wie zu Servern des Provider-AS sein.

 

[Sebbi]

Cloudflare hat schlicht kein Interesse daran, ihr Netz in irgendeiner Weise schlecht erreichbar zu machen.

das hat auch keiner gesagt, nur können nicht alle Webseiten an jeden Cloudflare Gateway gleichzeitig verfügbar sein, sonst würden ja Gateways teils dauerhaft überlastet werden.
heißt je nach Paket, was man nach CF bucht, wird die Website eben nicht am Gateway mit den direkten Peering des ISP des Aufrufers ausgeliefert, sondern an einen weniger ausgelasteten und günstigeren Gateway für CF, das aber dann ggf. längere Routing Wege bedeutet.

Bei so gut wie keinem größeren Provider hierzulande dürfte überhaupt irgendein Umweg nötig sein. Die sind direkt angebunden, in der Regel geht es nicht mal über einen IX. Die Cloudflare-Mirrors stehen sprichwörtlich beim Provider im Keller.

Wie gesagt, ist die Frage wie das CF handhabt, die angebotenen Websiten auch auf diesen Mirrors verfügbar zu machen oder ob man dafür extra zahlen müsste und ob sich Websites wie pcgh.de da sparen.

Diese Umwege kosten Cloudflare Geld, weil sie den Transit bei einem Tier1-Carrier einkaufen müssen.

DAS ist die Frage, inwieweit das wirklich der Fall ist. Nicht das ein direktes Peering zu einen entsprechenden ISP teurer ist als das zu dem Tier1-Carrier.

 

[Der Lord]

Ich kann übrigens das teils miese Telekom Peering bei Cloudflare (und auch gern AWS) bestätigen, am FTTH Anschluss.

Mit VPN (kein blödsinniges Cloud VPN, sondern WG Tunnel zu einem o2 Anschluss) ist alles tip top.

Es ist in den letzten Jahren zwar besser geworden, aber definitiv noch ein Thema.

 

[Web-Schecki]

nur können nicht alle Webseiten an jeden Cloudflare Gateway gleichzeitig verfügbar sein, sonst würden ja Gateways teils dauerhaft überlastet werden.

Doch. Also ich weiß nicht genau, was du mit Gateway meinst. Aber im Grunde genommen kann jede Anfrage an Cloudflare auch von jedem Cloudflare-Cluster beantwortet werden, egal, ob der nun in Frankfurt, New York, Singapur oder London steht. Das ist Sinn und Zweck des Ganzen.
Sicherlich gibt es aber einmal Cloudflare Free und einmal Cloudflare Premium, und mit letzterem scheinst du auch das bessere Routing zu bekommen. Es wurde allerdings schon beobachtet, dass du manuell eine Cloudflare-Premium-IP als Host eintragen kannst und dann auch die Webseiten mit Cloudlfare Free über besseres Routing erreichst - anycast sei dank. Die Webseiten werden also scheinbar tatsächlich überall gespiegelt.

Der Punkt ist nun: Auch Cloudflare Free-IPs (pcgh.de) erreichst du von allen gängigen Internetanschlüssen in Deutschland ohne Umwege. Für Cloudflare ist es intern nunmal egal, und wenn sie ausreichend Peering-Kapazitäten zur Verfügung haben, weil sich der ISP mit Cloudflare auf ein marktübliches Peerings geeinigt hat, dann gibt's auch keinen Grund für Umwege.

oder ob man dafür extra zahlen müsste und ob sich Websites wie pcgh.de da sparen.

Exakt, die sparen sich das. Würde ich auch machen, denn bei allen Anbietern außer der DTAG gibt es keinen Unterschied bzgl. des Routings.

Nicht das ein direktes Peering zu einen entsprechenden ISP teurer ist als das zu dem Tier1-Carrier.

Genau das ist bei der DTAG offensichtlich der Fall. Es ist günstiger, die Kunden der DTAG über einen anderen Tier1-Carrier anzubinden.
Cloudflare hat grundsätzlich Upstreams zu fast allen anderen Tier1-Carriern. Die werden sich den Transit aber alle teuer vergüten lassen, weswegen Cloudflare an direkten Peerings interessiert ist. Und die ISPs sind das normalerweise auch. Nur die DTAG offensichtlich nicht...

 

[Bodennebel]

Hier mal ein Traceroute zu pcgh.de von mir im Juni 2024: https://www.computerbase.de/forum/t...s-lahme-telekom-peering.2200295/post-29527738. Damals lief das Routing über New York mit entsprechend miesen Werten. Keine Ahnung, ob da Cloudflare involviert war. Da war das gestern über London richtig fix.

 

[Looniversity]

Cloudflare hat grundsätzlich Upstreams zu fast allen anderen Tier1-Carriern. Die werden sich den Transit aber alle teuer vergüten lassen, weswegen Cloudflare an direkten Peerings interessiert ist. Und die ISPs sind das normalerweise auch. Nur die DTAG offensichtlich nicht...

Bingo. Die Telekom nimmt von den Haushalten Geld dafür, "das Internet" bereitzustellen, aber will "vom Internet" gleichzeitig auch noch viel Kohle dafür, die Daten zum Kunden zu bringen. Dass der Kunde dafür aber schon bezahlt und die Telekom damit die Daten schon ranzuschaffen hat, ignoriert die Telekom geflissentlich.

Die Spitzfindigkeit ist, dass die Telekom sagt, sie stelle Haushalten nur den Zugang (quasi den Verbindungsaufbau) zum Netz bereit, nicht die Beförderung aller Daten. Das dürfte für den normal verständigen Verbraucher aber überraschend und damit nicht haltbar sein.

Dummerweise meint die Telekom, genug Marktanteil, Marktmacht und politisches Kapital zu haben, dass sie damit durchkommen oder zumindest dafür nichts auf den Deckel bekommen wird. Unter der Annahme kann sie mit dem Verhalten gar nicht verlieren. Und muss man leider feststellen, dass das seit Jahrzehnten auch stimmt. Die Politik will die Telekom als deutschen Champion und interessiert sich für solche Sachen nicht. Schlimmer noch, teilweise sieht die Politik das als schlaues Marktmodell.

Man stelle sich eine Dorfstraße vor, die trotz Verbindungen autos nur zu Lidl aber nicht zu Aldi fahren lässt, es sei denn, Aldi bezahlt die Straße für jedes Auto. Es wäre die reine Wegelagerei. Grrrr.

 

[Web-Schecki]

Da war das gestern über London richtig fix.

Dass das nun über London geht, ist sicherlich Cloudflare zu verdanken. Arelion wird sich das einiges kosten lassen, das ist nämlich deren Geschäftsmodell. Aber direktes Peering mit der DTAG ist scheinbar teurer, was einfach absurd ist.
Wie gesagt, bei allen anderen deutschen Internetanbietern klappt es.

Dummerweise meint die Telekom, genug Marktanteil, Marktmacht und politisches Kapital zu haben, dass sie damit durchkommen oder zumindest dafür nichts auf den Deckel bekommen wird.

Fairerweise ist es für den Gesetzgeber auch extrem schwierig, hier regulatorisch einzugreifen und dabei keinen größeren Schaden anzurichten. Denn grundsätzlich ist es ja durchaus nachvollziehbar, dass man die komplexen Entscheidungen bzgl. Peering, Transit und Routing mal schön den Netzbetreibern selbst überlässt, weil das individuell schon am besten hinbekommen. Überall sonst klappt das ja auch hervorragend. Ebenfalls ist es fast unmöglich, sinnvolle Ansprüche für den Verbraucher gesetzlich zu verankern. Dass man grundsätzlich auch mal 100ms Latenz z.B. zu einem Server in den USA haben kann, ist ja vor allem phsyikalisch bedingt. Bei Cloudflare ist es halt schlicht dämlich, weil die grundsätzlich jede Anfragen möglichst nah am Endkunden beantworten wollen, was ja eben insbesondere auch im Interesse des Endkunden ist.

Die DTAG ist einfach ein ziemlicher Sonderfall, weil sie sowohl Tier1-Carrier als auch riesiger Privatkunden-ISP ist und gleichzeitig kein Problem damit hat, ihre Kunden in Geiselhaft zu nehmen.
Man kann daher einfach nur davon abraten, sich freiwillig in diese Geiselhaft zu begeben. Es gibt nur in den seltensten Fällen keine günstigere und bessere Alternative.

 

[Firefly1337]

zudem ist auch die Frage, ob dein VPN nicht da auch einiges an bloatscripten noch rausgefiltert hat, da machen VPN Anbieter ja auch das Versprechen geben, da Werbung und Datenschutzbedenkliche Sachen auszufiltern.

In meinem Fall war das ein Wireguard Tunnel zu meinem eigenen VPS, also kein öffentlicher VPN-Anbieter.
Das Filtern übernehme ich schon zuhause via Adguard Home, also sowohl ohne als auch mit VPN.

Es lag also definitiv am Peering/Routing. Ich kann auch keine Experimente mehr anstellen, da ich wie gesagt (zum Glück) kein Telekom-Kunde mehr bin und auch nie wieder sein werde. Ich beglückwünsche jeden, der von Peering keine Ahnung hat oder das einfach nicht merkt, ich habs leider fast täglich gemerkt.

Wie dem auch sei, ich wollte mit meinem Beitrag kein neues Telekom-Bashing starten (auch wenn es meiner Meinung nach gerechtfertigt ist) - das Thema ist bekannt. Ich wollte lediglich bestätigen, dass O2 an einem Telekom-FTTH Anschluss eigenes Peering hat und man damit neben 1und1 eine Alternative hat, um dem Problem zu entkommen.

 

[froeschi62]

Könnte hier jemand mal tracen, der einen 1&1 oder O2 Anschluss besitzt?

tracert 185.60.114.159

1 <1 ms <1 ms <1 ms fritz.box
2 2 ms 1 ms 1 ms p3e9bf67e.dip0.t-ipconnect.de [62.155.246.126]
3 17 ms 17 ms 17 ms lon-sa1-i.LON.GB.NET.DTAG.DE [217.239.58.17]
4 15 ms 14 ms 14 ms 80.157.128.226
5 18 ms 17 ms 17 ms i-1008.ulcn-core01.telstraglobal.net [202.84.178.13]
6 150 ms 150 ms 151 ms i-1031.eqnx-core02.telstraglobal.net [202.84.249.9]
7 290 ms 290 ms 291 ms i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
8 291 ms 291 ms 289 ms i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
9 285 ms 284 ms 285 ms i-91.sydp10.telstraglobal.net [202.84.222.86]
10 290 ms 291 ms 290 ms unknown.telstraglobal.net [210.176.38.113]
11 355 ms 355 ms 355 ms ae2-br02-eqsy4.as57976.net [137.221.85.49]
12 * * * Zeitüberschreitung der Anforderung.
13 518 ms 418 ms 403 ms xe-0-0-0-0-br02-lgpy1.as57976.net [137.221.65.65]
14 358 ms 358 ms 358 ms et-0-0-1-pe01-lgpy1.as57976.net [137.221.84.83]
15 354 ms 354 ms 354 ms icn-lgpy1-ia-bons-01.as57976.net [137.221.66.97]
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 * * * Zeitüberschreitung der Anforderung.
22 * * * Zeitüberschreitung der Anforderung.
23 * * * Zeitüberschreitung der Anforderung.
24 * * * Zeitüberschreitung der Anforderung.
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung.
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 * * * Zeitüberschreitung der Anforderung.

 

[DLMttH]

Spoiler

Routenverfolgung zu 185.60.114.159 über maximal 30 Hops

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     6 ms     5 ms     5 ms  192.0.0.1
  3     9 ms     7 ms     6 ms  wup1101aihd001.versatel.de [62.214.42.209]
  4     8 ms     7 ms     8 ms  213.19.194.26
  5     8 ms     7 ms     8 ms  ae60.edge6.Dusseldorf1.Level3.net [213.19.194.25]
  6     *       18 ms    16 ms  ae1.3118.ear5.lon1.neo.colt.net [171.75.9.155]
  7    28 ms    29 ms    27 ms  unknown.telstraglobal.net [210.57.53.106]
  8    27 ms    26 ms    26 ms  i-10070.ulcn-core01.telstraglobal.net [202.84.178.53]
  9   159 ms   158 ms   158 ms  i-1031.eqnx-core02.telstraglobal.net [202.84.249.9]
 10   293 ms   292 ms   293 ms  i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
 11   294 ms   292 ms   293 ms  i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
 12   293 ms   292 ms   293 ms  i-91.sydp10.telstraglobal.net [202.84.222.86]
 13   293 ms   295 ms   298 ms  unknown.telstraglobal.net [210.176.38.113]
 14   433 ms   418 ms   419 ms  ae2-br02-eqsy4.as57976.net [137.221.85.49]
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16   412 ms   437 ms   437 ms  xe-0-0-0-0-br02-lgpy1.as57976.net [137.221.65.65]
 17   398 ms   397 ms   398 ms  et-0-0-1-pe01-lgpy1.as57976.net [137.221.84.83]
 18   405 ms   405 ms   404 ms  icn-lgpy1-ia-bons-01.as57976.net [137.221.66.97]
 [...]

 

[Looniversity]

Spoiler: Von 1und1 VDSL

tracert 185.60.114.159

Tracing route to 185.60.114.159 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     4 ms     4 ms     3 ms  p3e9bf7d5.dip0.t-ipconnect.de [62.155.247.213]
  3    24 ms    23 ms    23 ms  lon-sa1-i.LON.GB.NET.DTAG.DE [217.239.58.21]
  4   152 ms   152 ms   152 ms  80.157.128.226
  5   159 ms   158 ms   158 ms  i-1008.ulcn-core01.telstraglobal.net [202.84.178.13]
  6   164 ms   165 ms   164 ms  i-1031.eqnx-core02.telstraglobal.net [202.84.249.9]
  7   296 ms   295 ms   295 ms  i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
  8   296 ms   296 ms   296 ms  i-20208.sydp-core04.telstraglobal.net [202.84.141.26]
  9   294 ms   293 ms   293 ms  i-91.sydp10.telstraglobal.net [202.84.222.86]
 10   302 ms   314 ms   301 ms  unknown.telstraglobal.net [210.176.38.113]
 11   370 ms   367 ms   367 ms  ae2-br02-eqsy4.as57976.net [137.221.85.49]
 12     *        *        *     Request timed out.
 13   593 ms   439 ms   439 ms  xe-0-0-0-0-br02-lgpy1.as57976.net [137.221.65.65]
 14   377 ms   370 ms   380 ms  et-0-0-1-pe01-lgpy1.as57976.net [137.221.84.83]
 15   367 ms   367 ms   367 ms  icn-lgpy1-ia-bons-01.as57976.net [137.221.66.97]
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.

 

[DLMttH]

NetCologne ist ganz anders... 20 ms abziehen wegen VPN-Latenz.

Spoiler

Routenverfolgung zu 185.60.114.159 über maximal 30 Hops

  1    27 ms    26 ms    26 ms  fritz.box [192.168.178.1]
  2    36 ms    34 ms    33 ms  bras-vc10-lo0.netcologne.de [195.14.226.65]
  3    36 ms    35 ms    33 ms  ip-core-kln1-ae25.netcologne.de [78.35.33.149]
  4    35 ms    34 ms    34 ms  ip-core-sto2-et2-1-4.netcologne.de [78.35.10.11]
  5    33 ms    34 ms    32 ms  bdr-sto1-ae2.netcologne.de [81.173.192.118]
  6    38 ms    32 ms    32 ms  ae1.rt.ncl.cgn.de.retn.net [87.245.227.96]
  7     *       39 ms    35 ms  ae0-4.rt.eqx.fkt.de.retn.net [87.245.232.78]
  8    39 ms    36 ms    35 ms  FRA-POP41.bora.net [80.81.193.16]
  9   213 ms   233 ms   305 ms  1.213.153.209
 10   285 ms   303 ms   304 ms  1.208.107.77
 11   292 ms   254 ms   255 ms  61.42.234.254
 12   250 ms   246 ms   250 ms  117.52.1.146
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14   266 ms   316 ms   244 ms  110.45.174.214
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16   245 ms   246 ms   246 ms  et-0-0-0-pe01-lgpy1.as57976.net [137.221.84.75]
 17   256 ms   315 ms   306 ms  icn-lgpy1-ia-bons-01.as57976.net [137.221.66.97]
 18     *        *        *     Zeitüberschreitung der Anforderung.

 

[froeschi62]

Dankeschön. Es hat mich mal interessiert, wie sich das Routing zu EA/Battlefield-Servern bei anderen Providern verhält.

 

[Holzkopf]

Is halt weit weg Seoul Süd Korea die Gegend wo der Server hinter der IP steht.

 

[DLMttH]

Da mache ich es nicht besser, wenn ich über Sydney route

230 ms mit NetCologne VDSL gegen 350+

 

[eifelman85]

Spoiler: o2 VDSL

Routenverfolgung zu 185.60.114.159 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2    14 ms    13 ms    16 ms  loopback1.0005.acln.02.fra.de.net.telefonica.de [62.52.193.29]
  3    14 ms    14 ms    14 ms  bundle-ether37.0001.cord.02.fra.de.net.telefonica.de [62.53.12.56]
  4    14 ms    14 ms    13 ms  bundle-ether1.0001.corp.02.fra.de.net.telefonica.de [62.53.8.187]
  5    14 ms    14 ms    13 ms  176.52.252.28
  6    14 ms    14 ms    14 ms  94.142.107.201
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8   170 ms   169 ms   169 ms  if-bundle-56-2.qcore2.pvu-paris.as6453.net [80.231.245.40]
  9   166 ms   166 ms   166 ms  if-bundle-12-2.qcore1.pvu-paris.as6453.net [80.231.245.12]
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11   168 ms   168 ms   167 ms  if-bundle-2-2.qcore2.pye-paris.as6453.net [80.231.154.27]
 12   168 ms     *      167 ms  if-bundle-13-2.qcore1.ldn-london.as6453.net [80.231.196.37]
 13     *      170 ms   169 ms  195.219.213.139
 14   169 ms   168 ms   167 ms  if-bundle-14-2.qcore1.nto-newyork.as6453.net [195.219.51.157]
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16     *        *      170 ms  if-bundle-2-2.qcore2.sqn-sanjose.as6453.net [66.198.101.129]
 17   170 ms   170 ms   170 ms  63.243.188.6
 18     *        *        *     Zeitüberschreitung der Anforderung.

 

[h00bi]

Man stelle sich eine Dorfstraße vor, die trotz Verbindungen autos nur zu Lidl aber nicht zu Aldi fahren lässt, es sei denn, Aldi bezahlt die Straße für jedes Auto. Es wäre die reine Wegelagerei. Grrrr.

Das ist leider nicht korrekt. Und das ist auch das Problem an der Peering Thematik. Die Vorwürfe sind oftmals falsch formuliert, die Telekom kann das mit Fug und Recht abstreiten. Um bei deiner Analogie zu bleiben, die Telekom macht folgendes:

An deiner imaginären kleinen Dorfstraße ist ein normaler Lidl und ein normaler Aldi. Aldi entschließt sich nun, an dieser Dorfstraße einen riesigen Super-Aldi zu bauen, der viel mehr Kunden anlockt. Auf der kleinen Dorfstraße zum Super-Aldi entsteht durch die vielen Kunden dauernd Stau. Die Stadtverwaltung (Telekom) sagt Aldi: Wenn ihr eine breitere Straße zum Super-Aldi wollt, dann müsst ihr dafür bezahlen, auch wenn ihr bereits Gewerbesteuern bezahlt und die Autofahrer bereits Steuern bezahlen.

Es ist nämlich eben nicht so, dass die Telekom künstlich Engpässe schafft (was fälschlicherweise vorgeworfen wird), sie erweitern einfach nicht auf eigene Kosten.

Und das Konzept der Telekom funktioniert ja auch nur gegen kleinere Contentanbieter. Man stelle sich mal vor, die Telekom würde das mit massen-populären Diensten wie den ÖR Mediatheken, Netflix oder Amazon-Diensten machen. Da würden sogar meine Schwiegermutter kündigen und wechseln.
Aber Twitch? Wen interessiert denn schon Twitch? Wenn die was wollen, sollen sie zahlen...

 

[Looniversity]

Die Stadtverwaltung (Telekom) sagt Aldi: Wenn ihr eine breitere Straße zum Super-Aldi wollt, dann müsst ihr dafür bezahlen, auch wenn ihr bereits Gewerbesteuern bezahlt und die Autofahrer bereits Steuern bezahlen.

Dafür ist bei der Dorfstraße geregelt, dass der Super-Aldi (nur) für die eigene Zufahrt zur Dorfstraße bezahlen muss und für die öffentlichen Straßen gibt es auch Kriterien, nach denen Ausbauplanung zu erfolgen hat. Das ist beim Peering halt leider nicht der Fall.

Und das Konzept der Telekom funktioniert ja auch nur gegen kleinere Contentanbieter

Cloudflare sind halt nur gefühlt 30% des Internets. Dummerweise ist in der öffentlichen Wahrnehmung nicht "Cloudflare" langsam, sondern die Millionen Dienste/Marken darauf. Wenn Cloudflare mal eine Seite vorschalten würde, würde dem Thema sicherlich bald ähnlich viel Aufmerksamkeit zuteil als wäre Netflix betroffen.