Règles de fusion des segments TCP/IP

Cette section définit les règles qui spécifient quand un pilote miniport compatible RSC (receive segment coalescing) doit fusionner un segment pour une connexion TCP donnée. Si l’une des règles est enfreinte, une exception est générée et le conducteur du miniport doit abandonner la fusion du segment.

Le pilote miniport doit mettre à jour les en-têtes IP et TCP pour l’unité fusion unique (SCU). Le pilote miniport doit recalculer les sommes de contrôle TCP et IPv4 sur le SCU et chaîner la charge utile TCP.

Le premier des deux organigrammes suivants décrit les règles de fusion des segments et de mise à jour des en-têtes TCP. Cet organigramme fait référence aux mécanismes permettant de distinguer les DOUBK valides et les mises à jour de fenêtre. Le deuxième organigramme décrit ces mécanismes.

Ces organigrammes sont fournis comme référence pour comprendre les règles RSC. Une implémentation matérielle peut optimiser l’organigramme, tant que l’exactitude est conservée.

Les termes suivants sont utilisés dans les organigrammes :

Les organigrammes montrent que le pilote de miniport peut fusionner des segments avec des nombres ACK différents. Toutefois, le pilote de miniport doit respecter les règles suivantes concernant les numéros ACK, comme indiqué dans le premier organigramme ci-dessus :

• Après avoir effectué le numéro de séquence case activée, un ACK pur entrant peut être fusionné dans la SCU actuellement suivie s’il remplit l’une des conditions suivantes ou les deux :

  • H.ACK == SEG. ACK.

  • Le nombre de doublons d’ACK dans le segment coalescié qui est suivi est égal à zéro. En d’autres termes, H.DupAckCount == 0.

    En d’autres termes, tout ACK pur qui n’est pas un ACK en double ou une mise à jour de fenêtre déclenche une exception et ne doit pas être coalescé. Toutes ces ACL pures doivent être indiquées en tant que segments individuels. Cette règle garantit que RSC n’affecte pas le comportement ou les performances des algorithmes de contrôle de congestion TCP Windows.

• Un segment de données entrant (SEG. ACK == H.ACK) ou un ACK piggy-backed entrant (SEG. ACK>H.ACK) peut être fusionné dans la SCU actuellement suivie si les deux conditions suivantes sont remplies :

  • Le segment est contigu à la SCU dans l’espace de séquence. En d’autres termes, SEG. SEQ == H.NXT.
  • Le nombre de doublons d’ACK dans le segment coalescié qui est suivi est égal à zéro. En d’autres termes, H.DupAckCount == 0.

Notes supplémentaires sur la fusion ACK en double

Comportement de l’ACK en double

Le pilote miniport doit traiter un segment ACK en double équivalent à un ACK pur et ne pas le fusionner. Dans ce cas, il doit finaliser la SCU actuelle (le cas échéant) pour indication et indiquer le segment ACK en double en tant que segment individuel. Étant donné que les clients Windows utilisent des accusés de réception sélectifs (SACK) par défaut, un segment ACK en double génère probablement une exception. Pour obtenir un exemple , consultez Exemples de fusion de segments de réception. Si un segment avec DupAckCount> 0 est indiqué, NDIS désactive RSC sur l’interface.

Gestion de l’ACK en double lors du suivi d’une SCU composée de segments de données

Lors du suivi d’une SCU avec H.LEN> 0 (en d’autres termes, un segment fusionné qui contient des données), si un ACK en double arrive ensuite, la SCU de suivi doit être finalisée comme suit :

1. Une nouvelle SCU doit être suivie, en commençant par l’ACK en double.

2. Le DupAckCount pour la nouvelle SCU doit être défini sur zéro.

3. Le DupAckCount doit être incrémenté si d’autres ACL en double sont reçus.

Dans ce cas, DupAckCount sera inférieur de 1 au nombre de clés ACL en double. La pile de l’hôte gère correctement le comptage.

Gestion de l’ACK en double lors du suivi d’une SCU composée d’un ACK cumulé pur

Lors du suivi d’une SCU qui se compose d’un seul ACK cumulé pur (les règles interdisent la fusion de plusieurs AK pures), si un ACK en double arrive ensuite, le DupAckCount pour le SCU de suivi doit être incrémenté. Il doit également être incrémenté si d’autres ACL en double sont reçus. Dans ce cas, DupAckCount est égal au nombre de clés ACK en double qui sont coalescées.

Lorsque le premier segment reçu dans un DPC est un ACK en double

Dans ce cas, la carte réseau ne peut pas déterminer si le segment reçu est un ACK en double, car il ne conserve aucun état. Par conséquent, le segment doit être traité comme un ACK pur à la place comme suit :

1. Une nouvelle SCU doit être suivie, en commençant par ce segment.

2. Le DupAckCount pour la nouvelle SCU doit être défini sur zéro.

3. Le DupAckCount doit être incrémenté de 1 pour chaque ACK en double supplémentaire reçu.

Dans ce cas, DupAckCount sera égal à 1 de moins que le nombre réel de clés ACL en double. La pile de l’hôte gère correctement le comptage.

Exemption ACK en double

Le pilote miniport peut traiter un segment ACK en double équivalent à un ACK pur et ne pas le fusionner. Dans ce cas, il doit finaliser la SCU actuelle (le cas échéant) pour indication et indiquer le segment ACK en double en tant que segment individuel. Étant donné que les clients Windows utilisent SACK par défaut, un segment ACK en double génère probablement une exception. Pour obtenir un exemple, consultez Exemples de fusion de segments de réception. Cette exemption ne s’applique pas aux segments de mise à jour de fenêtre.

Fusion de segments avec l’option Timestamp

L’option d’horodatage TCP est la seule option qui peut être légalement coalescée. La fusion des segments avec cette option est laissée comme une décision spécifique à l’implémentation. Si le pilote miniport fusionne des segments avec l’option timestamp, il doit suivre les règles décrites dans l’organigramme suivant :

Lorsque vous indiquez un segment fusionné, les informations hors bande suivantes doivent être indiquées comme suit en définissant le membre NetBufferListInfo de la structure NET_BUFFER_LIST qui décrit le segment fusionné :

• Le nombre de segments fusionnés doit être stocké dans NetBufferListInfo[TcpRecvSegCoalesceInfo]. Membre CoalescedSegCount . Ce nombre représente uniquement les segments de données qui ont été coalescés. La fusion ACK pure est interdite et les segments de mise à jour de fenêtre ne doivent pas être comptés dans ce champ.

• Le nombre d’ACK en double doit être stocké dans NetBufferListInfo[TcpRecvSegCoalesceInfo]. Membre DupAckCount . Le premier organigramme ci-dessus explique comment cette valeur est calculée.

• Lorsque des segments avec l’option d’horodatage TCP sont fusionnés, NetBufferListInfo[RscTcpTimestampDelta] doit être rempli avec le delta absolu entre la valeur d’horodatage TCP la plus ancienne et la dernière valeur d’horodatage TCP observée dans la séquence de segments fusionnés comprenant la SCU. La SCU elle-même doit contenir la dernière valeur d’horodatage TCP observée dans la séquence de segments coalescés.

Les membres DupAckCount et RscTcpTimestampDelta sont interprétés si et seulement si le membre CoalescedSegCount est supérieur à zéro. Si coalescedSegCount est égal à zéro, le segment est traité comme un segment non-RSC non coalescé.

Pour plus d’informations sur le contenu du membre NetBufferListInfo , consultez NDIS_NET_BUFFER_LIST_INFO et NDIS_RSC_NBL_INFO.

Le bit PSH doit être ORed pour tous les segments coalescés. En d’autres termes, si le bit PSH a été défini dans l’un des segments individuels, le pilote miniport doit définir le bit PSH dans le SCU.

La finalisation d’une SCU implique :

• Recomputation du tcp et, le cas échéant, de la somme de contrôle IPv4.

• Mise à jour des en-têtes IP comme décrit dans Mise à jour des en-têtes IP pour les segments coalescés.

• Définition des bits ECN et des champs ECN dans les en-têtes TCP et IP sur les mêmes valeurs que celles définies dans les segments individuels.

Gestion des segments IPsec TCP/IP

Un carte réseau peut signaler les fonctionnalités de déchargement de tâches RSC et IPsec. (Voir Détermination des fonctionnalités RSC d’une carte réseau.) Toutefois, s’il prend en charge le déchargement de tâche IPsec, il ne doit pas tenter de fusionner les segments protégés par IPsec.