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 yo
Julien Richer wrote:
Le 1 décembre 2009 09:59, Thomas Mangin
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 ép
Le 1 décembre 2009 09:59, Thomas Mangin
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
> 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 permet
On Tue, 2009-12-01 at 08:52 +0400, Erwann Thoraval wrote:
> 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
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 pourq
Rémi Bouhl 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 ?
>
> Quand bien même ce serait le cas, ce n'est pas une excuse pour faire
> 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:
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 po
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 n
> 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---
List
Dear Thomas,
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
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 doi
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,
P
On Thu, 26 Nov 2009 18:22:10 +0100, "michel hostettler"
said:
> 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 proto
>> 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ù cet
> 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
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ù c
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 Mangi
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 auss
> 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 conte
On Thu, 26 Nov 2009 09:41:42 -0500, "anthony Hémond"
said:
> Une autre question simple: pourquoi les FAI ne divulguent pas cette
> information? C'est à dire pourquoi ne pas mentionner aux consommateurs le
> taux de contention. Toutes les compagnies ont-elles le même taux de
> contention?
Dans c
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 l
Le Wed, 25 Nov 2009 21:25:23 +0100,
"Radu-Adrian Feurdean" 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 :
Le Wed, 25 Nov 2009 13:16:07 +0100,
e-t172 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'ingr
On Wed, 25 Nov 2009 21:17:40 +0100, "Jerome Benoit"
said:
> Le Wed, 25 Nov 2009 14:18:51 +0100,
> Bernard Dugas 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
Le Wed, 25 Nov 2009 14:18:51 +0100,
Bernard Dugas 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 1
Pas assez pour demander pay peering :)
Thomas
---
from my iPhone
On 25 Nov 2009, at 15:52, Clement Cavadore 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 so
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 phras
> 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/
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
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
> 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 va
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émar
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 u
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 t
>> 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
ehalf 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
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 DD
> 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 l
> 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 car
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 d
> 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
> éth
Le , e-t172 a écrit :
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
> 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",
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 u
Le Wed, 25 Nov 2009 11:15:51 +0100,
"Radu-Adrian Feurdean" 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 concep
> 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
> 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ésu
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
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,
>> 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 éta
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 erre
>> 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 l
On Wed, 25 Nov 2009 00:34:52 +0100, "Bernard Dugas"
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 e
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 p
Le 25 novembre 2009 11:02, Dominique Rousseau a écrit :
> 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 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
> >> telec
> 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é pl
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.
Le Tue, 24 Nov 2009 16:19:45 +0100,
Alexandre Archambault 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 plu
Le Tue, 24 Nov 2009 08:25:59 +,
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
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
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, c
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,
>
Le 24/11/09, Julien Richer a écrit :
> 2009/11/24 Rémi Bouhl :
>>> 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
2009/11/24 Rémi Bouhl :
>> 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.
>
>> 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
> 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
> En soi BT ne mange pas "tout ce qu'il peut", pas plus qu'un autre
> protocole: l'utilisateur peut régler la conso, ou laisser tourner "au
> maximum", mais il peut également remplir sa bande passante avec autre
> chose.
Quand tu cherches a transférer pres d'un GIG aussi vite que possible ca en
p
Le 24/11/09, Thomas Mangin a écrit :
> 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 es
> 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 AN
Bon, alors faudrait qu'on m'explique. D'après la loi:
http://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=89C4D249BEFB50A6A2E69507EC49EA86.tpdjo09v_1?idArticle=LEGIARTI19296845&cidTexte=LEGITEXT06070987&dateTexte=20090808
l'ARCEP veille:
"Au respect par les opérateurs de communica
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
> 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/
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)?
Le 24/11/09, Thomas Mangin a écrit :
> 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 compr
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 surdimensio
Le 24 novembre 2009 09:48, Thomas Mangin
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
> 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 ?
>> (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
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
Le 24 novembre 2009 09:25, Thomas Mangin
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.
> Cec
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://new
Dom,
Le 24 novembre 2009 09:18, Dominique Rousseau 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 fai
> 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 e
Le 24 novembre 2009 09:01, Thomas Mangin
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
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.
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
> 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
89 matches
Mail list logo
