Je 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 TXT
Juste 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