KIWI fibre optique => Opérateurs grand public alternatifs => Espace technique internet Kiwi => Discussion démarrée par: jobarjo le 12 mars 2011 à 10:48:38 KIWI fibre optique => Opérateurs grand public alternatifs => Espace technique internet Kiwi => Discussion démarrée par: jobarjo le 12 mars 2011 à 10:48:38rendre prioritaire les paquets TCP ack sortants.Pourquoi ?
- impossible de mettre un serveur VPN (ou du moins beaucoup plus difficile car 2 gateways)Je ne vois pas ce que tu veux dire.
- pas de QoS. J'imagine que le routeur n'en fait pas (à tester). La moindre des choses est de rendre prioritaire les paquets TCP ack sortants.Je ne suis pas sûr de comprendre ce que tu entends pas TCP ack sortant, encore moins pourquoi ils devraient être prioritaires.
Je ne suis pas sûr de comprendre ce que tu entends pas TCP ack sortant, encore moins pourquoi ils devraient être prioritaires.Dans TCP, le récepteur prévient l'èmetteur qu'il a bien reçu les paquets en lui envoyant des packets TCP ACK(knowledge). Si tu perds un TCP ACK, l'èmetteur ré-èmet le paquet correspondant. En général, le débit baisse beaucoup. Donc, si tu ne les rends pas prioritaires (car peu nombreux) tu perds du débit en download dès que ton lien upload est occupé.
J'ai été assez surpris de vois qu'on pouvait dropper 90% des ack sortant sans véritable impact...C'est assez normal. Sur un TCP bien rempli on cherche à maximiser la taille de la fenêtre, c'est à dire le volume maximum qui peut potentiellement être encore dans le tuyau (entré d'un coté et pas encore sortir de l'autre) à tout instant.
(enfin ca réduit un peu la Rwin car il y a des paquets acquittés que le serveur pense non acquittés.Qu'est-ce que tu entends par "serveur"? Un TCP est intrinsèquement symétrique, il n'y a pas de coté "serveur" et de coté "client", c'est une paire de tuyaux.
Dans TCP, le récepteur prévient l'èmetteur qu'il a bien reçu les paquets en lui envoyant des packets TCP ACK(knowledge).Je connais, mais je ne vois pas ce que tu appelles donner la priorité aux paquets TCP ACK, ni même ce que tu appelles un paquet TCP ACK.
Si tu perds un TCP ACK, l'èmetteur ré-èmet le paquet correspondant. En général, le débit baisse beaucoup. Donc, si tu ne les rends pas prioritaires (car peu nombreux) tu perds du débit en download dès que ton lien upload est occupé.Non, l'èmetteur ré-èmet le paquet :
les routeurs adsl ont souvent un vilain défaut, ils mémorisent les paquets à èmettre pour en perdre le moins possible (jusqu'à plusieurs secondes)Sans ce buffer, on aurait de nombreuses pertes de paquets, TCP envoyant des paquets en nombre a des vitesse plus élevée que la liaison physique. Sur un accés 3G, les buffers sont petit et on est obligé de mettre une petite Rwin pour ne pas perdre de paquets.
Je connais, mais je ne vois pas ce que tu appelles donner la priorité aux paquets TCP ACK, ni même ce que tu appelles un paquet TCP ACK.Vu :
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10Je ne connaissais pas trop la commande tc et le manuel de "tc filter" manque à l'appel, mais si je ne me trompe pas, ça veut dire :tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1- et que l'en-tête IP fait exactement 20 octets (taille minimum, aucune option IP)Le problème c'est qu'aujourd'hui il est conseillé d'utiliser les timestamp, donc d'activer les options.
Sans ce buffer, on aurait de nombreuses pertes de paquets, TCP envoyant des paquets en nombre a des vitesse plus élevée que la liaison physique. Sur un accés 3G, les buffers sont petit et on est obligé de mettre une petite Rwin pour ne pas perdre de paquets.Si tu envoies plus de données que la liaison ne le permet, tu vas perdre des paquets : il y a pas de miracle!
Non, l'èmetteur ré-èmet le paquet :ou quand SACK n'est pas géré par les deux extrémités :
- Si il reçoit un paquet SACK lui indiquant un paquet manquant.
Le principe même d'un protocole de transport régulé (comme TCP) est d'arriver à perdre des paquets. Si tu ne perds pas de paquets c'est que tu n'as utilisé toute la capacité du lien.
Le problème c'est qu'aujourd'hui il est conseillé d'utiliser les timestamp, donc d'activer les options.Non : TCP Extensions for High Performance
Donc les l'en-tête IP dépasse 20 octets. (RFC 1323 http://www.ietf.org/rfc/rfc1323.txt (http://www.ietf.org/rfc/rfc1323.txt))
TCP calcul la latence afin d'optimiser le débit sans perdre de paquet.C'est ce que je dis : avec la file d'attente de capacité ridiculement grande dont parle jobarjo, la latence est aléatoire, on ne peut pas la mesurer : quand la file d'attente sera de taille raisonnable tu vas avoir une latence en rapport avec la technologie de lien employée, quand la file d'attente grandira ridiculement ("jusqu'à plusieurs secondes"), la latence sera démultipliée.
Cela nécessite un buffer...Où ça?
Ces calculs sont d'ailleurs très bien fait : on perd très peu de paquet avec TCP en étant très très proche du débit maximal de la ligne.Pour connaitre la hauteur du plafond il faut quand même s'y cogner.
To speed up downloads while an upload is going on, put ACK packets in the interactive classQu'est-ce qu'un "ACK packet"?
paquets TCP d'une taille inférieure à 64 octets, c'est à dire ayant moins de 24 octets d'options TCP et de données utiles.Cela signifie que les connexions utilisées en down pur sont optimisées, notamment quand on a
A>B GET une_url + quelques en-têtes
B>A 200 OK + quelques en-têtes + beaucoup de données
et de A>B PUT une_url + quelques en-têtes + beaucoup de données
B>A 200 OK + quelques en-têtes
c'est à dire des connexions avec taille(données dans un sens) >> taille(données dans l'autre sens).Dans TCP, le récepteur prévient l'èmetteur qu'il a bien reçu les paquets en lui envoyant des packets TCP ACK(knowledge). Si tu perds un TCP ACK, l'èmetteur ré-èmet le paquet correspondant. En général, le débit baisse beaucoup. Donc, si tu ne les rends pas prioritaires (car peu nombreux) tu perds du débit en download dès que ton lien upload est occupé.Je dirais qu'ils ne sont pas spécialement peu nombreux, mais qu'ils sont pas très gros et donc n'occupent pas le lien très longtemps.
La freebox le fait d'office depuis pas mal d'années, çà change beaucoup la qualité du service.En "mode routeur"?
Mais si tu upload pas, çà ne se voit pas. Le test est de simplement de downloader pendant que tu upload.
Donc les l'en-tête IP dépasse 20 octets.Pour voir ces paquets avec Wireshark, utiliser le filtre "ip.hdr_len > 20"
Mais une connexion TCP réellement utilisée dans les deux sens en même temps n'aura pas "ACK packet", elle ne sera donc pas "speed up"!Oui c'est vrai que j'avais pas pensé qu'un paquet avec le flag ACK pouvait contenir des données.
Pour moi, ça montre que c'est du bricolage.
Vu :La description de match (http://lartc.org/howto/lartc.adv-filter.html#AEN1289) : c'est exactement ce que je supposais :Code: [Sélectionner]# To speed up downloads while an upload is going on, put ACK packets inJe ne connaissais pas trop la commande tc et le manuel de "tc filter" manque à l'appel, mais si je ne me trompe pas, ça veut dire :
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
match TYPE VAL MASQ at OFF signifie en C :bool test (char *p) // p pointe sur le début de paquet
{
return (*(TYPE *) (p+OFF)) & MASQ == VAL;
}
Code: [Sélectionner]## match acks the hard way,
## IP protocol 6,
## IP header length 0x5(32 bit words),
## IP Total length 0x34 (ACK + 12 bytes of TCP options)
## TCP ack set (bit 5, offset 33)
# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:3
match u16 0x0000 0xffc0 at 2 en C :(*(u16*)(p+2)) & 0xffc0 == 0x0000 or 0xffc0 égal ~ 0x3F en calculant en u16 (voir remarque)| x & 0xffc0 | = x & ~ 0x3F |
| = x / 0x40 * 0x40 |
x & 0xffc0 == 0x0000x / 0x40 * 0x40 == 0x / 0x40 == 0x < 0x40or x = *(u16*)(p+2) correspond à la taille du paquet donc :0xffc0 == ~ (u16) 0x3Fça n'est valable que si int fait 16 bits, sinon l'integral promotion de (u16) 0x3F va en faire un unsigned int et ~ (u16) 0x3F vaudra ~ (unsigned int) 0x3F qui sera supérieur à 0xFFC0.
Un bug Windows fait que le système d'exploitation de Microsoft n'arrive pas activés les timestamps quand en face le serveur est Linux.Sur les autres OS, combien de paquets apparaissent quand on fait :
Linux représente la majorité des serveurs web et donc dans la majorité des cas les timestamps ne sont pas activés...
Fait le même test avec un autre système d'exploitation (MacOS, Linux, FreeBSD, ...). Les timestamps seront activés.
Pour voir ces paquets avec Wireshark, utiliser le filtre "ip.hdr_len > 20"et n'ont pas "router alert"?
Donc les l'en-tête IP dépasse 20 octets.Si je comprends bien la doc, pour gérer ce cas il faut utiliser : at nexthdr + TCP_OFFSET
La freebox le fait d'office depuis pas mal d'années, çà change beaucoup la qualité du service.La Freebox priorise les ACK depuis plusieurs années ?
Mais si tu upload pas, çà ne se voit pas. Le test est de simplement de downloader pendant que tu upload.
Mais une connexion TCP réellement utilisée dans les deux sens en même temps n'aura pas "ACK packet", elle ne sera donc pas "speed up"!C'est vrai mais dans la grande majorité des cas, c'est du http et tu n'utilise qu'un sens (a part faire des demande pour télécharger des images / pages).
Pour moi, ça montre que c'est du bricolage.
La Freebox priorise les ACK depuis plusieurs années ?Je ne vois qu'une façon de tester : comparer
Je ne voit pas dans le menu de configuration une option a activer, normal ?
C'est vrai mais dans la grande majorité des cas, c'est du http et tu n'utilise qu'un sens (a part faire des demande pour télécharger des images / pages).À part quand le pipelining est mis en œuvre (ce qui pose parfois problème), HTTP n'utilise jamais qu'un sens à la fois.
La description de match (http://lartc.org/howto/lartc.adv-filter.html#AEN1289) : c'est exactement ce que je supposais :Ce raisonnement, juste pour analyser une partie d'une commande "tc filter ... match", c'est quand même très laborieux.Code: [Sélectionner]match TYPE VAL MASQ at OFFsignifie en C :Code: [Sélectionner]bool test (char *p) // p pointe sur le début de paquet
{
return (*(TYPE *) (p+OFF)) & MASQ == VAL;
}
L'exemple donné dans la doc correspond exactement :
Sauf que le commentaire "IP Total length 0x34 " est faux : en fait 0x34 n'apparait même pas dans le filtre!
Il faut traduire :Code: [Sélectionner]match u16 0x0000 0xffc0 at 2en C :Code: [Sélectionner](*(u16*)(p+2)) & 0xffc0 == 0x0000or 0xffc0 égal ~ 0x3F en calculant en u16 (voir remarque)
doncdonc les conditions suivantes sont équivalentes :
x & 0xffc0 = x & ~ 0x3F = x / 0x40 * 0x40 Code: [Sélectionner]x & 0xffc0 == 0x0000Code: [Sélectionner]x / 0x40 * 0x40 == 0Code: [Sélectionner]x / 0x40 == 0Code: [Sélectionner]x < 0x40or x = *(u16*)(p+2) correspond à la taille du paquet donc :taille du paquet est < 0x40
En fait, le réel problème est que les routeurs adsl ont souvent un vilain défaut, ils mémorisent les paquets à èmettre pour en perdre le moins possible (jusqu'à plusieurs secondes).Tous? Lesquels?
Le script wondershaper réglait efficacement ce problème.pour un cas précis.
Il se trouve qu'après quelques années, ce script n'était plus nécéssaire chez free à la suite d'un update de leur part. Ils n'ont pas précisé quels algorithmes de QOS ils ont utilisés, mais le problème était réglé.Ni même si une QOS quelconque était à l'œuvre, ou si autre chose que la QOS a été modifié.
Ce sont les auteurs de wondershaper qui indiquent que la plupart des modems (peut être de l'époque?) ont ce problème. En effet, aux débuts de l'internet, et même de l'adsl, il n'était même pas autorisé de partager la ligne internet entre plusieurs utilisateurs chez la plupart des FAI.Je n'ai connaissance de ce genre de clause qu'avec un abonnement câble. De toute façon c'est parfaitement inapplicable : de l'extérieur, plusieurs PC derrière un SNAT apparaissent comme un seul PC.
Cà explique pourquoi les fabricants choisissaient la bête FIFO pour perdre le moins de paquets possible.Je ne suis pas certain que la bête FIFO perde le moins de paquets, cela dépend de beaucoup de paramètres.
Je n'ai connaissance de ce genre de clause qu'avec un abonnement câble. De toute façon c'est parfaitement inapplicable : de l'extérieur, plusieurs PC derrière un SNAT apparaissent comme un seul PC.Avant, avec Wanadoo il était interdit de partager sa connexion (c'était avant l’arrivée de la livebox)
Avant, avec Wanadoo il était interdit de partager sa connexion (c'était avant l’arrivée de la livebox)Comment ils contrôlaient ça?
From : Maxime Bizon
Date : Fri, 01 Jul 2005 19:49:07 +0200
User-Agent : Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
Bonsoir,
Un nouveau firmware a été déployé pour les Freebox v3 et v4 des dégroupés et non dégroupés.
Au menu :
- correction du bug de débit apparaissant avec certains modèles de cartes Wifi (chipset TI).
- il est maintenant possible de rediriger des plages complètes de ports, l’interface de configuration du mode routeur a été mise à jour. L’interface sur le téléviseur les fait également apparaître.
- pour les _dégroupés uniquement_, les redirections en mode routeur fonctionnent désormais en interne.
- l’interface permettant de récuperer les informations techniques de la Freebox sur le téleviseur et maintenant disponible pour les non dégroupés.
- gestion de QOS en upstream, que ce soit en mode bridge ou en mode routeur. la Freebox procède désormais à une gestion intelligente du
traffic sortant. Le champ TOS des paquets émis est examiné, et chaque queue possède un gestionnaire intelligent et juste (SFQ). Ainsi un gros upload ne perturbe plus le surf.
- et... le Freeplayer ! Toutes les informations à ce sujet sont sur http://adsl.free.fr/tv/freeplayer/ (http://adsl.free.fr/tv/freeplayer/)
Vous pouvez mettre à jour votre Freebox en redémarrant simplement celle-ci.
—
Maxime
Oui c'est vrai que j'avais pas pensé qu'un paquet avec le flag ACK pouvait contenir des données.Tous les paquets sauf le premier d'une connexion TCP indiquent un numéro ACK.
Finalement, une solution plus "universelle" est de faire une queue par flow, et d'utiliser un algorithme comme le SFQ (http://lartc.org/howto/lartc.qdisc.classless.html#LARTC.SFQ) dans l'ONT (au niveau de la congestion)Ce qui est plus propre.
Sinon, aucune réponse de kiwi sur le bug du port entrant à mes 2 emails. C'est très pénible d'accéder au service de 2 manières différentes selon que je sois à l'intérieur ou à l'extérieur de mon réseau. Impossible d'exploiter correctement la ligne internet avec la box.Tu as quoi comme OS sur tes machines?