un sujet vient de passer sur le QoS. Je vois à quoi ça sert, mais j'ai
une question.
D'après ce que j'ai compri, le QoS permet de prioriser certains type
de paquet (VoIP, ping, game,...) par rapport à d'autre (FTP) en fixant
des limites downspeed et upspeed
Ma question est :
Est ce que ces limites sont figées ou sont elles dynamiques en QoS ?
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par
exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que
les paquets prioritaires ne sont pas présent ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Denis Corbin
Le 04/05/2015 19:09, La Norme Française c'est pas le FN a écrit :
Bonjour
Hello
un sujet vient de passer sur le QoS. Je vois à quoi ça sert, mais j'ai une question.
D'après ce que j'ai compri, le QoS permet de prioriser certains type de paquet (VoIP, ping, game,...) par rapport à d'autre (FTP) en fixant des limites downspeed et upspeed
Ma question est : Est ce que ces limites sont figées ou sont elles dynamiques en QoS ?
*la* QoS (Quality of Service/Qualité de Service) ce n'est pas seulement une question de limitation de bande passante, le plus important le l'ordre de traitement des paquets dans la file d'attente. Si la file d'attente est vide, il n'y a pas de congestion et chaque paquet est transmis immédiatement, tu peux monter en débit tant qu'il n'y a pas d'accumulation de paquet dans la file d'émission, la QoS n'intervient pas.
Si par contre la file n'est pas vide, la QoS permet de prendre les paquets de tel type (téléphonie par exemple) et de les transmettre en premier même s'ils sont arrivés en dernier. Ils ne subissent donc pas la congestion (pas de bouchon pour eux, mieux que les pompiers dans le trafic urbain), c'est ce qu'on appel le trafic prioritaire (strict priority queueing). Après on peut limiter le trafic prioritaire en débit pour laisser du temps d'émission pour le reste. S'il y a trop de trafic prioritaire on peut décider de détruire le trafic prioritaire excédentaire. Dans ce cas c'est une limite *fixe* et indépendante de la présence de congestion, même quand il n'y a de congestion on ne pourra pas dépasser ce débit.
autre mécanisme qu'on trouve avec la QoS, c'est de définir des poids pour chaque type de trafic (le trafic est rangé par classe de trafic, librement défini lors de la configuration, par exemple on peut définir une classe pour le trafic FTP et TFTP, une autre pour SSH et Telnet, etc.).
la notion de poids est intéressante car elle permet de ne pas brider une classe inutilement comme vu dans l'exemple précédent, avec trois classes ayant des poids 1, 3 et 5 respectivement si une seule classe est présente, elle pourra utiliser 100% du débit. Si la classe 1 (poids 1) et la classe 2 (poids 3) sont présentes et qu'une congestion survient, pour chaque paquet de la classe 1 émis on émettra 3 paquets de la classe 2, si la congestion continue mais que le volume de trafic de la classe 2 s'amenuise, la classe 1 pourra émettre plus que 1/4 du débit (selon ce que la classe 2 laissera disponible).
c'est ce qu'on appelle CBWFQ "Class based Weigthed Fair Queue"
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut fonctionner avec une ou deux files strictement prioritaires, on peut aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour une ou plusieurs classes données (policying ou shaping), avec ici un seuil fixé et indépendant de l'état de congestion.
Merci d'avance
Le 04/05/2015 19:09, La Norme Française c'est pas le FN a écrit :
Bonjour
Hello
un sujet vient de passer sur le QoS. Je vois à quoi ça sert, mais j'ai
une question.
D'après ce que j'ai compri, le QoS permet de prioriser certains type
de paquet (VoIP, ping, game,...) par rapport à d'autre (FTP) en fixant
des limites downspeed et upspeed
Ma question est :
Est ce que ces limites sont figées ou sont elles dynamiques en QoS ?
*la* QoS (Quality of Service/Qualité de Service) ce n'est pas seulement
une question de limitation de bande passante, le plus important le
l'ordre de traitement des paquets dans la file d'attente. Si la file
d'attente est vide, il n'y a pas de congestion et chaque paquet est
transmis immédiatement, tu peux monter en débit tant qu'il n'y a pas
d'accumulation de paquet dans la file d'émission, la QoS n'intervient pas.
Si par contre la file n'est pas vide, la QoS permet de prendre les
paquets de tel type (téléphonie par exemple) et de les transmettre en
premier même s'ils sont arrivés en dernier. Ils ne subissent donc pas la
congestion (pas de bouchon pour eux, mieux que les pompiers dans le
trafic urbain), c'est ce qu'on appel le trafic prioritaire (strict
priority queueing). Après on peut limiter le trafic prioritaire en débit
pour laisser du temps d'émission pour le reste. S'il y a trop de trafic
prioritaire on peut décider de détruire le trafic prioritaire
excédentaire. Dans ce cas c'est une limite *fixe* et indépendante de la
présence de congestion, même quand il n'y a de congestion on ne pourra
pas dépasser ce débit.
autre mécanisme qu'on trouve avec la QoS, c'est de définir des poids
pour chaque type de trafic (le trafic est rangé par classe de trafic,
librement défini lors de la configuration, par exemple on peut définir
une classe pour le trafic FTP et TFTP, une autre pour SSH et Telnet, etc.).
la notion de poids est intéressante car elle permet de ne pas brider une
classe inutilement comme vu dans l'exemple précédent, avec trois classes
ayant des poids 1, 3 et 5 respectivement si une seule classe est
présente, elle pourra utiliser 100% du débit.
Si la classe 1 (poids 1) et la classe 2 (poids 3) sont présentes et
qu'une congestion survient, pour chaque paquet de la classe 1 émis on
émettra 3 paquets de la classe 2, si la congestion continue mais que le
volume de trafic de la classe 2 s'amenuise, la classe 1 pourra émettre
plus que 1/4 du débit (selon ce que la classe 2 laissera disponible).
c'est ce qu'on appelle CBWFQ "Class based Weigthed Fair Queue"
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par
exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que
les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut
fonctionner avec une ou deux files strictement prioritaires, on peut
aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour
une ou plusieurs classes données (policying ou shaping), avec ici un
seuil fixé et indépendant de l'état de congestion.
Le 04/05/2015 19:09, La Norme Française c'est pas le FN a écrit :
Bonjour
Hello
un sujet vient de passer sur le QoS. Je vois à quoi ça sert, mais j'ai une question.
D'après ce que j'ai compri, le QoS permet de prioriser certains type de paquet (VoIP, ping, game,...) par rapport à d'autre (FTP) en fixant des limites downspeed et upspeed
Ma question est : Est ce que ces limites sont figées ou sont elles dynamiques en QoS ?
*la* QoS (Quality of Service/Qualité de Service) ce n'est pas seulement une question de limitation de bande passante, le plus important le l'ordre de traitement des paquets dans la file d'attente. Si la file d'attente est vide, il n'y a pas de congestion et chaque paquet est transmis immédiatement, tu peux monter en débit tant qu'il n'y a pas d'accumulation de paquet dans la file d'émission, la QoS n'intervient pas.
Si par contre la file n'est pas vide, la QoS permet de prendre les paquets de tel type (téléphonie par exemple) et de les transmettre en premier même s'ils sont arrivés en dernier. Ils ne subissent donc pas la congestion (pas de bouchon pour eux, mieux que les pompiers dans le trafic urbain), c'est ce qu'on appel le trafic prioritaire (strict priority queueing). Après on peut limiter le trafic prioritaire en débit pour laisser du temps d'émission pour le reste. S'il y a trop de trafic prioritaire on peut décider de détruire le trafic prioritaire excédentaire. Dans ce cas c'est une limite *fixe* et indépendante de la présence de congestion, même quand il n'y a de congestion on ne pourra pas dépasser ce débit.
autre mécanisme qu'on trouve avec la QoS, c'est de définir des poids pour chaque type de trafic (le trafic est rangé par classe de trafic, librement défini lors de la configuration, par exemple on peut définir une classe pour le trafic FTP et TFTP, une autre pour SSH et Telnet, etc.).
la notion de poids est intéressante car elle permet de ne pas brider une classe inutilement comme vu dans l'exemple précédent, avec trois classes ayant des poids 1, 3 et 5 respectivement si une seule classe est présente, elle pourra utiliser 100% du débit. Si la classe 1 (poids 1) et la classe 2 (poids 3) sont présentes et qu'une congestion survient, pour chaque paquet de la classe 1 émis on émettra 3 paquets de la classe 2, si la congestion continue mais que le volume de trafic de la classe 2 s'amenuise, la classe 1 pourra émettre plus que 1/4 du débit (selon ce que la classe 2 laissera disponible).
c'est ce qu'on appelle CBWFQ "Class based Weigthed Fair Queue"
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut fonctionner avec une ou deux files strictement prioritaires, on peut aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour une ou plusieurs classes données (policying ou shaping), avec ici un seuil fixé et indépendant de l'état de congestion.
Merci d'avance
La Norme Française c'est pas le FN
On Tue, 05 May 2015 21:11:53 +0200, Denis Corbin wrote:
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut fonctionner avec une ou deux files strictement prioritaires, on peut aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour une ou plusieurs classes données (policying ou shaping), avec ici un seuil fixé et indépendant de l'état de congestion.
Merci pour toutes ces explications. (va faloir digerer tout ça)
Encore une question : peut on faire du "QoS" par application ? Par exemple prioriser 1 flux vidéo http par rapport à un autre. Ou un process par rapport à un autre.
Il me semble qu'il y a une appli pour ça sur windows mais je me rapelle plus du nom
On Tue, 05 May 2015 21:11:53 +0200, Denis Corbin
<news@edrusb.is-a-geek.org> wrote:
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par
exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que
les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut
fonctionner avec une ou deux files strictement prioritaires, on peut
aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour
une ou plusieurs classes données (policying ou shaping), avec ici un
seuil fixé et indépendant de l'état de congestion.
Merci pour toutes ces explications. (va faloir digerer tout ça)
Encore une question :
peut on faire du "QoS" par application ? Par exemple prioriser 1 flux
vidéo http par rapport à un autre. Ou un process par rapport à un
autre.
Il me semble qu'il y a une appli pour ça sur windows mais je me
rapelle plus du nom
On Tue, 05 May 2015 21:11:53 +0200, Denis Corbin wrote:
Je m'explique, quand le réseau fait passer peu de VoIP la nuit par exemple) est ce que le downspeed/upspeed d'un FPT augmente tant que les paquets prioritaires ne sont pas présent ?
tout va dépendre de ce que tu configures comme QoS. Nota, CBWFQ peut fonctionner avec une ou deux files strictement prioritaires, on peut aussi indépendamment de CBWFQ limiter la bande passante (le débit) pour une ou plusieurs classes données (policying ou shaping), avec ici un seuil fixé et indépendant de l'état de congestion.
Merci pour toutes ces explications. (va faloir digerer tout ça)
Encore une question : peut on faire du "QoS" par application ? Par exemple prioriser 1 flux vidéo http par rapport à un autre. Ou un process par rapport à un autre.
Il me semble qu'il y a une appli pour ça sur windows mais je me rapelle plus du nom
Denis Corbin
Le 05/05/2015 23:24, La Norme Française c'est pas le FN a écrit : [...]
Encore une question : peut on faire du "QoS" par application ? Par exemple prioriser 1 flux vidéo http par rapport à un autre. Ou un process par rapport à un autre.
oui, libre à toi de définir une classe de service qui corresponde aux flux http video... Le problème que tu auras c'est selon l'équipement que tu utilises tu ne pourras peut-être te baser que sur les ports TCP/UDP le champ DSCP, les adresses IP, etc. Si les ports UDP sont connus ou les paquets taggués (DSCP) pas de souci, si par contre il faut faire une analyse des paquets plus poussée (couche 7), tu risques de ne pas pouvoir trouver beaucoup d'équipements qui te le permettront de faire ce type de QoS (flux HTTP vidéo d'un côté, flux HTTP html de l'autre)... il faut regarder du côté des firewall à mon avis.
Il me semble qu'il y a une appli pour ça sur windows mais je me rapelle plus du nom
Le 05/05/2015 23:24, La Norme Française c'est pas le FN a écrit :
[...]
Encore une question :
peut on faire du "QoS" par application ? Par exemple prioriser 1 flux
vidéo http par rapport à un autre. Ou un process par rapport à un
autre.
oui, libre à toi de définir une classe de service qui corresponde aux
flux http video... Le problème que tu auras c'est selon l'équipement que
tu utilises tu ne pourras peut-être te baser que sur les ports TCP/UDP
le champ DSCP, les adresses IP, etc. Si les ports UDP sont connus ou les
paquets taggués (DSCP) pas de souci, si par contre il faut faire une
analyse des paquets plus poussée (couche 7), tu risques de ne pas
pouvoir trouver beaucoup d'équipements qui te le permettront de faire ce
type de QoS (flux HTTP vidéo d'un côté, flux HTTP html de l'autre)... il
faut regarder du côté des firewall à mon avis.
Il me semble qu'il y a une appli pour ça sur windows mais je me
rapelle plus du nom
Le 05/05/2015 23:24, La Norme Française c'est pas le FN a écrit : [...]
Encore une question : peut on faire du "QoS" par application ? Par exemple prioriser 1 flux vidéo http par rapport à un autre. Ou un process par rapport à un autre.
oui, libre à toi de définir une classe de service qui corresponde aux flux http video... Le problème que tu auras c'est selon l'équipement que tu utilises tu ne pourras peut-être te baser que sur les ports TCP/UDP le champ DSCP, les adresses IP, etc. Si les ports UDP sont connus ou les paquets taggués (DSCP) pas de souci, si par contre il faut faire une analyse des paquets plus poussée (couche 7), tu risques de ne pas pouvoir trouver beaucoup d'équipements qui te le permettront de faire ce type de QoS (flux HTTP vidéo d'un côté, flux HTTP html de l'autre)... il faut regarder du côté des firewall à mon avis.
Il me semble qu'il y a une appli pour ça sur windows mais je me rapelle plus du nom
