[atnog] Google Peerings - local pref

Wed Jul 14 09:06:23 CEST 2021

Hi Klaus

Also was ich entweder bestätigen kann oder z.T. aus Erfahrung sehe, oder auch durch Gespräche (historisch oder mit Dritten) z.T. vermute, ist, 

dass auch grosse Netze diese 3 Kategorien unterscheiden und auch je nach Type verschiedene Prioritäten und auch z.T. verschiedene Anzahlen an Prefixen drauf legen.
Direkte IXP Session mit großen CDN ist immer besser als Routeserver, da RS nur ein indirektes Peering ist und oft nur zu Basisfunktionalität führt, während man bei einer direkten Session voll im System bekannt ist.
Für PNI gilt natürlich sinngemäß dasselbe - das kann bei CDN je nach Produktionskostenfaktor und technischen bzw. strategischen  bzw. politischen Parametern ggf. eine andere Bewertung haben ...

Ein weiteres Kriterium ist natürlich, was der Cluster pre-loaded oder im Cache hat bzw. wofür er aktiviert ist - je kleiner, desto wahrscheinlicher ist es, dass der Content von wo anders kommt.

Cluster sind afaik nicht gut darin, hierarchisch zu funktionieren - d.h. Cache-Fallback ist eher unwahrscheinlich (=älterer Kenntnisstand - weiss nicht ob sich das inzwischen geändert hat)

Was auch eine Rolle spielen kann und vielfach unterschätzt wird, ist die Rolle der DNS Resolver. Wenn ich in z.B. Velden am Wörthersee bin und die 8.8.8.8 DNS Resolver verwende die z.B. aus London
antworten, kann es ja nach CDN passieren, dass nicht der nahe Cluster in Klagenfurt verwendet wird, sondern der Cluster in London als "nächstliegend" zugeteilt wird.

Was auch eine Rolle spielen kann ist ICMP blocking oder ICMP Rate limiting - ganz toll sind rate limits die auf und zu gehen - das kann bei CDN zu einem Flapping der zugeteilten Cluster führen, wenn der 
CDN durch seine Ping Entfernungsfeststellung auf die DNS Resolver glaubt, dass die Region ausgefallen ist, und dann auf eine entfernte Region umschwenkt, von wo aus der Ping noch funktioniert - und dann
wieder zurückschaltet u.s.w. ...

Auch zu beachten ist, dass bei CDN die BGP Path Entscheidung nur einen Teil der Entscheidung ausmacht, da die DNS Zuordnung, aus welchem Cluster geliefert wird, eine darüberliegende Entscheidung darstellt,
die eine Vielzahl von Parametern berücksichtigt ... Größe der Cluster, strategische Gewichtung, Produktionspreise pro Bit oder was auch immer hier einwirkt können Einfluss nehmen ...

Manche ISP/Incumbent schaffen es auch im Transport in-country 3 mal so viel Latency zu erzeugen als der Umfang des ganzen Landes physikalisch eigentlich ausmachen würde - da CDN oft auf RTT schaut, kann
es dann auch durchaus passieren, dass sogar der Cache irgendwo aus dem Nachbarland vorranging drankommt anstatt der eigene in-country Cache ... gleiches ist auch in Grenzregionen vorstellbar, sofern die
so vernetzt sind, dass die RTT über die Grenze kürzer ist als der eigentlich logische Hauptstadt-Cluster ...

Auch ein Thema: verwirrende Prefix announcement Strategien - es gibt Netze die announcen an jedem Upstream und jedem Peering irgendwas anderes und produzieren tonnenweise überlappende /24, /23, /23, /21 ...
in total seltsamen Kombinationen - da geben irgendwann auch große CDN auf, weil keiner mehr durchschaut, was der announcende ISP eigentlich selber will ... (best: superprefixe-only)

auch nicht zu vergessen: VPN Nutzung der User kann alles auf den Kopf stellen ... je restriktiver ein Land eingreift, desto ineffizienter wird das ganze Routing weil dann so gut wie alles über weit entfernte 
Tunnel Endpunkte reinläuft ... das gleiche treibt oft auch die massive Verwendung von 8888 oder 1111 oder 9999...

in jedem Fall kann ich sagen:
- achtet auf Eure direkten peering Sessions (vor allem die großen strategischen) und geeignete IXP Anbindung
- berücksichtigt, dass multiple peering Sessions gut sind, da die Cluster-Sourcing´s aus vielerlei Quellen kommen können - CDN ist ganz gut im richtig zuordnen der jeweils passenden IXP Übergänge ...
- überlegt Euch, wo steht ggf. Eurer Cache Cluster und wo steht örtlich deren Haupt Master-Quelle und wo habe ich meine Peering Sessions geografisch (in Europa kommt vieles aus dem linken oberen Quadranten)
- passt auf wenn über routeserver überraschende peerings zu major CDN an einem neben-IXP entstehen, wo Ihr selber zu wenig Bandbreite habt...
- Frankfurt, Amsterdam und London gelten als Tier1 Voll-Hub´s - d.h. wenn ich User in Schottland bediene richte ich mich eher an London aus - in Österreich eher an Frankfurt - und dann gibt es darüberliegend auch
  noch die umliegenden oder dazwischen liegenden Tier2 Hub´s wie z.B. Wien oder Zürich oder Mailand oder München die da ebenfalls strategisch passend eingewoben sein wollen ...
- schaut, dass Ihr die portal logins nützt, die z.T. angeboten werden (z.B. Google Peering Portal) - dort seht Ihr Trafficflüsse pro Quelle/Übergang und auch Fehlerraten pro Prefix ...
- achtet generell auf Eure RTT Zustände im eigenen Netz und auch zu den Peerings und Upstreams - Wien nach Wien über Frankfurt ist vielfach noch immer real in vielen Übergängen ...
- achtet auf Eure verteilte DNS Resolver Strategien und icmp filter 
- und vergesst nicht, dass da bei all diesen Punkten IPv6 auch mitspielen könnte ...

vielleicht ist hier jemand von Euch näher an der CDN Industrie dran als ich es bin - mein Wissen stützt sich primär auf Beobachtungen aus der peering Ecke

Bernd

-----Ursprüngliche Nachricht-----
Von: atnog <atnog-bounces at atnog.at> Im Auftrag von Klaus Darilion
Gesendet: Dienstag, 13. Juli 2021 21:30
An: atnog at atnog.at
Betreff: [atnog] Google Peerings - local pref

Hallo!

Ich definiere hier mal 3 unterschiedliche Peerings:
a) public peering (IX) via route server
b) public peering (IX) with direct BGP sessions
c) private peering

Auf fast allen unseren Standorten hat unser regionaler ISP ein Peering mit Google, aber Google verwendet nur ein paar dieser Peerings um zu unseren Anycast Standorten zu routen. Ich vermute, dass das daran liegt, dass manche Provider ein private Peering mit Google haben, andere über IX, und Google für private Peerings eine höhere local pref setzt. 

Weiß jemand ob meine Theorie stimmt? Bzw. ob Google (oder andere ISPs) hier wirklich Unterscheidungen machen? Unterscheiden ISPs auch zwischen a) und b)?

lg
Klaus

_______________________________________________
atnog mailing list
atnog at atnog.at
https://atnog.at/mailman/listinfo/atnog