Bonjour à tous !
 
          Je suis en train de mettre en place un système de limitation de débit avec WonderShaper, globalement le principe est de déplacer la file d'attente du modem vers l'interface Ethernet afin de pouvoir agir sur cette file d'attente, ça ne pose pas de problème du point de vue de l'upload, par contre, pour le download, il est indiqué que la meilleure chose à faire est de dropper quelques paquets si ils arrivent trop vite, ce qui donne lieu à un ralentissement de la transmission (donc un débit moindre et on évite les congestions sur le download), par contre celà nécessite une retransmission des paquets, donc une utilisation non nécessaire de la bande passante....
 
L'auteur indique que l'on peut agir sur la fenetre TCP, visiblement, avec les nouveaux noyaux (exemple Debian Etch), celà est possible...ma question est la suivante: J'ai vu que la modification de la fenetre TCP pouvait provoquer de graves problèmes de transmissions à cause des équipements qui ne supportent pas ceci (fort ralentissement du traffic), quels sont les types d'équipements concernés ? Ce sont les équipement anciens ? nouveaux ? Celà vaut il la peine de s'en occuper ?
 
Merci d'avance!
RedVivi

wof, dropper un paquet que tu as reçu de ton WAN, c'est vraiment idiot et couteux. T'as un lien sur la modif de rwin ? ça me paraît assez compliqué à faire comme truc. Pour ralentir les paquets en arrivée, mieux vaudrait peut-être faire un peu de rétention sur ton routeur, quelques ms en cas de congestion

Voici le lien: http://web2news.ac-versailles.fr/a [...] 85c855d797

 
 
Celà dépend du taux de paquets perdus dans le cadre de la congestion, le problème c'est que j'ai aucune idée de la grandeur de cette valeur, si 30% des paquets sont retransmis ça pose problème, si c'est 2% ce n'est pas trop génant. En fait au niveau de la gestion de la bande passante come je l'ai dit le problème provient du download que l'on ne peut controler....

Absolument aucun rapport.
 
Si y a des équipements qui ont du mal à suivre des RFC vieux de 15ans, dommage pour eux. Surtout que le RFC n'est pas imcompatible avec l'existant. Et dans ce cas, ils sont surtout tres mauvais de ne pas arriver à suivre le rythme d'une pauvre session TCP, d'imposer des limites arbitraires, de ne pas etre capable de détecter une pauvre option TCP (pour éventuellement la supprimer). Même windows supporte ça modulo une clef de registre.
La solution est d'ailleurs de toucher à /proc/sys/net/ipv4/tcp_window_scaling et pas à net.ipv4.tcp_moderate_rcvbuf
 
Bref, je ne vois pas le rapport avec ton message initial. Je ne connais pas de routeur qui modifie les fenêtres TCP des sessions qu'ils routent. Je ne comprends pas ton message mélange de TCP et de traffic shaping.

Exact pour le tcp_window_scaling, pour plus d'informztions par rapport au traffic shaping et le TCP, jette un coup d'oeil au code de http://www.traduc.org/docs/HOWTO/v [...] HOWTO.html
 
[Extrait]
 

 
On rejette ce qui arrive trop vite pour diminuer le taux de transfert (on joue sur le controle d'erreur de TCP), on peut éviter de jouer sur le controle d'erreur en modifiant la fenetre TCP

nan mais dans l'histoire, c'est toi qui comprends pas bien... ce qui se passe côté router et côté endpoint... tipoftheday: la fenêtre TCP, elle passe son temps à changer.

et laisse tomber tc, utilise tcng.

et je sors

Il est intéressant de jouer sur la fenêtre TCP quand les délais de transite sont important (lien satellite), dans ce cas il faut de base ouvrir au maximum la fenêtre dés le début de la transmission.
Sinon tout dépend des équipements traversés (taille des buffers) et de ce qu'on veut obtenir en jouant sur cette fenêtre.  
Les sondes de type Ipanema ou Packeteer qui font de la gestion fine de bande passante, à priori comme ton soft que je ne connais pas, vont utiliser des buffers pour vider tous ceux des équipements réseaux entre 2 sondes (pour ne pas provoquer de congestion dans le réseau) et ensuite "jouer" avec les fenêtres TCP des applications pour contrôler le trafic.
Pour Taz: le lien entre TCP et traffic shaping c'est ce que je viens d'expliquer, le mécanisme de partage de bande passante utilise le fonctionnement des fenêtres TCP pour contrôle le flux (pour un état stationnaire, pas sur des burst ponctuels, elles ont des temps de réaction au mieux de l'ordre de la minute). C'est très efficace sur tu TCP, mais bien sur l'UDP casse ce fonctionnement. La gestion des fenêtres TCP n'est donc pas le seul mécanisme utiliser pour gérer le partage de bande passante.
 

Ok merci pour les précisions pour la fenetre TCP ! Par contre j'ai une dernière question:
 

 
Je ne comprends pas la signification de 0x1, 0x5....car ces marques ne correspondent (apparemment) à aucune file d'attente, ce serait plus logique de mettre --set-mark <numero de classid>, genre --set-mark 13 etc.....
 
Merci beaucoup !
RedVivi

c'est la valeur du champ TOS du header du paquet IP

ces valeurs sont utilisées seulement par netfilter (cf le man d'iptables). tc les utilisent ensuite.

Les quelques lignes de script que j'ai posté sont susceptibles de gérer le traffic....Mais je ne vois pas la logique du script, pour moi les numéros de file d'attentes et les files d'attentes ne sont pas utilisées !?

les lignes "tc filter..." placent le trafic dans les bonnes files en fonction de la marque précédente

Okaayy ! Merci ! Est-ce que quelqu'un a déjà fait de la gestion de bande passante de cette sorte (retour d'expérience) ? vaut il mieux plein de règles avec un classificateur genre l7 filter plutot que peu de règle avec le TOS ?
 
Pourquoi utiliser tcng plutot que tc ?

 
 
Est-il plus judicieux d'utiliser cette notation ou alors le numéro de file d'attente ?