Bon, c'est vrai que pour le fonctionnement de TCP je me suis un peu trompé, même si la deuxième partie de ton explication correspond à ce que je décrivais : on pousse jusqu'au max possible avant de perdre des paquets, et là on diminue un peu.
Sauf que *les* algorithmes en jeu sont un peu plus compliqués que ça. D'une part, globalement on fait de l'Additive Increase Multiple Decrease (AIMD) ce qui signifie que tous les algorithmes contrôlant la taille de la fenêtre la font toujours décroître plus violemment qu'ils ne la font croître. C'est l'origine du fameux comportement oscillatoire de TCP quand on graphe une session.
Par contre ce qu'on voit aussi quand on graphe une session, c'est que au début ça monte très vite et après ça fait de plus petites oscillations autour du débit optimal. C'est parce que au début d'une session ou juste après la détection d'une congestion, on est en Slow Start (ou en Fast Recovery dans des piles plus modernes) qui est un algorithme qui croît exponentiellement. Une fois qu'on a passé un certain seuil (qui typiquement dépend du Maximum Segment Size négocié en début de session), on bascule en Congestion Avoidance qui lui croît de façon linéaire.
Grosso modo, on a un comportement plutôt très sensible à la congestion qui peut rapidement diminuer le débit et le ramener à un débit stable autour du débit optimal sans perte. C'est en cela que le shaping marche.
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Il le voit en fonction des ACK effectivement. Mais il surveille aussi le timing de ces ACK (ou surtout de leur absence ou celui des dupliqués). D'ailleurs on dit parfois qu'une session TCP est guidée par une horloge à ACK (ACK Clock, expression de Van Jacobson). Ca passe par le RTO (retransmission timeout) qui est calculé en fonction du temps d'aller-retour (round-trip time, RTT) et de sa variation. Ca veut dire que plus j'ai de trafic plus je suis considéré comme sensible à la congestion et donc plus la granularité de mon horloge à ACK est élevée et plus je retransmets facilement.
Bref, si tu réintroduis ce que j'ai expliqué sur Slow Start et Congestion Avoidance, ça veut dire que si tu shape que dans sur le descendant (par rapport au client), tu vas certes répondre vite et provoquer une détection rapide de congestion mais à cause de la nature AIMD des algorithmes utilisés, tu vas aussi oscillé plus vite et aller te stabiliser plus vite autour du débit optimal sans perte, c'est-à-dire celui qui correspond au shaping.
C'est pour ça qu'il y avait des tutoriaux pour OpenBSD PF qui montraient comment prioritiser les ACK sur tes sessions SSH pour bien garder l'interactivité d'une telle session TCP.
C'est mon avis et je le partage.
PS : TCP on dit souvent que c'est dans la RFC 793 mais il faut au moins rajouter la 896, 1122, la 1323, la 2001, la 2585 sans parler de toutes celles qui fleurissent sur des modifications des algorithmes d'évitement de congestion soit dans des cas généraux (genre l'Appropriate Byte Counting qu'il y a sous Linux) soit dans des cas particuliers (il y a des algorithmes plus mieux pour les liens qui tendent naturellement à avoir plus de pertes sans que ça indique une congestion comme le sans-fil).
[^] # Re: QoS
Posté par vjm . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 4.
Sauf que *les* algorithmes en jeu sont un peu plus compliqués que ça. D'une part, globalement on fait de l'Additive Increase Multiple Decrease (AIMD) ce qui signifie que tous les algorithmes contrôlant la taille de la fenêtre la font toujours décroître plus violemment qu'ils ne la font croître. C'est l'origine du fameux comportement oscillatoire de TCP quand on graphe une session.
Par contre ce qu'on voit aussi quand on graphe une session, c'est que au début ça monte très vite et après ça fait de plus petites oscillations autour du débit optimal. C'est parce que au début d'une session ou juste après la détection d'une congestion, on est en Slow Start (ou en Fast Recovery dans des piles plus modernes) qui est un algorithme qui croît exponentiellement. Une fois qu'on a passé un certain seuil (qui typiquement dépend du Maximum Segment Size négocié en début de session), on bascule en Congestion Avoidance qui lui croît de façon linéaire.
Grosso modo, on a un comportement plutôt très sensible à la congestion qui peut rapidement diminuer le débit et le ramener à un débit stable autour du débit optimal sans perte. C'est en cela que le shaping marche.
Bah oui que ça ralentit l'émission, puisque le client n'a pas reçu les paquets. Mais le serveur, lui, ne voit pas que t'as perdu des paquets magiquement : il le voit en fonction de ton émission des ACKs. C'est pour ça que j'en couclue que c'est bien l'upload qui détermine la vitesse de download (quand on shape, hein, et dans la limite de la taille de connexion en download bien sûr)...
Il le voit en fonction des ACK effectivement. Mais il surveille aussi le timing de ces ACK (ou surtout de leur absence ou celui des dupliqués). D'ailleurs on dit parfois qu'une session TCP est guidée par une horloge à ACK (ACK Clock, expression de Van Jacobson). Ca passe par le RTO (retransmission timeout) qui est calculé en fonction du temps d'aller-retour (round-trip time, RTT) et de sa variation. Ca veut dire que plus j'ai de trafic plus je suis considéré comme sensible à la congestion et donc plus la granularité de mon horloge à ACK est élevée et plus je retransmets facilement.
Bref, si tu réintroduis ce que j'ai expliqué sur Slow Start et Congestion Avoidance, ça veut dire que si tu shape que dans sur le descendant (par rapport au client), tu vas certes répondre vite et provoquer une détection rapide de congestion mais à cause de la nature AIMD des algorithmes utilisés, tu vas aussi oscillé plus vite et aller te stabiliser plus vite autour du débit optimal sans perte, c'est-à-dire celui qui correspond au shaping.
C'est pour ça qu'il y avait des tutoriaux pour OpenBSD PF qui montraient comment prioritiser les ACK sur tes sessions SSH pour bien garder l'interactivité d'une telle session TCP.
C'est mon avis et je le partage.
PS : TCP on dit souvent que c'est dans la RFC 793 mais il faut au moins rajouter la 896, 1122, la 1323, la 2001, la 2585 sans parler de toutes celles qui fleurissent sur des modifications des algorithmes d'évitement de congestion soit dans des cas généraux (genre l'Appropriate Byte Counting qu'il y a sous Linux) soit dans des cas particuliers (il y a des algorithmes plus mieux pour les liens qui tendent naturellement à avoir plus de pertes sans que ça indique une congestion comme le sans-fil).