Mobilfunknetzumbau bei Telefonica (O2/E-Plus)

Da an diversen Stellen immer mal wieder Fragen oder Missverständnisse auftauchen, was Telefonica derzeit mit den Mobilfunknetzen von O2 und E-Plus im Rahmen der Netzfusion macht, hier mal eine kurze Zusammenfassung.

Umstellungsmaßnahmen

Es gibt im wesentlichen zweierlei Umstellungsmaßnahmen:

  • Großflächige „Recolorings“, d.h Umstellungen des Netzcodes
  • Konsolidierungen von bestimmten Standorten

Netzgebiete

Die großflächigen Umstellungen beziehen sich auf folgende Netzgebiete:

  • Süd: Baden-Württemberg und Bayern (ohne Unterfranken)
  • Nord-Ost: Schleswig-Holstein, Hamburg, Bremen, Niedersachsen, Mecklenburg-Vorpommern, Sachsen-Anhalt, Berlin, Brandenburg, Thüringen, Sachsen
  • West: Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Hessen, Unterfranken

Recoloring

Bei den Recolorings wird der Netzcode der O2-Sender (262-07) in einem Netzgebiet auf den Netzcode von E-Plus (262-03) umgeschaltet. Dieser Netzcode soll am Ende der Netzfusion übrig bleiben. Die Technik der Sender und deren Anbindung wird beim Recoloring ansonsten nicht verändert.

Das erste Recoloring fand im Herbst 2016 im Netzgebiet Süd statt. Alle GSM- und UMTS-Stationen, die bis dahin den O2-Netzcode verwendet haben, wurden auf den E-Plus-Netzcode (das ist der Netzcode, der am Ende des Netzfusion bestehen bleiben soll) umgeschaltet. Gleichzeitig mit diesem GSM- und UMTS-Recoloring wurde O2-LTE in den bisher für E-Plus-Karten gesperrten Bereichen freigegeben. Das LTE-Recoloring folgte dann im Februar 2017.

Im Netzgebiet Nord-Ost läuft das „Recoloring“ seit Q1/2017. Berichte z.B. im Telefon-Treff-Forum deuten darauf hin, dass a) langsamer Recolored wird als im Netzgebiet Süd, aber b) gleichzeitig auch LTE umgestellt wird und c) dort auch die LTE-Sperre mit dem Recoloring entfällt.

Das Netzgebiet West dürfte im Q2/2017 starten.

Ein Hinweis, wo gerade Arbeiten stattfinden, gibt der O2 Live Check. Dort ist direkt unter der Überschrift „Live Check für Ihren Standort“ ein Hinweistext der aktuell bearbeitete Gebiete nennt.

Konsolidierung

Die Konsolidierung ist der endgültige Umbau auf die einheitliche, neue Infrastruktur. Dabei werden nicht nur Netzcodes umgeschaltet sondern meist der komplette Sender für ein bis mehrere Wochen abgeschaltet, abgebaut und mit neuer Technik (und Anbindung) neu aufgebaut. Für den Aussenstehenden ist das aber nach dem Recoloring nicht mehr ohne weiteres erkennbar. Helfen kann hier eine App, die die technischen Daten des Mobilfunknetzes auslesen kann (ich bevorzuge „NetMonster“). Wenn diese plötzlich Änderungen des/der „area codes“ anzeigt, deutet das auf den Umbau hin.

Disclaimer

Ich bin kein Telefonica Mitarbeiter sondern nur technisch interessierter Nutzer.

BEREC-Konsultation zu Netzneutralitätsregeln

Im Herbst 2015 hat das EU-Parlament die europäische Netzneutralitätsverordnung verabschiedet, seit einigen Tagen ist nun der Entwurf der technischen Richtlinien zur Netzneutrlitätsverordnung von BEREC (dem Verband der Telekommunikationsregulierer der EU-Länder) veröffentlich worden. Bis zum 18. Juli 14:00 können interessierte an der Konsultation teilnehmen, Beiträge dazu sind per Mail an NN-Consultation@berec.europa.eu zu richten.

Meinen Konsultationsbeitrag habe ich eben abgeschickt:

Dear Ladies and Gentleman,

First of all I would like to thank you for your work on the guidelines
on implementation of net-neutrality rules according to regulation
2015/2120 and the chance to comment on the draft.

In 1997 I had my first contact with the internet via a local computer
and internet club, which helped citizens getting access to the internet
and trains them on how to use services and applications. During my time
as a university student, the internet was an important source for
lectures and research information. Now working as a software developer,
internet access without blocked or throttled services and applications
is still crucial for me.

Concerning "specialised services" and zero-rating contracts, I prefer a
strict approach, requiring technical rather than economical necessities
for QoS. Allowing ISPs to implement any kind of discrimination between
CAPs would negatively influence the development of new internet based
services or applications. In addition it would also negatively influence
the economical development of smaller ISPs, as their market power (i.e.
number of subscribers) is not sufficient to get the same payment for
"specialised services" from CAPs as the bigger ISPs. Hence the bigger
ISPs will be able to profit from a double sided market - as they already
try to do within the IP-interconnection/peering-sector - and maybe lower
the end user prices to a level which cannot be offered by smaller ISPs
which don't profit from a double sided market.

Here are my comments to some of your guideline paragraphs:

Regarding IP-interconnection/peering
------------------------------------

As you mentioned in par. 6, IP-interconnection/peering policies can be
abused to circumvent the net-neutrality regulation by facilitating
insufficient (i.e. recurringly congested) interconnection capacities for
normal IAS and only installing sufficient capacities towards certain CAPs.

Par. 15 should require ISPs to implement an IP-interconnection/peering
policy which provides sufficient capacities and prevents recurring
congestion.

Par. 56 should emphasize that ISPs should not only provide transparent
information about traffic management measures to NRAs but also to
end-users. These information should also include details on overbooking
factors of networks and IP-interconnection/peering capacities.

Par. 112 & 113 should mention that not only sufficient network capacity
is required to provide a "specialised service" but also sufficient
IP-interconnection/peering capacity.

Par. 158ff. should require the certified monitoring systems to also be
designed to monitor performance issues caused by insufficient
IP-interconnection/peering. This could help NRAs to detect
IP-interconnection/peering policies aimed at circumventing the regulation.

Par. 164 should also include monitoring of IP-interconnection/peering
capacities in the supervision duties of the NRAs.

Regarding zero-rating
---------------------

Par. 36 - 40 should also consider commercial practices influencing end
users' exercise of rights (instead of directly limiting them) like
zero-rating of specific applications to be an infringement of the
regulation. Such practices force end users to prefer a specific
application (and hence CAPs) which discriminates other CAPs providing
applications of the same category and might even discourage new CAPs
from entering the market as they could not compete with existing CAPs
due to existing zero-rated applications.

ISPs offering contracts with zero-rated applications (or classes of
applications) should be required to offer a comparable service without
zero-rating at a reasonable price (i.e. without prohibitive high pricing).

Par. 45 should be clarified: The second point is in contrast to allowing
certain types of zero-rating: Zero-rating always causes some
applications or classes of applications (those that are not zero-rated)
to have a higher effective data price as other(s). E.g. if there is a
mobile tariff plan at 10 EUR including 1 GB of data volume and
zero-rating a specific music streaming application, then the price of 1
MB of the specific music streaming application is 0 while any other data
is at 0,01 EUR per MB (and therefore at a higher price). So there is a
strong disincentive to use any other music streaming service than the
zero-rated one.

Regarding "specialised services"
--------------------------------

Par. 101 should not allow "specialised services" to circumvent
regulation on zero-rating. E.g. the combination of a regular IAS with
limited data volume and a "specialised service" for a certain IP-TV
service with unlimited data volume should not be allowed as it
influences the end user’s decision on which IP-TV service to use.

Par. 118 should ensure that the end user's IAS performance shall not be
impacted by currently unused "specialised services". Furthermore, it
should be added that ISPs offering "specilised services" have to provide
a way for end users to configure the priorisation on the dedicated last
mile (e.g. to allow an end user to reserve a minimum of 60% of the
access speed for the IAS).

Regarding terminal equipment
----------------------------

Par. 23 should define the NTP as passive component to prevent ISPs from
declaring their preferred routers as NTP and thereby forcing customers
to buy or rent certain models.

I hope you can take my comments into consideration for a further
refinement of the guidelines, as I consider strict net-neutrality rules
as crucial for the development of the internet.

Kind regards,

Daniel Weber

Visual Studio 2015 Update 1: TargetUniversalCRTVersion wird nicht aktualisiert

Nach der Installation vom Update 1 für Visual Studio 2015 profitiert man evtl. nicht von der einen oder anderen Korrektur in der Universal Runtime, weil die Versionsnummer des Windows SDKs in den Konfigurationsdateien der Build-Tools nicht von 10.0.10240.0 auf 10.0.10586.0 hochgesetzt wird und somit die falschen (d.h. veralteten) LIB-Dateien vom Linker herangezogen werden.

Um die Versionsnummer manuell zu korrigieren geht man (mit Adminrechten) folgendermaßen vor:

  • Eine Sicherung der Datei „%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Common.props“ anlegen.
  • Das Schreibschutzattribut der Datei entfernen.
  • Die Datei bearbeiten, nach dem Eintrag für „TargetUniversalCRTVersion“ suchen und den Wert von 10.0.10240.0 auf 10.0.10586.0 hochsetzen.

Visual Studio 2015: Funktion „stat“ inkompatibel mit Windows XP/2003

Ja, Windows XP und Windows Server 2003 werden von Microsoft nicht mehr unterstützt, aber als Anwendungsentwickler muss man alte Betriebssystemversionen leider manchmal noch etwas länger unterstützen, weil der eine oder andere Kunde „etwas“ länger zur Migration benötigt.

Erfreulicherweise liefert Microsoft mit Visual Studio 2015 weiterhin Build-Tools für Windows XP/2003 mit, allerdings hat sich in der Laufzeitbibliothek zum Windows SDK 10.0.10240.0 (mindestens) ein Fehler eingeschlichen, der den Windows XP/2003 Support etwas eischränkt:

Die Funktion „stat“ zur Ermittlung von Dateieigenschaften (Größe, Zeitstempel, Attribute, …) läuft unter Windows XP/2003 für Dateien grundsätzlich in einen Fehler und errno steht danach nichtssagend auf EINVAL. Erst ein Blick auf den Rückgabewert der Windows-API-Funktion „GetLastError“ liefert ERROR_CALL_NOT_IMPLEMENTED.

Ein Blick in den Quellcode der Universal Runtime erklärt das Problem: Die intern verwendete Hilfsfunktion „common_stat_handle_file_opened“ benutzt die Windows-API-Funktion „GetFileInformationByHandleEx“, die es erst ab Windows Vista/2008 gibt.

Mit dem Visual Studion 2015 Update 1 bzw. im Windows SDK 10.0.10586.0 hat Microsoft diesen Fehler korrigiert und benutzt die ältere Windows-API-Funktion „GetFileInformationByHandle“.

Warum das korrigierte Windows SDK evtl. trotz Installation des Update 1 nicht zum Einsatz kommt, erkläre ich in einem separaten Blog-Beitrag.

VDSL-Vectoring im Nahbereich: Entscheidungsentwurf der BNetzA liegt vor

Seit die Telekom Anfang 2015 den Antrag auf Öffnung der Nahbereiche für VDSL-Vectoring bei der Bundesnetzagentur gestellt hat, gab es deutlichen Protest von den Telekom-Wettbewerbern. Ein Versuch, die letzte Meile zu Remonopilisieren, wurde der Telekom vorgeworfen. Nun ist endlich ein Entscheidungsentwurf da und obwohl ich sonst eher Telekom-kritisch argumentiere, sehe ich diesen positiv.

Worum geht es eigentlich?

Wenn sowohl im Hauptverteiler der Telekom ein Indoor-DSLAM (bzw. -MSAN) als auch ein Outdoor-MSAN im Nahbereich Kunden auf benachbarten Leitungen bedient, dann hat das Signal aus dem Indoor-MSAN bereits einiges an Strecke zurückgelegt und ist daher an der Stelle, wo auf der Nachbarleitung der Outdoor-MSAN sein Signal mit voller Leistung einspeist, bereits geschwächt und wird daher durch Crosstalk (Übersprechen zwischen den Leitungen) stärker in Mitleidenschaft gezogen. Um das zu vermeiden, wurde der Aufbau von Outdoor-MSAN erst ab mehr als 550 Metern (Kabel-)Entfernung zum Hauptverteiler – außerhalb des sogenannten Nahbereichs – gestattet.

VDSL-Vectoring hat damit nun gleich zwei Probleme:

  1. Aktuelle Vectoring-MSAN sind nicht „Hauptverteilertauglich“, weil dort zu viele Anschlüsse mittels der Vectoringtechnik „unter einen Hut“ gebracht werden müssten. D.h. um Kunden, die über Kabelverzweiger im Nahbereich versorgt werden, Vectoring anbieten zu können, müsste dieser Kabelverzweiger im Nahbereich zu einem Outdoor-MSAN ungebaut werden.
  2. Damit Vectoring überhaupt funktioniert, müssen alle VDSL-Anschlüsse im jeweiligen Verzweigerkabel vom selben MSAN bedient werden, damit dieser die gegenseitigen Störeinflüsse berücksichtigen und ausgleichen kann.

Die Telekom hat Anfang 2015 bei der Bundesnetzagentur daher den Antrag gestellt, in allen Nahbereichen Outdoor-MSAN zur Erschließung mit VDSL-Vectoring aufstellen zu dürfen. Im Gegenzug würde sie sich zur Erschließung wirklich aller Nahbereiche – nicht nur der Rosinen – verpflichten.

Warum haben die Wettbewerber damit Probleme?

Für einige Wettbewerber bedeutet dies de facto den „Rauswurf“ aus den Hauptverteilern sofern sie VDSL angeboten haben. Für andere Wettbewerber, die sich anderer Technologien bedient haben, bedeutet dies eine veränderte Konkurrenzsituation.

Warum sehe ich die Entscheidung dennoch positiv?

Sieht man sich die verschiedenen Wettbewerber, die gegen Nahbereichsvectoring argumentiert haben, genauer an, dann wird schnell klar, dass das große Geschrei unbegründet ist.

Die Kabelnetzbetreiber, allen voran Vodafone (mittels Kabel Deutschland) und Unity Media, nutzen komplett eigene Infrastruktur und haben somit durch Nahbereichsvectoring keinen technisch Nachteil. Ihr Gejammer kommt nur daher, dass ihr Geschwindigkeitsvorsprung – zumindest auf den Downstream bezogen – gegenüber der Telekom (und deren Resellern) dadurch wieder kleiner wird.

Die großen Wettbewerber mit eigener ADSL-Infrastruktur, Vodafone (ohne Kabel Deutschland) und Telefonica O2, haben bereits vor längerem angekündigt, verstärkt auf Bitstream-Vorleistungen der Telekom für VDSL setzen zu wollen. Beide haben also durch das Nahbereichsvectoring auch keinen technischen Nachteil sondern profitieren von den höheren möglichen Geschwindigkeiten für ihre Bitstream-Anschlüsse.

Bleiben noch die kleineren regionalen Anbieter und Stadtnetzprovider, wie z.B. Ewetel, M-Net oder NetCologne, die möglicherweise eigenes VDSL-Equipment in manchen Hauptverteilern aufgebaut haben, dass dadurch nun überflüssig wird und künftig durch Bitstream-Vorleistungen ersetzt werden müsste. Ja, hier sehe ich technisch und wirtschaftliche Nachteile, da diese Anbieter zukünftig evtl. weniger Flexibilität bei Anschlussschaltungen haben und evtl. noch nicht abbezahlte Hardware in den Ruhestand schicken müssen. Nur deswegen allerdings allen 9.000 Nahbereichen Vectoring vorzuenthalten und die Bewohner damit für die geringe Entfernung zum Hauptverteiler sogar zu bestrafen wäre doch zu viel der Rücksichtnahme.

Offenbar hat man das bei der BNetzA ähnlich gesehen und will den Telekom-Wettbewerbern ebenso den Ausbau von Nahbereichen erlauben, vorausgesetzt die Ausbauzusage geht bis Mai 2016 ein und der Wettbewerber ist um den jeweiligen Nahbereich herum bereits jetzt flächendeckener mit VDSL präsent als die Telekom. Problem dabei ist jedoch wiederum die potentielle „Rosinenpickerei“, wodurch die verbleibenden Nahbereiche für die Telekom unrentabel werden könnten.

Warum nicht gleich Glasfaser bis in die Wohnung?

Ja, das wäre freilich eine feine Sache, aber hier bin ich realistisch: Für die großflächige FTTH-Erschließungen sind die Nutzer hierzulande zu geizig, zu bequem und technisch zu wenig versiert. Das führt zu der bizarren Situation, das sich viele Wohnungseigentümer bzw. Eigentümergemeinschaften gegen eine Erschließung sträuben: „Wir haben doch schnelles Internet über das Kabelnetz.“ (mit lausigem Upstream), „Wir wollen nicht schon wieder Bauarbeiten in den Häusern.“, „Warum soll schon wieder im Garten gebaggert werden?“ oder „Mir reichen die 16 MBit/s über den Kupferanschluß, warum soll ich monatlich 10 EUR mehr bezahlen?“

Besser in naher Zukunft schnellere Anbindungen in den Nahbereichen als irgendwann in ferner Zukunft FTTH. Möglicherweise kommt der Appetit auf mit dem Essen und der Wunsch nach echten FTTH-Anschlüssen folgt umso schneller.

Warum bedürfen OTT-Messenger keiner Regulierung?

In Folge einer interessanten Twitter-Diskussion zu meinem Blog-Post „Ruf der Telekom-Lobby nach Regulierung der OTTs“ möchte ich noch etwas konkretisieren, warum aus meiner Sicht keine OTT-Messenger-Regulierung erforderlich ist. Dazu werfe ich einen Blick darauf, was, warum bei „Anbietern öffentlicher Telekommunikationsnetze“ reguliert ist:

  • Regulierung um Koexistenz zu ermöglichen und technische Störeinflüsse zu vermeiden
    OTTs können zwangsläufig nur oberhalb des IP-Layer angesiedelte Protokolle nutzen, somit ist die technische Regulierung in diesem Punkt bereits gegeben.
  • Regulierung der „Kontrolle über Zugang zu Endnutzern“ (§18 TKG)
    OTTs haben kein temporäres Monopol auf der „letzten Meile“ und bieten typischerweise auch keine Laufzeitverträge, d.h. der Nutzer kann technisch und finanziell jederzeit mehrere OTT-Messenger parallel nutzen. Es liegt somit keine Kontrolle über den Zugang zu Endnutzern vor.
  • Zusammenschaltungsregulierung
    Da der Endnutzer jederzeit mehrere OTT-Messenger parallel nutzen kann, ist eine Zusammenschaltungsregulierung nicht erforderlich. Im Hinblick auf die Innovationskraft wäre sie sogar schädlich, weil der Funktionsumfang somit auf den „kleinsten gemeinsamen Nenner“ reduziert werden würde.
  • Regulierung von Vorleistungspreisen
    Da das Angebot eines OTT-Dienstes keinen Einkauf von Vorleistungen bei anderen OTT-Dienstanbietern sondern nur weltweite IP-Konnektivität erfordert, ist eine Regulierung von Vorleistungspreisen hinfällig.
  • Regulierung von Endkundenpreisen
    Da der Endnutzer jederzeit beliebig zwischen OTT-Messengern wechsel/wählen kann, (bisher) keiner der Anbieter den Markt dominiert und (bisher) keiner der Anbieter für die normale Nutzung nutzungsabhängige Entgelte erhebt, ist eine Regulierung von Endkundenpreisen nicht erforderlich.

Umgekehrt folgt aus der Argumentation natürlich auch, dass von klassischen Telcos angebotene OTT-Messenger-Dienste aus meiner Sicht keiner Regulierung unterliegen sollten, solange die Nutzung anderer OTT-Messenger nicht unterbunden oder erschwert wird (Stichwort „Kontrolle über Zugang zu Endnutzern“).

Ruf der Telekom-Lobby nach Regulierung der OTTs

Laut einem Artikel des Magazins telecompaper haben sich die Chefs der europäischen Ex-Monopol-Telcos per Brief an den Präsidenten des Europäischen Rats, Donald Tusk, gewandt, um dort für eine strengere Regulierung der sogenannten OTTs – Over-the-top-Kommunikationsanbieter wie z.B. Skype oder WhatsApp – aber auch für eine „investitionsfreundlichere“ Regulierung im Zugangsgeschäft zu werben.

Der zweite Teil dürfte gegen die bestehende Regulierung zur Zugangsgewährung für alternative Anbieter sowie gegen zukünftige, ernsthafte Regeln zur Netzneutralität gerichtet sein, also beides nicht verbraucherfreundlich.

Der erste Teil – die Forderung nach Regulierung der OTTs – hingegen wirkt auf den ersten Blick sogar positiv, könnte man sich als Endbenutzer davon doch z.B. besseren Datenschutz erhoffen. Tatsächlich ist es aber eher die Vorgehensweise einen neidischen Kindes: Den erfolgreichen OTTs, die allesamt keine Ex-Monopolisten mit „geerbter“ Infrastruktur sind, soll das wirtschaftliche Leben mit regulatorischen Auflagen erschwert werden. Wünsche wie z.B. Interoperabilität zwischen verschiedenen Messaging-Anbietern klingen auf den ersten Blick verlockend, auf den zweiten Blick dürfte das zu einer „Zwangsvereinheitlichung“ der Dienste führen, wodurch die für die Wahl eines Dienstes ausschlaggebenden Features erzwungenermaßen verschwinden könnten.

Beispiel: Würde ein Messaging-Dienst mit Ende-zu-Ende-Verschlüsselung zur transparenten Interoperabilität mit unverschlüsselten Diensten gezwungen sein, könnte die Kommunikation zwangsläufig nicht mehr Ende-zu-Ende-verschlüsselt sein. Dem Dienst würde damit zwangsweise sein Alleinstellungsmerkmal genommen werden. Das wäre genau das Gegenteil der häufigen Forderung der Telekom-Lobby nach innovationsfreundlicher Regulierung, wenn die Innovationen somit wegreguliert würden!

Warum das ganze? Unsere Ex-Monopol-Telcos sind mit ihrer eigentlichen Rolle als reiner „Datentransporteur“ nicht zufrieden. Sie verstehen sich als „vertikaler Dienstleister“ – quasi ein digitaler Gemischtwarenladen. Der Endkunde soll am liebsten in einem „walled garden“ eingesperrt werden, in dem nur die Dienste der Telco selbst und eventueller (zahlungswilliger) Partner (ungedrosselt) zur Verfügung stehen. Das Sägen an der Netzneutralität sowie regulatorische Hürden sollen helfen, die (zahlungsunwilligen) OTTs aus dem „walled garden“ auszusperren.

Den besseren Weg, nämlich die technische Leistung des Datentransports wieder mit dem erwarteten Niveau anzubieten (ich meine hiermit nicht exorbitant hohe Datenraten auf der Endkundenleitung sondern direkte Peerings, niedrige Latenzen und stabile Datenraten auch zur Primetime) will leider keine der Ex-Monopol-Telcos gehen.

Fehlende Netzneutralität für Telekom-Kunden spürbar

Bei vielen Diskussionen pro und contra Netzneutralität wird von der Contra-Seite darauf hingewiesen, dass wir bisher auch keine vorgeschriebene Netzneutralität hatten und deren fehlen bisher niemandem unangenehm aufgefallen sei.

Das ist falsch, die fehlende Netzneutralität ist für viele Internetnutzer durchaus spürbar. Vom Provider Init7 gibt es dazu eine sehr technische Erläuterung, die ich im Folgenden in eine für Normalanwender leichter verdauliche Form bringen möchte. Vorab bedarf es etwas Grundwissen, um die Daten- und Geldströme im Internet verstehen zu können.

Welche Arten von Datenzusammenschaltungen gibt es?

  • Transit: Provider A kauft bei Provider B Zugang zum gesamten Internet ein, es ist Aufgabe von Provider B, das gesamte Internet erreichbar zu machen.
  • Peering: Provider A und Provider B tauschen Daten zwischen ihren Netzen (und den eigenen Kunden) direkt und kostenneutral aus. I.d.R. an Bedingungen geknüpft, damit beide Seiten dadurch profitieren.

Sonder-/Mischformen:

  • Partial Transit: Provider A kauft bei Provider B Zugang zu Teilen des Internets ein, die B besonders einfach erreichen kann. I.d.R. günstiger als normaler Transit.
  • Paid Peering: Provider A kauft bei Provider B direkten Zugang zu dessen Netz (und dessen Kunden), also quasi sehr partieller Transit. I.d.R. angeboten, wenn Bedingungen für normales Peering nicht erfüllt sind.

Anhand der Datenzusammenschaltungen kann man Provider nun in ein dreistufiges System einordnen:

  • Tier 1 Provider: Kaufen keinen Transit ein, decken das gesamte Internet durch Peerings mit anderen Tier 1 Providern ab.
  • Tier 2 Provider: Kaufen Transit ein, nutzen aber auch Peerings zur Kostenreduzierung und/oder Performanceverbesserung.
  • Tier 3 Provider: Kaufen nur Transit ein.

Kommen wir nun zurück zum eigentlichen Thema, wo/wie spüren Telekom-Kunden die fehlende Netzneutralität?

Die Telekom ist seit Dezember 2010 ein Tier 1 Provider, d.h. Sie kauft keinen Transit mehr ein sondern wickelt ihren ganzen Datenverkehr über kostenneutrale Peerings mit anderen Tier 1 Providern ab (nebenbei: Die 2013 angedachte DSL-Drossel wurde u.a. mit dem teuren Einkauf von Traffic begründet.) oder wird sogar von Contentprovidern dafür bezahlt.

Viele dieser Peerings zwischen der Telekom und anderen Tier 1 Providern (z.B. Cogent, Level 3, NTT, GTT, TeliaSonera, XO, …) sind jedoch zur „Primetime“ massiv überlastet, wodurch die Datenübertragungsraten einbrechen (Paketverluste) und die Reaktionszeiten in die Höhe gehen (Latenzen). Laut Aussage von Level 3 wird ein Ausbau der Zusammenschaltungen von der Telekom verweigert.

Warum? Als großer Zugangsprovider kann man seine eigenen Endkunden und die seiner IP-Reseller (im Fall der Telekom sind das Congstar und teilweise 1&1) als Druckmittel benutzen und die Contentprovider in gewisser Weise erpressen: „Möchtest Du meine Endkunden schnell erreichen können? Dann kaufe bitte Transit oder Paid Peering direkt bei mir ein, die normalen Wege sind leider überlastet.“

Auf den ersten Blick nicht weiter schlimm, ist doch egal, wo man (noch) Transit einkauft, schaut man sich jedoch die Preise an, die die Telekom laut Init7 verlangt, wird das Problem klar:

  • Doppelter Marktpreis
  • Progressives Preissystem

Vor diesem Hintergrund drängt sich dem Telekom-Kunden nun doch der Verdacht auf, dass die überlasteten Peerings der Telekom (die normalen Spuren) volle Absicht sind, um den Contentprovidern die teuren „Überholspuren“ schmackhaft zu machen.

Wer leidet darunter? Die Telekom-Kunden, die nur die Angebote wirklich schnell erreichen können, die sich eine „Überholspur“ ins Telekom-Netz kaufen. Init 7 hat dazu eine Vergleichsmöglichkeit (leider nicht mehr auf der Originalseite aufrufbar, daher nicht mehr als Vergleichsmöglichkeit nutzbar) online gestellt, wo man sich jeweils Audio- und Video-Stream auf dem normalen Weg und über die teure „Überholspur“ ansehen kann. Der Unterschied ist auch außerhalb der „Primetime“ bereits deutlich.

Vor diesem Hintergrund wirken auch die Versuche der Telekom, ein nationales Routing bzw. ein Schengen-Routing durchzusetzen, ganz anders: Der Versuch, die Provider per Gesetz zum Transit-Einkauf zu zwingen.

Update 11:30:

Ja, in diesem Beitrag geht es nicht um klassische, aktive Netzneutralitätsverletzungen bei der ein Anbieter aktiv den Datenstrom negativ beeinflusst, sondern um passive Netzneutralitätsverletzungen, bei der ein Anbieter durch seine Peering- und Preispolitik indirekt aber bewusst den Datenstrom negativ beeinflusst. Das Ergebnis ist im wesentlichen dasselbe.

Update 31.07.2019:

Das Thema ist weiterhin aktuell, einige der Quellen sind aber in Folge von Redesigns etc. nicht mehr unter ihren originalen URLs erreichbar. Ich habe stattdessen die entsprechenden Stände in der Wayback Machine verlinkt.

Telekom: Update gegen IPv6-Probleme an Broadcom-Linecards wird ausgerollt

Im Oktober hatte ich von den IPv6-Problemen der Telekom mit bestimmten MSAN mit Broadcom 164.37 Linecards berichtet. Damals hatte Helge vom Telekom-Hilft-Team angekündigt, dass mit dem Software-Update leider nicht mehr vor dem Jahreswechsel zu rechnen sei.

Zum Glück ist die Telekom aber manchmal auch ihrem Zeitplan voraus: Vor einigen Tagen wurde im Onlinekosten-Forum bereits von einem Insider angekündigt, dass sich hier demnächst etwas tun könnte, mittlerweile liegen die ersten Bestätigungen bisher betroffener im (neuen) Telekom-Hilft-Forum vor.

Nachdem dieser MSAN-Typ im Rahmen des VDSL-Vectoring-Ausbaus wohl relativ häufig verbaut wurde und wird, bin ich gespannt, ob sich dieser Bugfix nun sichtbar in der IPv6-Verbreitung in Deutschland und speziell bei der Telekom auswirken wird.

Zeit per NTP auf Windows-Systemen

Für den üblichen Client-PC ist es nicht weiter problematisch, wenn die Systemuhr nicht auf die Sekunde genau gestellt ist. Auf Servern möchte man aber exaktere Uhrzeiten, z.B. damit zeitlich abgestimmte Prozesse in einem Serververbund korrekt ablaufen oder aber clusterweit einheitliche Zeiten in den Logfiles sichergestellt sind.

Windows bietet zwar seit Version 5.1 (XP bzw. Server 2003) einen integrierten NTP-Client und -Server an, der jedoch in den aktuellen Windows-Versionen leider ab Werk derart fehlkonfiguriert ist, dass er für verlässliche Zeitsynchronisation nicht brauchbar ist: Auf Standalone PCs und Server (d.h. keine Windows-Domain) wird der Dienst nicht automatisch sondern nur einmal wöchentlich per Taskplaner gestartet. Selbst wenn man ihn auf automatischen Start umstellt, beendet er sich i.d.R. danach wieder selbst. Mit wenigen Zeilen auf der Shell bringt man ihm aber wieder eine brauchbare Funktion bei.

Folgendes Script führt der Reihe nach die nötigen Schritte durch:

net stop w32time
reg add HKLM\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient \
    /v SpecialPollInterval /t REG_DWORD /d 86400 /f
sc triggerinfo w32time delete
sc config w32time start= Auto
net start w32time
w32tm /config /manualpeerlist:"0.de.pool.ntp.org,0x9 1.de.pool.ntp.org,0x9 \
    2.de.pool.ntp.org,0x9 3.de.pool.ntp.org,0x9" /syncfromflags:manual /update
w32tm /resync
  • Der Dienst wird gestoppt (falls er wider erwarten doch gerade läuft).
  • Das Poll-Interval wird von 7 Tagen auf 24 Stunden reduziert.
  • Die Dienste-Trigger, die den Dienst außerhalb von Windows-Domains stoppen, werden gelöscht.
  • Der automatische Dienst-Start wird aktiviert und…
  • …der Dienst gestartet.
  • Die de-Pool NTP-Server werden konfiguriert.
  • Ein sofortiger Resync der Zeit wird ausgelöst.

Als kleine Batchdatei abgelegt kann man damit neu einzurichtende PCs oder Server schnell mit brauchbarer NTP-Synchronisation ausstatten oder den Aufruf sogar in einen automatischen Installationsprozess integrieren.