Beiträge von pufferueberlauf

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

    Zitat von gponner

    Bei den kostenlosen Plänen will Cloudflare natürlich nichts zubuttern und routet den Traffic so, dass kein kostenpflichtiger Transit stattfinden muß.

    Was nahezu unmoeglich ist, wenn Clouflare versucht Endkunden der Telekom zu bedienen... gibt zwischen Cloudflare und der Telekom keine (oeffentlich bekannte) direkte Verbindung, das geht immer ueber andere Vermittler (letztlich die anderen T1-ISPs) und mindestens einer von denen muesste kostenneutral mit Cloudflare peeren um kostenpflichtigen Transit zu umgehen... das einzige was Cloudflare da IMHO beeinflussen kann ist wie teuer der Transit ist...

    Wobei momentan unklar ist, wer hier fuer den Umweg ueber die USA verantwortlich ist Cloudflare, oder die Telekom

  • Erfahrungen mit OpenInfra und Internetnord

    Zitat von kandamir

    Wenn ich recht drüber nachdenke, dann könnte mein Sohn durchaus auch „Opfer“ der Peering-Strategie der Telekom gewesen sein. Der beklagte sich immer wieder, dass die EA-Server zur abendluchen Primetime schlecht erreichbar gewesen seien. Ich hatte das allerdings eher als Unterdimensionierung eingestuft, nicht als Peering-Problem.

    Das haengt bei der Telekom beides zusammen... Was passiert ist, dass die Telekom nicht will, dass Inhalteanbieter Endkunden der Telekom gut erreichen koennen ohne bei der Telekom dafuer zu zahlen. Als T1-ISP ist die Telekom jedoch stolz darauf mit den anderen T1-ISPs zu peeren (T1 wird man, wenn man den ganzen Rest des Internets durch kostenneutrale Peerings erreichen kann, d.h. die T1-ISPs muessen miteinander Peeren, macht man das nicht muss man Transit bei den ISPs kaufen mit denen man nicht peert), aber wenn Inhalteanbieter wie EA Transit bei einem anderen ISP als der Telekom kauefen, koennen sie darueber die Endkunden der Telekom erreichen... damit EA und Co. trotzdem ernsthaft ueberlegen Transit/Peering auch bei der Telekom einzukauefen, sorgt die Telekom dafuer dass die Peerings mit den anderen T1-ISPs alle leicht unterdimensioniert sind, damit es in der Primetime zu Problemen kommt (hohe Latenz/Jitter/Paketverlust (alles "Gift" fuer on-line Echtzeitspiele), niedriger Durchsatz,).

    Hier eine aktuelle Aktionswebseite zu dem Thema mit ein paar Medienberichten zu dem Thema.

  • Anfängerfrage: Richtiger Router-Anschluss an GF-TA-Dose?

    Die 7520 ist ein "Sondermodell" (urspruenglich dieselbe Hardware wie die 7530, aber mit rein paar Limits in der Firmware, wie 2 Gigabit und 2 FastEthernet LAN Ports, statt 4xGigabit) welches AVM fuer 1&1 aufgelegt hat. Und weil bei 1&1 die Modemrouter irgendwann ist Kundeneigentum uebergehen findet man die recht haeufig und guenstig auf Kleinanzeigen/Ebay...

    Die urspruengliche Version der 7520 kann man auf OpenWrt umflashen, dann sind alle LAN Ports mit Gigabit nutzbar, aber dann geht die AVM Telephonie nicht mehr...

  • Stiegeler - meine bisherigen Erfahrungen und aktuelle Probleme

    Zitat von wandler

    Wenn erst bei Auslastung > 100 % erweitert wird, würde ich als Kunde keine Unterschrift unter den Vertrag setzen, sondern Mobilfunk nehmen. Der hat dann ein deutlich besseres Nutzungserlebnis.


    Weil Mobilfunk ja bekanntlich bei Ueberlast (also Auslastung > 100 %) ganz einfach, billig und schnell in der Kapazitaet erweitert werden kann...

    Aber ich weiss, Du willst hier primaer ein bisschen freundlich trollen... Dir sei's gegoennt.

  • 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.