Posté par Pierre .
En réponse au journal n9ufbox.
Évalué à 3.
A. ca y est j'ai compris.
Non, c'est CIPA dont je voulais parler.
Lu sur proxad.free.support
"Il y a encombrement de la CIPA, c'est tout"
(c) Brina a titre officiel [adresse en proxad.net]
LDCOM=neuf telecom apperment mais c possible qu'ils partagent^W vendent aux autres fai.
CIPA= Collecte IP/ADSL aparemment == FT
about free, je ne peut résister à citer ce poste de J.P. Iribarren sur pfa
Sujet: Re: blocage port sur ip/adsl
De: "J.P. Iribarren" <famirib33@free.fr>
Groupe de discussion: proxad.free.adsl
Date: Mon, 1 Mar 2004 18:29:11 +0100
Nicolas Midey wrote:
> [snip]
Bonjour Nicolas, bonjour Albert et les autres intervenants,
Comme Albert a cité mon nom un ou deux étages plus haut, et que la
discussion semble prendre un tour un peu -- heuu -- passionné, je
reviens y mettre mon grain de sel, ou mon coup d'extincteur, comme vous
voulez...
> Elle est impossible, car les gens de free connaissent mieux le
> matériel que le constructeur lui-même.
. Ils sont bons, mais quand même... :o)
> Et une QoS involontaire sur les ports déjà cités me parrait encore
> plus improbable.
> Donc oui, votre pseudo réponse ne me plait pas.
Je ne connais en effet pas un seul matériel (haut de gamme, s'entend)
qui applique de la QoS par défaut sur une interface réseau. J'avais
évoqué il y a quelques milliers de messages la possibilité que Free
utilise de la QoS, en précisant que ça me parait raisonnable; je vais
essayer de réexpliquer pourquoi:
Imaginez que vous êtes responsable réseau chez Free. Vous savez que les
tuyaux de la Collecte IP/ADSL (les tuyaux de FT qui acheminent vers Free
les flux des non-dégroupés) sont saturés, et vous ne pouvez
malheureusement pas agir sur le "diamètre" de ces tuyaux (la bande
passante chez FT).
Toutefois, si vous ne faites rien, ce manque de bande passante va se
traduire par des paquets mis à la poubelle *au petit bonheur* par un ou
plusieurs des routeurs situés le long du tuyau. Ça va tomber sur
n'importe quel paquet de préférence, et plus rien ne marchera
correctement, que ce soit le P2P, le Web ou l'e-mail.
En revanche, si vous mettez en place un mécanisme de QoS de la famille
fair-queuing (proposé dans une variante ou une autre par tous les
constructeurs de routeurs pro), vous pouvez faire en sorte que votre
routeur de liaison à la Collecte IP/ADSL trie les différents flux (par
catégorie d'abord: ICMP, TCP, UDP, IPSec, etc... puis par ports TCP ou
UDP) et arbitre ces flux en limitant *automatiquement* le débit des flux
qui consommeraient volontiers toute la bande passante disponible (P2P)
au détriment des "petits" flux (telnet, e-mail). Pas besoin de filtrer
explicitement tel ou tel port, ça s'équilibre tout seul.
Ça fonctionne à peu près comme ça (c'est juste un exemple avec des
chiffres bidon, et il existe d'autres variantes d'algorithme, mais c'est
pour illustrer le principe):
1. on (je veux dire: la couche QoS du routeur) calcule combien de flux
différents doivent passer dans le tuyau; supposons qu'il y en ait trois:
du SMTP (e-mail, TCP port 25), du HTTP (Web, TCP port 80) et du P2P (TCP
port 411).
2. on divise la bande passante par trois, et on commence par proposer à
chaque flux sa part du gateau: 33% pour chacun.
3. vu sa nature, le SMTP ne va même pas manger le centième de sa part
(soit 0.3% de la bande passante), le Web va en manger la moitié(16,7%),
et étant donné le nombre d'utilisateurs simultanés et la taille des
fichiers téléchargés, le P2P va entièrement consommer sa part (33%).
4. on calcule combien il reste de rab' de gateau: 100% -
(33%+16.7%+0.3%) = 50%.
5. on distribue ce qui reste du gateau à parts égales aux flux qui en
veulent encore: le SMTP n'a plus faim, le Web a les dents du fond qui
baignent, mais le P2P veut bien reprendre du gateau à hauteur des 50%
qui restent. Miam.
6. quand il n'y a plus de gateau, il n'y en a plus: donc, quand les deux
autres flux sont actifs, si le flux total P2P à acheminer représente
plus de (33% + 50%), soit 83% de la bande passante disponible, le P2P
commence à perdre des paquets, et des posts enflammés façon "bridage des
ports" commencent à envahir p.f.a... En revanche, aux heures creuses, le
débit total du flux P2P reste inférieur aux 83% disponibles, aucun
paquet n'est mis à la poubelle, et les fans de P2P sont contents.
Ce genre de mécanisme est donc fait pour servir les différents flux de
la manière la plus *équitable* possible, tout en évitant de dépasser la
bande passante totale disponible (ce qui conduirait à une situation
*encore pire*). Quand un flux commence à être limité, c'est qu'il
"dépasse les bornes". Les services qui "trinquent" en premier sont donc
ceux qui auraient tendance à monopoliser la bande passante et à marcher
sur les pieds des autres flux. C'est sans doute le cas du P2P aux heures
d'affluence.
Vous comprendrez que *si* Free a utilisé ce type de QoS (mais je n'en
sais rien, c'est juste une *hypothèse*), ce n'est pas pour enquiquiner
le monde, c'est pour assurer *en moyenne* le meilleur service avec des
ressources limitées sur lesquelles ils n'ont pas de moyen d'agir (la
Collecte IP/ADSL est gérée par FT).
*Si* ce genre de mécanisme est bien utilisé, quand les Freenautes font
des tests, il est normal qu'ils constatent un comportement standard sur
les flux qui sont (relativement) peu consommateurs de bande passante, et
qu'ils trouvent un comportement dégradé sur des flux qui ont tendance à
saturer les tuyaux. Il n'y a pas un Grand Yaka qui a décidé chez Free
que le P2P, c'est MAL, et qui a serré explicitement la vis aux ports
411, etc. C'est tout simplement automatique. Si demain tous les
Freenautes se mettaient en tête de faire du téléchargement FTP à
outrance, on verrait sans doute arriver sur p.f.a. des posts avec pour
titre "Free bride le FTP !"...
Evidemment, si Free était propriétaire du tuyau, on pourrait leur
reprocher de ne pas le "muscler" (comme ils le font régulièrement pour
le peering, par exemple), mais ce n'est pas le cas. Je fais donc
l'hypothèse (vraisemblable, mais non prouvée) qu'ils ont utilisé le
moyen que j'ai décrit plus haut pour fournir le meilleur *compromis* de
service. Moi, à leur place, c'est ce que j'aurais fait. Et ils ne
peuvent peut-être pas trop communiquer là-dessus parce que ça mettrait
directement FT en cause.
Quand à FT, je pense qu'ils doivent faire pas mal d'heures supp' en ce
moment pour déployer la collecte régionale, qui multipliera les tuyaux
et devrait permettre de retrouver de la bande passante.
(et pour prévenir la question: Wanadoo utilise un plan de collecte
*privé*, indépendant de la Collecte IP/ADSL, ce qui explique qu'ils
soient moins impactés que les autres FAIs)
Voilà, c'était juste une petite digression technique pour donner
quelques éléments de réflexion à ceux qui pensent que Free (ou FT) se
moque de ses clients. Je ne crois pas que ce soit le cas, ni pour l'un
ni pour l'autre. Et je ne suis pas actionnaire, et même pas encore
dégroupé ! :o)
[^] # Re: n9ufbox
Posté par Pierre . En réponse au journal n9ufbox. Évalué à 3.
Non, c'est CIPA dont je voulais parler.
Lu sur proxad.free.support
"Il y a encombrement de la CIPA, c'est tout"
(c) Brina a titre officiel [adresse en proxad.net]
LDCOM=neuf telecom apperment mais c possible qu'ils partagent^W vendent aux autres fai.
CIPA= Collecte IP/ADSL aparemment == FT
about free, je ne peut résister à citer ce poste de J.P. Iribarren sur pfa
Sujet: Re: blocage port sur ip/adsl
De: "J.P. Iribarren" <famirib33@free.fr>
Groupe de discussion: proxad.free.adsl
Date: Mon, 1 Mar 2004 18:29:11 +0100
Nicolas Midey wrote:
> [snip]
Bonjour Nicolas, bonjour Albert et les autres intervenants,
Comme Albert a cité mon nom un ou deux étages plus haut, et que la
discussion semble prendre un tour un peu -- heuu -- passionné, je
reviens y mettre mon grain de sel, ou mon coup d'extincteur, comme vous
voulez...
> Elle est impossible, car les gens de free connaissent mieux le
> matériel que le constructeur lui-même.
. Ils sont bons, mais quand même... :o)
> Et une QoS involontaire sur les ports déjà cités me parrait encore
> plus improbable.
> Donc oui, votre pseudo réponse ne me plait pas.
Je ne connais en effet pas un seul matériel (haut de gamme, s'entend)
qui applique de la QoS par défaut sur une interface réseau. J'avais
évoqué il y a quelques milliers de messages la possibilité que Free
utilise de la QoS, en précisant que ça me parait raisonnable; je vais
essayer de réexpliquer pourquoi:
Imaginez que vous êtes responsable réseau chez Free. Vous savez que les
tuyaux de la Collecte IP/ADSL (les tuyaux de FT qui acheminent vers Free
les flux des non-dégroupés) sont saturés, et vous ne pouvez
malheureusement pas agir sur le "diamètre" de ces tuyaux (la bande
passante chez FT).
Toutefois, si vous ne faites rien, ce manque de bande passante va se
traduire par des paquets mis à la poubelle *au petit bonheur* par un ou
plusieurs des routeurs situés le long du tuyau. Ça va tomber sur
n'importe quel paquet de préférence, et plus rien ne marchera
correctement, que ce soit le P2P, le Web ou l'e-mail.
En revanche, si vous mettez en place un mécanisme de QoS de la famille
fair-queuing (proposé dans une variante ou une autre par tous les
constructeurs de routeurs pro), vous pouvez faire en sorte que votre
routeur de liaison à la Collecte IP/ADSL trie les différents flux (par
catégorie d'abord: ICMP, TCP, UDP, IPSec, etc... puis par ports TCP ou
UDP) et arbitre ces flux en limitant *automatiquement* le débit des flux
qui consommeraient volontiers toute la bande passante disponible (P2P)
au détriment des "petits" flux (telnet, e-mail). Pas besoin de filtrer
explicitement tel ou tel port, ça s'équilibre tout seul.
Ça fonctionne à peu près comme ça (c'est juste un exemple avec des
chiffres bidon, et il existe d'autres variantes d'algorithme, mais c'est
pour illustrer le principe):
1. on (je veux dire: la couche QoS du routeur) calcule combien de flux
différents doivent passer dans le tuyau; supposons qu'il y en ait trois:
du SMTP (e-mail, TCP port 25), du HTTP (Web, TCP port 80) et du P2P (TCP
port 411).
2. on divise la bande passante par trois, et on commence par proposer à
chaque flux sa part du gateau: 33% pour chacun.
3. vu sa nature, le SMTP ne va même pas manger le centième de sa part
(soit 0.3% de la bande passante), le Web va en manger la moitié(16,7%),
et étant donné le nombre d'utilisateurs simultanés et la taille des
fichiers téléchargés, le P2P va entièrement consommer sa part (33%).
4. on calcule combien il reste de rab' de gateau: 100% -
(33%+16.7%+0.3%) = 50%.
5. on distribue ce qui reste du gateau à parts égales aux flux qui en
veulent encore: le SMTP n'a plus faim, le Web a les dents du fond qui
baignent, mais le P2P veut bien reprendre du gateau à hauteur des 50%
qui restent. Miam.
6. quand il n'y a plus de gateau, il n'y en a plus: donc, quand les deux
autres flux sont actifs, si le flux total P2P à acheminer représente
plus de (33% + 50%), soit 83% de la bande passante disponible, le P2P
commence à perdre des paquets, et des posts enflammés façon "bridage des
ports" commencent à envahir p.f.a... En revanche, aux heures creuses, le
débit total du flux P2P reste inférieur aux 83% disponibles, aucun
paquet n'est mis à la poubelle, et les fans de P2P sont contents.
Ce genre de mécanisme est donc fait pour servir les différents flux de
la manière la plus *équitable* possible, tout en évitant de dépasser la
bande passante totale disponible (ce qui conduirait à une situation
*encore pire*). Quand un flux commence à être limité, c'est qu'il
"dépasse les bornes". Les services qui "trinquent" en premier sont donc
ceux qui auraient tendance à monopoliser la bande passante et à marcher
sur les pieds des autres flux. C'est sans doute le cas du P2P aux heures
d'affluence.
Vous comprendrez que *si* Free a utilisé ce type de QoS (mais je n'en
sais rien, c'est juste une *hypothèse*), ce n'est pas pour enquiquiner
le monde, c'est pour assurer *en moyenne* le meilleur service avec des
ressources limitées sur lesquelles ils n'ont pas de moyen d'agir (la
Collecte IP/ADSL est gérée par FT).
*Si* ce genre de mécanisme est bien utilisé, quand les Freenautes font
des tests, il est normal qu'ils constatent un comportement standard sur
les flux qui sont (relativement) peu consommateurs de bande passante, et
qu'ils trouvent un comportement dégradé sur des flux qui ont tendance à
saturer les tuyaux. Il n'y a pas un Grand Yaka qui a décidé chez Free
que le P2P, c'est MAL, et qui a serré explicitement la vis aux ports
411, etc. C'est tout simplement automatique. Si demain tous les
Freenautes se mettaient en tête de faire du téléchargement FTP à
outrance, on verrait sans doute arriver sur p.f.a. des posts avec pour
titre "Free bride le FTP !"...
Evidemment, si Free était propriétaire du tuyau, on pourrait leur
reprocher de ne pas le "muscler" (comme ils le font régulièrement pour
le peering, par exemple), mais ce n'est pas le cas. Je fais donc
l'hypothèse (vraisemblable, mais non prouvée) qu'ils ont utilisé le
moyen que j'ai décrit plus haut pour fournir le meilleur *compromis* de
service. Moi, à leur place, c'est ce que j'aurais fait. Et ils ne
peuvent peut-être pas trop communiquer là-dessus parce que ça mettrait
directement FT en cause.
Quand à FT, je pense qu'ils doivent faire pas mal d'heures supp' en ce
moment pour déployer la collecte régionale, qui multipliera les tuyaux
et devrait permettre de retrouver de la bande passante.
(et pour prévenir la question: Wanadoo utilise un plan de collecte
*privé*, indépendant de la Collecte IP/ADSL, ce qui explique qu'ils
soient moins impactés que les autres FAIs)
Voilà, c'était juste une petite digression technique pour donner
quelques éléments de réflexion à ceux qui pensent que Free (ou FT) se
moque de ses clients. Je ne crois pas que ce soit le cas, ni pour l'un
ni pour l'autre. Et je ne suis pas actionnaire, et même pas encore
dégroupé ! :o)