6.1.2. L'Émetteur TCP (The TCP Sender)

Pour une connexion TCP utilisant ECN, les nouveaux paquets sont transmis avec le codepoint ECT défini dans l'en-tête IP. Lorsque l'expéditeur n'a besoin que d'un seul codepoint ECT pour tous les paquets qu'il envoie sur la connexion TCP, il DEVRAIT utiliser ECT(0). Si l'expéditeur reçoit un paquet ACK ECN-Echo (ECE) (c'est-à-dire un paquet ACK avec le drapeau ECN-Echo défini dans l'en-tête TCP), alors l'expéditeur sait que la congestion a été rencontrée dans le réseau sur le chemin de l'expéditeur au récepteur. L'indication de congestion DEVRAIT être traitée comme si elle était une perte de congestion dans un TCP non compatible ECN. C'est-à-dire que le TCP source réduira de moitié la fenêtre de congestion "cwnd" et réduira le seuil de démarrage lent "ssthresh". Le TCP expéditeur NE DEVRAIT PAS augmenter la fenêtre de congestion en réponse à la réception d'un paquet ACK ECN-Echo.

TCP NE DEVRAIT PAS réagir aux indications de congestion plus d'une fois pour chaque fenêtre de données (ou, plus libéralement, pour chaque temps d'aller-retour). C'est-à-dire que la fenêtre de congestion de l'expéditeur TCP DEVRAIT être réduite une seule fois en réponse à une série de paquets perdus et/ou CE d'une seule fenêtre de données. De plus, le TCP source NE DEVRAIT PAS réduire le seuil de démarrage lent ssthresh s'il a déjà été réduit au cours du dernier temps d'aller-retour. Cependant, si des paquets retransmis sont abandonnés, le TCP source interprète cela comme une nouvelle instance de congestion.

Après que le TCP source ait réduit sa fenêtre de congestion en réponse à un paquet CE, les accusés de réception entrants qui continuent d'arriver peuvent "cadencer" des paquets sortants selon ce que permet la fenêtre de congestion réduite. Si la fenêtre de congestion contient seulement un MSS (maximum segment size, taille de segment maximale), et que le TCP expéditeur reçoit un paquet ACK ECN-Echo, alors le TCP expéditeur DEVRAIT en principe réduire encore de moitié sa fenêtre de congestion. Cependant, la valeur de la fenêtre de congestion a une limite inférieure d'un MSS. Si le TCP expéditeur continue à envoyer avec une fenêtre de congestion d'un MSS, cela entraînera la transmission d'un paquet par temps d'aller-retour. Il est nécessaire de réduire davantage le taux d'envoi de l'expéditeur TCP même lors de la réception d'un paquet ECN-Echo lorsque la fenêtre de congestion est de 1. Nous utilisons le temporisateur de retransmission comme moyen de réduire davantage le taux dans cette situation. Ainsi, lors de la réception d'un paquet ECN-Echo lorsque la fenêtre de congestion est de 1, le TCP expéditeur DOIT réinitialiser le temporisateur de retransmission. Le TCP expéditeur ne pourra alors envoyer un nouveau paquet que lorsque le temporisateur de retransmission expirera.

Lorsqu'un TCP expéditeur compatible ECN réduit sa fenêtre de congestion pour quelque raison que ce soit (en raison d'un délai de retransmission, d'une retransmission rapide ou en réponse à une notification ECN), le TCP expéditeur définit le drapeau CWR dans l'en-tête TCP du premier nouveau paquet envoyé après la réduction de fenêtre. Si ce paquet est abandonné dans le réseau, le TCP expéditeur devra réduire à nouveau la fenêtre de congestion et retransmettre le paquet perdu.

Nous nous assurons que les informations "Congestion Window Reduced" (Fenêtre de Congestion Réduite) sont livrées de manière fiable au récepteur TCP. C'est parce que si le nouveau paquet portant le drapeau CWR est abandonné, le TCP expéditeur devra réduire à nouveau sa fenêtre de congestion et envoyer un autre nouveau paquet avec le drapeau CWR défini. Ainsi, le bit CWR dans l'en-tête TCP NE DEVRAIT PAS être défini sur des paquets retransmis.

Lorsqu'un expéditeur de données TCP est prêt à définir le bit CWR après avoir réduit la fenêtre de congestion, il DEVRAIT définir le bit CWR uniquement sur le premier nouveau paquet qu'il transmet.

[Floyd94] discute plus en détail de la réponse TCP à ECN. [Floyd98] discute des tests de validation dans le simulateur ns, illustrant divers scénarios ECN. Ces scénarios incluent les suivants : ECN suivi d'un autre ECN, d'une retransmission rapide ou d'un délai de retransmission ; délai de retransmission ou retransmission rapide suivi d'ECN ; et fenêtre de congestion d'un paquet suivie d'ECN.

TCP suit les algorithmes existants pour envoyer des paquets en réponse aux ACK entrants, aux accusés de réception dupliqués multiples ou aux délais de retransmission [RFC2581]. Lorsque TCP reçoit un paquet ACK qui n'a pas le bit ECN-Echo défini, il suit également la procédure normale d'augmentation de la fenêtre de congestion [RFC2581].