Fenetre de congestion

Bien le bonjour a tous,

Comme a mon habitude, voici ma petite question de la journée :
Dans TCP, est ce qu'on combine l'utilisation d'une fenêtre glissante et d'une fenêtre de congestion ?

Voili voilou ! Bonne chance pour la suite !

pour la fenêtre de congestion c'est certain, mais il me semble que la gestion des acquis se fait avec un espèce de selective-repeat+go-backn, dans le cours on a les 4 "cas" de réception (paquet attendu, précédent non acquitté, trou, remplissage de trou) et les actions en conséquence, du moins si j'ai bien compris ta question et la matière :p

EDIT: en fait je viens de relire plus attentivement,et je dirais que j'avais mal compris ta question.

Pour la fenêtre glissante je ne pense pas qu'on en ait encore besoin, étant donné que les acquits se basent sur les numéros de séquence calculées avec la taille des MSS (l'acquit étant toujours le prochain numéro de séquence à recevoir), et ce mécanisme couplé à la fenêtre de congestion (qui au final n'est qu'une variable, un bête nombre) nous dit ce qu'on peut envoyer.
Bon je vais partir du principe que je ne suis pas super clair, alors on va faire un petit exemple.
On veut transmettre 6000 bytes avec un MSS de 1500. On va dire qu'on commence avec un premier numéro de séquence de 39 (ça change un peu de 0).

Donc le premier tpdu contient un numéro de séquence de 39. Le destinataire le reçoit, cool, il envoie un acquit. == > ACK (1539)
L'émetteur reçoit ACK 1539, il sait que le prochain tpdu a envoyer doit avoir un num de séquence = 1539, etc pour 3039, 4539, 6039.

Et pour la fenêtre de congestion, c'est juste la quantité de données non acquittées qu'il peut envoyer à un destinataire, plus besoin de fenêtre glissante, la belle vie quoi.

Salut richard !

Avant toute chose merci pour ta réponse.
Figure toi que je m'étais fais exactement la même réflexion que toi, mais swinnen m'a dissuader :

"Oui ... c'est nécessaire puisque sans la fenêtre glissante, on utilise
le protocole à 1 bit (envoi des TPDU et attente de l'acquit) ce qui
risque pas vraiment de causer une congestion"

Et vive Linux
Donc voila, on a bien a la fois une fenêtre de congestion et une fenêtre qui coopèrent étroitement.

Voili voilou, bonne chance a tous pour demain (ou après demain)

Ah bon d'accord. C'est tout ce qu'il a dit? A-t-il parlé des numéros de séquence en rapport avec les MSS?

Niark, non. Une fois que la réponse est trop longue a rédiger il ne répond pas ^^

Bon, je lui ai envoyé un mail pour avoir plus d'infos, voici sa réponse, entrecoupée de mes questions (en rouge):

Salut Richard,


Etant donné qu'on utilise des numéros de séquence en relation avec le MSS, pourquoi a-t-on encore besoin d'une fenêtre glissante? Que contiendra-t-elle? Son contenu et sa taille seront-ils fixés du début à la fin de la connexion ou bien évolueront-ils au fil des échanges?

La taille de la fenêtre évolue au fil du temps.



On pourrait simplement créer une liste qui contiendrait les numéros de séquence des tpdu envoyés mais non encore acquittés, et cette liste serait combinée avec la valeur de congestion qui nous donne la quantité de données que l'on peut envoyer. Je ne vois plus vraiment l'intérêt de la fenêtre glissante comme je la conçois, c'est-à-dire comme elle nous est présentée dans le slide 114 (Transfert fiable d'information (18)). Pouvez-vous m'éclairer?


Bon reprenons les choses dans l'ordre. Au début, nous avons le protocole
à 1 bit dans lequel on envoie au plus une information qui est acquittée
par le destinataire.

Les performances étant mauvaises, on imagine envoyer plus d'information.
Cependant, et c'est la partie qui fait défaut dans ton raisonnement, il
ne faut pas submerger celui-ci (c'est le contrôle de flux) et donc, le
destinataire a la possibilité de mentionner une taille de fenêtre qui
évolue en fonction de sa charge.

Dans ce que tu proposes, l'émetteur enverrait des informations à son
rythme avec, comme limitation, le contrôle de congestion. Cette façon de
travailler mènera à un plus grand nombre de congestion puisque lorsque
le destinataire est submergé, tu n'en tiendrais pas compte avant la
perte effective d'information.

Donc, le principe de la fenêtre glissante permet de limiter l'émission
en fonction des capacités du destinataire mais permet aussi des
performances plus grande puisqu'on envoie plus d'information qu'auparavant.

J'espère que c'est maintenant plus clair.

Louis SWINNEN.

Merci pour l'info mon brave ^^