[FRnOG] Le travail du groupe Forces (protocole ouvert de communication *dans* le routeur) quasiment terminé
Avec la publication hier des RFC 5810 (le protocole), 5811 (le transport), 5812 (le modèle de routeur), etc, le groupe de travail ForCES de l'IETF a quasiment terminé son travail qui était de normaliser un protocole de communication entre les éléments d'un routeur, permettant de créer des routeurs modulaires et de faire son marché librement. Reste plus qu'à l'implémenter et à le déployer :-) http://www.bortzmeyer.org/5810.html Ce RFC conclut, après un très long travail, les efforts du groupe de travail Forces (http://tools.ietf.org/wg/forces) de l'IETF. Ce groupe était chargé de produire un protocole permettant la communication entre les différents éléments d'un routeur, afin de permettre d'acheter ces éléments chez des vendeurs différents. Un tel protocole pourrait permettre d'ouvrir le monde actuellement très fermé des routeurs de haut de gamme, mais il n'est pas sûr du tout qu'il soit un jour effectivement mis en #339;uvre. Le travail de Forces avait commencé il y a de nombreuses années et le premier RFC, le RFC 3654 avait été publié en 2003. Maintenant, grâce à ce RFC 5810 (et quelques compagnons comme le RFC 5811 sur le protocole de transport), le travail est quasiment terminé et la partie Normalisation de Forces avec lui. Il reste à l'implémenter et à faire en sorte qu'il soit disponible dans les routeurs... Conformément au cahier des charges du RFC 3654, et au cadre général de Forces exposé par le RFC 3746, ce nouveau protocole permet la communication entre deux catégories d'élements qui composent un routeur, les CE (Control Element) et les FE (Forwarding Element). (La section 3 rappelle le vocabulaire de Forces.) Les premiers, les CE, font tourner des algorithmes compliqués comme OSPF ou BGP, ils prennent des décisions « de haut niveau » et les seconds, les FE, font le travail « bête » mais ultra-rapide, de commutation de chaque paquet. Aujourd'hui, dans un routeur (Forces dit NE, pour Network Element, et pas routeur) haut de gamme, le CE est typiquement un processeur standard, avec un système d'exploitation (parfois un Unix),le FE est un ASIC aux capacités bien plus limitées mais aux performances fantastiques. Comme le protocole de communication entre le CE et le FE est privé, pas question de faire tourner du logiciel libre sur le CE, pas question d'acheter le processeur à un vendeur et les ASIC à un autre. C'est ce problème que Forces veut résoudre. Dans Forces, la relation entre les CE et les FE est simple : le CE est le maître et le FE l'esclave. Les informations nécessaires au FE sont regroupées dans des LFB (Logical Function Block) dont la description est faite en XML (cf. RFC 5812). Le protocole lui-même n'utilise pas XML. Le protocole ne spécifie que la communication entre FE et CE, pas celles qui pourraient exister entre FE ou bien entre CE, ni celle qui relie les CE à leur gérant (l'interface d'administration du routeur). (La section 4 rappelle le cadre général de Forces, exposé dans le RFC 3746.) Le protocole Forces est également responsable de l'établissement et de la terminaison des associations entre un routeur (NE) et des CE ou FE (section 4.4). Une fois l'association faite, le CE envoie des ordres au FE, ordres exprimés avec le protocole Forces, et encapsulés dans un protocole de transport, le TLM (Transport Layer Mapping) qui fait l'objet d'un RFC séparé (RFC 5811). La section 4.3.1 du RFC détaille la question de l'atomicité des requêtes Forces. Le protocole permet des requêtes atomiques (toutes sont exécutées, ou bien aucune ne l'est, section 4.3.1.1.1) mais aussi des requêtes exécutées séquentiellement jusqu'au premier échec (section 4.3.1.1.3) ou encore des requêtes exécutées même si la précédente était un échec (section 4.3.1.1.2). Mieux, Forces permet des transactions ACID (section 4.3.1.2). L'encodage des paquets sur le câble fait l'objet de la section 6. Tous les paquets ont un en-tête commun, suivi d'un ou plusieurs TLV. Parmi les champs de l'en-tête commun, un numéro de version sur 4 bits (actuellement 1), le type du message, sur 8 bits (les différents types sont décrits en section 7 et le tableau complet est dans l'annexe A.1) et les adresses (nommées ID) de l'expéditeur et du destinataire. Ces ID, ces adresses, sont codés sur 32 bits et doivent être uniques à l'intérieur du routeur (mais pas forcément pour tout l'Internet). Rappelez-vous qu'un des buts de Forces est de pouvoir gérer des équipements très complexes, où CE et FE ne sont pas forcément dans la même boîte. À noter que les adresses des CE et des FE sont séparées (les premières commencent toujours par 00 et les secondes par 01). Une fois passé l'en-tête commun, viennent les TLV, décrits dans la section 6.2. Le choix de TLV permet de simplifier l'analyse des messages, certains FE n'apprécieraient en effet pas forcément de devoir analyser du XML. À noter que le champ Valeur d'un TLV peut contenir d'autres TLV. Le contenu légal d'un message
[FRnOG] Re: [FRnOG] Le travail du groupe Forces (protocole ouvert de c ommunication *dans* le routeur) q uasiment terminé
Cela semble très bien en principe. Merci Stéphane pour l'effort de communication au sujet de ForCES. Est-ce qu'il y a qqpart une présentation plus facile à avaler pour des étudiants ( bac+4/5 )? William Le Fri, 19 Mar 2010 09:24:33 +0100, Stephane Bortzmeyer bortzme...@nic.fr a écrit: Avec la publication hier des RFC 5810 (le protocole), 5811 (le transport), 5812 (le modèle de routeur), etc, le groupe de travail ForCES de l'IETF a quasiment terminé son travail qui était de normaliser un protocole de communication entre les éléments d'un routeur, permettant de créer des routeurs modulaires et de faire son marché librement. Reste plus qu'à l'implémenter et à le déployer :-) http://www.bortzmeyer.org/5810.html Ce RFC conclut, après un très long travail, les efforts du groupe de travail Forces (http://tools.ietf.org/wg/forces) de l'IETF. Ce groupe était chargé de produire un protocole permettant la communication entre les différents éléments d'un routeur, afin de permettre d'acheter ces éléments chez des vendeurs différents. Un tel protocole pourrait permettre d'ouvrir le monde actuellement très fermé des routeurs de haut de gamme, mais il n'est pas sûr du tout qu'il soit un jour effectivement mis en #339;uvre. Le travail de Forces avait commencé il y a de nombreuses années et le premier RFC, le RFC 3654 avait été publié en 2003. Maintenant, grâce à ce RFC 5810 (et quelques compagnons comme le RFC 5811 sur le protocole de transport), le travail est quasiment terminé et la partie Normalisation de Forces avec lui. Il reste à l'implémenter et à faire en sorte qu'il soit disponible dans les routeurs... Conformément au cahier des charges du RFC 3654, et au cadre général de Forces exposé par le RFC 3746, ce nouveau protocole permet la communication entre deux catégories d'élements qui composent un routeur, les CE (Control Element) et les FE (Forwarding Element). (La section 3 rappelle le vocabulaire de Forces.) Les premiers, les CE, font tourner des algorithmes compliqués comme OSPF ou BGP, ils prennent des décisions « de haut niveau » et les seconds, les FE, font le travail « bête » mais ultra-rapide, de commutation de chaque paquet. Aujourd'hui, dans un routeur (Forces dit NE, pour Network Element, et pas routeur) haut de gamme, le CE est typiquement un processeur standard, avec un système d'exploitation (parfois un Unix),le FE est un ASIC aux capacités bien plus limitées mais aux performances fantastiques. Comme le protocole de communication entre le CE et le FE est privé, pas question de faire tourner du logiciel libre sur le CE, pas question d'acheter le processeur à un vendeur et les ASIC à un autre. C'est ce problème que Forces veut résoudre. Dans Forces, la relation entre les CE et les FE est simple : le CE est le maître et le FE l'esclave. Les informations nécessaires au FE sont regroupées dans des LFB (Logical Function Block) dont la description est faite en XML (cf. RFC 5812). Le protocole lui-même n'utilise pas XML. Le protocole ne spécifie que la communication entre FE et CE, pas celles qui pourraient exister entre FE ou bien entre CE, ni celle qui relie les CE à leur gérant (l'interface d'administration du routeur). (La section 4 rappelle le cadre général de Forces, exposé dans le RFC 3746.) Le protocole Forces est également responsable de l'établissement et de la terminaison des associations entre un routeur (NE) et des CE ou FE (section 4.4). Une fois l'association faite, le CE envoie des ordres au FE, ordres exprimés avec le protocole Forces, et encapsulés dans un protocole de transport, le TLM (Transport Layer Mapping) qui fait l'objet d'un RFC séparé (RFC 5811). La section 4.3.1 du RFC détaille la question de l'atomicité des requêtes Forces. Le protocole permet des requêtes atomiques (toutes sont exécutées, ou bien aucune ne l'est, section 4.3.1.1.1) mais aussi des requêtes exécutées séquentiellement jusqu'au premier échec (section 4.3.1.1.3) ou encore des requêtes exécutées même si la précédente était un échec (section 4.3.1.1.2). Mieux, Forces permet des transactions ACID (section 4.3.1.2). L'encodage des paquets sur le câble fait l'objet de la section 6. Tous les paquets ont un en-tête commun, suivi d'un ou plusieurs TLV. Parmi les champs de l'en-tête commun, un numéro de version sur 4 bits (actuellement 1), le type du message, sur 8 bits (les différents types sont décrits en section 7 et le tableau complet est dans l'annexe A.1) et les adresses (nommées ID) de l'expéditeur et du destinataire. Ces ID, ces adresses, sont codés sur 32 bits et doivent être uniques à l'intérieur du routeur (mais pas forcément pour tout l'Internet). Rappelez-vous qu'un des buts de Forces est de pouvoir gérer des équipements très complexes, où CE et FE ne sont pas forcément dans la même boîte. À noter que les adresses des CE et des FE sont séparées (les premières commencent toujours par 00 et les secondes par 01). Une fois passé l'en-tête commun, viennent les TLV, décrits dans la section
[FRnOG] RE: [FRnOG] Troll (un peu en avance) sur la symétrie d'Internet ?
Tous les réseaux qui doivent être accessible à tous les utilisateurs Par contre, les 6 millions de sourds et malentendants en France, ils l'écoutent comment sa vidéo ? L'accessibilité n'est apparemment pas le fort de l'Arcep ... Cdlt Ludovic LACOSTE -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Pierre Col Envoyé : jeudi 18 mars 2010 21:56 À : frnog@frnog.org Objet : [FRnOG] Troll (un peu en avance) sur la symétrie d'Internet ? Le troll du vendredi est un peu en avance, car je persiste à ne pas être d'accord avec le président de l'ARCEP, et je le dis : à mon sens, sur Internet distinguer amont et aval n'a plus de sens ! http://bit.ly/videoARCEP -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] RE: [FRnOG] Troll (un peu en a vance) sur la symétrie d'Internet ?
Le site web de l'ARCEP est même désormais totalement inaccessible car en maintenance. Forcément je taquine : http://www.zdnet.fr/blogs/infra-net/le-site-internet-de-l-arcep-est-aux-abonnes-absents-39750263.htm C'est ballot :-) PS : j'irai soutenir Benjamin Bayart le 13 avril au colloque ARCEP que je couvrirai pour ZDNet... -- Pierre Ludovic LACOSTE a écrit : Tous les réseaux qui doivent être accessible à tous les utilisateurs Par contre, les 6 millions de sourds et malentendants en France, ils l'écoutent comment sa vidéo ? L'accessibilité n'est apparemment pas le fort de l'Arcep ... Cdlt Ludovic LACOSTE -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Pierre Col Envoyé : jeudi 18 mars 2010 21:56 À : frnog@frnog.org Objet : [FRnOG] Troll (un peu en avance) sur la symétrie d'Internet ? Le troll du vendredi est un peu en avance, car je persiste à ne pas être d'accord avec le président de l'ARCEP, et je le dis : à mon sens, sur Internet distinguer amont et aval n'a plus de sens ! http://bit.ly/videoARCEP -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pertes de packets pour joindre Free ?
On 19/03/2010 15:17, Alexandre Legrix wrote: Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? mtr --report 88.177.15.60 HOST: satanas Loss% Snt Last Avg Best Wrst StDev 1. eeegw 0.0%100.2 0.2 0.1 0.5 0.1 2. lo9-lns951-tip-voltaire.neri 0.0%10 41.8 42.3 41.0 48.8 2.3 3. gi1-15-121-nb-voltaire-1.ner 0.0%10 41.6 41.7 41.2 42.2 0.3 4. te2-1-92-nb-jeuneurs-2.nerim 0.0%10 237.6 63.2 41.5 237.6 61.5 5. ProXad-th1.FreeIX.net 0.0%10 41.6 43.9 41.0 52.9 4.3 6. 212.27.58.77 20.0%10 42.0 42.2 41.3 44.4 1.0 7. bzn-crs16-1-be1001.intf.rout 0.0%10 42.6 42.8 42.2 44.5 0.7 8. cbv-6k-1-po20.intf.routers.p 50.0%10 42.5 42.4 42.0 42.8 0.3 9. rouen-6k-1-v810.intf.routers 0.0%10 44.3 43.9 43.2 44.8 0.5 10. caen-6k-1-v800.intf.routers. 0.0%10 45.6 45.8 45.1 46.4 0.4 11. dea14-1.dslg.proxad.net 0.0%10 46.2 46.7 46.2 47.3 0.3 12. ??? 100.0100.0 0.0 0.0 0.0 0.0 13. dea14-1-88-177-15-60.fbx.pro 0.0%10 72.4 71.9 65.5 98.8 9.8 Cordialement. Il n'y a pas de pertes sur ta destination on dirait, juste sur les hops intermédiaire, qui peut être on autre chose à faire que de traiter l'ICMP... -- Simon. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pertes de packets pour joindre Free ?
Salut, On 19/03/2010 15:17, Alexandre Legrix wrote: Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? mtr --report 88.177.15.60 HOST: satanas Loss% Snt Last Avg Best Wrst StDev 1. eeegw 0.0%100.2 0.2 0.1 0.5 0.1 2. lo9-lns951-tip-voltaire.neri 0.0%10 41.8 42.3 41.0 48.8 2.3 3. gi1-15-121-nb-voltaire-1.ner 0.0%10 41.6 41.7 41.2 42.2 0.3 4. te2-1-92-nb-jeuneurs-2.nerim 0.0%10 237.6 63.2 41.5 237.6 61.5 5. ProXad-th1.FreeIX.net 0.0%10 41.6 43.9 41.0 52.9 4.3 6. 212.27.58.77 20.0%10 42.0 42.2 41.3 44.4 1.0 7. bzn-crs16-1-be1001.intf.rout 0.0%10 42.6 42.8 42.2 44.5 0.7 8. cbv-6k-1-po20.intf.routers.p 50.0%10 42.5 42.4 42.0 42.8 0.3 9. rouen-6k-1-v810.intf.routers 0.0%10 44.3 43.9 43.2 44.8 0.5 10. caen-6k-1-v800.intf.routers. 0.0%10 45.6 45.8 45.1 46.4 0.4 11. dea14-1.dslg.proxad.net 0.0%10 46.2 46.7 46.2 47.3 0.3 12. ??? 100.0100.0 0.0 0.0 0.0 0.0 13. dea14-1-88-177-15-60.fbx.pro 0.0%10 72.4 71.9 65.5 98.8 9.8 Cordialement. Du rate-limit des familles ? Arthur. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Pertes de packets pour joindre Free ?
Alexandre Legrix a écrit : Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? Oui et ce depuis la nuit du 18 au 19 avec un arrêt complet des services chez moi ! Je n'ai eu de nouveau la connexion que hier tard dans la soirée mais toujours pas d'accès à mes mails via imap free (sans aucun rapport avec leur réseau) ! -- -- NetBSD: 26 ans d'experience feront toujours la difference. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pertes de packets pour joindre Free ?
2010/3/19 Alexandre Legrix alexandre.leg...@euro-web.fr Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? Statistiques Ping pour 81.93.250.111: Paquets : envoyés = 19, reçus = 15, perdus = 4 (perte 21%), Durée approximative des boucles en millisecondes : Minimum = 161ms, Maximum = 169ms, Moyenne = 165ms Depuis une FB à Lyon, 20% de pertes vers euro-web.fr au passage, tu pointes une IP avec un reverse fbx.pro quelqu'un a des info sur ça ? c'est un peu HS, mais je n'ai jamais vu d'offres PRO chez iliad, hormis si c'est des tests avec la branche télécom italia rachetée en même temps qu'Alice.
Re: [FRnOG] Pertes de packets pour joindre Free ?
On 19/03/2010 15:30, Julien Richer wrote: 2010/3/19 Alexandre Legrix alexandre.leg...@euro-web.fr mailto:alexandre.leg...@euro-web.fr Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? Statistiques Ping pour 81.93.250.111 http://81.93.250.111: Paquets : envoyés = 19, reçus = 15, perdus = 4 (perte 21%), Durée approximative des boucles en millisecondes : Minimum = 161ms, Maximum = 169ms, Moyenne = 165ms Depuis une FB à Lyon, 20% de pertes vers euro-web.fr http://euro-web.fr au passage, tu pointes une IP avec un reverse fbx.pro http://fbx.pro quelqu'un a des info sur ça ? c'est un peu HS, mais je n'ai jamais vu d'offres PRO chez iliad, hormis si c'est des tests avec la branche télécom italia rachetée en même temps qu'Alice. $ host 88.177.15.60 60.15.177.88.in-addr.arpa domain name pointer dea14-1-88-177-15-60.fbx.proxad.net. Proxad, ca a toujours été Pro, non ? :)
Re: [FRnOG] Pertes de packets pour joindre Free ?
Re Statistiques Ping pour 81.93.250.111: Paquets : envoyés = 19, reçus = 15, perdus = 4 (perte 21%), Durée approximative des boucles en millisecondes : Minimum = 161ms, Maximum = 169ms, Moyenne = 165ms Depuis une FB à Lyon, 20% de pertes vers euro-web.fr Julien par ou passes tu afin de joindre Euro Web ? Sinon le fbx.pro c'est parceque le proxad.net a été tronqué :)) -- Alexandre Legrix Administrateur Système Euro Web Tel : 01-75-43-75-75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pertes de packets pour joindre Free ?
Le 19 mars 2010 15:35, Alexandre Legrix alexandre.leg...@euro-web.fr a écrit : Re Statistiques Ping pour 81.93.250.111: Paquets : envoyés = 19, reçus = 15, perdus = 4 (perte 21%), Durée approximative des boucles en millisecondes : Minimum = 161ms, Maximum = 169ms, Moyenne = 165ms Depuis une FB à Lyon, 20% de pertes vers euro-web.fr Julien par ou passes tu afin de joindre Euro Web ? Sinon le fbx.pro c'est parceque le proxad.net a été tronqué :)) en effet, pas l'habitude des reverse tronqués sorry ^^ sinon le chemin depuis lyon en IPv4 : Détermination de l'itinéraire vers euro-web.fr [81.93.250.111] avec un maximum de 30 sauts : 1 1 ms1 ms1 ms 192.168.0.1 221 ms20 ms20 ms 88.160.234.254 3 * 21 ms21 ms 213.228.9.126 4 * 21 ms20 ms lyon-crs16-1-be1000.intf.routers.proxad.net[212.27.59.129] 527 ms27 ms27 ms th2-crs16-1-be2001.intf.routers.proxad.net[212.27.59.29] 6 * 162 ms 162 ms cbv-6k-1-po21.intf.routers.proxad.net[212.27.58.2] 7 167 ms 166 ms 167 ms gc-pni-cbv.routers.proxad.net[212.27.38.226] 8 166 ms 166 ms * EURO-WEB-SARL.Po1-425.ar3.CDG2.gblx.net[64.212.98.162] 9 165 ms 165 ms 168 ms eqx-6k1.euroweb-network.com [78.41.236.18] 10 167 ms 167 ms 165 ms ix2-gw1-6k.euroweb-network.com[81.93.243.186] 11 168 ms 166 ms 167 ms srv4.netavous.net [81.93.250.111] Itinéraire déterminé.
Re: [FRnOG] Pertes de packets pour joindre Free ?
Bonjour, Statistiques Ping pour 81.93.250.111: Paquets : envoyés = 39, reçus = 39, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 27ms, Maximum = 63ms, Moyenne = 34ms* vers le même serveur (pour avoir les même référence) depuis une freebox a Clermont-Ferrand Cordialement -- Stéphane CREMEL Le 19 mars 2010 15:30, Julien Richer jul...@ywigo.fr a écrit : 2010/3/19 Alexandre Legrix alexandre.leg...@euro-web.fr Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? Statistiques Ping pour 81.93.250.111: Paquets : envoyés = 19, reçus = 15, perdus = 4 (perte 21%), Durée approximative des boucles en millisecondes : Minimum = 161ms, Maximum = 169ms, Moyenne = 165ms Depuis une FB à Lyon, 20% de pertes vers euro-web.fr au passage, tu pointes une IP avec un reverse fbx.pro quelqu'un a des info sur ça ? c'est un peu HS, mais je n'ai jamais vu d'offres PRO chez iliad, hormis si c'est des tests avec la branche télécom italia rachetée en même temps qu'Alice.
Re: [FRnOG] Pertes de packets pour joindre Free ?
GreG a écrit : Gros soucis pour moi aussi . Ping à plus de 160ms sur plusieurs fbx vers Dedibox ou OVH . traceroute to 88.191.88.14 (88.191.88.14), 30 hops max, 40 byte packets 1 192.168.3.250 (192.168.3.250) 1.981 ms 2.375 ms 2.829 ms 2 78.230.117.254 (78.230.117.254) 23.407 ms 23.860 ms 25.317 ms 3 caen-3k-1-a5.routers.proxad.net (213.228.11.126) 26.151 ms 26.609 ms 27.570 ms 4 rouen-6k-1-v800.intf.routers.proxad.net (212.27.50.53) 30.035 ms 30.989 ms 31.447 ms 5 * * * 6 bzn-crs16-1-be1002.intf.routers.proxad.net (212.27.50.189) 36.657 ms 25.398 ms 24.939 ms 7 dedibox-2-p.intf.routers.proxad.net (212.27.50.162) 161.252 ms * * 8 88.191.2.49 (88.191.2.49) 163.486 ms 164.689 ms 165.148 ms 9 emma.gergosnet.com (88.191.88.14) 165.976 ms 167.182 ms 167.516 ms GreG [bsdoui...@baseii ~]$ traceroute 88.191.88.14 traceroute to 88.191.88.14 (88.191.88.14), 64 hops max, 52 byte packets 1 192.168.0.16 (192.168.0.16) 0.102 ms 0.056 ms 0.053 ms 2 82.233.221.254 (82.233.221.254) 19.672 ms 19.632 ms 20.708 ms 3 caen-3k-1-a5.routers.proxad.net (213.228.11.126) 18.727 ms 20.375 ms 18.9 66 ms 4 rouen-6k-1-v800.intf.routers.proxad.net (212.27.50.53) 22.414 ms 21.133 ms 22.404 ms 5 * * * 6 bzn-crs16-1-be1002.intf.routers.proxad.net (212.27.50.189) 24.190 ms 22.357 ms 22.149 ms 7 * dedibox-2-p.intf.routers.proxad.net (212.27.50.162) 160.170 ms 185.487 ms 8 88.191.2.49 (88.191.2.49) 156.924 ms 159.649 ms 158.885 ms 9 emma.gergosnet.com (88.191.88.14) 157.219 ms 157.914 ms 159.382 ms C'est drôle je pars de Caen université et pourtant je suis plus rapide en ping ! -- -- NetBSD: 26 ans d'experience feront toujours la difference. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pertes de packets pour joindre Free ?
Le 19/03/2010 15:27, fbsdouille a écrit : Alexandre Legrix a écrit : Bonjour. Vous aussi vous constatez que le reseau Free/Proxad présente quelques soucis ? Oui et ce depuis la nuit du 18 au 19 avec un arrêt complet des services chez moi ! Je n'ai eu de nouveau la connexion que hier tard dans la soirée mais toujours pas d'accès à mes mails via imap free (sans aucun rapport avec leur réseau) ! Gros soucis pour moi aussi . Ping à plus de 160ms sur plusieurs fbx vers Dedibox ou OVH . traceroute to 88.191.88.14 (88.191.88.14), 30 hops max, 40 byte packets 1 192.168.3.250 (192.168.3.250) 1.981 ms 2.375 ms 2.829 ms 2 78.230.117.254 (78.230.117.254) 23.407 ms 23.860 ms 25.317 ms 3 caen-3k-1-a5.routers.proxad.net (213.228.11.126) 26.151 ms 26.609 ms 27.570 ms 4 rouen-6k-1-v800.intf.routers.proxad.net (212.27.50.53) 30.035 ms 30.989 ms 31.447 ms 5 * * * 6 bzn-crs16-1-be1002.intf.routers.proxad.net (212.27.50.189) 36.657 ms 25.398 ms 24.939 ms 7 dedibox-2-p.intf.routers.proxad.net (212.27.50.162) 161.252 ms * * 8 88.191.2.49 (88.191.2.49) 163.486 ms 164.689 ms 165.148 ms 9 emma.gergosnet.com (88.191.88.14) 165.976 ms 167.182 ms 167.516 ms GreG --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Troll (un peu en ava nce) sur la symétrie d'Internet ?
- Xavier Beaudouin k...@oav.net a écrit : Le troll du vendredi est un peu en avance, car je persiste à ne pas être d'accord avec le président de l'ARCEP, et je le dis : à mon sens, sur Internet distinguer amont et aval n'a plus de sens ! http://bit.ly/videoARCEP +1 Distinguer un amont et un aval, un producteur et un consommateur n'a jamais eu de sens selon le concept de l'internet: ce n'est qu'un réseau décentralisé de réseaux divers et épars. A ce titre, les relations entre les actifs terminaux sont horizontales et non verticales. Techniquement, rien (en dehors des contraintes quantitatives) ne devrait empêcher M. Michu (qui a quelques connaissances en informatique) de monter un service visible du reste du réseau. Selon mon humble avis, discuter concrètement de la Net-neutrality, ce n'est pas seulement s'arrêter aux problèmes rencontrés dans le Core Network. Il ne faudrait pas oublier ceux qui existent dans la partie Edge. Quelques exemples pour vous donner des idées: 1. Rien n'a été entrepris vis à vis du fléau des IPs dynamiques. 2. Le régulateur français n'a pris aucune mesure pour encourager l'élargissement de la bande passante montante pour les liaisons des particuliers (toutes technologies cuivre et radio confondues) lorsque le contexte technique le permet alors que des normes et protocoles ont été mises au point depuis quelques années (ADSL2+ annexe M et HSUPA par exemple). L'arrivée de la Fibre Optique semble débloquer partiellement ce problème d'asymétricité des services imposée au commun des mortels. -- Geoffroy GRAMAIZE --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Troll (un peu en avance) sur la s ymétrie d'Internet ?
Vendredi Bougon sans Troll / Techniquement, rien (en dehors des contraintes quantitatives) ne devrait empêcher M. Michu (qui a quelques connaissances en informatique) de monter un service visible du reste du réseau. C'est un concept que les politiciens ne comprennent pas, tout citoyen peut être distributeur de contenu, et le prix de la distribution est faible car l'internet est un milieu de forte compétition. C'est l'effet blog ou wikipedia - ça devrait pourtant facile a réaliser ! Le problème a' mon sens est que la seule distribution reconnue publiquement depuis les machines des internautes est souvent seulement assimilée a des activités illégales. C'est pour cela que les distributeurs spécialisés dans les produits facilement digitalisables, sont anxieux de perdre leur contrôle de la distribution, afin de garder leur influence sur les créateurs, qui leur permet de taxer les consommateurs et de dégager des marges importantes. IMHO, les FAI et les industrie de distributions, qui se nomment parfois créative pour cacher leur vrai nature, sont juste deux distributeurs, l'un a haute marge et spécialisé, l'autre a faible marge et générique. Certaines de ces industrie, la presse par exemple, réalise la nature du changement et réagisse, peut-etre, mieux que d'autres Selon mon humble avis, discuter concrètement de la Net-neutrality, ce n'est pas seulement s'arrêter aux problèmes rencontrés dans le Core Network. Il ne faudrait pas oublier ceux qui existent dans la partie Edge. Quelques exemples pour vous donner des idées: Mon problème est que les lois ne facilitent pas la compétitions, qui existe toujours sur le net, mais aide les monopoles car : - le lobby est toujours fait par des gros, et une fois les lois en place, les révisions se succèdent toujours (voire extension de la durée des copyright) - les lois augmente la barre d'entree dans un marché - les lois ont souvent des effets de bords que personne ne peux prevoir (DMCA a de bon exemples..) Donc les gens poussant pour la neutralité du net, sont en train, a mon humble avis, de se tirer dans les pieds. Quand la taille et capacité des réseaux se stabiliseront - c'est a dire quand le net aura passe sont enfance actuelle de croissance quasi exponentielle - le besoin pour le DPI et autre mesure de contrôle du trafic passeront. C'est comme si on avait demandé des loi contre l'utilisation des proxy HTTP a l'époque modem et que mal écrite, ces lois nous empêchaient maintenant d'utiliser des reverse proxies pour les sites web ... 1. Rien n'a été entrepris vis à vis du fléau des IPs dynamiques. Ce fléaux n'est que temporaire, IPv6 le résoudra, ou Carrier NAT le remplacera. 2. Le régulateur français n'a pris aucune mesure pour encourager l'élargissement de la bande passante montante pour les liaisons des particuliers (toutes technologies cuivre et radio confondues) lorsque le contexte technique le permet alors que des normes et protocoles ont été mises au point depuis quelques années (ADSL2+ annexe M et HSUPA par exemple). On est juste en train de voir Annexe A arriver en Angleterre chez BT, Annexe M est seulement offert par les LLU. La France n'est pas en retard, donc je ne vois aucune raisons pressentes pour le gouvernement Français de légiférer alors qu'au moins un opérateur a une position forte en faveur du déploiement de ces nouvelles technologies. L'arrivée de la Fibre Optique semble débloquer partiellement ce problème d'asymétricité des services imposée au commun des mortels. Et cela va changer _totallement_ l'internet, tout comme l'ADSL a change l'internet du modem; Est-il prudent de légiférer un internet que nous ne connaissons pas encore ? Incantation magique - qui ne marche jamais - pour garder les trolls dans leurs caves / Bon week-end, Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Nouveau troll : qui doit payer ?
http://www.zdnet.fr/blogs/infra-net/neutralite-du-net-quid-des-equilibres-economiques-entre-grands-acteurs-39750238.htm Bon week-end ! -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nouveau troll : qui doit payer ?
On Fri, Mar 19, 2010 at 06:47:12PM +0100, Pierre Col wrote: http://www.zdnet.fr/blogs/infra-net/neutralite-du-net-quid-des-equilibres-economiques-entre-grands-acteurs-39750238.htm Bon week-end ! je répondrai au président d'UFC que choisir, que dans un supermarché toutes les choses consomés sont facturées par le supermarché. c'est comme si on demandait au supermarché (^H^H^H Opérateur) d'augmenter l'espace de vente pour permettre à un grossiste (^H^H^H CDN) de vendre en direct ses produits sans payer pour l'espace et l'électricité et sans pour autant augmenter les revenus des producteurs/agriculteurs (^H^H^H Artistes) ni baisser les prix pour les consomateurs. A+ -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: Troll (un peu en avance) sur la symétrie d'Internet ?
Bonsoir, Pierre Col a écrit : J'ai expliqué à cette personne que j'étais plus taquin que méchant et lui ai glissé cet avis : Exigez de votre hébergeur (un hébergeur n'est pas une SSII, c'est un métier différent, et vous devriez avoir accès direct à l'hébergeur sans qu'il vous soit masqué par la SSII...) qu'il fasse les maintenances la nuit entre 2 et 4 h du matin. C'est ce que font les vrais hébergeurs. Donc les vrais hébergeurs travaillent 14h par semaine. Il doit bien tourner leur réseau !!! Heureusement on est vendredi ! Cordialement, Christophe Baegert --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Re: Troll (un peu en avance) sur la symétrie d'Internet ?
On Fri, 19 Mar 2010 19:43:06 +0100, Christophe Baegert c.baegert-lis...@lixium.fr said: Donc les vrais hébergeurs travaillent 14h par semaine. Il doit bien tourner leur réseau !!! La diference jusqu'a 35 heures ils la passent sur FRnOG :) -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nouveau troll : qui doit payer ?
Le vendredi 19 mars 2010 à 19:16 +0100, Frédéric Gander a écrit : je répondrai au président d'UFC que choisir, que dans un supermarché toutes les choses consomés sont facturées par le supermarché. c'est comme si on demandait au supermarché (^H^H^H Opérateur) d'augmenter l'espace de vente pour permettre à un grossiste (^H^H^H CDN) de vendre en direct ses produits sans payer pour l'espace et l'électricité et sans pour autant augmenter les revenus des producteurs/agriculteurs (^H^H^H Artistes) ni baisser les prix pour les consomateurs. Sous-entendrais tu que le supermarché vend les marchandises des grossistes sans se faire de marge au passage ? Et n'aurait donc aucun intérêt à grossir ? C'est amusant, comme idée, généralement les grossistes (et détaillants) se plaignent des chaines de grande distribution, qui imposent leur prix d'achat... :-) -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nouveau troll : qui doit payer ?
On Fri, 19 Mar 2010 19:16:24 +0100, Frédéric Gander fgan...@corp.free.fr said: c'est comme si on demandait au supermarché (^H^H^H Opérateur) d'augmenter l'espace de vente pour permettre à un grossiste (^H^H^H CDN) de vendre en direct ses produits sans payer pour l'espace et l'électricité et sans pour autant augmenter les revenus des producteurs/agriculteurs (^H^H^H Artistes) ni baisser les prix pour les consomateurs. D'un autre point de vue, si le CDN etait vraiment mechant, comme lui il ne revent pas du transit/connectivite IP (il est end-user), il pouvait dire aux ISPs recalcitrants AVFF, on droppe vos routes/on vous null-route (la neutralite ca les arrange en fonction du fric qu'elle rapporte). Ca donnerait quoi chez Centrappel avec plein d'appels Au secours YouMotion/DailyTube marche pas !. Pire encore, de les router en statique vers une page style Vous etes chez un ISP qui n'a pas acces aux services de ___. Faut arreter les analogies foireuses. Pour l'instant l'utilisateur paye un bundle de services qui comprend parmi autres choses acces internet. Je vois pas pourquoi les CDN doivent aussi payer les FAI. Pourquoi pas les FAI qui payent les CDN pour acceder a leur contenu ? Sinon, ca coute combien le Gbps de paid peering chez Free ? Toujours plus cher que le transit (le meme que Free achete) ? -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nouveau troll : qui doit payer ?
Le 19/03/2010 21:49, Radu-Adrian Feurdean a écrit : Faut arreter les analogies foireuses. Pour l'instant l'utilisateur paye un bundle de services qui comprend parmi autres choses acces internet. Je vois pas pourquoi les CDN doivent aussi payer les FAI. Pourquoi pas les FAI qui payent les CDN pour acceder a leur contenu ? mais-oui-mais-tu-comprends-eux-y-doivent-financer-un-réseau-qui-coute-cher-a-faire-évoluer-et-a-entretenir-alors-que-le-cdn-lui-son-réseau-y-coute-rien :) (si je fais un rapide résumé dans les grandes lignes hein) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nouveau troll : qui doit payer ?
Frédéric, Le 19/03/10 19:16, Frédéric Gander a écrit : c'est comme si on demandait au supermarché (^H^H^H Opérateur) d'augmenter l'espace de vente pour permettre à un grossiste (^H^H^H CDN) de vendre en direct ses produits sans payer pour l'espace et l'électricité et sans pour autant augmenter les revenus des producteurs/agriculteurs (^H^H^H Artistes) ni baisser les prix pour les consomateurs. C'est vrai, et si on poursuit cette logique, on se rends compte que les FAI ne sont que des intermédiaires inutiles et obsolètes, et que le gros méchant CDN peut juste les foutre dehors pour vendre en direct. Mais au fait, c'est pas ce que Google commence aux USA ? Moi je crois que si le modèle économique de base des FAI revenait à une certaine sanité, c'est à dire vendre juste un accès au prix qu'il coûte, ce serait quand même plus simple que de recopier bêtement un modèle compliqué, genre de demi-terminaisons... KISS, ça veut aussi dire pas prendre les gens _que_ pour des cons. Et Internet s'est quand même monté comme ça, preuve que ça marche, alors qu'il quasi-régresse ces temps ci, preuve que cretin-FAI versus vilain-CDN c'était juste une mauvaise idée. -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Nouveau troll : qui doit payer ?
Le 19/03/10 22:09, Spyou a écrit : Le 19/03/2010 21:49, Radu-Adrian Feurdean a écrit : Faut arreter les analogies foireuses. Pour l'instant l'utilisateur paye un bundle de services qui comprend parmi autres choses acces internet. Je vois pas pourquoi les CDN doivent aussi payer les FAI. Pourquoi pas les FAI qui payent les CDN pour acceder a leur contenu ? Je te retourne la question, que seraient les FAI sans les services des CDN ? Comment feraient ils sans Google pour orienter leurs eyeballs ? C'est Google qui devrait se faire payer par les FAI en fait, ils sont plus dépendants d'UNE boite que Google de tous les ISP... mais-oui-mais-tu-comprends-eux-y-doivent-financer-un-réseau-qui-coute-cher-a-faire-évoluer-et-a-entretenir-alors-que-le-cdn-lui-son-réseau-y-coute-rien :) (si je fais un rapide résumé dans les grandes lignes hein) Attends j'essaye aussi : oui-mais-ses-abonnés-le-payent-déjà-pour-ça (-il-devrait-pas-etre-trop-gourmand-non-plus-c-est-se-foutre-de-la-gueule-du-monde) j'ai bon ? Sinon, expliquer aux visiteurs avec un joli banner que si ça rame c'est parce que ton FAI fait pas ce pourquoi tu le paye, va voir celui là ou pas IPv6 - pas de chocolat, moi ça me plait bien comme idée -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
