Le truc c'est que quand on fait de la QoS, limiter le flux descendant ne sert quasiment à rien. C'est l'upload qui détermine tout.
Explications :
Si un téléchargement est en train d'occuper plein de BP qui fait que le surf sur le web va lentement, et qu'on choisit de "dropper" des paquets de ce gros flux (que ce soit au niveau du DSLAM ou du routeur/*box), l'ordi qui télécharge va juste ACKer les paquets bien arrivés et NACKer les autres, ce qui fait que le serveur en face va en envoyer encore plus pour compenser les paquets "perdus". Ce qui ne va pas arranger la situation.
Quand un serveur envoie du traffic à une machine (qui à priori dans notre cas a un débit plus faible), il va envoyer à bloc au départ et s'adapter en fonction du rythme des ACK de la machine cliente en face. Et c'est donc le rythme d'upload de la machine cliente qui va déterminer la vitesse d'envoi pour le serveur, que ce rythme soit limité parce que l'upload est saturé (genre, quand le client fait du P2P) ou parce que le download l'est (la ligne n'a pas un assez gros début descendant, les paquets font la queue avant le client (genre au DSLAM) et que donc le client ne peut pas ACKer des paquets qu'il n'a pas encore reçu).
Tout ça est géré par TCP, c'est le principe du protocole.
Par contre, pour la TV et le téléphone, je pense que c'est géré autrement car déjà ce n'est pas du TCP, mais par contre c'est du non-connecté donc avec potentielle perte de paquet, mais ça ne fait pas grand chose car ce sont des services "temps réel" donc où on ne renvoit rien si ça foire. De plus, ces débits sont souvent fixes, ce qui facilite le dimensionnage de la QoS descendante.
[^] # Re: QoS
Posté par benoar . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 1.
Explications :
Si un téléchargement est en train d'occuper plein de BP qui fait que le surf sur le web va lentement, et qu'on choisit de "dropper" des paquets de ce gros flux (que ce soit au niveau du DSLAM ou du routeur/*box), l'ordi qui télécharge va juste ACKer les paquets bien arrivés et NACKer les autres, ce qui fait que le serveur en face va en envoyer encore plus pour compenser les paquets "perdus". Ce qui ne va pas arranger la situation.
Quand un serveur envoie du traffic à une machine (qui à priori dans notre cas a un débit plus faible), il va envoyer à bloc au départ et s'adapter en fonction du rythme des ACK de la machine cliente en face. Et c'est donc le rythme d'upload de la machine cliente qui va déterminer la vitesse d'envoi pour le serveur, que ce rythme soit limité parce que l'upload est saturé (genre, quand le client fait du P2P) ou parce que le download l'est (la ligne n'a pas un assez gros début descendant, les paquets font la queue avant le client (genre au DSLAM) et que donc le client ne peut pas ACKer des paquets qu'il n'a pas encore reçu).
Tout ça est géré par TCP, c'est le principe du protocole.
Par contre, pour la TV et le téléphone, je pense que c'est géré autrement car déjà ce n'est pas du TCP, mais par contre c'est du non-connecté donc avec potentielle perte de paquet, mais ça ne fait pas grand chose car ce sont des services "temps réel" donc où on ne renvoit rien si ça foire. De plus, ces débits sont souvent fixes, ce qui facilite le dimensionnage de la QoS descendante.