Re: [FRnOG] ADSL contention
Mathieu wrote: j'avais déjà vu une modif de sfq qui fait ça: ça s'appelle esfq http://fatooh.org/esfq-2.6/ cependant, ça ne semble plus maintenu... En me baladant paisiblement dans le menuconfig du Kernel (oui, j'ai des activités bizarres) je suis tombé sur ça : CONFIG_NET_CLS_FLOW: If you say Y here, you will be able to classify packets based on a configurable combination of packet keys. This is mostly useful in combination with SFQ. Plus d'infos ici : http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commitdiff;h=e5dfb815181fcb186d6080ac3a091eadff2d98fe Add new flow classifier, which is meant to extend the SFQ hashing capabilities without hard-coding new hash functions and also allows deterministic mappings of keys to classes, replacing some out of tree iptables patches like IPCLASSIFY (maps IPs to classes), IPMARK (maps IPs to marks, with fw filters to classes), ... Ca semble pouvoir faire ce que je veux, mais la documentation semble... comment dire... inexistante... la discussion suivante donne des pistes : http://kerneltrap.org/mailarchive/linux-netdev/2008/1/31/667679 Quelqu'un a déjà utilisé ce truc ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Si, entre autres. Mais je ne comprends pas pourquoi, alors que le FAI en question est pourtant relié au GIX local, tout le trafic passe par la métropole. Étonnante optimisation. Je ne sais pas pour ton FAI, mais a une époque, AOL UK terminait ses client dialup au USA car cela leur permettait d'éviter certaines taxes nationales. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 1 décembre 2009 09:59, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Si, entre autres. Mais je ne comprends pas pourquoi, alors que le FAI en question est pourtant relié au GIX local, tout le trafic passe par la métropole. Étonnante optimisation. Je ne sais pas pour ton FAI, mais a une époque, AOL UK terminait ses client dialup au USA car cela leur permettait d'éviter certaines taxes nationales. AOL France aussi, au moins à l'époque du 56k. On sortait à l'est des US (j'ai plus la ville en tête) que du bonheur pour le ping. Chez AOL il devait y avoir plus de marketeux (pour envoyer les CDs 50heures gratuites !) que de tech. Leur disparition n'a du attrister personne. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Julien Richer wrote: Le 1 décembre 2009 09:59, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Si, entre autres. Mais je ne comprends pas pourquoi, alors que le FAI en question est pourtant relié au GIX local, tout le trafic passe par la métropole. Étonnante optimisation. Je ne sais pas pour ton FAI, mais a une époque, AOL UK terminait ses client dialup au USA car cela leur permettait d'éviter certaines taxes nationales. AOL France aussi, au moins à l'époque du 56k. On sortait à l'est des US (j'ai plus la ville en tête) que du bonheur pour le ping. Chez AOL il devait y avoir plus de marketeux (pour envoyer les CDs 50heures gratuites !) que de tech. Leur disparition n'a du attrister personne. Ah, ça explique la situation ultra-fréquente qu'on rencontrait à l'époque du 56K sur les serveurs de jeu : - Eh, mais j'ai un ping de merde ! - T'es chez AOL ? - Gagné :) -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Julien Richer a écrit : Tu préfèrerai pouvoir choisir parmi 2 options à la signature ? #Option1 : J'accepte que mes flux soient priorisés pour la bonne tenu du réseau. Exemple : Voip HTTP BT Certains jours, HTTP peut aller à 20Mb/s et BT à 1Mb/s, c'est normal. #Option 2 : Je préfère qu'on ne touche pas à mes flux, j'ai donc un débit global dépendant uniquement de la charge réseau Certains jours que se soit HTTP ou BT c'est seulement 2Mb/s, la navigation n'est pas fluide (fuck gmail) et la voip passe mal, mais c'est normal, le réseau est chargé et j'assume. Le problème de prioriser les flux dans le réseau de transit est qu'on en arrive parfois à des aberrations quand c'est réalisé par des branquignols. Je vais prendre pour exemple mon FAI perso ici, sur l'île de la Réunion où les accès « au reste du monde » sont une denrée rare. La journée, pas de problème pour faire passer toutes sortes de protocoles : http est réactif, je peux faire de la voip et du BT et si ma voip est hachée, je coupe BT, tout va bien. Là où ça se corse, c'est le soir et le week-end. Aux heures de pointe, impossible de faire autre chose que du http. Vous me direz, tant pis pour BT, à ces heures là, on veut que Mme Michu ait accès au web et que ce soit fluide. Soit. Mais là où ça devient grand-guignolesque, c'est que même SSH, je l'ai dans l'os. Il est tout simplement impossible que je me connecte à une autre machine en SSH, pourtant basée sur l'île et ne générant pas de trafic sortant (il y a un GIX local) (remarquez, c'est pareil pour une machine en métropole). En revanche, je peux aller sur dailytube et télécharger à 400kbps facile en http. La voip, c'est pareil, ça passe en dernier. Merci qui ? Merci mon FAI ! -- Erwann --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Hello, [...] Mais là où ça devient grand-guignolesque, c'est que même SSH, je l'ai dans l'os. Il est tout simplement impossible que je me connecte à une autre machine en SSH, pourtant basée sur l'île et ne générant pas de trafic sortant (il y a un GIX local) (remarquez, c'est pareil pour une machine en métropole). En revanche, je peux aller sur dailytube et télécharger à 400kbps facile en http. La voip, c'est pareil, ça passe en dernier. Merci qui ? Merci mon FAI ! C'est pas parce que ton FAI remonte tout le traffic en métropole, au hasard ? Alors qu'il pourrais terminer ses sessions L2TP a la réunion et faire un peering local pour pas faire du tromboning ? /Xavier--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
C'est pas parce que ton FAI remonte tout le traffic en métropole, au hasard ? Alors qu'il pourrais terminer ses sessions L2TP a la réunion et faire un peering local pour pas faire du tromboning ? Quand bien même ce serait le cas, ce n'est pas une excuse pour faire lagger du SSH (comprendre: ce n'est pas une excuse pour prioriser des flux). L'argument selon lequel les FAI priorisent les flux pour le bien du client tombe sur ce simple exemple: un FAI ne peut pas tout prévoir. Ce n'est pas son boulot de prévoir ce qui est bon pour le client ou pas. Ça, c'est le problème du client qui est branché au bout. Faire en sorte que les clients voraces ne plombent pas les autres, OK. Mais c'est tout. Parce que ces bêtises, on voit déjà où ça mène: à une aberration. Un protocole qui nécessite une très faible latence (SSH) pour le confort de l'utilisateur, se fait totalement plomber par une décision idiote. Et c'est une décision idiote, car elle a été prise par quelqu'un dont ce n'est pas le rôle de prendre ce genre de décisions. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Rémi Bouhl a écrit : Xavier Beaudouin a écrit : C'est pas parce que ton FAI remonte tout le traffic en métropole, au hasard ? Alors qu'il pourrais terminer ses sessions L2TP a la réunion et faire un peering local pour pas faire du tromboning ? Si, entre autres. Mais je ne comprends pas pourquoi, alors que le FAI en question est pourtant relié au GIX local, tout le trafic passe par la métropole. Étonnante optimisation. Quand bien même ce serait le cas, ce n'est pas une excuse pour faire lagger du SSH (comprendre: ce n'est pas une excuse pour prioriser des flux). Ceci est vrai également. Tant pis, je m'y fais aux 500ms de latence en temps normal. En revanche, même si des choix de priorisation de trafic doivent effectivement être fait, ils peuvent être faits avec intelligence, et pas à la machette. À propos, je fais comment pour connaître la politique de trafic avant de m'abonner ? Je vais voir les commerciaux du FAI et je leur demande si je pourrai faire du SSH aux heures de pointe ? J'imagine déjà leur tête. -- Erwann --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Michel, Lorsqu'un transit est réalisé en MPLS, les équipements LNS commutent en MPLS et ne vont pas observer ce qui se passe au-dessus. Seuls, les équipements PE responsables de la 1ère étiquette peuvent éventuellement atteindre l'IP client. A mon avis, le nombre de ces équiments ne doit pas être pléthoriques. Those guys can do MPLS and other decapsulation (I know as they are based near our offices and I have meet them). I have no idea about other vendors as I have no kit myself. http://www.syphan.com/ Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Dear Thomas, Lorsqu'un transit est ralis en MPLS, les quipements LNS commutent en MPLS et ne vont pas observer ce qui se passe au-dessus. Seuls, les quipements PE responsables de la 1re tiquette peuvent ventuellement atteindre l'IP client. A mon avis, le nombre de ces quiments ne doit pas tre plthoriques. Those guys can do MPLS and other decapsulation (I know as they are based near our offices and I have meet them). I have no idea about other vendors as I have no kit myself. http://www.syphan.com/ Thomas Sorry..., it was "In my view, on a transit network, the number of these LNS equipments should not be very excessive". Best regards, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Sorry..., it was In my view, on a transit network, the number of these LNS equipments should not be very excessive. Quand le réseau est grand, ces équipements les BRAS/LNS gèrent un bon nombre d'échanges mais tu vas quand même en avoir un bon nombre. Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
e-t172 a écrit : Rémi Bouhl wrote: Je schématise: on a un tuyau à 1 Gb/s, avec dessus 500 utilisateurs qui ont jusqu'à 20 Mb/s chacun. Tant que le tuyau n'est pas saturé, chacun peut utiliser le maximum de sa ligne. Dès l'instant où le tuyau commence à saturer (un peu avant, en fait, dès que la latence augmente de façon sensible), on garantit à chaque utilisateur 1Gb/500 = 2Mb/s. Ce qui signifie que ceux qui prennent 20Mb/s se feront légèrement diminuer le débit, afin de garantir un tuyau à 2Mb/s pour madame Michu. Et si tout le monde veut utiliser le tuyau à fond, alors on bride tout le monde à 2Mb/s. Autrement dit, faire passer en priorité les utilisateurs qui consomment peu, par rapport à ceux qui consomment beaucoup, afin de garantir une latence faible aux usages qui consomment peu et demandent une latence faible. Et si l'utilisateur veut faire du BT à fond _et_ jouer en ligne, le fait que BT rende son jeu injouable devient son problème à lui. Ça paraît plus simple de trier les paquets par utilisateur (donc par IP) plutôt que de faire du DPI, non? Ce n'est pas faisable, ça? Garantir la même latence et le même débit à chaque utilisateur, et le laisser se démerder avec, plutôt que de prioriser le trafic de type machin de l'utilisateur A au détriment du trafic truc de l'utilisateur B? En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Ainsi, la capacité est répartie de manière équitable entre les sources. D'ailleurs j'ai pour projet de patcher SFQ sous Linux parce que je vais bientôt me retrouver dans une situation dans laquelle je vais avoir besoin de faire ça sur une passerelle Linux pour un petit réseau (50+ hôtes). La solution parfaite serait un mélange des deux : d'abord on partage équitablement selon la source, PUIS en bonus, on priorise l'interactif par rapport au batch. j'avais déjà vu une modif de sfq qui fait ça: ça s'appelle esfq http://fatooh.org/esfq-2.6/ cependant, ça ne semble plus maintenu... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Exception des cas où nous avons de la P2PTV est elle ralentie comme le téléchargement de fichiers? D'ailleurs VUze offre cette possibilité de commencer à regarder un téléchargement en même temps qu'il se fait. Mais sommes nous alors dans du streaming en P2P? Le 26 novembre 2009 12:05, Thomas Mangin thomas.man...@exa-networks.co.uka écrit : C'est vrai mais 100 connexion a 10k ou une connexion a a service web sous haute disponibilité a 1000k c'est la même chose (le service web a moins d'overhead pour être exact :p) La vrai différence est que je suis devant la machine quand je veux me servir du web et je veux la page maintenant aussi vite que possible - j'attends la page. Quand je telecharge avec BT, je veux le contenu au plus vite mais c'est un téléchargement de fond, je veux toujours pouvoir surfer,lire mon mail correctement C'est pour ça que BT/Emule/etc sont les protocoles qui sont mis de cote par le DPI - car aucune personne saine d'esprit regarde sa fenêtre Vuze et la barre de progression aller de 1.04 % a 1.05% a 1.06% a . pendant 30 minutes :) Regards, Thomas Mangin Technical Director -- Exa Networks Limited - http://www.exa-networks.co.uk/ Company No. 04922037 - VAT no. 829 1565 09 27-29 Mill Field Road, BD16 1PY, UK Phone: +44 (0) 845 145 1234 - Fax: +44 (0) 1274 567646 On 26 Nov 2009, at 16:54, anthony Hémond wrote: Sur la question du P2P, j'ai un passage à vous faire lire extrait de déclaration d'une compagnie nord américaine sur le P2P: There are two ways that P2P file sharing applications unfairly use bandwidth compared to other non-P2P applications. First, a P2P application, rather than opening up only one stream or session, will open up 40 to 100 TCP sessions in an effort to transfer data as fast as possible using multiple sources and can therefore grab dozens to 100s times more bandwidth than a traditional single-stream application such as email or Internet banking applications (see the diagram below-EN PJ de ce courriel ). By initiating more and more P2P applications on powerful computers, the user will continue to expand the number of active streams eventually consuming all available bandwidth. To further compound the bandwidth demand, some users will employ multiple computers on the same Internet connection. Second, once all the available bandwidth is being consumed, the P2P applications will use a queuing technique for additional requests until more bandwidth becomes available. The P2P application queuing of multiple requests combined with inherent application persistence of P2P enable it to sustain a continuous maximum network traffic load, 24 hours a day, 7 days a week and 365 days a year, as long as there are queued requests. Commentaires et réactions? Le 26 novembre 2009 10:57, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Dans certains pays (UK et NL par exemple), les offres business DSL font mention de ce taux, avec differents prix en fonction du taux. Pour l'ADSL, au UK - c'est faisaient pas font. Les contrat BT n'y font plus reference depuis 2006. Mais comme BT forçait ses revendeur a indiquer cette contention avant, le principe est bien compris. Si bien compris que les lien P2P peuvent maintenant être acheté en 1:1 ou moins cher en 5:1 (vu qu'entre les échanges c'est maintenant du MPLS et plus de l'ATM) L'histoire de contention n'a en effet rien de technique. Ca c'est fait, pris en compte dans les prix, mais pas toujours (en France quasi-jamais) communique aux end-users. Je ne suis pas d'accord, c'est technique puisque c'est ce qui va servir au planning des capacité (etc.). En pratique, la contention pourrait etre plus haute ou basse en fonction des cycles de mise a jour. Mais finalement si un lien ne voient jamais de congestion a 50 pour 1, il y a peu de chance de voir une mise a jour de la connexion même si le service est vendu a 20 pour 1, mais cela ne gène aucun client. La regle a plus tendance a être je met a jour quand ma ligne commence a passer 70% en pointe. Thomas p2p.pdf
Re: [FRnOG] ADSL contention
Bonsoir Thomas, C'est vrai mais 100 connexion a 10k ou une connexion a a service web sous haute disponibilité a 1000k c'est la même chose (le service web a moins d'overhead pour être exact :p) Remonter dans les couches suppose que l'on a accès à l'IP. Or, il existe des tas de situations où cette vision simple n'est pas possible : - Réseaux à commutation tout-optique (OTN ou pas) - Concaténation virtuelle où les octets sont éparpillées dans différentes unités de protocole, sur différents chemins - Mise en tunnel de l'IP client - Pseudofil... Bien sûr, tout cela n'empêche pas de gamberger. Cordialement, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Exception des cas où nous avons de la P2PTV est elle ralentie comme le téléchargement de fichiers? D'ailleurs VUze offre cette possibilité de commencer à regarder un téléchargement en même temps qu'il se fait. Mais sommes nous alors dans du streaming en P2P? Dans le cas de streaming P2P tu as toujours besoin de seeders fourni par le fournisseur de service (pour assurer un démarrage rapide du film) Si j'avais a le faire, j'ajouterai une exception pour ces site et puis les contacterai pour du pay peering - oups :D Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
anthony Hémond wrote: Exception des cas où nous avons de la P2PTV est elle ralentie comme le téléchargement de fichiers? D'ailleurs VUze offre cette possibilité de commencer à regarder un téléchargement en même temps qu'il se fait. Mais sommes nous alors dans du streaming en P2P? Bonjour, Pour BT, quelques prototypes sont en cours d'implémentation... quelques labos travaillent dessus, l' irisa.fr (inria/cnrs rennes) notamment. (Je dois pouvoir retrouver les publis si besoin). Quand ( / si ) ce sera un peu plus finalisé, ça promet ... autant pour les users que les opérateurs :) Cdlt, -- Mathieu Goessens IT consultant. geb...@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Tue, Nov 24, 2009 at 05:18:46PM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: C'est vrai faire un virement banquaire c'est moins important que de telecharger un AVI^WISO de 700 Mb . L'http qui dure plus de qq seoncdes va donc être passé en priorité plus faible, comme bittorrent ? (et ce, meme si ça fait ramer tf1vision ou m6replay ?) J'etais sarcastique . Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Wed, Nov 25, 2009 at 09:48:23AM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: Le Tue, Nov 24, 2009 at 05:18:46PM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: C'est vrai faire un virement banquaire c'est moins important que de telecharger un AVI^WISO de 700 Mb . L'http qui dure plus de qq seoncdes va donc être passé en priorité plus faible, comme bittorrent ? (et ce, meme si ça fait ramer tf1vision ou m6replay ?) J'etais sarcastique . Et moi je posais une vraie question. Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux interactifs, pour lesquels une latence plus élevée dégrade le ressenti. Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application interactive, ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). Les application moins prioritaires seraient tous les transferts bulk, qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame) Donc, est ce que les solutions de DPI existantes/déployées font cette différentiation ? Ou alors on tire juste sur les protocoles p2p (bt, mule, ...), juste parceque ça, c'est forcément utilisé que par les vilains piratins qui volent dans le porte-monnaie d'Universal ? -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Wed, Nov 25, 2009 at 11:11:51AM +0100, Marien Lebreton [marien.lebre...@gmail.com] a écrit: [...] Avec le http pipelining (activé par défaut sous Opera et bientôt Firefox, et très sérieusement considéré chez MS pour IE8 mais finalement abandonné pour le moment car IIS4 5 ne supportent pas ou mal et ça aurait fait mauvais genre... mais on peut supposer que ça ne mettra pas des années à arriver), cette approche est probalement déjà obsolète. On parle de DPI. Donc les GET successifs, dans le même tuyau, ils sont capables de les différenciers d'un transfert bulk. (ou alors faut qu'ils changent de métier) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
On Wed, 25 Nov 2009 00:34:52 +0100, Bernard Dugas bernard.dugas.2...@is-production.com said: Là par contre, je crois que ça change : l'arrivée de la fibre, c'est justement la disparition de la contention. Je sais, je suis un peu en avance, comme d'habitude :-) Je prepare le pop-corn des maintenant. On va commencer avec episode 1 : 10 lignes 100 Mbps full, caqune essayant d'utiliser ses 100 Mbps en meme temps (c'etait sans contention, n'est pas? ). Mais la vraie révolution qui s'annonce, c'est vraiment la fin de la contention : dorénavant, il vaudra mieux investir dans l'augmentation de capacité que gérer de la pénurie de débit. Je commence a comprendre ton idee, mais je ne crois pas une seconde. Un exemple fait sur un coin de table, donc corrigez moi si erreur : dans le cas le pire où on utilise des switches 48 ports 1Gbps, avec une architecture adaptée, on peut commuter SANS CONTENTION 9 milliards de lignes 1Gbps avec 7 couches de switches, ce qui donne un coût de commutation mondiale sans contention de 140$ par ligne en comptant 20$/port. Oui, erreur. Le sans contention c'est seulement dans le backplane du switch, pas sur les up-links. Pour faire du sans contention sur l'uplink, il faut que sur les 48 ports, 43 sont user ports 1G, et les 5 restantes sont des uplinks 10G. Deja a 44 x 1G + 4 x 10G il y a un peu de contention (40:44 mais quand-meme). Parce-que avoir 24 ports user + 1 port-channel de 24 interfaces comme uplink, c'est un peu con et ca casse serieusement ton modele. Par sans contention, je veux dire que chaque ligne peut échanger 1Gbps full-duplex avec n'importe quelle autre ligne, sans déranger les autres. Evidamment, 47 lignes 1G ne peuvent echanger 1Gbps avec la 48eme (toujouts 1Gbps). Ils vont forcement se deranger. Un backplane non-bloquant (sans contention) n'a pas de probleme a commuter X Gbps en etree, assez longtemps qu'il peut les sortir sur autres X Gbps d'interfaces. Encore une fois, si ce n'est pas encore clair : le contept contention-free reste assez souvent dans le backplane du switch. En tout cas, c'est pas si evident que ca de l'implementer sur un vrai reseau. Cela s'améliore si on prend des concentration de ports plus importantes par switch ou des ports 10G puis 100G, mais les prix montent aussi :-) Vous avez bien lu, il s'agit bien de l'estimation grossière d'un seul réseau niveau 2 qui couvre la terre entière et toute sa population : je connais des problèmes d'adressage, de stabilité et de gestion qui le rendent impossible tel quel bien sûr, mais l'important est de voir que c'est d'une taille et d'un prix raisonnables ! C'est pourquoi je suis persuadé que, plutôt que de couper des cheveux en 4 pour rationner la bande passante en cherchant qui doit passer en premier, il vaudrait mieux travailler tous ensemble avec la perspective d'un réseau mondial sans contention, basé sur de la fibre et des switches simples, robustes et bon marchés. C'est du second degre ou quoi ? Non, cela c'est parce que la production est centralisée : si chaque foyer qui se chauffe au fuel ou au gaz, au lieu de les bruler bêtement, faisait de la cogénération électrique en utilisant la chaleur résultante, le problème ne se poserait pas. Bonjour, je cherche 2 Kg d'uranium 235 pour ma centrale electrique personelle. Et ça c'est parce que les lignes fibres à 1Gbps ne sont pas dispo dans les résidences secondaires pour les téléconférences 3D du lundi matin ! ... et la marmote fume du papier-alu. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Je suis d'accord, je passais les slides car autant que je sache le nouveau protocol BT utilise le même principe avec la latence (il y a eu du buffering - le lien est sature, et packet loss - le buffer est plein et perds des packets) comme moyen de detection (je n'ai pas encore lu les specs du protocole) Çà doit pas être tout a fait çà l'heuristique, parce que çà ne peut marcher que si les RX et TX queue font du tail dropping. Si tu as de la congestion la latence sera plus variable plus haute. Je n'ai pas vu de papier sur le proto, pas plus que le code alors je ne sais pas ce qu'ils font exactement. Le travail de l'IETF sur DCCP mérite également un coup d'œil (Ils ont carrément pris le point de vue : les protos existants sont trop mal foutus pour gérer la congestion proprement, on va en faire un qui va le faire nativement et proprement : http://www.ietf.org/rfc/rfc4336.txt). Les mécanismes proposés (enfin certains) peuvent être codé au niveau application. Merci du pointeur. je n'ai jamais regarde ce que SCTP avait en reserve pour ca non plus. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 25/11/2009 00:34, Bernard Dugas a écrit : Mais la vraie révolution qui s'annonce, c'est vraiment la fin de la contention : dorénavant, il vaudra mieux investir dans l'augmentation de capacité que gérer de la pénurie de débit. Un exemple fait sur un coin de table, donc corrigez moi si erreur : dans le cas le pire où on utilise des switches 48 ports 1Gbps, avec une architecture adaptée, on peut commuter SANS CONTENTION 9 milliards de lignes 1Gbps avec 7 couches de switches, ce qui donne un coût de commutation mondiale sans contention de 140$ par ligne en comptant 20$/port. Par sans contention, je veux dire que chaque ligne peut échanger 1Gbps full-duplex avec n'importe quelle autre ligne, sans déranger les autres. Tu peux reproduire ton schéma ? Je dois pas avoir le même coin de table. Avec un switch 9 milliards de ports, soit, mais avec 7 niveaux ? Si 48 gus sur le switch A veulent causer aux 48 gus du switch B, en traversant quelques couches de ton archi, tu fais comment ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
L'http qui dure plus de qq seoncdes va donc être passé en priorité plus faible, comme bittorrent ? (et ce, meme si ça fait ramer tf1vision ou m6replay ?) J'etais sarcastique . Hum moi aussi je suis sarcastique... Car M6 et TF1 ont explosé Wizzgo sous pretexte que le service étais concurent de leur soit disant services tf1vision et m6replay. L'été dernier j'étais en chine et... j'ai essayé m6replay, qui m'as gentillement dit vous n'etes pas en france, bla, bla Un coup de tunnel ipsec a réglé le problème... CQFD... Comme quoi le service que proposait Wizzgo avais au moins lui une utilité pas celui proposé. Xavier -- Association KAZAR - http://kazar.net/ Non profit hosting for anybody in France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Dominique Rousseau wrote: Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux interactifs, pour lesquels une latence plus élevée dégrade le ressenti. Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application interactive, ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). Les application moins prioritaires seraient tous les transferts bulk, qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame) C'est intéressant comme réflexion. C'est exactement le même principe que les schedulers CPU, qui sont capables d'estimer si un processus est de type interactif ou de type batch et priorise les tâches interactives (qui consomment peu mais qui ont besoin du CPU tout de suite) par rapport aux tâches batch (qui consomment le maximum pendant un certain temps). Je sais pas si y'a eu des recherches pour adapter ça au réseau : si un flux consomme peu, alors il est considéré interactif et ses paquets passeront avant ceux des flux qui consomment le maximum. En théorie, distinguer les deux est très simple : dans le cas de l'interactif c'est majoritairement constitué de petits paquets, dans le cas du batch c'est constitué uniquement de gros paquets (= MTU). En fait on peut même faire ça avec une box Linux et le traffic control assez simplement. On utilise une queuing discipline de type PRIO et on classifie les paquets taille MTU dans une première queue et les paquets taille = MTU dans une deuxième (bon, avec une marge pour le MTU). Le résultat c'est que les paquets MTU passent avant les autres, et comme ce sont généralement des paquets liés à des applications interactives, bingo. Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment. Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un y a déjà pensé avant ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
e-t172 wrote: Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment. Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un y a déjà pensé avant ? Après réflexion, je me rend compte que c'est exactement ce que fait SFQ (Stochastic Fair Queuing) sous Linux : il fait en sorte que chaque conversation ait une part égale de la capacité. Or, comme une conversation interactive débite peu, avec SFQ elle aura logiquement une priorité plus haute que celles qui consomment beaucoup. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Le Wed, 25 Nov 2009 11:15:51 +0100, Radu-Adrian Feurdean r...@ftml.net a écrit : Encore une fois, si ce n'est pas encore clair : le contept contention-free reste assez souvent dans le backplane du switch. En tout cas, c'est pas si evident que ca de l'implementer sur un vrai reseau. C'est un concept qui n'existe pas, le lockless ou le contention-free ;-) On aura tjs besoin de protéger des structures de données d'accès concurrent en lecture, en écriture selon le cas, niveau soft ou hard, peu importe. Les primitives de locking évoluent lentement et diminuent les lock contentions mais on ne les vire complétement jamais dans l'état actuel de l'art. C'est un peu comme le complete fair queuing, le mot 'complete' avec du 'fair queueing', çà va pas ensemble. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpkZZEJ2NBYY.pgp Description: PGP signature
Re: [FRnOG] ADSL contention
Bernard Dugas a écrit : Un exemple fait sur un coin de table, donc corrigez moi si erreur : dans le cas le pire où on utilise des switches 48 ports 1Gbps, avec une architecture adaptée, on peut commuter SANS CONTENTION 9 milliards de lignes 1Gbps avec 7 couches de switches, ce qui donne un coût de commutation mondiale sans contention de 140$ par ligne en comptant 20$/port. La seule théorie valide que j'ai trouvé, c'est de faire des triangles imbriqués les uns dans les autres, 16 downlink, 16 side link, et 16 uplinks. Dans ces conditions, on peut faire du 1Gbps non bloquant de n'importe quel point à n'importe quel point .. Sauf que la contention démarre au 4eme niveau de switchs (2x16Gbps ne suffisant pas a transporter les 4x16Gbps des users qui sont en dessous) Pour 9 milliards de prises, j'arrivais donc a 562.5 millions de switchs de premier niveau nécessaires, soit, pour faire un arbre complet, 29 couches de switchs donc un peu moins de 1,2 milliard de switchs, a 960$ le switch, ça fait 1080 milliards de $, soit 120$ la prise. Bernard, je veux bien voir aussi ton coin de table, si tu avais une idée de topologie plus intelligente qu'un arbre :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Et moi je posais une vraie question. Desole, je venais de me lever - encore un peu dans les choux :) Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux interactifs, pour lesquels une latence plus élevée dégrade le ressenti. C'est surement ce qui est fait (dans la limite de ce qui peut être différencié). Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application interactive, ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). On ne va pas commercer a prioriser en fonction de la destination.. HTTP c'est HTTP - banque ou jeu web 2.0 interractif Video Flash utilise souvent un port différent 1935? ca aide :) Les application moins prioritaires seraient tous les transferts bulk, qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame) Le DPI est souvent applique sur les liens de peering / transit. On va rire (ou pas) quand BT va commencer a prefer le traffic interne du FAI a du transit. Ca risque de causer des problemes de saturation des lien interne. Donc, est ce que les solutions de DPI existantes/déployées font cette différentiation ? AFAIK - non Regarde le code d'OpenDPI si tu veux avoir une idee de comment la detection est faite. http://www.opendpi.org/ Ou alors on tire juste sur les protocoles p2p (bt, mule, ...), juste parceque ça, c'est forcément utilisé que par les vilains piratins qui volent dans le porte-monnaie d'Universal :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Moralité: pour ne pas se faire pourrir les flux P2P, fragmentez les données afin de diminuer le MTU ;+) Non les kit DPI font du packet reassembly et autant que je sache ca ne changerait rien. (Mais je me trompe peut-etre). Blague à part, est-ce que ça ne serait pas envisageable (et éthiquement plus propre) de garantir un débit à chaque utilisateur en cas de congestion du réseau? Il est pas très optimal ton algo :D Tu veux encore plus de plaintes sur cette liste que les FAI sont méchants :D Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Rémi Bouhl wrote: Je schématise: on a un tuyau à 1 Gb/s, avec dessus 500 utilisateurs qui ont jusqu'à 20 Mb/s chacun. Tant que le tuyau n'est pas saturé, chacun peut utiliser le maximum de sa ligne. Dès l'instant où le tuyau commence à saturer (un peu avant, en fait, dès que la latence augmente de façon sensible), on garantit à chaque utilisateur 1Gb/500 = 2Mb/s. Ce qui signifie que ceux qui prennent 20Mb/s se feront légèrement diminuer le débit, afin de garantir un tuyau à 2Mb/s pour madame Michu. Et si tout le monde veut utiliser le tuyau à fond, alors on bride tout le monde à 2Mb/s. Autrement dit, faire passer en priorité les utilisateurs qui consomment peu, par rapport à ceux qui consomment beaucoup, afin de garantir une latence faible aux usages qui consomment peu et demandent une latence faible. Et si l'utilisateur veut faire du BT à fond _et_ jouer en ligne, le fait que BT rende son jeu injouable devient son problème à lui. Ça paraît plus simple de trier les paquets par utilisateur (donc par IP) plutôt que de faire du DPI, non? Ce n'est pas faisable, ça? Garantir la même latence et le même débit à chaque utilisateur, et le laisser se démerder avec, plutôt que de prioriser le trafic de type machin de l'utilisateur A au détriment du trafic truc de l'utilisateur B? En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Ainsi, la capacité est répartie de manière équitable entre les sources. D'ailleurs j'ai pour projet de patcher SFQ sous Linux parce que je vais bientôt me retrouver dans une situation dans laquelle je vais avoir besoin de faire ça sur une passerelle Linux pour un petit réseau (50+ hôtes). La solution parfaite serait un mélange des deux : d'abord on partage équitablement selon la source, PUIS en bonus, on priorise l'interactif par rapport au batch. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Le DPI est souvent applique sur les liens de peering / transit. On va rire (ou pas) quand BT va commencer a prefer le traffic interne du FAI a du transit. Ca risque de causer des problemes de saturation des lien interne. Pour etre plus comlet: Certain LNS/BRAS comme le redback ont des cartes DPI optionnelles, donc certain FAI font du DPI a l'edge. Mais comme le DPI c'est cher, le plus souvent sur les gros réseau c'est fait sur la sortie (moins de kit). Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Bon, il ne me reste plus qu'a change mon port BT pour 80 (TCP) et 53 ou mieux 5060 (UDP) :p Le QOS mal fait peut aider les DDOS en favorisant le traffic de DDOS par rapport au traffic normal. Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Thomas Mangin wrote: En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Bon, il ne me reste plus qu'a change mon port BT pour 80 (TCP) et 53 ou mieux 5060 (UDP) :p Le QOS mal fait peut aider les DDOS en favorisant le traffic de DDOS par rapport au traffic normal. Je parle de l'adresse IP source, pas du port source. Autrement dit, si 1.2.3.4 et 4.3.2.1 utilisent le lien, chacun obtient une part équitable. Peu importe ce qu'ils font avec ou les ports qu'ils utilisent, qu'ils fassent du DDoS ou du BT, on s'en fout, ils font la queue comme tout le monde. Si je veux faire de la VoIP en même temps, je passe d'abord parce que *JE* consomme moins que les téléchargeurs fous. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
RE: [FRnOG] ADSL contention
Question non technique mais de droit: comment concilier la prioritisation avec le principe de la neutralité du net réaffirmé hier pas les députés européens lors de l'adoption du paquet télécoms? GRM -Original Message- From: owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] On Behalf Of Dominique Rousseau Sent: mercredi 25 novembre 2009 11:03 To: frnog@FRnOG.org Subject: Re: [FRnOG] ADSL contention Le Wed, Nov 25, 2009 at 09:48:23AM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: Le Tue, Nov 24, 2009 at 05:18:46PM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: C'est vrai faire un virement banquaire c'est moins important que de telecharger un AVI^WISO de 700 Mb . L'http qui dure plus de qq seoncdes va donc être passé en priorité plus faible, comme bittorrent ? (et ce, meme si ça fait ramer tf1vision ou m6replay ?) J'etais sarcastique . Et moi je posais une vraie question. Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux interactifs, pour lesquels une latence plus élevée dégrade le ressenti. Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application interactive, ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). Les application moins prioritaires seraient tous les transferts bulk, qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame) Donc, est ce que les solutions de DPI existantes/déployées font cette différentiation ? Ou alors on tire juste sur les protocoles p2p (bt, mule, ...), juste parceque ça, c'est forcément utilisé que par les vilains piratins qui volent dans le porte-monnaie d'Universal ? -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Bonjour, Radu-Adrian Feurdean wrote: Je prepare le pop-corn des maintenant. Merci ! Salé, s'il te plait :-) On va commencer avec episode 1 : 10 lignes 100 Mbps full, caqune essayant d'utiliser ses 100 Mbps en meme temps (c'etait sans contention, n'est pas? ). Tout à fait,mais je te propose de partir sur des ports 1Gbps, c'est pas plus cher et plus facile pour calculer... Donc pour expliciter, si tu as PT ports totaux entre lesquels tu ne veux pas de contention et des switches de N ports, quelle architecture mettre en place pour n'avoir aucune contention entre les PT ports ? Et c'est plus amusant si PT N :-) Ensuite, si PT=9G ports, on a couvert chaque habitant de la planète et on n'a plus besoin de uplink... pour un certain temps. Je propose de lancer un concours sur la liste ? Mais la vraie révolution qui s'annonce, c'est vraiment la fin de la contention : dorénavant, il vaudra mieux investir dans l'augmentation de capacité que gérer de la pénurie de débit. Je commence a comprendre ton idee, mais je ne crois pas une seconde. En l'occurence, il ne s'agit pas de croire, juste de réfléchir. Parce-que avoir 24 ports user + 1 port-channel de 24 interfaces comme uplink, c'est un peu con et ca casse serieusement ton modele. Disons que c'est la brique d'un lego dont on dispose facilement. On peut faire mieux mais c'est plus cher :-) Ensuite on fera varier N le nombre de ports du switch, si ça aide. Encore une fois, si ce n'est pas encore clair : le contept contention-free reste assez souvent dans le backplane du switch. En tout cas, c'est pas si evident que ca de l'implementer sur un vrai reseau. Mais est-ce possible ? d'où ce concours :-) C'est pourquoi je suis persuadé que, plutôt que de couper des cheveux en 4 pour rationner la bande passante en cherchant qui doit passer en premier, il vaudrait mieux travailler tous ensemble avec la perspective d'un réseau mondial sans contention, basé sur de la fibre et des switches simples, robustes et bon marchés. C'est du second degre ou quoi ? C'est pas en cachant un objectif qu'on y arrive, même si on n'y est pas encore... Quand on me dit que la contention est impossible à éviter, j'ai l'intuition que c'est faux, et même que les moyens techniques et financiers existent aujourd'hui, même si l'architecture globale doit être étudiée avec attention. A bientôt, -- __Bernard DUGAS __ | IS Production s.a. Innovative Solutions | --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Bonjour, Simon Morvan wrote: Tu peux reproduire ton schéma ? Je crois que je vais laisser proposer des solutions, il doit y en avoir d'autres que celle que j'ai vue, autant ne pas vous influencer :-) Je dois pas avoir le même coin de table. C'est l'inconvénient des tables rondes. Avec un switch 9 milliards de ports, soit, mais avec 7 niveaux ? Si 48 gus sur le switch A veulent causer aux 48 gus du switch B, en traversant quelques couches de ton archi, tu fais comment ? Effectivement, je pense que je ne peux pas utiliser tous les ports pour les lignes utilisateurs :-) Bonne réflexion... -- __Bernard DUGAS __ | IS Production s.a. Innovative Solutions | --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Spyou wrote: La seule théorie valide que j'ai trouvé, c'est de faire des triangles imbriqués les uns dans les autres, 16 downlink, 16 side link, et 16 uplinks. Dans ces conditions, on peut faire du 1Gbps non bloquant de n'importe quel point à n'importe quel point .. Sauf que la contention démarre au 4eme niveau de switchs (2x16Gbps ne suffisant pas a transporter les 4x16Gbps des users qui sont en dessous) Pour 9 milliards de prises, j'arrivais donc a 562.5 millions de switchs de premier niveau nécessaires, soit, pour faire un arbre complet, 29 couches de switchs donc un peu moins de 1,2 milliard de switchs, a 960$ le switch, ça fait 1080 milliards de $, soit 120$ la prise. Bernard, je veux bien voir aussi ton coin de table, si tu avais une idée de topologie plus intelligente qu'un arbre :) Merci pour cette réponse ! Le suspens continue ;-) Pourquoi s'arrêter au tiers des ports ? A bientôt, -- __Bernard DUGAS __ | IS Production s.a. Innovative Solutions | | Technoparc Pays de Gex bernard.dugas.2...@is-production.com | | 01633 ST GENIS POUILLY CEDEX - FRANCE - Mob.: +33 615 333 770 | | PLEASE NOTE NEW EMAIL !ATTENTION NOUVEL EMAIL ! | |__| --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
On FrNOG $people wrote: (plein de trucs...) Ce qui est amusant dans ce thread, c'est qu'on n'a pas vu des masses de staff technique d'un quelconque FAI un tant soit peu significatif y participer... -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Radu-Adrian Feurdean wrote: Pour relier X noeuds a Amsterdam (ou pire, Olso) avec Y autres a Auckland ou Sidney (en meme temps que AMS a NYC et NYC a SYD), ca va faire de la fibre a tirer :) On ne peut pas tuer tous les trolls en même temps : commençons par la capacité de commutation :-) On a pas reussi a faire ca (100% contention-free) avec des canaux voix a 64k, alors avec du 100M ou 1G ... C'est sûr qu'un commutateur voix à 20$ le port 1Gbps, ça ne court pas les rues. Ce qui illustre la force d'Ethernet : faisons simple pour multiplier. Continuons. A bientôt, -- __Bernard DUGAS __ | IS Production s.a. Innovative Solutions | --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Ce qui est amusant dans ce thread, c'est qu'on n'a pas vu des masses de staff technique d'un quelconque FAI un tant soit peu significatif y participer... Tu viens de me vexer Clément :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Pas assez pour demander pay peering :) Thomas --- from my iPhone On 25 Nov 2009, at 15:52, Clement Cavadore clem...@cavadore.net wrote: On Wed, 2009-11-25 at 15:39 +, Thomas Mangin wrote: Ce qui est amusant dans ce thread, c'est qu'on n'a pas vu des masses de staff technique d'un quelconque FAI un tant soit peu significatif y participer... Tu viens de me vexer Clément :D Rajoute donc Francais dans ma phrase, alors, si ca peut te faire plaisir :-). Tu as combien de eyeball derrière ton réseau, Thomas ? -- Clément --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Wed, 25 Nov 2009 14:18:51 +0100, Bernard Dugas bernard.dugas.2...@is-production.com a écrit : Je propose de lancer un concours sur la liste ? On gagne quoi ? :) a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpmt4m6gUAox.pgp Description: PGP signature
Re: [FRnOG] ADSL contention
On Wed, 25 Nov 2009 21:17:40 +0100, Jerome Benoit jerome.ben...@grenouille.com said: Le Wed, 25 Nov 2009 14:18:51 +0100, Bernard Dugas bernard.dugas.2...@is-production.com a écrit : Je propose de lancer un concours sur la liste ? On gagne quoi ? :) LA biere de plus au beer event du FRNOG :) -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Wed, 25 Nov 2009 13:16:07 +0100, e-t172 e-t...@akegroup.org a écrit : La solution parfaite serait un mélange des deux : d'abord on partage équitablement selon la source, PUIS en bonus, on priorise l'interactif par rapport au batch. Tu peux faire çà avec IMQ (qui rajoute la possibilité de faire de l'ingress queueing au noyau Linux) : http://www.linuximq.net a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpQo7TQvviNJ.pgp Description: PGP signature
Re: [FRnOG] ADSL contention
Le Wed, 25 Nov 2009 21:25:23 +0100, Radu-Adrian Feurdean r...@ftml.net a écrit : LA biere de plus au beer event du FRNOG :) Hum, pas assez bandant : un accès gratuit à vie au backbone Next-Generation ? ;-) a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgp94wB1Cf5Iv.pgp Description: PGP signature
Re: [FRnOG] ADSL contention
Tu commences avec des mots qui sont totelement inconnus aux Joe Users (*) francais. Je suis surpris. Ici BT l'avait clairement dans leur contrat a 20:1 (la meme bande passante est vendu 20 fois). Ce n'est plus le cas et BT parle maintenant de l'expérience fourni mais le fait est que rien n'a change et la notion est bien comprise. Pire encore, dans les departement IT des PME, on connait que rarement le concept de contention. Ca c'est plus grave ... Les entreprises doivent savoir qu'elle ont un service non garantie et sans SLA. Pour baisser les couts BT offre maintenant des P2P avec une contention de 5:1 Pour 21CN (leur resau tout IP) c'est a dire deux lignes spécialisés jusqu'aux l'échanges les plus proches (1:1), et une connexion MPLS entre les deux (a 1:1 ou 5:1). Le prix des deux queues est fixe, le prix de la bande passante est fonction de la distance dans le réseau BT ... Ce qui est plutot logique. Je suppose que ce concept (qui se pratique malgres tout aussi en France) doit avoir une implication negative niveau marketing. C'est impossible de vendre de l'ADSL a bas prix autrement. Il faudra noter que la contention peut être présenté sans jamais avoir d'impact sur le service. Le problème des FAI c'est Bittorrent qui utilise très agressivement la connexion. Le nouveau protocol Bitrrent sur UDP (uTP) a l'air intéressant car il semble que si il détecte de la congestion entre deux point il ralenti le transfert tout seul. En cela c'est très proche de cette idée (que je trouve bonne - mais qui n'a pas son équivalent en IPv6 - pas de place libre dans le header v6) http://www.peering-forum.eu/assets/Presentations/briscoebtqosinterconnect.pdf En gros, cela dit : un lien pas utilise au maximum est une perte. Un lien trop utilise est un probleme. Fournissons a l'edge une maniere de detecter la congestion dans le réseau en taggant les packets passant par des lien avec congestion afin d'avoir le meilleur rendement possible. (Les slides ne sont pas tres clair) (*) Joe User etant evidamment l'epoux de mme Michu. Moi je pensais plutot que c'etait le neuveu Americain de Madame Michu. La genealogie des Michu est complique :D Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Hello, Le 24 nov. 2009 à 09:01, Thomas Mangin a écrit : [...] C'est impossible de vendre de l'ADSL a bas prix autrement. Il faudra noter que la contention peut être présenté sans jamais avoir d'impact sur le service. Le problème des FAI c'est Bittorrent qui utilise très agressivement la connexion. Le nouveau protocol Bitrrent sur UDP (uTP) a l'air intéressant car il semble que si il détecte de la congestion entre deux point il ralenti le transfert tout seul. En cela c'est très proche de cette idée (que je trouve bonne - mais qui n'a pas son équivalent en IPv6 - pas de place libre dans le header v6) http://www.peering-forum.eu/assets/Presentations/briscoebtqosinterconnect.pdf En gros, cela dit : un lien pas utilise au maximum est une perte. Un lien trop utilise est un probleme. Fournissons a l'edge une maniere de detecter la congestion dans le réseau en taggant les packets passant par des lien avec congestion afin d'avoir le meilleur rendement possible. (Les slides ne sont pas tres clair) Oula... Si je doutes pas que les systèmes ouverts (le vrai avec de la bière en carburant pour coder) auront le support du re-ecn dans très peut de temps (comme ça avais déjà été fait avec l'ecn), je doute que les OS avec des fenêtres colorées l'aurons et encore moins que le park actuel et futur auront cette option rapidement. Quid des Fenêtres avec l'eXPérience dedans, ou celle de la Vie ou encore celles numéro 7... ? L'idée est bonne mais quand on a vu le délais pour l'ecn soit a peut près déployé partout My 0,02€ Xavier--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Tue, Nov 24, 2009 at 08:01:01AM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: Je suppose que ce concept (qui se pratique malgres tout aussi en France) doit avoir une implication negative niveau marketing. C'est impossible de vendre de l'ADSL a bas prix autrement. Il faudra noter que la contention peut être présenté sans jamais avoir d'impact sur le service. Le problème des FAI c'est Bittorrent qui utilise très agressivement la connexion. Pas d'accord. Les FAIs-qui-veulent-la-cremiere-avec-le-beurre c'est avec les Toimotion ou autres qu'ils passent en mode « toi y'en a nous acheter du paid-peering si toi vouloir que ton service marche ». -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 24 novembre 2009 09:01, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : ... (Les slides ne sont pas tres clair) Non, effectivement, mais sur le principe (et si j'ai bien compris) ça permet de régler pas mal de problèmes d'un coup. Traduction pour les noobs en technique comme moi, avec ça, on peut maxer les ports de switch sans risquer de perte, c'est bien ça ? Question : est ce que c'est fonctionel et déployable à court terme sur des OS libres à jour ? Question subsidiaire (en reply au mail suivant de Xavier), est ce qu'une box sous un *nix libre qui gère le signalement de la congestion en amont d'un système à fenêtres permet d'implémenter ce contrôle de congestion ? (*) Joe User etant evidamment l'epoux de mme Michu. Moi je pensais plutot que c'etait le neuveu Americain de Madame Michu. La genealogie des Michu est complique :D Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme Nicolle --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Oula... Si je doutes pas que les systèmes ouverts (le vrai avec de la bière en carburant pour coder) auront le support du re-ecn dans très peut de temps (comme ça avais déjà été fait avec l'ecn), je doute que les OS avec des fenêtres colorées l'aurons et encore moins que le park actuel et futur auront cette option rapidement. Quid des Fenêtres avec l'eXPérience dedans, ou celle de la Vie ou encore celles numéro 7... ? Je suis d'accord, je passais les slides car autant que je sache le nouveau protocol BT utilise le même principe avec la latence (il y a eu du buffering - le lien est sature, et packet loss - le buffer est plein et perds des packets) comme moyen de detection (je n'ai pas encore lu les specs du protocole) La grosse différence étant qu'il détecte une congestion existante alors que re-ecn va pouvoir tagger juste avant la congestion. L'idée est bonne mais quand on a vu le délais pour l'ecn soit a peut près déployé partout On risque de voir un nombre de firewall qui vont détecter ces packets comme dangereux et les bloquer (qui a dit PIX :p). L'edge peut être le DSLAM/MSAN permettant aux FAI de le déployer de manière transparente pour leurs clients. Ceci dit, je suis comme toi pas très optimiste Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Dom, Le 24 novembre 2009 09:18, Dominique Rousseau d.rouss...@nnx.com a écrit : Pas d'accord. Les FAIs-qui-veulent-la-cremiere-avec-le-beurre c'est avec les Toimotion ou autres qu'ils passent en mode « toi y'en a nous acheter du paid-peering si toi vouloir que ton service marche ». Un mulet non capé ça fait freezer n'importe quelle ADSL, avec 25% de perte et l'impression de pousser une brouette... Et ça en interne sur le réseau du FAI, pas besoin d'en sortir pour constater le problème ! Tu te souviens pas quand tu jouais à War3 en téléchargement des vidéos ? ;) -- Jérôme Nicolle --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Salut, Le 24 nov. 09 à 09:12, Xavier Beaudouin a écrit : L'idée est bonne mais quand on a vu le délais pour l'ecn soit a peut près déployé partout Un vieux serpent de mer de chez Adobe fait récemment surface et va peut être finir par pas mal bouleverser la nature du trafic http://newteevee.com/2009/11/21/get-ready-for-flash-player-10-1-to-stream-p2p-video-to-millions-swap-files-bittorrent-style/ Adobe planche dessus depuis 2007 donc le jour où ça sera officiellement dans la nature ça pourra aller très vite... Si un jour ça sort. Antoine--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 24 novembre 2009 09:25, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : On risque de voir un nombre de firewall qui vont détecter ces packets comme dangereux et les bloquer (qui a dit PIX :p). L'edge peut être le DSLAM/MSAN permettant aux FAI de le déployer de manière transparente pour leurs clients. Ceci dit, je suis comme toi pas très optimiste Pour de la gestion de congestion, tant que ça ne regarde pas le contenu, c'est à la limite une simple nécessité pour assurer le transport des données. Mais c'est quand même de l'intelligence dans le réseau, non ? -- Jérôme Nicolle --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 24 nov. 2009 à 09:25, Thomas Mangin a écrit : Oula... Si je doutes pas que les systèmes ouverts (le vrai avec de la bière en carburant pour coder) auront le support du re-ecn dans très peut de temps (comme ça avais déjà été fait avec l'ecn), je doute que les OS avec des fenêtres colorées l'aurons et encore moins que le park actuel et futur auront cette option rapidement. Quid des Fenêtres avec l'eXPérience dedans, ou celle de la Vie ou encore celles numéro 7... ? Je suis d'accord, je passais les slides car autant que je sache le nouveau protocol BT utilise le même principe avec la latence (il y a eu du buffering - le lien est sature, et packet loss - le buffer est plein et perds des packets) comme moyen de detection (je n'ai pas encore lu les specs du protocole) La grosse différence étant qu'il détecte une congestion existante alors que re-ecn va pouvoir tagger juste avant la congestion. :) L'idée est bonne mais quand on a vu le délais pour l'ecn soit a peut près déployé partout On risque de voir un nombre de firewall qui vont détecter ces packets comme dangereux et les bloquer (qui a dit PIX :p). Je dis pas PIX, mais je dis les firewall pas mis a jour parce oul ça pourrais déconner ou zut j'ai pas d'argent pour le contrat de maintenance de mon super firewall corporate(r)(c)(tm) qu'il faillais mettre toussa... Exemple concret : tcp windows scaling et certains gens que je connais qui ont peur de mettre ça en place parce qu'ils ont eu des problèmes... Bref :) Xavier--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
(Les slides ne sont pas tres clair) Non, effectivement, mais sur le principe (et si j'ai bien compris) ça permet de régler pas mal de problèmes d'un coup. Traduction pour les noobs en technique comme moi, avec ça, on peut maxer les ports de switch sans risquer de perte, c'est bien ça ? Question : est ce que c'est fonctionel et déployable à court terme sur des OS libres à jour ? Question subsidiaire (en reply au mail suivant de Xavier), est ce qu'une box sous un *nix libre qui gère le signalement de la congestion en amont d'un système à fenêtres permet d'implémenter ce contrôle de congestion ? Sur le principe, chaque routeur/switch qui detecte un lien trop utilise marque le packet passant a travers avec un evil bit. Quand le packet arrive a l'edge, le kit se dit ... ou la la, je demande du plein de mauvais traffic ... parlons un peu moins vite a cette destination qui passe a travers un internet avec congestion. Tout le monde parle un peu moins vite et le problème de congestion disparait laissant le lien utilise au mieux. Cela pourrait aussi être utilise quand tu génères vraiment trop de méchant traffic, le MSAN dit: j'en ai assez de toi t'es trop vile, HOP je te te met au coin avec du QOS si dans 10 minutes tu es devenu raisonnable je suspendrai la punition. Ca serai plus juste que du DPI :p Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Un mulet non capé ça fait freezer n'importe quelle ADSL, avec 25% de perte et l'impression de pousser une brouette... Et ça en interne sur le réseau du FAI, pas besoin d'en sortir pour constater le problème ! Tu te souviens pas quand tu jouais à War3 en téléchargement des vidéos ? ;) Mais la mule qui a lance le mulet electronique va appeler le service technique du FAI et les insulter que ce sont de voleurs et qu'il n'a pas le service qu'il a paye très cher. Que le web ne marche pas, que PING montre un problème chez les FAI car tous les routeurs du FAI ont un problème - le FAI est vraiment inconpetant ... Et tout ce qui ce suit :D Avec ca, la mule est ralenti, et tout marche bien tout seul. En theorie ... Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 24 novembre 2009 09:48, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Sur le principe, chaque routeur/switch qui detecte un lien trop utilise marque le packet passant a travers avec un evil bit. Ah c'est le Evil Bit ? Mince, je fais comment avec mon admin OpenBSD parano qui s'en sert en interne ? -- Jérôme Nicolle --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
J'ai reçu ce mail off-list comme je ne sais pas si c'était voulu ou pas, voici la réponse (sans références a l'expéditeur). si je comprends bien, on prefere mettre des sous dans du soft compliqué qui peut ne pas marcher que dans l'installation d'un matériel actif suffisamment surdimensionné pour prendre la charge sans encombre dans les 3 prochaines années ? Non je ne pense pas tu comprennes bien - désolé :D - car : - Cette fonctionnalité existe seulement sur papier actuellement. C'est de la recherche. - Avec un rollout progressif, tu installes la fonctionnalité quand tu replaces tes équipements, il n'y a pas de sur-cout. - Les couts des FAI c'est plus complexe que ca en a l'air - Installer du DPI pour limiter Bittorrent sur un reseau a un retour sur investissement d'entre 1 et 3 mois (en ne limitant que bittorrent que pour les 5% des plus gros utilisateur seulement). (en gros 10% des utilisateurs génère 90% du traffic d'un FAI - et ce sont 100% des clients qui font chier la hotline) je connais un FAI qui au bout des 30 jours de crédit pour l'achat du kit avait déjà l'argent en économie sur le budget prévu pour le kit et _personne_ n'avait remarque l'installation. Du kit actif capable de faire du 10GB line rate DPI, il y a en a déjà partout. Rien ne change. Certain FAI le dise clairement, d'autre pas http://www.ispreview.co.uk/story/2009/11/02/entanet-uk-imposes-new-traffic-management-upon-broadband-isps.html (ce n'est pas celui a qui je faisait référence) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Désolé pour la question idiote, mais c'est légal, ça (De faire du DPI et de la QoS en fonction de l'utilisation)? Oui. Et sans DPI la plupart des reseaux des gros tomberaient. BT tuerait le réseau (sans rire). Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
On Tue, 2009-11-24 at 10:52 +, Thomas Mangin wrote: Désolé pour la question idiote, mais c'est légal, ça (De faire du DPI et de la QoS en fonction de l'utilisation)? Oui. Et sans DPI la plupart des reseaux des gros tomberaient. BT tuerait le réseau (sans rire). ils sont donc pas si gros que ca, et les milliards de CA (et de benefs) ne sont pas réinvestis proprement dans l'accroissement des capacités de leur réseau. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
le truc c'est que les opérateurs sont soumis a obligation de résultat, donc utiliser un DPI pour réduire le débit ne doit etre qu'une mesure temporaire en attendant la fin des travaux pour augmenter le débit disponible sur le réseau... Avant tout, je vais rappeler que je parle du marche ANGLAIS. Je n'ai pas de connaissance du marche français. De plus je ne pense que nous sommes dans des zones de flou légal (car cela n'a jamais ete teste devant les cours). Enfin, le but du DPI est bien de garantir une qualité de service en appliquant une prioritisation du traffic. La méthode choisi peut-etre _par_exemple_ de donner a BT, qui mange tout ce qu'il peut, la bande passante restante une fois que tout le reste est passe, mais d'autre options sont possibles. Le DPI permet de ne pas saturer les liens (pas de packet loss, bonne qualite de video, etc.) tout en permettant d'utiliser au maximum les lignes, en etant sur que les protocoles interactifs aient un basse latency. Les courbes de traffic des FAI ca resemble a ca (avec des pointes en soiree pour les particuliers, et vers 13:00 pour les boites) http://www.ams-ix.net/statistics/ Maintenant imaginez le blanc du graph comme etant ce qui est la capacité libre (simplification). Si vous laissez BT prendre ce qu'il veut la courbe reste la meme mes les piques vont être plus élevé (ie demandant surement des mises a jour très chère de liens/fibres/routeurs/etc.), le DPI permet de repartir ce traffic sur les heures plus creuses - permettant une meilleure utilisation des ressources. Le truc est de perdre un packet par ici et par la pour jouer sur le TCP windows scaling sur les connexion TCP de BT .. http://en.wikipedia.org/wiki/TCP_window_scale_option http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Window_scaling Le nouveau protocol BT, fait la même chose mais lui même en UDP. Merci pour moi (je n'ai pas de kit DPI :p) exemple qui n'est pas nouveau (2007): http://www.generation-nt.com/free-fai-ufc-condamnation-isere-abonne-grenoble-actualite-47182.html La c'est totalement diffèrent on parle de problèmes grave sur le service. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
L'analyse est pertinente, mais si l'opérateur vendait que ce qu'il ne peut fournir, il ne pourrait donc plus le vendre 30 euros par mois... après tout le monde est libre de prendre un accès ADSL 20 Mb à 30 euros TTC par mois, ou une SDSL à 8 Mb à 150 euros HT. Mais si je prends un ADSL 20 Mb, et que je m'aperçois que le 20 Méga tourne à 20 Méga quand je fais du HTTP, et 10 Méga quand je fais du torrent, y'a baleine sous gravier (anguille sous roche) et ce n'est pas normal. Comment le FAI gère de son côté, je m'en fiche et je ne veux pas le savoir: moi j'ai un bout de tuyau qui se comporte différemment en fonction de ce que je mets dedans, alors qu'il est censé être indifférent au contenu. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le 24/11/09, Julien Richerjul...@ywigo.fr a écrit : 2009/11/24 Rémi Bouhl remibo...@gmail.com: L'analyse est pertinente, mais si l'opérateur vendait que ce qu'il ne peut fournir, il ne pourrait donc plus le vendre 30 euros par mois... après tout le monde est libre de prendre un accès ADSL 20 Mb à 30 euros TTC par mois, ou une SDSL à 8 Mb à 150 euros HT. Mais si je prends un ADSL 20 Mb, et que je m'aperçois que le 20 Méga tourne à 20 Méga quand je fais du HTTP, et 10 Méga quand je fais du torrent, y'a baleine sous gravier (anguille sous roche) et ce n'est pas normal. Comment le FAI gère de son côté, je m'en fiche et je ne veux pas le savoir: moi j'ai un bout de tuyau qui se comporte différemment en fonction de ce que je mets dedans, alors qu'il est censé être indifférent au contenu. Tu préfèrerai pouvoir choisir parmi 2 options à la signature ? #Option1 : J'accepte que mes flux soient priorisés pour la bonne tenu du réseau. Exemple : Voip HTTP BT Certains jours, HTTP peut aller à 20Mb/s et BT à 1Mb/s, c'est normal. #Option 2 : Je préfère qu'on ne touche pas à mes flux, j'ai donc un débit global dépendant uniquement de la charge réseau Certains jours que se soit HTTP ou BT c'est seulement 2Mb/s, la navigation n'est pas fluide (fuck gmail) et la voip passe mal, mais c'est normal, le réseau est chargé et j'assume. Je prends l'option 2. Tout simplement parce que ce n'est pas le boulot de l'opérateur que de trier entre HTTP et BT. Qu'une QoS s'exerce afin de garantir à chaque utilisateur les mêmes conditions d'accès, pas de problème: On est 1000 à vouloir utiliser 10 Méga sur un lien qui balance 1 Giga, ça fait 1 Méga par utilisateur, et chacun se démerde pour choisir ce qu'il fait passer dedans. Ça c'est logique. Mais je ne vois pas en quoi le trafic HTTP du client A devrait être prioritaire sur le trafic BT du client B. Ils payent tous les deux le même prix pour le même accès, il n'y a aucune raison d'en pénaliser (même légèrement) un pour favoriser l'autre, parce qu'ils utilisent différemment leur ligne. Si le tuyau est trop petit, il l'est pour tout le monde. Tu as raison, les FAI vendait un service avec contention alors quand il n'y avait pas de contenu c'était facile. Puis la video est arrive - et BT. Le marche change et l'internet devient en quelques années, le monde de la video sur demande et de GROS téléchargements. Les FAI se retrouvent avec une situation difficile. Ben oui, force est de constater que ce qui était vrai il y a quelques années (tout le monde ne fait pas la même chose en même temps) n'est plus vrai, bien au contraire: ça serait plutôt Le soir et la nuit, on fait tous du BT en même temps. Partant de là, c'est assez curieux que les FAI s'accrochent à un ancien modèle et tente de contraindre les usages à rentrer dans le modèle (en pénalisant les nouveaux usages) au lieu d'adapter leur modèle (donc leurs offres et leurs tarifs) aux nouveaux usages. Bien sûr qu'il y a des problèmes de congestion sur d'autres réseaux (téléphone, courrier) à des périodes de pointe. Mais France Telecom ne trie pas les appels en fonction de leur contenu, pas plus que La Poste ne trie les courriers en fonction de leur contenu. Il n'y a que les FAI qui transgressent cette règle de neutralité, sans doute parce que ça ne se voit pas. Je vais me repeter, je parle des FAI ANGLAIS JE NE PARLES PAS DES FAI FRANCAIS. JE NE SAIS PAS CE QU'ILS FONT (meme si il y a des chances que certaines pratiques passent outre manche) Et non, il n'y a pas anguille sous roche. Il y a application des termes et condition du service vendu. Par exemple: http://www.enta.net/Policies/Acceptable_Use_Policy/ Section Excessive bandwidth or Disk Utilisation Leur clients ont signées ces termes - le prix est lie a ces termes. En droit anglo-saxon c'est peut-être valable, mais en France, si une clause d'un contrat est contraire à la législation, c'est la clause qui saute (voire, tout le contrat). Ceci dit, je suis d'accord avec cette idée selon laquelle, si le client achète n'importe quoi (ou plus précisément, achète de l'Internet frelaté), autant lui vendre n'importe quoi. Par contre, dans ta section Excessive bandwidth or Disk Utilisation je ne vois rien qui discrimine un usage par rapport à un autre. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Avant tout, pour l'ambiance : http://open.spotify.com/track/651vRxPMVxJGlZQquNoXe6 Qu'une QoS s'exerce afin de garantir à chaque utilisateur les mêmes conditions d'accès, pas de problème: On est 1000 à vouloir utiliser 10 Méga sur un lien qui balance 1 Giga, ça fait 1 Méga par utilisateur, et chacun se démerde pour choisir ce qu'il fait passer dedans. Ça c'est logique. C'est ce qui peut se fait avec BT. tous les utilisateurs se partagent la bande passante libre. Desole BT est le protocole qui prend le plus sur le reseau et c'est le dernier servi. Mais les FAI ne sont pas si mauvais Emule and CO au aussi le droit au même traitement. Mais je ne vois pas en quoi le trafic HTTP du client A devrait être prioritaire sur le trafic BT du client B. Car Monsieur Michu il veut pouvoir faire ses courses sur Auchan.com et que si le traffic BT n'est pas limite BT sera 99.99% des liens et Auchan.com (a qui il ne faut pas grand chose) ne marchera plus. En un mot, tu ne me crois pas quand je te dis que BT veut TOUTE la bande passante TOUT le temps - donc je ne vais plus essayer de te convaincre. Ils payent tous les deux le même prix pour le même accès, il n'y a aucune raison d'en pénaliser (même légèrement) un pour favoriser l'autre, parce qu'ils utilisent différemment leur ligne. Si le tuyau est trop petit, il l'est pour tout le monde. C'est vrai faire un virement banquaire c'est moins important que de telecharger un AVI^WISO de 700 Mb . plus vrai, bien au contraire: ça serait plutôt Le soir et la nuit, on fait tous du BT en même temps. Le soir et la nuit ... de nos jours c'est 24/7/365 ? C'est vrai que sans avoir access aux infos netflow des routeurs c'est pas facile de savoir. http://torrentfreak.com/bittorrent-the-one-third-of-all-internet-traffic-myth/ http://torrentfreak.com/bittorrent-still-king-of-p2p-traffic-090218/ http://www.ipoque.com/study/ipoque-Internet-Study-08-09.pdf Bien sûr qu'il y a des problèmes de congestion sur d'autres réseaux (téléphone, courrier) à des périodes de pointe. Mais France Telecom ne trie pas les appels en fonction de leur contenu, pas plus que La Poste ne trie les courriers en fonction de leur contenu. Il n'y a que les FAI qui transgressent cette règle de neutralité, sans doute parce que ça ne se voit pas. A bon ... Tu crois que l'échange ne donne pas priorité aux appels vers le 18/17/etc. par rapport a un appel a tes amis ?? En droit anglo-saxon c'est peut-être valable, mais en France, si une clause d'un contrat est contraire à la législation, c'est la clause qui saute (voire, tout le contrat). IANAL - Je pense que cette clause est aussi valable en droit Français - mais je ne defendrai pas ce point. Par contre, dans ta section Excessive bandwidth or Disk Utilisation je ne vois rien qui discrimine un usage par rapport à un autre. Ca dit : si tu utilise trop notre reseau (notre noc décide de la définition de trop comme il veut), on te bride comme on a envie. C'est un peu mieux dit, mais c'est ce qui est dit :) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Le Tue, Nov 24, 2009 at 05:18:46PM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: C'est vrai faire un virement banquaire c'est moins important que de telecharger un AVI^WISO de 700 Mb . L'http qui dure plus de qq seoncdes va donc être passé en priorité plus faible, comme bittorrent ? (et ce, meme si ça fait ramer tf1vision ou m6replay ?) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] ADSL contention
Rémi Bouhl a écrit: L'analyse est pertinente, mais si l'opérateur vendait que ce qu'il ne peut fournir, il ne pourrait donc plus le vendre 30 euros par mois... après tout le monde est libre de prendre un accès ADSL 20 Mb à 30 euros TTC par mois, ou une SDSL à 8 Mb à 150 euros HT. Mais si je prends un ADSL 20 Mb, et que je m'aperçois que le 20 Méga tourne à 20 Méga quand je fais du HTTP, et 10 Méga quand je fais du torrent, y'a baleine sous gravier (anguille sous roche) et ce n'est pas normal. Comment le FAI gère de son côté, je m'en fiche et je ne veux pas le savoir: moi j'ai un bout de tuyau qui se comporte différemment en fonction de ce que je mets dedans, alors qu'il est censé être indifférent au contenu. --- Liste de diffusion du FRnOG http://www.frnog.org/ Si j'achète une connexion ADSL en Best Effort, et si l'opérateur décide / a envie de limiter un flux, ca ne me choque pas et je trouve çà normal. Par contre si tu achète un ADSL avec débit garanti, là c'est autre chose (et + cher). C'est ce qu'écrit Alexandre Archambault dans son mail. Par ailleurs, pour reprendre l'analogie avec La Poste, je te rappelle qu'il existe différents tarifs (lent, rapide) qui affecte le délai d'acheminement de ta lettre/colis :-) Et c'est pareil pour le téléphone en heure de pointe (style un 31/12 à minuit...) ou le SMS. Tu vas pas exiger à ton opérateur de te garantir un canal dédié rien que pour toi pour quelques dizaines d'euros par mois. François-Xavier
Re: [FRnOG] ADSL contention
Le Tue, 24 Nov 2009 16:19:45 +0100, Alexandre Archambault aarchamba...@corp.free.fr a écrit : Pour le reste (c'est en réaction par rapport à ce qu'on peut lire ici ou là), ça témoigne d'une profonde méconnaissance des fondamentaux qui régissent notre secteur (aussi bien en téléphonie qu'en data puis IP) depuis plus d'un siècle, quand un chercheur danois (Erlang) s'est penché sur la question d'une application de la loi de Poisson aux réseaux, afin de baisser drastiquement les coûts d'équipement et d'exploitation et, in fine, s'assurer de l'essor du truc (et encore, il a fallu 60 ans pour que les process humains en matière de câblage des accès puissent être modélisés de la sorte). PASTA a été utile, maintenant je suis loin d'être sur qu'il soit encore pertinent de nos jours pour modéliser le trafic d'un ISP mais en même temps, si les ISPs n'aident pas à valider des modèles plus pertinent ... tout le monde va se coltiner du PASTA (avec des tomates et des lardons) pendant encore un moment ... a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpVE88h9BQ9m.pgp Description: PGP signature
Re: [FRnOG] ADSL contention
Bonjour, Alexandre Archambault wrote: Encore une fois, les industries de réseau en général et les communications électroniques en particulier, c'est un modèle technico- économique reposant sur une approche statistique du risque, en l'occurrence la charge réseau induite par un abonné moyen. Et en plus c'est vous (l'équipe de free) qui avez popularisé en France le fait que le coût d'usage d'un réseau Ethernet, c'est l'amortissement de sa capacité crête, quelle que soit son utilisation. Et vive les vrais forfaits illimités ;-) Mais certains n'ont toujours pas compris... Voilà pourquoi on peut difficilement faire sans contention de trafic, c'est inhérent à toute activité de réseau. Là par contre, je crois que ça change : l'arrivée de la fibre, c'est justement la disparition de la contention. Je sais, je suis un peu en avance, comme d'habitude :-) Mais la vraie révolution qui s'annonce, c'est vraiment la fin de la contention : dorénavant, il vaudra mieux investir dans l'augmentation de capacité que gérer de la pénurie de débit. Un exemple fait sur un coin de table, donc corrigez moi si erreur : dans le cas le pire où on utilise des switches 48 ports 1Gbps, avec une architecture adaptée, on peut commuter SANS CONTENTION 9 milliards de lignes 1Gbps avec 7 couches de switches, ce qui donne un coût de commutation mondiale sans contention de 140$ par ligne en comptant 20$/port. Par sans contention, je veux dire que chaque ligne peut échanger 1Gbps full-duplex avec n'importe quelle autre ligne, sans déranger les autres. Cela s'améliore si on prend des concentration de ports plus importantes par switch ou des ports 10G puis 100G, mais les prix montent aussi :-) Vous avez bien lu, il s'agit bien de l'estimation grossière d'un seul réseau niveau 2 qui couvre la terre entière et toute sa population : je connais des problèmes d'adressage, de stabilité et de gestion qui le rendent impossible tel quel bien sûr, mais l'important est de voir que c'est d'une taille et d'un prix raisonnables ! C'est pourquoi je suis persuadé que, plutôt que de couper des cheveux en 4 pour rationner la bande passante en cherchant qui doit passer en premier, il vaudrait mieux travailler tous ensemble avec la perspective d'un réseau mondial sans contention, basé sur de la fibre et des switches simples, robustes et bon marchés. Voilà pourquoi le réseau électrique saute quand tout le monde rallume la lumière en même temps à l'issue de l'extinction des feux sauvons la planète, Non, cela c'est parce que la production est centralisée : si chaque foyer qui se chauffe au fuel ou au gaz, au lieu de les bruler bêtement, faisait de la cogénération électrique en utilisant la chaleur résultante, le problème ne se poserait pas. pourquoi il est quasiment impossible de passer un coup de fil aux 12 coups de minuits de la St Sylvestre, Et ça c'est parce que free ne fait pas encore passer les gsm et la 3G sur internet ;-) pourquoi ça bloquera toujours à St Arnould le dimanche soir, Et ça c'est parce que les lignes fibres à 1Gbps ne sont pas dispo dans les résidences secondaires pour les téléconférences 3D du lundi matin ! A bientôt, -- __Bernard DUGAS __ | IS Production s.a. Innovative Solutions | --- Liste de diffusion du FRnOG http://www.frnog.org/
