Je dispose d'une liaison internet 1,2 Mbps dans les 2 sens. Sur cette
liaison, j'ai du traffic http et smtp. Je voudrai limiter le débit du smtp à
300kbps , dans les 2 sens. Je n'ai pas la main sur le routeur du provider,
je dois donc agir sur le switch pour mettre de la Qos
Le routeur de mon provider est connecté sur un switch Cisco 2950 (port 1 du
switch). Sur le port 2 de mon switch, j'ai la connexion vers mon réseau
local. Je n'ai rien d'autre de connecter sur le switch, tout le flux qui
arrive d'internet ressort de l'autre côté.
Pour le flux sortant, je ne pense pas avoir de problème limiter mon traffic
SMTP. Par contre, est ce que je peux limiter le traffic SMTP qui vient
d'internet?
Pour le flux sortant, je ne pense pas avoir de problème limiter mon traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Fri, 9 Jan 2004 12:24:57 +0100, vincent <toto@nospam.com> wrote:
Pour le flux sortant, je ne pense pas avoir de problème limiter mon
traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP
qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la
liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre
du traffic-shaping sur le switch ne fera que retarder les paquets après
qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé
et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si
les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le
sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses
connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera
beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Pour le flux sortant, je ne pense pas avoir de problème limiter mon traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
benoit.sansspam
Jacques Caron wrote:
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la place du switch ?
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Jacques Caron <jc@imfeurope.com> wrote:
Partiellement. Normalement, la limitation devrait se faire en amont de la
liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre
du traffic-shaping sur le switch ne fera que retarder les paquets après
qu'ils soient arrivés, donc trop tard.
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la
place du switch ?
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la place du switch ?
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Pierre LALET
Benoit wrote:
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la place du switch ?
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet/ Droids Corporation -- http://www.rstack.org/droids/ Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Benoit wrote:
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la
place du switch ?
Ca ne changera rien au fait que les paquets sont déjà arrivés (de
"notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande
passante que l'on veut sauvegarder.
pierre
--
Pierre LALET -- http://www.enseirb.fr/~lalet/
Droids Corporation -- http://www.rstack.org/droids/
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Pourquoi ne pas rajouter un routeur an milieu qu'on gère soi-même à la place du switch ?
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet/ Droids Corporation -- http://www.rstack.org/droids/ Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
benoit.sansspam
Pierre LALET wrote:
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Il y a des jours où je ferai mieux de rester au lit ;-)
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Pierre LALET <lalet@enseirb.fr> wrote:
Ca ne changera rien au fait que les paquets sont déjà arrivés (de
"notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande
passante que l'on veut sauvegarder.
Il y a des jours où je ferai mieux de rester au lit ;-)
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Il y a des jours où je ferai mieux de rester au lit ;-)
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
T0t0
"Pierre LALET" wrote in message news:btm7qs$ioa$
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au serveur en face de changer son débit. Donc même si tu agis en aval, tu peux avoir une action non négligeable sur le débit de la connexion. C'est notamment un des principes de fonctionnement du Packetshaper de Packeteer. Donc c'est une bonne solution à mon avis, si le routeur intermédiaire sais gérer ce genre de choses, ce qui n'est pas évident...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pierre LALET" <lalet@enseirb.fr> wrote in message
news:btm7qs$ioa$1@news.u-bordeaux.fr
Ca ne changera rien au fait que les paquets sont déjà arrivés (de
"notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande
passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au
serveur en face de changer son débit. Donc même si tu agis en aval,
tu peux avoir une action non négligeable sur le débit de la connexion.
C'est notamment un des principes de fonctionnement du Packetshaper de
Packeteer.
Donc c'est une bonne solution à mon avis, si le routeur intermédiaire
sais gérer ce genre de choses, ce qui n'est pas évident...
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au serveur en face de changer son débit. Donc même si tu agis en aval, tu peux avoir une action non négligeable sur le débit de la connexion. C'est notamment un des principes de fonctionnement du Packetshaper de Packeteer. Donc c'est une bonne solution à mon avis, si le routeur intermédiaire sais gérer ce genre de choses, ce qui n'est pas évident...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
vincent
Bonjour,
Merci pour ces informations. L'idée me parait interessante car ce sont surtout les gros fichiers qui pénalisent ma liaison. Donc si je comprends bien, pour limiter mon flux internet entrant, il faut que j'applique le traffic-shaping en sortie de mon interface entre le switch et mon LAN ? et pour le traffic sortant, j'applique le traffic-shaping en sortie de l'interface entre le switch et le routeur du fai?
Je vais essayer de mettre ça en oeuvre. Vincent
"Jacques Caron" a écrit dans le message de news:
Salut,
On Fri, 9 Jan 2004 12:24:57 +0100, vincent wrote:
Pour le flux sortant, je ne pense pas avoir de problème limiter mon traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Bonjour,
Merci pour ces informations. L'idée me parait interessante car ce sont
surtout les gros fichiers qui pénalisent ma liaison.
Donc si je comprends bien, pour limiter mon flux internet entrant, il faut
que j'applique le traffic-shaping en sortie de mon interface entre le switch
et mon LAN ?
et pour le traffic sortant, j'applique le traffic-shaping en sortie de
l'interface entre le switch et le routeur du fai?
Je vais essayer de mettre ça en oeuvre.
Vincent
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de
news:opr1iajqpkq1hokb@news.free.fr...
Salut,
On Fri, 9 Jan 2004 12:24:57 +0100, vincent <toto@nospam.com> wrote:
Pour le flux sortant, je ne pense pas avoir de problème limiter mon
traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP
qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la
liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre
du traffic-shaping sur le switch ne fera que retarder les paquets après
qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé
et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si
les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le
sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses
connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera
beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Merci pour ces informations. L'idée me parait interessante car ce sont surtout les gros fichiers qui pénalisent ma liaison. Donc si je comprends bien, pour limiter mon flux internet entrant, il faut que j'applique le traffic-shaping en sortie de mon interface entre le switch et mon LAN ? et pour le traffic sortant, j'applique le traffic-shaping en sortie de l'interface entre le switch et le routeur du fai?
Je vais essayer de mettre ça en oeuvre. Vincent
"Jacques Caron" a écrit dans le message de news:
Salut,
On Fri, 9 Jan 2004 12:24:57 +0100, vincent wrote:
Pour le flux sortant, je ne pense pas avoir de problème limiter mon traffic SMTP. Par contre, est ce que je peux limiter le traffic SMTP qui vient d'internet?
Partiellement. Normalement, la limitation devrait se faire en amont de la liaison sur laquelle on veut appliquer de la QoS, donc chez le FAI. Mettre du traffic-shaping sur le switch ne fera que retarder les paquets après qu'ils soient arrivés, donc trop tard.
Cependant, TCP va normalement se rendre compte que le trafic est retardé et s'adapter en réduisant le débit d'envoi. Mais ce n'est valable que si les connexions TCP durent assez longtemps pour que ce soit efficace. Ce le sera donc d'autant plus qu'il s'agit d'un nombre limité de grosses connexions TCP (par exemple un envoi de gros fichier attaché). Ce le sera beaucoup moins s'il s'agit de très nombreux petits e-mails.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
vincent
Merci pour les conseils. Je ne pense pas que le routeur du fai pose un probleme par rapport à ça. c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons? En tout cas, je vais essayer. Vincent
"T0t0" a écrit dans le message de news:
"Pierre LALET" wrote in message news:btm7qs$ioa$
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au serveur en face de changer son débit. Donc même si tu agis en aval, tu peux avoir une action non négligeable sur le débit de la connexion. C'est notamment un des principes de fonctionnement du Packetshaper de Packeteer. Donc c'est une bonne solution à mon avis, si le routeur intermédiaire sais gérer ce genre de choses, ce qui n'est pas évident...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Merci pour les conseils.
Je ne pense pas que le routeur du fai pose un probleme par rapport à ça.
c'est le principe de tcp de s'adapter au debit du segment le plus faible
quelque soit le debit disponible sur les autres tronçons?
En tout cas, je vais essayer.
Vincent
"T0t0" <bibi@antionline.org> a écrit dans le message de
news:6f7c28326234111dbf6584e1d3213838.28089@mygate.mailgate.org...
"Pierre LALET" <lalet@enseirb.fr> wrote in message
news:btm7qs$ioa$1@news.u-bordeaux.fr
Ca ne changera rien au fait que les paquets sont déjà arrivés (de
"notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande
passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au
serveur en face de changer son débit. Donc même si tu agis en aval,
tu peux avoir une action non négligeable sur le débit de la connexion.
C'est notamment un des principes de fonctionnement du Packetshaper de
Packeteer.
Donc c'est une bonne solution à mon avis, si le routeur intermédiaire
sais gérer ce genre de choses, ce qui n'est pas évident...
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Merci pour les conseils. Je ne pense pas que le routeur du fai pose un probleme par rapport à ça. c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons? En tout cas, je vais essayer. Vincent
"T0t0" a écrit dans le message de news:
"Pierre LALET" wrote in message news:btm7qs$ioa$
Ca ne changera rien au fait que les paquets sont déjà arrivés (de "notre" côté de la ligne bas débit), et qu'ils ont déjà occupé la bande passante que l'on veut sauvegarder.
Si si. Si tu joues sur la taille de fenêtre TCP, tu demandes au serveur en face de changer son débit. Donc même si tu agis en aval, tu peux avoir une action non négligeable sur le débit de la connexion. C'est notamment un des principes de fonctionnement du Packetshaper de Packeteer. Donc c'est une bonne solution à mon avis, si le routeur intermédiaire sais gérer ce genre de choses, ce qui n'est pas évident...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Jacques Caron
Salut,
On Fri, 9 Jan 2004 17:22:31 +0100, vincent wrote:
Merci pour ces informations. L'idée me parait interessante car ce sont surtout les gros fichiers qui pénalisent ma liaison.
Ca devrait donc avoir un effet, même s'il n'est pas forcément garanti (un expéditeur avec une implémentation TCP mal faite peut saturer la liaison sans se rendre compte de rien).
Donc si je comprends bien, pour limiter mon flux internet entrant, il faut que j'applique le traffic-shaping en sortie de mon interface entre le switch et mon LAN ?
Oui. Prévoir un débit max inférieur à celui souhaité au niveau de la liaison.
et pour le traffic sortant, j'applique le traffic-shaping en sortie de l'interface entre le switch et le routeur du fai?
Tout à fait.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Fri, 9 Jan 2004 17:22:31 +0100, vincent <toto@nospam.com> wrote:
Merci pour ces informations. L'idée me parait interessante car ce sont
surtout les gros fichiers qui pénalisent ma liaison.
Ca devrait donc avoir un effet, même s'il n'est pas forcément garanti (un
expéditeur avec une implémentation TCP mal faite peut saturer la liaison
sans se rendre compte de rien).
Donc si je comprends bien, pour limiter mon flux internet entrant, il
faut que j'applique le traffic-shaping en sortie de mon interface entre
le switch et mon LAN ?
Oui. Prévoir un débit max inférieur à celui souhaité au niveau de la
liaison.
et pour le traffic sortant, j'applique le traffic-shaping en sortie de
l'interface entre le switch et le routeur du fai?
Tout à fait.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Merci pour ces informations. L'idée me parait interessante car ce sont surtout les gros fichiers qui pénalisent ma liaison.
Ca devrait donc avoir un effet, même s'il n'est pas forcément garanti (un expéditeur avec une implémentation TCP mal faite peut saturer la liaison sans se rendre compte de rien).
Donc si je comprends bien, pour limiter mon flux internet entrant, il faut que j'applique le traffic-shaping en sortie de mon interface entre le switch et mon LAN ?
Oui. Prévoir un débit max inférieur à celui souhaité au niveau de la liaison.
et pour le traffic sortant, j'applique le traffic-shaping en sortie de l'interface entre le switch et le routeur du fai?
Tout à fait.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jacques Caron
On Fri, 9 Jan 2004 17:26:12 +0100, vincent wrote:
c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence augmente en cas de saturation d'un lien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Fri, 9 Jan 2004 17:26:12 +0100, vincent <toto@nospam.com> wrote:
c'est le principe de tcp de s'adapter au debit du segment le plus faible
quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence
augmente en cas de saturation d'un lien.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence augmente en cas de saturation d'un lien.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Ettore
Jacques Caron wrote:
On Fri, 9 Jan 2004 17:26:12 +0100, vincent wrote:
c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence augmente en cas de saturation d'un lien.
Jacques. Je me mêle de quelque chose que je ne connait pas bien mais j'ai lu une
fois sur la question de la qos que les providers ménageaient d'énormes files d'attentes sur leurs routeurs pour optimiser leurs statistiques de débit (pas celle des ping !). Dans ces conditions l'idée d'envoyer des signaux de saturation du lien vers le routeur du provider me semble un peu vain mais je raconte sans doute n'importe quoi. Ettore
Jacques Caron wrote:
On Fri, 9 Jan 2004 17:26:12 +0100, vincent <toto@nospam.com> wrote:
c'est le principe de tcp de s'adapter au debit du segment le plus faible
quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence
augmente en cas de saturation d'un lien.
Jacques.
Je me mêle de quelque chose que je ne connait pas bien mais j'ai lu une
fois sur la question de la qos que les providers ménageaient d'énormes
files d'attentes sur leurs routeurs pour optimiser leurs statistiques de
débit (pas celle des ping !). Dans ces conditions l'idée d'envoyer des
signaux de saturation du lien vers le routeur du provider me semble un
peu vain mais je raconte sans doute n'importe quoi.
Ettore
c'est le principe de tcp de s'adapter au debit du segment le plus faible quelque soit le debit disponible sur les autres tronçons?
En fait il ne s'adapte pas au débit, mais à la latence. Or la latence augmente en cas de saturation d'un lien.
Jacques. Je me mêle de quelque chose que je ne connait pas bien mais j'ai lu une
fois sur la question de la qos que les providers ménageaient d'énormes files d'attentes sur leurs routeurs pour optimiser leurs statistiques de débit (pas celle des ping !). Dans ces conditions l'idée d'envoyer des signaux de saturation du lien vers le routeur du provider me semble un peu vain mais je raconte sans doute n'importe quoi. Ettore
