Beiträge von pufferueberlauf

  • Stiegeler - meine bisherigen Erfahrungen und aktuelle Probleme

    Zitat von kingpin42

    MSANs der DTAG hängen auch in den allermeisten Fällen an 1G Schnittstellen, und das reicht dann auch aus. Würde dem Ganzen jetzt wenig Bedeutung zumessen.

    Die Adtran HiX 56XX Chassis, die bei der Telekom oft zum Einsatz kommen, haben IIRC als Standard zwei uplink "Slots" die entweder mit 1, oder 10 Gbps Optiken bestueckt werden koennen, also 1, 2, 10, 11, oder 20 Gbps. Diese Upstream-Kapazitaet wird mit allen Linecards (je nach Chassisgroesse 4 oder 8*) geteilt.

    Wenn ein ISP will, kann er auch zusaetzliche Uplink-Karten zustecken, aber unklar ob das bei der Teleiom im Feld tatsaechlich gemacht wird, die 20Gbps die ohne diese Option moeglich sind, duerften fuer die mesiten MSAN voll ausreichen wuerde ich schaetzen.


    *) Ich meine gelesen zu haben, dass im Mittel pro Outdoor-MSAN wohl 3 Linecards bestueckt sind, aber ich weiss nicht wo... Bei VDSL2 Profil 25b haben die Linecards 48 Ports, d.h. im Mittel ca. 140 TALs pro MSAN.

  • Stiegeler - meine bisherigen Erfahrungen und aktuelle Probleme

    Zitat von wandler

    Wohlgemerkt in anderen Ländern hat ein einziger Haushalt einen 10Gbit/s-Anschluss, nicht eine komplette Region.

    Eine echten 10Gbps Anschluss gibt es wohl (z.B. Init7 in der Schweiz, oder Bahnhof in Schweden), aber das ist IMHO auch weltweit gesehen selten... was es momentan haeufiger gibt, ist, dass sich (bis zu) 32-64 Nutzer ein XGDS-PON Segment teilen (z.B. Salt/SwissCom in der Schweiz). Und so ein Segment hat halt nur gerundet 10 Gbps:

    GS-PON
    T-REC-G.9807.1-201606-I!!PDF-E.pdf
    B.9.2.1 Line rate
    The transmission line rate is a multiple of 8 kHz. The target standardized XGS-PON system supports the following variant: XGS-PON with a downstream line rate of 9.95328 Gbit/s and an upstream line rate of 9.95328 Gbit/s.

    C.10.1.3.1 Downstream FEC
    C.10.1.3.1.1 Downstream FEC codeword
    For 9.95328 Gbit/s nominal line rate, the downstream FEC code is RS(248, 216). Each downstream PHY frame contains 627 FEC codewords. Each codeword is 248 bytes long. Within a codeword, 216 data bytes are followed by 32 parity bytes.

    C.10.1.3.2 Upstream FEC
    C.10.1.3.2.1 Upstream FEC codeword
    For 9.95328 Gbit/s, the upstream FEC code is RS(248, 216). The PSBu section is not included in the FEC codeword. The first codeword in a PHY burst begins with the upstream FS header section. All allocations of a particular ONU have the same FEC status. Contiguous allocations are encoded as a single block of data, so that there is at most one shortened codeword at the end of the burst. For 9.95328 Gbit/s, the upstream FEC parity bytes insertion and payload reconstruction are shown in Figures C.10.13 and C.10.14, respectively.

    brutto nach FEC:
    9.95328 * (216/248) = 8.66899 Gbps


    XGSPON Overhead (PPPoE)
    #XGSPON-XGEM: XGEM = 8 Byte
    COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
    PPPoE: 8 Byte
    8+18+8 = 34

    maximaler VLAN+PPPoE+IPv4+TCP Durchsatz:
    9.95328 * (216/248) * ((1500-8-20-20) / (1500-8+34)) = 8.24860248425 Gbps

    D.h. nach deutschen Werberegeln bestenfalls: netto 8.25 Gbps

    Allerdings duerfte eines Mehrwert eines 10 Gbps Anschlusses fuer die meisten (interaktiven) Nutzungen gegenueber z.B. 100 Mbps oder 1000 Mbps kaum spuerbar sein, ausser fuer Speedtests und digitalen Schwanvergleich...

  • Ubiquiti Cloud Gateway Fiber mit 1G Bidirectional Single-Mode Optical Module ohne Modem nutzen?

    Zitat von DLMttH

    Das tatsächliche Modem, "Glasfaser Modem 2", kostet einmalig rund 40 Euro auf dem freien Markt.

    In der Tat:

    • der grosse rote Elektronikmarkt nimmt aktuell 39.99 EUR plus 2.99 EUR fuer den Versand
    • die Telekom nimmt entweder 49.99 EUR plus 6.95 EUR fuer den Versand oder vermietet das GF2 fuer 1.95 EUR/Monat (Laufzeit 12 Monate).

    Ab (39.99+2.99)/1.95 = 22.04 Monaten ist kaufen billiger als mieten... bzw. wenn Du vorhast innerhalb der naechsten 22 Monate auf XGS-PON umzusteigen (dann braeuchstet Du einen neuen XGS-PON-ONT) oder ganz mit dem Festnetz aifzuhoeren, dann mag mieten sinnvoll sein.

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von Phino

    Er hat beides zum Testen gleichzeitig am Start und er kann für sein Nutzerverhalten so gar keine Einschränkungen feststellen. Warum soll er jetzt deine Problem-Server nutzen, wenn die ihn so gar nicht interessieren?

    Das Problem ist hier IMHO "kann für sein Nutzerverhalten so gar keine Einschränkungen feststellen". Die Symptome sind: zur Spitzenzeiten erhoehte Latenz/jitter und Paketverlust und als Konsequenz geringerer Durchsatz.

    Jetzt zeigt mir den "Normalo-Nutzer" der das a) bemerkt und das b) wenn er/sie es denn bemerkt die Verantwortung nicht auf den Serverbetreiber schiebt?

    Das Spiel welches die Telekom (und andere ISPs die die Voraussetzungen erfuellen*) hier spielt ist (IMHO in der Umsetzung kompetent), dafuer zu sorgen, dass Zugang ueber Transitanbieter fuer Inhalteanbieter (die ihren Service praezise ueberwachen duerften) mit messbaren Performanceeinbussen einhergeht, waehrend die Endnutzer das idealer weise entweder nicht bemerken, oder aber es dem Inhalteanbieter zuschreiben...


    *) Das geht nur wenn man selber so gross ist nicht auf Transit angewiesen zu sein**, und zusaetzlich ausreichend viele Endkunden in einem lukrativen Markt versorgt... Das Vodafone, O2, DG, MNet, ... das nicht auch versuchen, hat IMHO weniger mit fairerem Geschaeftsgebaren dieser Unternehmen zu tun (so gerne ich das glauben will) und mehr damit, dass sie im deutschen Markt schlicht nicht so aufegestellt sind, dass sie diese Masche versuchen koennen.

    **) Bzw. wenn man Transit braucht muss man mit einen Transitprovider zusammenarbeiten, so wie Telekom und SwissCom es in der Vergangenheit gemacht hatten, siehe hier bei Init7.

  • Glasfaser zwischen zwei Häusern (12m) - ADSS-Kabel, Montage & Konverter gesucht

    Ich wuerde da mein Glueck mit der Glasfaser versuchen... zur Not eine optische Uebertragung à la Taara (aber das ist viel teurer als 2 Medienkonverter und etwas konfektioniertes Kabel, ich wette mit dem richtigen Suchbegriff findest Du auch Anbieter fier konfektionierte Kabel, ich wuerde z.B. nach FTTH-Drop-Cable suchen und darauf achten eine Variante fuer Aussen und in der Sonne zu waehlen...)

  • Peering/Transit - wie gut verbindet Dein ISP Dich mit dem Rest des Internets

    Die Twitch addresses sind einmal bei fastly:

    FASTLY (AS54113) IP Connectivity — Radar by Qrator

    und einmal bei Amazon:

    AMAZON-02 (AS16509) IP Connectivity — Radar by Qrator

    da sind die AS Nummern im MTR Resultat hilfreich und dann bei

    Qrator.Radar – Real-Time BGP Monitoring & Analytics
    Discover real-time BGP monitoring and analytics with Qrator.Radar. Track network incidents, optimize routing, and ensure internet stability.
    radar.qrator.net

    und/oder

    PeeringDB
    The Interconnection Database
    www.peeringdb.com

    nach dem AS suchen. qrator versucht auch anzugeben wer bei wem Transit kauft (provider) und wer mit wem peert (Peerings)

  • 1&1 / Telekom Peering vergleich

    Oh, nur Hoerensagen... als Endkunde habe ich keinen direkten Kontakt mit Transitanbietern und daher auch keine Erfahrung erster Hand. Bei Cogent hatte ich abgespeichert:

    • Peert nicht mit HE -> unvollstaendige IPv6 Abdeckung
    • ist problematisch wenn single-homed (allerdings ist single-homed ja immer etwas riskant.)

    gut moeglich, dass das nicht mehr stimmt...

  • Peering/Transit - wie gut verbindet Dein ISP Dich mit dem Rest des Internets

    Post 2 detaillierte Beispielmessung

    Hoster FDCServers in Frankfurt (FDC war mal single-homed ueber Cogent und damit ein guter Messpunkt fuer die worstcase Erreichbarkeit, aber inzweischen hat FDC deutlich mehr Provider und ist ganz gut vernetzt)

    1: Durchsatz:

    85.7 Mbps (theoretisches Limit: 100 * ((1500-8-20-20-12)/(1500+34)) = 93.87) Messung bei aktivem Heimnetz, daher voll innerhalb der Erwartung

    2/3 idle/working Latenz:

    Die Messung erfolgte waehrend des Downloads

    4. Paketverlust:

    Ist mit wget schwer zu messen... (aber erhoehter Paketverlust bewirkt i.d.R. verringerten Durchsatz und der gemessene Durchsatz ist wie erwartet).

    5. Netzwerkpfad in Vorwaerts-Richtung

    siehe 2/3, hier ISP(AS6805, O2/Telefonica) -> Telxius (AS12956, T1-ISP, ebenfalls Telefonica-Tochter) -> TATA Communications (AS6453, T1-ISP) -> FDCServer (AS30058)

    6. Netzwerkpfad in Rueckwaerts-Richtung

    https://www.fdcservers.net/looking-glass bietet eigentlich einen reversen traceroute/mtr an, aber der will gerade nicht "An error occurred".


    Das Beispiel zeigt eine unproblematische Verbindung, d.h. O2 ist gut mit Telxius (erwartbar) und indirekt auch gut mit TATA verbunden.

  • Peering/Transit - wie gut verbindet Dein ISP Dich mit dem Rest des Internets

    Liebes Forum,

    Transit/Peering/Interconnect ist ein Thema das letztlich fuer alle ISP unabhaengig der Zugangstechnologie theoretisch relevant ist. I.d.R. ist der Zustand des Interconnects bei vielen ISPs befriedigend bis gut, so dass man da praktisch wenig Gedanken dran verschwenden muss. Aber nichts desto trotz ist das einer der Punkte in dem sich ISP unterscheiden und daher ist es hilfreich das selber fuer den eigenen ISP abschaetzen zu koennen.

    Erst mal zur Terminologie, Peering bezeichnet i.d.R. eine (meist kostenneutrale) Verbindung zwischen zwei Autonomen System (AS, quasi die Baussteine des Internets, meist betreibt ein ISP ein eigenes AS) bei dem Pakete ausgetauscht werden die jeweils im Netz des anderen Terminieren. Transit hingegen bezeichnet eine (i.d.R. fuer den kleineren Partner kostenpflichtige) Verbindung zwischen 2 AS, bei denen einer der Partner nicht nur Pakete ins eigene Netz handelt, sondern auch generell Pakete in den Rest des Internets (oder bestimmte begrenzte Adressbereiche des Internets). (Das ist jetzt recht grob und damit im Detail inkorrekt, aber ich hoffe die generelle Idee wird verstanden). Die groesssten ISPs koennen quasi das ganze Internet ueber kostenneutrale Peerings errreichen (die sogenannten Tier-1 ISP) muesssen also nominell nirgendwo Transit einkaufen, bzw. die grossen T1-ISP verkaufen i.d.R. alle Transit (zusaetzlich gibt es noch andere grosse Transitanbieter wie Cogent die selber keine vollen T1-ISP sind).

    Fuer Endkunden ist das erstmal egal welche wirtschaftlichen Beziehungen der eigene ISP aufbauen muss um Zugang zum ganzen Internet zu organisieren... fuer den ISP selber ist es relevant weil i.d.R. Transit teurer ist als Peerings aber zum Peering gehoeren immer zwei, d.h. man kann nur dann kostenneutral peeren wenn beide Seiten dazu bereit sind, und gerade die grossen T1-ISP verkaufen lieber Transit. Jetzt ist es so, dass die T1 zwingend kostenneutral miteinander Peeren (sonst erreichen sie nicht das ganze Internet), d.h. im Prinzip sind die Kunden eines T1 immer auch per Transit von den anderen T1 ISP erreichbar. Manche T1, die selber auch viele Endkunden haben (z.B. AT&T, ComCast, Deutsche Telekom) versuchen die grossen Inhalteanbieter dazu zu motivieren direkten Zugang beim T1 zu kaufen, statt dessen Netz per Transit zu erreichen. Damit das funktioniert und die Inhalteanbieter daran ein Interesse haben Zugang zu kaufen werdend dabei manchmal die Peerings zu den anderen T1-ISP absichtlich leicht unterdimensioniert, so dass es gerade zu den Spitzenlastzeiten zu erhoehtem Paketverlust und Latenz/Jitter kommt, so wie zu geringerem Durchsatz.


    Wie kann man nun als Endnutzer selber nachsehen wie gut einen der eigene ISP mit dem Internet verbindet? Idealerweise misst man Durchsatz, Paketverlust, und Latenz zu allen anderen AS, aber das ist bei ca 90000 aktiven AS ein aussichtsloses Unterfangen, zudem enthalten nur wenige dieser AS Server die ein individueller Nutzer erreichen will. Und nicht alle AS sind gleich gut and den Rest des Internets angeschlossen. Man kann vom eigenen ISP schon erwarten, dass er keine Hindernisse aufbaut, aber fuer die Anbindung beliebiger Server in anderen AS ist er schwerlich verantwortlich.

    Weil prinzipiell das ganze Internet per Transit von den grossen T1-ISP erreichbar ist, sollte es in erster Naeherung reichen zu ueberpruefen wie gut/schlecht man Servern die direkt un diesen T1 Netzen gehostet werden verbunden ist, bzw. welchen Durchsatz und welche Latenz man in der Primetime zu solchen System messen kann. Bei ca. 15 vollen T1 und ca. 15 "regionalen" T1 waeren das immer noch ca. 30 Messpunkte, was fuer eine schnelle Messung immer noch etwas aufwendig ist. (Auch weil man erst mal Messpunkte in diesen ~30 AS finden muss die zuverlaessige Daten liefern und die ebenso zuverlaessig nur ueber dieses AS erreicht werden koennen).

    Um einen solchen Messpunkt zu nutzen sollte man idealerweise zur Primetime:

    1. den Durchsatz fuer einen grossen Datentransfer messen
    2. die idle Latenz zu diesem Messpunkt (d.h. ohne zusaetzliche Last)
    3. die working Latenz zu diesem Messpunkt (d.h. waehrend eines Kapazitaetstests der die Leitung auslastet)
    4. den Paketverlust messen
    5. den Netzwerkpfad in Vorwaerts-Richtung (zum Server) dokumentieren
    6. den Netzwerkpfad in Rueckwerts-Richtung (vom Server) dokumentieren (z.B. mittels Looking-Glass Server beim Messpunktbetreiber)

    Dabei sind die Punkte 3, 4, und 6 besonders knifflig.

    Da kaum ein Server im Internet echte Garantien zur bereit gestellten Kapazitaet macht, reicht es nicht aus eine solche Messung von einem ISP in Isolation zu machen, sondern man sollte (zu aehnlichen Zeiten gemachte) Messungen zum selben Messpunkt von verschiedenen ISP vergleichen.

    Das war jetzt eher abstrakt, daher im Folge-Post mal eine Beispiel Messung und in Post 3 eine Liste mit einfachen Messungen (Durchsatz oder Latenz) die sich als nuetzlich erwiesen haben um ISP miteinander zu vergleichen.


    Bezueglich 2/3, und 5 bieten sich MTR/Trippy als Messtools an, die messen die Latenz und den Vorwaertsnetzwerkpfad:

    MTR

    Code
    #IPv4:
mtr -ezb4 -o LSNBAWVJMXI example.com
#IPv6:
mtr -ezb6 -o LSNBAWVJMXI example.com

    TRIPPY

    Code
    # Unter https://github.com/fujiapple852/trippy/releases zur aktuellen Release navigieren und unter Assets das passende Archiv fuer das eigene Endsystem (Windows, Macos, Linux) runterladen und lokal entpacken.
# Unter Windows CMD als Administrator starten, ins Verzeichnis mit der Datei trip.exe wechseln und folgendes aufrufen, die Firewall muss eventuell fuer Trippy geoeffnet werden.
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -4 --tui-custom-columns holsravbwdtKM --icmp --tos 181 example.com 
# Linux/Macos
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 --tui-custom-columns holsravbwdtKM --icmp --tos 181 example.com 
# Windows
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 example.com 
# jeweils nach ca. 100 Messungen Trippy einfrieren (mit CTRL-f) und einen Screenshot machen und posten

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von mbo77

    Die genauen Metriken wird umlaut wohl nicht preisgeben. Aber deine Schlussfolgerung ist ebenso einfach Spekulation.

    Das ist inkorrekt, meine Schlussfolgerungen sind aus der Beschreibung des Tests bei Connect abgeleitet (ich zitiere den Text explizit). Mir draengt sich der Eindruck auf, Du hast weder die Beschreibung bei Connect noch meine Analyse/Zerlegung derselben gelesen... ja natuerlich spekuliere ich auf Basis dieser unvollstaendigen Informationen, aber auf welcher Basis spekulierst Du denn?

    Zitat von mbo77

    Da in vielen Haushalten über viele verschiedene Provider gemessen wird, kann man das durchaus in Bezug setzen. Auch passive Daten in den genutzten Apps lassen einige Schlussfolgerungen zu.

    Ja, aber keine Aussage zur Peering/Transit-Qualitaet eines ISPs... aber darum geht es hier...

    Zitat von mbo77

    Such doch mal den Kontakt zu umlaut und äußere deine Bedenken. Vielleicht wird man sie ausräumen.

    Ich habe auf Basis der veroeffentlichen Informationen ein relativ klares Bild gewonnen was der Test leistet, und was er nicht leistet. Wenn Umlaut da mit mir drueber sprechen will, berate ich die gerne, allerdings nicht aus reiner Herzensguete und fuer ein warmes Wort.

    Zitat von mbo77

    Und für mich gilt darüber hinaus: Einer mir (zwar im Detail unbekannten), aber umfangreichen Datenbasis schenke ich deutlich mehr Glauben,

    Es geht hier nicht um Glauben, es geht um Wissen, also um Fakten, und da verwechselst Du IMHO Masse mit Klasse. Ist aber auch egal, das vorsaetzliche Unterpeering der Telekom ist kein Geheimnis und deren hohe Transit-/Peeringpreise auch nicht, das mag Dir gehen den Strich gehen, aendert aber nichts an der Lage. Und da ich erwarte, dass nichts diesseits von einem expliziten Gestaendnis von Timotheus Höttges oder einem einschlaegigen Urteil eines Gerichtes davon ueberzeugen wird, dass dem so ist, werde ich das jetzt hier im Thread wo es klar OT ist ruhen lassen.

    Ueber den Connect Test koennen wir hier weiterdiskutieren.

    Fuer die Unterpeering Situation sollten wir einen neuen Thread eroeffnen...

  • Kommentar zum Crowdsourcingteil des Connect Festnetztests (2024)

    Aber nach dem ganzen negativen hier mal etwas konstruktives, Wie muesste denn ein Test aussehen der die Transit/Peering Qualitaet moeglichst objektiv misst?


    In erster Naeherung sind T1-ISP solche ISP die das ganze Internet erreichen koennen (ohne fuer den Zugang dazu zahlen zu muessen*) und die aus dem gesamten Internet erreicht werden koennen. Diese T1-ISP sind letztlich die Garanten dafuer, dass man ueber Transit das ganze Internet erreichen kann. Weil die direkte Messung der Konnektivitaet zu allen anderen Autonomen Systemen praktisch zu aufwendig ist, waere in erster Naeherung eine Messung von Durchsatz und Latenz-unter-Last zu den grossen T1 Netzen (und eventuell zu den "regionalen T1-Netzen)) ein gutes Mass um die Qualitaet des Transit abzuschaetzen. D.h. man braeuchte Testserver in je nach Ambition 10-30 Netzen. Dan laesst sich der Transit/Peering Fingerabdruck eines Test ISPs dadurch darstellen, dass man zu jedem der T1 jeweils die maximale Latenz-unter-Last-Zunahme und den minimalen Durchsatz beides zur lokalen Primetime gemessen bestimmt.


    Echtes Peering ist schwerer zu messen, aber i.d.R. sollten direkte Peerings weniger unter Ueberlast leiden, daher ist eventuell die oben beschriebe Transitmessung erstmal ausreichend. Besser als der Umlaut-Test ist das alle Male, weil zielgerichtet.


    *) Das heisst nicht dass keine Kosten entstehen duerfen, nur halt nicht nutzungsabhaengig.

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von mbo77

    Leider doch, denn sie spiegeln die Nutzererfahrung wider.

    In wie weit das? Der Test hat aktive Messungen gegen Server die die Nutzer in dem moment gar nicht brauchen, und passive Tests bei denen der Test nicht weiss was gerade passiert, ist die Uebertragungsrate gerade Sender-, Empfaenger-, oder Netzwerk-limitiert und wie bewertet der Nutzer das. Das weiss der Test nicht und da fragt er Test auch den Nutzer nicht nach...

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von mbo77

    Und das ist völlig valide, solange du nicht mithilfe dieser Einzelerfahrung einen Test mit 800 Millionen Datenpunkte diskreditieren willst.

    Letzte Meldung, die Crowsourcing-Messung hat weder den Zweck die Peeringqualitaet von ISPs objektiv zu vergleichen, noch ist sie zu diesem Zweck geeignet. Daher sind diese 800 Millionen/Milliarden/... Datenpunkte fuer unsere Diskussion komplett irrelevant.

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von mbo77

    Die Anbieter können sich jederzeit um direktes Peering bemühen.
    Das machen ja auch die meisten.

    Eine Sichtweise. Eine andere Sichtweise ist, dass die Telekom hier gegen den Geist der EU Verordnung 2015/2120 verstoesst:

    Zitat

    (4)

    Ein Internetzugangsdienst bietet unabhängig von den vom Endnutzer verwendeten Netztechnologien und Endgeräten den Zugang zum Internet und somit grundsätzlich zu all seinen Abschlusspunkten. Es ist jedoch möglich, dass aus nicht von den Internetzugangsanbietern zu vertretenden Gründen bestimmte Abschlusspunkte des Internets nicht immer zugänglich sind. Daher sollte gelten, dass ein Anbieter seiner Verpflichtung im Zusammenhang mit der Bereitstellung eines Internetzugangsdienstes im Sinne dieser Verordnung nachgekommen ist, wenn der betreffende Dienst eine Anbindung an nahezu alle Abschlusspunkte des Internets bereitstellt. Daher sollten die Internetzugangsanbieter die Anbindung an keinen zugänglichen Abschlusspunkt des Internets beschränken.

    Zitat

    (9)

    Ziel eines angemessenen Verkehrsmanagements ist es, zu einer effizienten Nutzung der Netzressourcen und zur Optimierung der Gesamtübermittlungsqualität entsprechend den objektiv unterschiedlichen Anforderungen an die technische Qualität der Dienste bei speziellen Verkehrskategorien und somit den übermittelten Inhalten, Anwendungen und Diensten beizutragen. Von den Internetzugangsanbietern angewandte angemessene Verkehrsmanagementmaßnahmen sollten transparent, nichtdiskriminierend und verhältnismäßig sein, und sie sollten nicht auf kommerziellen Erwägungen beruhen. Die Anforderung, dass Verkehrsmanagementmaßnahmen nicht diskriminierend sein dürfen, schließt nicht aus, dass die Internetzugangsanbieter zur Optimierung der Gesamtübermittlungsqualität Verkehrsmanagementmaßnahmen anwenden, bei denen zwischen objektiv verschiedenen Verkehrskategorien unterschieden wird. Um die Gesamtqualität und das Nutzererlebnis zu optimieren, sollte jede derartige Differenzierung nur auf der Grundlage objektiv verschiedener Anforderungen an die technische Qualität der Dienste (beispielsweise in Bezug auf Verzögerung, Verzögerungsschwankung, Paketverlust und Bandbreite) bei bestimmten Verkehrskategorien, nicht aber auf Grundlage kommerzieller Erwägungen zulässig sein. Derartige differenzierende Maßnahmen sollten in einem angemessenen Verhältnis zum Zweck der Optimierung der Gesamtqualität stehen und gleichartigen Verkehr gleich behandeln. Derartige Maßnahmen sollten nicht länger als erforderlich beibehalten werden.

    Zitat

    (15)

    Drittens könnten Maßnahmen, die über derartige angemessene Verkehrsmanagementmaßnahmen hinausgehen, auch erforderlich sein, um eine drohende Netzüberlastung zu vermeiden, d. h. in Situationen, in denen sich die Überlastung abzeichnet, und zur Milderung der Auswirkungen einer Netzüberlastung, sofern diese Netzüberlastung nur zeitweilig oder unter außergewöhnlichen Umständen auftritt. Nach dem Grundsatz der Verhältnismäßigkeit ist es erforderlich, dass auf diese Ausnahme gestützte Verkehrsmanagementmaßnahmen gleichartige Verkehrskategorien gleich behandeln. Eine zeitweilige Überlastung sollte so verstanden werden, dass sie sich auf spezielle Situationen von kurzer Dauer bezieht, in denen ein plötzlicher Anstieg der Zahl der Nutzer über die Zahl der regelmäßigen Nutzer hinaus oder ein plötzlicher Anstieg der Nachfrage nach einzelnen Inhalten, Anwendungen oder Diensten die Übertragungskapazität einiger Netzkomponenten übersteigt und den Rest des Netzes schwerfälliger reagieren lässt. Eine zeitweilige Überlastung könnte insbesondere in Mobilnetzen auftreten, die variableren Bedingungen — wie etwa physische Störungen, geringere Versorgung in Gebäuden oder eine variable Zahl aktiver Nutzer mit Standortveränderungen — unterliegen. Es kann zwar vorhersehbar sein, dass eine derartige zeitweilige Überlastung gelegentlich an einigen Punkten des Netzes auftritt, und zwar so, dass sie nicht als außergewöhnlich betrachtet werden kann, ohne jedoch oft genug oder für so lange Zeiträume aufzutreten, dass eine Kapazitätserweiterung in wirtschaftlicher Hinsicht gerechtfertigt wäre. Eine außergewöhnliche Überlastung sollte so verstanden werden, dass sie sich — sowohl in Mobil- als auch in Festnetzen — auf unvorhersehbare und unvermeidbare Situationen der Überlastung bezieht. Mögliche Gründe für diese Situationen sind beispielsweise technisches Versagen — etwa ein Diensteausfall aufgrund beschädigter Kabel oder anderer beschädigter Infrastrukturkomponenten, unerwartete Änderungen bei der Verkehrslenkung oder eine erhebliche Zunahme des Netzverkehrs aufgrund von Notsituationen oder andere außerhalb der Kontrolle des Internetzugangsanbieters liegende Situationen. Diese Überlastungsprobleme dürften nicht sehr häufig auftreten, sind aber möglicherweise schwerwiegend und nicht zwangsläufig von kurzer Dauer. Die Erforderlichkeit, über die angemessenen Verkehrsmanagementmaßnahmen hinausgehende Verkehrsmanagementmaßnahmen anzuwenden, um den Auswirkungen einer zeitweiligen oder außergewöhnlichen Netzüberlastung vorzubeugen oder sie zu mildern, sollte den Betreibern von Internetzugangsdiensten nicht die Möglichkeit bieten, das allgemeine Verbot der Blockierung, Verlangsamung, Veränderung, Beschränkung, Störung, Schädigung oder Diskriminierung bestimmter Inhalte, Anwendungen oder Dienste oder bestimmter Kategorien derselben zu umgehen. Für wiederkehrende und länger dauernde Fälle von Netzüberlastungen, bei denen es sich weder um außergewöhnliche noch um zeitweilige Überlastungen handelt, sollte nicht auf diese Ausnahmen zurückgegriffen werden können, sondern sie sollten vielmehr im Wege einer Erweiterung der Netzkapazität angegangen werden.


    Die Telekom verkauft ihren Kunden Internetzugang und steht damit in der Pflicht diesen nicht aus kommerziellem Interesse artifiziell einzuschraenken. Aber genau das tut die Telekom beim vorsaetzlichen Unterpeering prinzipiell. Die heisslaufenden Peerings (die die Telekom mit geringen Kosten erweitern koennte) dienen nur dem Zweck den Zugang zu den Endkunden der Telekom nochmals verkaufen zu koennen. Aber es ist eine Sache dem Geiste der Verordnung zu wider zu handeln und eine Andere dafuer belangt zu werden.

    Zitat von mbo77

    Die Kritik konnte ich beim letzten Mal bereits nicht nachvollziehen und da kommt dann der Punkt, wo ich das zu den Akten lege, da wir uns im Kreis drehen. Auch heute gibt es für mich keinerlei Erkenntnisgewinn.

    Dann eruebrigt sich eine weitere Diskussion zwischen uns beiden zu diesem Thema, mehr als explizit klar machen warum der Test fuer unseren Zweck ungeeignet ist kann ich kaum leisten.

    Zitat von mbo77

    Da halte ich mich lieber an Messpunkte, die bei 736.000 Anschlüssen erhoben wurden. Im realen Leben.

    Messpunkte, von denen Du erkennbar nicht weisst wie die zu interpretieren sind. Du laesst Dich da IMHO von einer grossen Zahl blenden ohne zu hinterfragen in wie weit diese Zahl repraesentativ ist.