Auteur Sujet: QoS : rendre prioritaire les paquets TCP ack sortants (Lu 18057 fois)

corrector · « **Réponse #12 le:** 12 mars 2011 à 14:17:51 »

Citation de: vivien le 12 mars 2011 à 12:11:34

Non, l'èmetteur ré-èmet le paquet :
- Si il reçoit un paquet SACK lui indiquant un paquet manquant.

ou quand SACK n'est pas géré par les deux extrémités :
- si il reçoit un certain nombre de ACK identiques, ce qui indique que des segments sont arrivés qui sont postérieurs à un premier segment qui n'est pas arrivé

vivien · « **Réponse #13 le:** 12 mars 2011 à 14:18:07 »

Citation de: corrector le 12 mars 2011 à 14:06:44

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.

TCP calcul la latence afin d'optimiser le débit sans perdre de paquet. Cela nécessite un buffer...
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.

corrector · « **Réponse #14 le:** 12 mars 2011 à 14:23:45 »

Citation de: vivien le 12 mars 2011 à 13:56:12

Le problème c'est qu'aujourd'hui il est conseillé d'utiliser les timestamp, donc d'activer les options.
Donc les l'en-tête IP dépasse 20 octets. (RFC 1323 http://www.ietf.org/rfc/rfc1323.txt)

Non : TCP Extensions for High Performance

corrector · « **Réponse #15 le:** 12 mars 2011 à 14:28:43 »

Citation de: vivien le 12 mars 2011 à 14:18:07

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.

Citation de: vivien le 12 mars 2011 à 14:18:07

Cela nécessite un buffer...

Où ça?

Citation de: vivien le 12 mars 2011 à 14:18:07

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.

corrector · « **Réponse #16 le:** 16 mars 2011 à 04:59:18 »

Citer

To speed up downloads while an upload is going on, put ACK packets in the interactive class

Qu'est-ce qu'un "ACK packet"?

Citation de: corrector le 12 mars 2011 à 12:54:13

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
- un client qui download un fichier
- un serveur qui upload un fichier

La notion de paquet ACK correspond à l'utilisation d'un circuit quasiment en sens unique, sur le modèle de :

Code: [Sélectionner]

A>B GET une_url + quelques en-têtes
B>A 200 OK + quelques en-têtes + beaucoup de données

et de

Code: [Sélectionner]

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

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

Pour moi, ça montre que c'est du bricolage.

corrector · « **Réponse #17 le:** 16 mars 2011 à 05:12:58 »

Citation de: jobarjo le 12 mars 2011 à 11:31:30

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.

Citation de: jobarjo le 12 mars 2011 à 11:31:30

La freebox le fait d'office depuis pas mal d'années, çà change beaucoup la qualité du service.
Mais si tu upload pas, çà ne se voit pas. Le test est de simplement de downloader pendant que tu upload.

En "mode routeur"?

corrector · « **Réponse #18 le:** 19 mars 2011 à 22:53:08 »

Citation de: vivien le 12 mars 2011 à 13:56:12

Donc les l'en-tête IP dépasse 20 octets.

Pour voir ces paquets avec Wireshark, utiliser le filtre "ip.hdr_len > 20"

J'ai fais un sondage, et je n'ai vu que de l'IGMP avec l'option "router alert".

vivien · « **Réponse #19 le:** 20 mars 2011 à 22:56:56 »

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.

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.

jobarjo · « **Réponse #20 le:** 29 mars 2011 à 10:28:32 »

Citation de: corrector le 16 mars 2011 à 04:59:18

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

Pour moi, ça montre que c'est du bricolage.

Oui c'est vrai que j'avais pas pensé qu'un paquet avec le flag ACK pouvait contenir des données.
Cette optimisation concerne donc principalement des uploads de gros fichiers, ce qui est déja une bonne chose. Mais j'avais pas tilté que çà causerait un désordonnement.

Après avoir regardé plus longuement TCP, j'ai vu qu'il existe d'autres moyens de gérer la contention sans perdre trop de paquets.
Par exemple, l'explicit congestion notification, semble bien. Mais c'est désactivé par défaut sous windows 7.

Finalement, une solution plus "universelle" est de faire une queue par flow, et d'utiliser un algorithme comme le SFQ dans l'ONT (au niveau de la congestion)

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.

corrector · « **Réponse #21 le:** 22 mai 2011 à 06:38:12 »

Citation de: corrector le 12 mars 2011 à 12:54:13

Vu :
Code: [Sélectionner]
# 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 :

La description de match : c'est exactement ce que je supposais :

Code: [Sélectionner]

match TYPE VAL MASQ at OFF signifie 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 :

Citer

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

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 2 en C :

Code: [Sélectionner]

(*(u16*)(p+2)) & 0xffc0 == 0x0000 or 0xffc0 égal ~ 0x3F en calculant en u16 (voir remarque)
donc

x & 0xffc0	= x & ~ 0x3F
	= x / 0x40 * 0x40

donc les conditions suivantes sont équivalentes :

Code: [Sélectionner]

x & 0xffc0 == 0x0000

Code: [Sélectionner]

x / 0x40 * 0x40 == 0

Code: [Sélectionner]

x / 0x40 == 0

Code: [Sélectionner]

x < 0x40or x = *(u16*)(p+2) correspond à la taille du paquet donc :

taille du paquet est < 0x40

Remarque :

Ne pas supposer qu'en C:

Code: [Sélectionner]

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.

corrector · « **Réponse #22 le:** 22 mai 2011 à 07:18:44 »

Citation de: vivien le 20 mars 2011 à 22:56:56

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.

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.

Sur les autres OS, combien de paquets apparaissent quand on fait :

Citation de: corrector le 19 mars 2011 à 22:53:08

Pour voir ces paquets avec Wireshark, utiliser le filtre "ip.hdr_len > 20"

et n'ont pas "router alert"?

Combien de paquets correspondent au critère :

tcp and ip.hdr_len > 20

corrector · « **Réponse #23 le:** 22 mai 2011 à 07:22:18 »

Citation de: vivien le 12 mars 2011 à 13:56:12

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
au lieu de : at IP_OFFSET

Mais je demande à voir quels sont les paquets TCP qui ont des options IP.

Auteur Sujet: QoS : rendre prioritaire les paquets TCP ack sortants (Lu 18057 fois)

corrector

QoS : rendre prioritaire les paquets TCP ack sortants

vivien

QoS : rendre prioritaire les paquets TCP ack sortants

corrector

QoS : rendre prioritaire les paquets TCP ack sortants

corrector

QoS ACK prioritaire

corrector

QoS ACK prioritaire

corrector

QoS ACK prioritaire

corrector

QoS ACK prioritaire

vivien

QoS ACK prioritaire

jobarjo

QoS : rendre prioritaire les paquets TCP ack sortants

corrector

Syntaxe de "tc filter add ... protocol ip ... u32 match"

corrector

Wireshark : "tcp and ip.hdr_len > 20"

corrector

"tc filter add ... protocol ip ... u32 match TYPE ... at nexthdr +", options IP