Facebook Videos ruckeln

Bei meinem Internetzugang zu Hause habe ich seit einiger Zeit das Problem, dass Videos auf Facebook angefangen haben zu ruckeln. Wie jeder sich das sicherlich gut vorstellen kann, ist das ziemlich unschön und es ist insbesondere noch nerviger, wenn man über einen langsamen Kupferanschluss, sonder über einen schnellen FTTH Anschluss verfügt.

Zuerst dachte ich, dass es ein Routing Issue bei meinem ISP sein könnte. Nach einer Konversation auf Twitter mit meinem ISP (hier nochmals ein “Danke” für den schnellen und kompetenten Support) stellte sich heraus, dass es ein DNS Problem zu sein scheint. Offensichtlich liefert mein lokaler DNS Resolver (ich betreibe aus diversen Gründen meinen eigenen Resolver) in meinem LAN eine andere IP als Antwort, als der Resolver von meinem ISP.

Schauen wir uns dazu mal den DNS Eintrag zu www.facebook.com mal genauer an:

$ dig www.facebook.com AAAA
 
; <<>> DiG 9.9.8-P3 <<>> www.facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4636
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.com. IN A
 
;; ANSWER SECTION:
www.facebook.com. 2315 IN CNAME star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 38 IN AAAA 2a03:2880:f000:13:face:b00c:0:1823
 
;; AUTHORITY SECTION:
c10r.facebook.com. 2079 IN NS a.ns.c10r.facebook.com.
c10r.facebook.com. 2079 IN NS b.ns.c10r.facebook.com.
 
;; ADDITIONAL SECTION:
a.ns.c10r.facebook.com. 2519 IN AAAA 2a03:2880:fffe:b:face:b00c:0:99
a.ns.c10r.facebook.com. 2511 IN A 69.171.239.11
b.ns.c10r.facebook.com. 2152 IN AAAA 2a03:2880:ffff:b:face:b00c:0:99
b.ns.c10r.facebook.com. 2111 IN A 69.171.255.11
 
;; Query time: 1 msec
;; SERVER: 2a02:168:9800::4d#53(2a02:168:9800::4d)
;; WHEN: So Feb 28 12:14:46 CET 2016
;; MSG SIZE rcvd: 213

Wie man sehen kann, ist www.facebook.com ein CNAME auf star-mini.c10r.facebook.com. Die für c10r.facebook.com zuständigen Name Server sind a.ns.c10r.facebook.com und b.ns.c10r.facebook.com.

Kommt von meinem Resolver die Anfrage für star-mini.c10r.facebook.com an a.ns.c10r.facebook.com, so erhalte ich die IP 2a03:2880:f000:13:face:b00c:0:1823, welche nach Miami führt. So ist es auch nicht weiter verwunderlich, dass die Videos auf Facebook ruckeln, wenn die Daten von der anderen Seite des Atlantiks kommen. Zumal ist die Latenz mit 125 ms recht hoch.

Stelle ich den gleichen Request an Resolver meines ISPs (ns10.init7.net), so erhalte ich die IP 2a03:2880:f01c:21b:face:b00c:0:25de als Antwort. Diese IP steht in Frankfurt und bis dort hin ist die Latenz nur 7 ms.
Die gleiche Antwort erhalte ich auch vom zweiten DNS Resolver meines ISPs, ns20.init7.net.

Der Resolver ns20.init7.net scheint im Datacenter Layer One in Zürich zu stehen, also unmittelbar zu meinem Server, wo auch dieses Blog gehostet ist.

$ traceroute6 -Ia ns20.init7.net
traceroute6 to ns20.init7.net (2001:1620:2777:2::20) from 2001:1620:20a4::9, 64 hops max, 16 byte packets
 1 [AS13030] gw-dogan-init7.dogan.ch 42.454 ms 2.511 ms 7.324 ms
 2 [AS13030] ns20.init7.net 0.556 ms 0.553 ms 0.415 ms

In der Tat wirklich nahe. Kommt nun der Request von meinem Server im Layer One Datacenter, so erhalte ich die IP 2a03:2880:2040:7f21:face:b00c:0:25de zurück und die führt mich in die USA.

Dies ist wirklich spannend. Obwohl bis jetzt alle Requests aus dem gleichen AS und sogar aus dem gleichen Netz kamen, lieferte Facebook mir jedes mal eine andere IP zurück, wobei nur die Antwort der Resolver meines ISP, ns10.init7.net und ns20.init7.net, zum jeweils nächsten Facebook Server verwiesen.

Wie sieht es mit anderen ISPs und Resolvern aus?

Der Google Public DNS Resolver liefert mir die IP 2a03:2880:f008:1e:face:b00c:0:25de zurück (abgefragte aus AS 13030), welche in Mailand steht. 34 ms Latenz. Eine brauchbare Antwort.

Bei Swisscom sieht es ebenfalls ähnlich aus wie bei Init7: Stellt man den Request an den Resolver dns2.bluewin.ch, bekommt man die IP 2a03:2880:f007:1e:face:b00c:0:25de zurück und man landet in Wien. Stellt man den Request direkt an a.ns.c10r.facebook.com, bekommt man 2a03:2880:fffe:b:face:b00c:0:99 zurück und man landet in den USA.

Interessant ist es bei Solnet: Bei einer Anfrage an den Resolver soho.solnet.ch wird man nach Frankfurt (2a03:2880:f01c:21b:face:b00c:0:25de) geschickt. Bei einer direkten Anfrage an a.ns.c10r.facebook.com geht es nach Warschau (2a03:2880:fffe:b:face:b00c:0:99). Die Latenz nach Warschau ist mit 28 ms immer noch in einem sehr guten Rahmen.

Einzig beim Kieler Provider TNG bekommt man immer das gleiche Resultat: Egal ob man den Resolver des ISP oder a.ns.c10r.facebook.com fragt, man wird nach Frankfurt geleitet (2a03:2880:f01c:21b:face:b00c:0:25de).

 

Workaround

Möchte bzw. kann man nicht auf den eigenen Resolver verzichten und möchte nicht mit ruckelnden Videos auf Facebook konfrontiert werden, so kann man als Workaround die Anfragen für facebook.com und fbcdn.net an einen anderen Resolver schicken. Ich habe mich entschieden, die Anfragen an den Resolver meines ISPs weiter zu leiten – dazu ist in der unbound.conf folgende Anpassung notwendig:

forward-zone:
 name: "facebook.com."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"
 
forward-zone:
 name: "fbcdn.net."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

Wie man sehen kann, konnte ich so die Latenz von 125 ms auf angenehme 7 ms reduzieren:

Fazit

Bei allen ISPs wurde jeweils a.ns.c10r.facebook.com (der zuständige autoritative DNS server für  10r.facebook.com, Anycast) nach Frankfurt geroutet. Die erhaltene Antwort schickt jedoch den Browser mal in die USA oder mal nach Europa. Wird der Browser in die USA geschickt, kann das zu Problemen beim Abspielen von Videos auf Facebook führen. Dieses Verhalten ist für mich nicht nachvollziehbar und aus meiner Sicht scheint das Content Delivery Network von Facebook zu funktionieren. Einen Fehler mit Anycast oder Routing würde ich jedoch hier ausschliessen.

Generell ist zu empfehlen, wenn immer möglich den Resolver des ISPs zu verwenden.

Diesen Umstand habe ich dem technischen Support von Facebook gemeldet. Updates, werde ich wieder hier in meinem Blog posten.

Update  (1. März 2016)

Daniel Stirnimann hat mich darauf aufmerksam gemacht, dass das von mir beobachtete Verhalten ebenfalls mit Ripe Atlas beobachtet werden kann. In der folgenden Grafik wurde ping6 star-mini.c10r.facebook.com vom Atlas Probe ausgeführt, wobei der Hostname von der Probe selber aufgelöst wurde:

In der zweiten Grafik wurde ebenfalls ping6 star-mini.c10r.facebook.com ausgeführt, der Hostname wurde jedoch durch den Resolver des ISPs aufgelöst:

Wie man sehen kann ist das Resultat sehr unterschiedlich. Offensichtlich scheint Facebook Resolver von ISPs und kleinere Resolver anders zu behandeln

 

 

Update  (28. August 2016)

WhatsApp, welches mittlerweile seit gut zwei Jahren zu Facebook gehört, benutzt das Facebook CDN und zeigt das gleiche Verhalten wie Facebook. Auch hier empfiehlt es sich, die Konfiguration des Resolvers anzupassen:

forward-zone:
 name: "whatsapp.com."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

forward-zone:
 name: "whatsapp.net."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

Anmerkung zu IPv4 & IPv6

Es gibt keinen Unterschied zu IPv4 und IPv6. Die Antworten zum A und AAAA Record stehen jeweils im Zusammenhang.