 Peering Google / Youtube => Discussion démarrée par: vivien le 02 mai 2011 à 22:01:14
 Peering Google / Youtube => Discussion démarrée par: vivien le 02 mai 2011 à 22:01:14Je confirme que l'accès Internet de Free est en forte dégradation ces derniers mois. Youtube est catastrophique sur de très longues périodes dans la journée, pas juste quelques heures en soirée.
Je pensais qu'il était dans la philosophie du FAI de fournir un accès de qualité, de maximiser ses peering quel qu'en soit le prix... bref, je me trompais lourdement!
Leon.
il faut ponderer peut-etre que google a décidé peut etre il y a X mois de changer ses r€gl€s de peering... tout cela on ne le saura jamais avec leur close de confidientalité mais c'est toujours l'abonné final qui en patit, la preuve en est...
> Faux, faux et faux :D (ne prends pas la remarque personnellement, j'aime juste tordre le cou aux idées reçu)
blague à part, c'est facile de dire ok nous c'est gratuit mais c'est vous qui payez.. le probleme la c'est deOui, je suis d'accord.
refiler la facture à l'autre...
Du délire!
la communauté Internet doit t-il payer la totalité des trafics non P2P (anonymes on dira) réputés consommateurs de BP....on a le meme bleme avec megaupload&Cie...Évidement, c'est meilleur pour Free ou tout autre FAI si le trafic reste dans leurs réseaux, mais Internet est un maillage de réseau, est on a tous besoin de contenu qui viens de l'exterieur.
Pour finir sur le sujet Google, tu n'as pas répondu. Il paie, et ne peuvent pas payer plus. Donc Free a tord ^_^.
Oui, je suis d'accord.Free voudrait faire payer une terminaison d'appel Internet.
Mais dans ce cas, Google est le mauvais exemple. Ils font un effort énorme pour être présent partout quasiment afin d'offrir des liens directes aux FAIs nationaux (tel Free, Orange, SFR).
Le but pour eux est de réduire les couts de transit. Maintenant si les FAIs reviennent pour dire ils faut que Google paie la question est quoi?
Et avec l'Arcep qui veux pousser le FTTH et la terminaison d'appel on se retrouverait a financer la boucle local avec des taxes sur les fournisseurs de contenu... urgh. Pas de quoi nourrir l'innovation...
Quelle est ton idée de l'innovation ? faut bien que soit le fournisseur de contenu ou/et le FAI ou/et le client passe à la caisse....Ba, ca depend. En tout cas ça ne veux pas dire faire payer les petits pour enrichir les gros.
Free voudrait faire payer une terminaison d'appel Internet.C'est quoi un "appel Internet"?
Pour Free celui qui appelle, c'est celui qui envoie des données, donc le CDN (Content Delivery Network).C'est au volume?
Les hébergeurs, eux, disent que celui qui appelle, c'est celui qui initie la connexion et donc le client du FAI qui fait la demande de la page / vidéo.
Et avec l'Arcep qui veux pousser le FTTH et la terminaison d'appel on se retrouverait a financer la boucle local avec des taxes sur les fournisseurs de contenu... urgh. Pas de quoi nourrir l'innovation...La TA sur le téléphone est basé sur le cout de la boucle locale : elle est très différente entre le fixe et le mobile. Ce qui est contestable, parce que celui qui choisit d'être joignable uniquement par le mobile (pour économiser l'abonnement fixe, parce que c'est plus pratique) devrait assumer le surcout de cette technologie.
Pour Free celui qui appelle, c'est celui qui envoie des données, donc le CDN (Content Delivery Network).Ce n'est pas du tout la logique de la terminaison d'appel ça : c'est la logique numéro "SVA" non-surtaxé, donc numéro vert/azur : celui qui reçoit l'appel paie.
Les hébergeurs, eux, disent que celui qui appelle, c'est celui qui initie la connexion et donc le client du FAI qui fait la demande de la page / vidéo.C'est parfaitement logique puisqu'on fait une analogie avec le téléphone :
exact, http://www.journaldunet.com/ebusiness/telecoms-fai/fai-pour-terminaison-d-appel-internet-1110.shtml (http://www.journaldunet.com/ebusiness/telecoms-fai/fai-pour-terminaison-d-appel-internet-1110.shtml)Mais justement en téléphonie le trafic est symétrique et donc exactement équilibré : le rapport up/down est de 1.
Les FAI favorables à une "terminaison d'appel" Internet
(...)
En France, les FAI défendent une autre solution, indique Les Echos, celle de la terminaison d'appel. Comme dans le secteur de la téléphonie mobile, les opérateurs qui achemineraient le trafic au client final seraient rémunérés.
j'ai écouté MJ + akon.... 360 ok 480 c'est juste avec quelques grosses coupures et 720 c'est la cata....
réseau FREE dans le nord....
Pas possible ce soir de regarder du 1080p https://youtu.be/57PPjOOFYRo (https://youtu.be/57PPjOOFYRo)Quelle IP?
BineQuelle IP?
Mon ip?Celle de 1e100 depuis laquelle tu télécharges la vidéo.
En fait la saturation proviendrait seulement du protocole. Pas de souci en IPV4C'est sur qu'il y a eu des améliorations récentes, chez Free, mais c'est loin d'être parfait, y compris en IPV4. Chez moi, aux heures de pointes (bizarrement), c'est impossible de regarder des vidéos en 1080p.
Conneries, il est extrêmement simple de démontrer que Free laisse volontairement les liens transit en surcharge.Volontairement? Je ne pense pas quand même, il ne faut pas abuser. Ca n'est souvent pas si simple que ça, la relation entre 2 opérateurs.
                                                            Packets               Pings
 Host                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. [AS-1] 192.168.1.254                                   0.0%    11    0.2   0.2   0.2   0.4   0.1
 2. [AS12322] 82.231.26.254                                0.0%    11   23.3  22.6  21.9  23.3   0.5
 3. [AS12322] montpellier-6k-1-a5.routers.proxad.net       0.0%    11   22.4  24.7  22.4  36.0   3.9
 4. [AS12322] montpellier-9k-1-be1201.routers.proxad.net   0.0%    11   22.6  23.5  22.1  24.2   0.6
 5. [AS12322] toulouse-6k-1-po52.intf.routers.proxad.net   0.0%    11   26.4  26.6  25.5  27.4   0.7
 6. [AS12322] bordeaux-crs16-1-be1005.intf.routers.proxad  0.0%    11   29.8  29.7  28.7  30.8   0.6
 7. [AS12322] bzn-crs16-1-be1100.intf.routers.proxad.net  18.2%    11   39.5  38.8  37.6  39.8   0.7
 8. [AS174] 149.6.115.21                                   0.0%    11   40.2  86.0  39.3 231.0  70.9
 9. [AS174] te0-2-0-6.ccr21.par01.atlas.cogentco.com       0.0%    11   39.3  39.7  38.2  41.6   0.8
10. [AS174] te0-1-0-1.ccr21.lon13.atlas.cogentco.com       0.0%    10   47.8  47.0  46.0  48.6   0.9
11. [AS174] 154.54.58.218                                  0.0%    10   45.9 107.7  45.9 350.7 103.4
12. [AS174] gblx.lon01.atlas.cogentco.com                  0.0%    10   49.6  48.3  46.4  54.9   2.6
13. [AS3549] ae5.scr3.LON3.gblx.net                        0.0%    10   46.7  50.9  45.8  88.8  13.3
14. [AS3549] po1.ar7.AMS2.gblx.net                         0.0%    10   51.8  51.4  50.6  52.7   0.6
15. [AS3549] 64.211.193.226                               10.0%    10   52.3  52.1  51.3  52.6   0.4
16. [AS15169] 208.117.247.177                              0.0%    10   50.9  51.8  50.8  52.7   0.7
17. [AS15169] 208.117.247.185                              0.0%    10   51.2  51.5  50.5  52.6   0.7
18. [AS43515] 208.65.155.210                               0.0%    10   51.6  51.4  50.4  53.2   0.8
traceroute to 2a00:1450:4007:7::12 (2a00:1450:4007:7::12), 30 hops max, 80 byte packets
 1  2a01:e35:2e71:af20:: (2a01:e35:2e71:af20::) [AS12322]  2.620 ms  2.603 ms  2.590 ms
 2  * * *
 3  2a01:e00:1:11::1 (2a01:e00:1:11::1) [AS12322]  44.592 ms  45.552 ms  46.797 ms
 4  2a01:e00:1:10::2 (2a01:e00:1:10::2) [AS12322]  48.474 ms  49.701 ms  52.151 ms
 5  2001:4860:1:1:0:3022:: (2001:4860:1:1:0:3022::) [AS15169]  73.824 ms google-pni-3.intf.routers.proxad.net (2a01:e00:4:5::2) [AS12322]  75.797 ms  76.993 ms
 6  2001:4860:0:1::33c (2001:4860:0:1::33c) [AS15169]  56.080 ms  41.356 ms  43.513 ms
 7  2a00:1450:4007:7::12 (2a00:1450:4007:7::12) [AS15169]  67.492 ms  68.286 ms  69.240 ms
   4 tours-6k-1.routers.proxad.net (213.228.19.62) 11.936 ms * *
5 orleans-6k-1-po2.intf.routers.proxad.net (212.27.50.73) 14.303 ms * *
6 bzn-crs16-1-be1101.intf.routers.proxad.net (212.27.50.69) 18.789 ms 19.324 ms 20.001 ms
7 te2-8.365.mag02.par01.atlas.cogentco.com (149.6.160.101) 159.067 ms 152.893 ms 153.014 ms
8 te0-5-0-6.mpd21.par01.atlas.cogentco.com (130.117.49.89) 16.237 ms te0-3-0-6.mpd21.par01.atlas.cogentco.com (130.117.50.66) 15.614 ms te0-5-0-6.mpd21.par01.atlas.cogentco.com (130.117.49.89) 15.102 ms
9 te7-7.mpd02.lon01.atlas.cogentco.com (130.117.2.6) 199.602 ms te3-3.mpd02.lon01.atlas.cogentco.com (130.117.0.109) 181.270 ms 181.319 ms
10 google.lon01.atlas.cogentco.com (130.117.14.90) 20.506 ms 21.375 ms 22.092 ms
11 64.233.175.27 (64.233.175.27) 22.809 ms 64.233.175.25 (64.233.175.25) 23.773 ms 64.233.175.27 (64.233.175.27) 24.500 ms
12 72.14.232.134 (72.14.232.134) 20.754 ms 21.098 ms 21.321 ms
13 209.85.251.231 (209.85.251.231) 27.439 ms 21.150 ms 124.459 ms
14 216.239.46.113 (216.239.46.113) 28.691 ms 216.239.46.253 (216.239.46.253) 32.530 ms 216.239.46.117 (216.239.46.117) 26.164 ms
15 bru01m01-in-f105.1e100.net (209.85.147.105) 21.503 ms 20.613 ms 20.590 ms
Les mauvaises performances de Youtube en IPv6 pourraient ne pas être lié a Google mais a la saturation des serveurs qui encapsule IPv6 dans IPv4 chez Free.Quelques test de débit réalisé sur http://ipv4.proof.ovh.net/ (http://ipv4.proof.ovh.net/) et http://ipv6.proof.ovh.net/ (http://ipv6.proof.ovh.net/) avec la même ligne adsl:
IP			Download (kb/s)	Upload (kb/s)	Latency (ms)
82.231.26.xxx		17252	753	88
82.231.26.xxx		17770	749	86
82.231.26.xxx		17795	752	87
2a01:e35:2e71::xxxx	16877	731	89
2a01:e35:2e71::xxxx	16383	729	90
2a01:e35:2e71::xxxx	16826	731	88
Il y a bien quelques kb/s mesurés en moins (probablement dû à encapsulation), mais largement de quoi faire passer un flux 1080p de youtube. Je doute donc que le problème soit en rapport avec l'encapsulation coté free.Youtube n'est pas le seul a être lent en IPv6 comme le montre les tests de débit en IPv6 (https://lafibre.info/free-la-fibre/freebox-revolution-fibre-ftth-debit-en-telechargement-de-1-gbs/msg35545/#msg35545) (le même serveur OVH est testé en IPv6 et en IPv4).Sur ces test, ipv6 devrait etre natif sur le réseau free (ftth, pas d'encapsulation a priori).
On dirait que Free a coupé le peering privé en IPv4 (pour forcer Google a payer qq chose ?) et a oublié de le désactiver en IPv6.A priori seulement pour youtube, vers www.google.fr (https://www.google.fr) :
                                                                                                                   Packets               Pings
 Host                                                                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. [AS-1] 192.168.1.254                                                                                           0.0%    13    0.2   0.2   0.2   0.3   0.0
 2. [AS12322] 82.231.26.254                                                                                        0.0%    13   22.3  22.5  21.5  23.5   0.6
 3. [AS12322] montpellier-6k-1-a5.routers.proxad.net                                                               0.0%    13   22.5  23.0  21.8  24.7   0.9
 4. [AS12322] montpellier-9k-1-be1201.routers.proxad.net                                                           0.0%    13   22.7  23.1  22.3  24.1   0.6
 5. [AS12322] toulouse-6k-1-po52.intf.routers.proxad.net                                                           0.0%    13   26.9  26.7  25.9  28.1   0.7
 6. [AS12322] bordeaux-crs16-1-be1005.intf.routers.proxad.net                                                      0.0%    13   30.0  30.2  28.9  35.2   1.6
 7. [AS12322] bzn-crs16-1-be1100.intf.routers.proxad.net                                                           7.7%    13   38.3  38.4  37.3  39.4   0.7
 8. [AS12322] cbv-9k-1-be1001.intf.routers.proxad.net                                                              0.0%    12   39.6  39.0  37.9  39.7   0.6
 9. [AS15169] 72.14.216.98                                                                                         8.3%    12   59.8  68.2  59.8 122.2  19.1
10. [AS15169] 209.85.250.142                                                                                       0.0%    12   38.1  67.6  37.9 351.6  89.9
11. [AS15169] 72.14.233.105                                                                                        0.0%    12   47.3  66.0  47.3 239.5  54.8
12. [AS15169] 72.14.239.63                                                                                         0.0%    12   48.5  67.7  47.4 235.8  54.2
13. [AS15169] 209.85.254.41                                                                                        0.0%    12   48.7  67.3  47.9 232.1  52.1
    209.85.254.57
14. [AS15169] fra07s07-in-f106.1e100.net                                                                           0.0%    12   48.2  64.0  47.6 234.3  53.6
L’interconnexion est direct.5  2001:4860:1:1:0:3022:: (2001:4860:1:1:0:3022::) [AS15169]  73.824 ms google-pni-3.intf.routers.proxad.net (2a01:e00:4:5::2) [AS12322]  75.797 ms  76.993 ms- problème sur le réseau de google. (encapsulation qui tient pas la route de leur coté si elle existe, ou bien capacité du lien saturé pour leur interconnexion entre paris et leur datacenter youtube en ipv6)Donc on pourrait dire que Free est devenu smart en ce qui concerne la gestion de la bande passante vers Google: les service Google passe par le lien de peering a Courbevoie, et le gros du trafic Youtube passe par Cogent.En fait comme tout le monde connait youtube ils font en sorte que ça fonctionne bien avec google, donc je crois qu'ils ont du peering directement, mais avant quand c'était foireux c'était bien parce que ça passait par cogentco, donc pour toutes les machines qu'on veut joindre en passant par les liens de transit c'est super foireux, surtout avec cogentco et tata.
Concernant la partie IP6, je pense que c'est bien que Free "favorise" les clients en 6 car depuis que le protocole existe (10 ans ou plus? *) la généralisation est encore loin d’être une réalité...
* Verification: IPv6 date de 1996! (https://en.wikipedia.org/wiki/IPv6 (https://en.wikipedia.org/wiki/IPv6))
Quelques test de débit réalisé sur http://ipv4.proof.ovh.net/ (http://ipv4.proof.ovh.net/) et http://ipv6.proof.ovh.net/ (http://ipv6.proof.ovh.net/) avec la même ligne adsl:Il faudrait refaire le test avant minuit.Code: [Sélectionner]IP Download (kb/s) Upload (kb/s) Latency (ms)Il y a bien quelques kb/s mesurés en moins (probablement dû à encapsulation), mais largement de quoi faire passer un flux 1080p de youtube. Je doute donc que le problème soit en rapport avec l'encapsulation coté free.
82.231.26.xxx 17252 753 88
82.231.26.xxx 17770 749 86
82.231.26.xxx 17795 752 87
2a01:e35:2e71::xxxx 16877 731 89
2a01:e35:2e71::xxxx 16383 729 90
2a01:e35:2e71::xxxx 16826 731 88
### DNS FREE ###
$ dig @212.27.40.240 -x 212.27.40.240 +short
dns1.proxad.net.
-
$ dig @212.27.40.240 www.google.com (https://www.google.com) AAAA +short
www.l.google.com (http://www.l.google.com).
2a00:1450:4001:c01::67
-
$ dig @212.27.40.240 www.google.fr (https://www.google.fr) AAAA +short
www.google.com (https://www.google.com).
www.l.google.com (http://www.l.google.com).
2a00:1450:4001:c01::68
-
$ dig @212.27.40.240 www.youtube.com (https://www.youtube.com) AAAA +short
youtube-ui.l.google.com.
2a00:1450:8007::be
-
$ dig @212.27.40.240 www.youtube.fr (https://www.youtube.fr) AAAA +short
youtube-ui.l.google.com.
2a00:1450:4001:c01::5b
-
$ dig @212.27.40.240 ipv6.google.com AAAA +short
ipv6.l.google.com.
2a00:1450:4001:c01::6a
-
$ dig @212.27.40.240 www.free.fr (https://www.free.fr) AAAA +short
2a01:e0c:1:1599::1
-
$ dig @212.27.40.240 www.kame.net (http://www.kame.net) AAAA +short
orange.kame.net.
2001:200:dff:fff1:216:3eff:feb1:44d7
-
### DNS GOOGLE ###
$ dig @8.8.8.8 -x 8.8.8.8 +short
google-public-dns-a.google.com.
-
$ dig @8.8.8.8 www.google.com (https://www.google.com) AAAA +short
www.l.google.com (http://www.l.google.com).
-
$ dig @8.8.8.8 www.google.fr (https://www.google.fr) AAAA +short
www.google.com (https://www.google.com).
www.l.google.com (http://www.l.google.com).
-
$ dig @8.8.8.8 www.youtube.com (https://www.youtube.com) AAAA +short
youtube-ui.l.google.com.
-
$ dig @8.8.8.8 www.youtube.fr (https://www.youtube.fr) AAAA +short
youtube-ui.l.google.com.
-
$ dig @8.8.8.8 ipv6.google.com AAAA +short
ipv6.l.google.com.
2a00:1450:4001:c01::93
-
$ dig @8.8.8.8 www.free.fr (https://www.free.fr) AAAA +short
2a01:e0c:1:1599::1
-
$ dig @8.8.8.8 AAAA www.kame.net (http://www.kame.net) +short
orange.kame.net.
2001:200:dff:fff1:216:3eff:feb1:44d7
IP			Download (kb/s)	Upload (kb/s)	Latency (ms)
82.231.26.xxx		17429	751	96
2a01:e35:2e71::xxxx	17211	736	93
			$ dig @212.27.40.240 www.google.com (https://www.google.com) AAAA +short
www.l.google.com (http://www.l.google.com).
2a00:1450:8007::69
$ dig @212.27.40.240 www.google.fr (https://www.google.fr) AAAA +short
www.google.com (https://www.google.com).
www.l.google.com (http://www.l.google.com).
2a00:1450:8007::69
$ dig @212.27.40.240 www.youtube.com (https://www.youtube.com) AAAA +short
youtube-ui.l.google.com.
2a00:1450:400c:c00::88
$ dig @212.27.40.240 www.youtube.fr (https://www.youtube.fr) AAAA +short
youtube-ui.l.google.com.
2a00:1450:400c:c00::88
dig +short porttest.dns-oarc.net TXTJuste pour signaler que les soucis en ipv6 semblent résolus: vitesse de téléchargement au maximum de la capacité de ma ligne avec même un débit un peu plus stable et élevé qu'en ipv4.
Je suis un peu hors sujet, mais je pensait, avant, que le passage à l'IPv6 se ferait selon le schéma suivant :C'était effectivement le plan originel : on "allume" progressivement IPv6, puis quand tout le monde sera en double-pile, on commence à éteindre IPv4. Maintenant, c'est juste trop tard pour ce plan originel, car on n'a plus d'IPv4.
1 - Dual stack optionnel (option IPv6 à activer)
2 - Dual stack systématiquement installé (coté box et coté OS - c'est le cas avec Linux et MacOS X depuis longtemps et Windows depuis Vista)
3 - Ensemble des serveurs joignable en IPv4 et IPv6
4 - Premiers abonnés avec uniquement une IPv6 (sans IPv4 privée pour accéder au réseau IPv4 via du NAT)
Aujourd'hui on est toujours à l'étape 1.
Une prévision (on verra si le futur me donne raison) : Je pense que l'année 2015 sera celle du basculement où le trafic mondial IPv6 dépassera IPv4.Pour ma part, je suis très mauvais en boule de cristal ;) . Au vu des déploiements actuels, on n’est même pas sûr qu'IPv6 domine un jour (il y a des gens à qui le NAT plait).
Pour ma part, je suis très mauvais en boule de cristal ;) . Au vu des déploiements actuels, on n’est même pas sûr qu'IPv6 domine un jour (il y a des gens à qui le NAT plait).
Un abonné au FAI xxxx avec une IPv4 natté sans IPv6 peut accéder à des serveurs IPv6 only ?Oui, avec du "NAT" sur les réponses DNS AAAA.
Tu change les réponses des DNS, c'est ça ?
Si l'ordinateur ne possédé qu'une connectivité IPv4, il est incapable de faire quoi que ce soit avec les IPv6 retournée par les les champs IPv6 du DNS (requêtes AAAA) d'où mon idée de proxy joignable en IPv4.
Je pense que le peering privé Youtube / Google reprend du service...
traceroute to [url=https://www.youtube.com]www.youtube.com[/url] (66.102.13.93), 30 hops max, 60 byte packets
 1  88.175.72.254 (88.175.72.254)  21.292 ms  21.574 ms  22.820 ms
 2  78.254.1.190 (78.254.1.190)  38.336 ms  38.610 ms  38.809 ms
 3  ivr94-1-v902.intf.nra.proxad.net (78.254.255.57)  26.075 ms  26.438 ms  27.585 ms
 4  stmaurice-6k-1-po3.intf.nra.proxad.net (78.254.255.53)  28.646 ms * *
 5  th2-crs16-1-be1008.intf.routers.proxad.net (212.27.50.29)  31.237 ms  31.888 ms  32.772 ms
 6  cbv-9k-1-be1002.intf.routers.proxad.net (212.27.59.9)  33.843 ms  20.943 ms  20.597 ms
 7  google-pni-3.routers.proxad.net (212.27.40.102)  50.639 ms 72.14.216.98 (72.14.216.98)  50.233 ms google-pni-3.routers.proxad.net (212.27.40.102)  51.451 ms
 8  209.85.250.142 (209.85.250.142)  25.232 ms 209.85.251.40 (209.85.251.40)  25.646 ms  26.006 ms
 9  209.85.253.20 (209.85.253.20)  32.857 ms  34.321 ms 216.239.43.233 (216.239.43.233)  34.774 ms
10  209.85.240.159 (209.85.240.159)  41.381 ms 209.85.240.220 (209.85.240.220)  39.857 ms 209.85.240.159 (209.85.240.159)  60.427 ms
11  216.239.49.30 (216.239.49.30)  47.551 ms  47.887 ms 216.239.49.28 (216.239.49.28)  46.959 ms
12  64.233.174.133 (64.233.174.133)  46.171 ms  41.736 ms 64.233.174.137 (64.233.174.137)  37.941 ms
13  ez-in-f93.1e100.net (66.102.13.93)  37.901 ms  38.263 ms  36.617 ms