Taille de la fenêtre TCP, faut-il vraiment s'en occuper ?

Taille de la fenêtre TCP, faut-il vraiment s'en occuper ? - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 02-07-2007 à 20:53:56    

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

Reply

Marsh Posté le 02-07-2007 à 20:53:56   

Reply

Marsh Posté le 03-07-2007 à 09:10:21    

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

Reply

Marsh Posté le 03-07-2007 à 11:10:14    

Reply

Marsh Posté le 03-07-2007 à 11:54:35    

Taz a écrit :

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


 
 
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....

Reply

Marsh Posté le 04-07-2007 à 10:07:12    


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.

Reply

Marsh Posté le 04-07-2007 à 10:51:32    

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]
 

Code :
  1. ########## Flux descendant (downlink) #############
  2. # Ralentir le flux descendant à une valeur légèrement plus faible que votre
  3. # vitesse rélle de manière à éviter la mise en file d'attente chez notre
  4. # FAI. Faites des tests pour voir la vitesse maximum à laquelle vous pouvez
  5. # le configurer. Les FAI ont tendance à avoir *d'énormes* files d'attente
  6. # pour s'assurer de la rapidité des gros téléchargements.
  7. #
  8. # attache la réglementation d'entrée (ingress policer) :
  9. tc qdisc add dev $DEV handle ffff: ingress
  10. # Filtre *tout* (0.0.0.0/0), rejette tout ce qui arrive trop
  11. # rapidement :


 
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


Message édité par redvivi le 04-07-2007 à 10:51:53
Reply

Marsh Posté le 04-07-2007 à 10:59:10    

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


Message édité par Taz le 04-07-2007 à 10:59:16
Reply

Marsh Posté le 04-07-2007 à 13:41:19    

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.
 

Reply

Marsh Posté le 04-07-2007 à 15:49:49    

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

Code :
  1. CEIL=240
  2. tc qdisc add dev eth0 root handle 1: htb default 15
  3. tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
  4. tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil ${CEIL}kbit prio 0
  5. tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
  6. tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
  7. tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
  8. tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
  9. tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
  10. tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
  11. tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
  12. tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
  13. tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10
  14. tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
  15. tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
  16. tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
  17. tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
  18. tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
  19. tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15
  20. ####DEBUT CLASSIFICATION
  21. iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
  22. iptables -t mangle -A PREROUTING -p icmp -j RETURN
  23. iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
  24. iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
  25. iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
  26. iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN


 
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

Reply

Marsh Posté le 04-07-2007 à 15:57:42    

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.

Message cité 1 fois
Message édité par l0ky le 04-07-2007 à 16:13:48
Reply

Marsh Posté le 04-07-2007 à 15:57:42   

Reply

Marsh Posté le 04-07-2007 à 16:00:49    

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 !?

Reply

Marsh Posté le 04-07-2007 à 16:09:32    

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


Message édité par l0ky le 04-07-2007 à 16:15:41
Reply

Marsh Posté le 04-07-2007 à 16:14:16    

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 ?

Reply

Marsh Posté le 04-07-2007 à 16:15:55    

l0ky a écrit :

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.


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

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed