La plupart des documents des fournisseurs d'applications incluent des paramètres TCP et ethernet spécifiques destinés à garantir le fonctionnement optimal de l'application. Ces mêmes paramètres suffisent généralement pour assurer des performances de stockage IP optimales.

Cette technologie permet à un client de demander à un expéditeur d'arrêter temporairement la transmission de données. Cela est généralement fait parce que le récepteur est incapable de traiter les données entrantes assez rapidement. À un moment donné, demander à un expéditeur de cesser la transmission était moins perturbant que d'avoir un récepteur de paquets de rejet parce que les tampons étaient pleins. Ce n'est plus le cas avec les piles TCP utilisées dans les systèmes d'exploitation d'aujourd'hui. En fait, le contrôle de flux cause plus de problèmes qu'il ne résout.

Les problèmes de performances causés par le contrôle de flux Ethernet ont augmenté ces dernières années. En effet, le contrôle de flux Ethernet fonctionne au niveau de la couche physique. Si une configuration réseau permet à un système d'exploitation hôte d'envoyer une demande de contrôle de flux Ethernet à un système de stockage, il en résulte une pause des E/S pour tous les clients connectés. Étant donné qu'un nombre croissant de clients sont servis par un seul contrôleur de stockage, la probabilité qu'un ou plusieurs de ces clients envoient des demandes de contrôle de flux augmente. Le problème a été fréquemment rencontré sur les sites des clients qui possèdent une virtualisation étendue du système d'exploitation.

Une carte réseau sur un système NetApp ne doit pas recevoir de demandes de contrôle de flux. La méthode utilisée pour obtenir ce résultat varie en fonction du fabricant du commutateur réseau. Dans la plupart des cas, le contrôle de flux sur un commutateur Ethernet peut être réglé sur receive desired ou receive on, ce qui signifie qu'une demande de contrôle de flux n'est pas transmise au contrôleur de stockage. Dans d'autres cas, la connexion réseau sur le contrôleur de stockage risque de ne pas permettre la désactivation du contrôle de flux. Dans ce cas, les clients doivent être configurés pour ne jamais envoyer de demandes de contrôle de flux, soit en changeant la configuration NIC sur le serveur hôte lui-même, soit en changeant les ports de commutateur auxquels le serveur hôte est connecté.

L'utilisation de trames Jumbo a été démontrée afin d'améliorer les performances des réseaux 1 Gbit en réduisant la surcharge du processeur et du réseau, mais l'avantage n'est généralement pas significatif.

L'utilisation de trames Jumbo dans un réseau de 10 Gb est presque obligatoire. En effet, la plupart des implémentations de 10 Gbits atteignent une limite de paquets par seconde sans trames Jumbo avant d'atteindre le seuil de 10 Gbits. L'utilisation de trames jumbo améliore l'efficacité du traitement TCP/IP car elle permet au système d'exploitation, au serveur, aux cartes réseau et au système de stockage de traiter moins de paquets, mais des paquets plus volumineux. L'amélioration des performances varie d'une carte réseau à l'autre, mais elle est significative.

Dans le cas des implémentations de trames Jumbo, il est courant, mais incorrect, que tous les périphériques connectés doivent prendre en charge les trames Jumbo et que la taille MTU doit correspondre de bout en bout Au lieu de cela, les deux extrémités du réseau négocient la taille de trame la plus élevée mutuellement acceptable lors de l'établissement d'une connexion. Dans un environnement standard, un commutateur réseau est défini sur une taille MTU de 9 9216, le contrôleur NetApp est défini sur 9000 et les clients sont configurés sur une combinaison de 9000 et 1514. Les clients qui prennent en charge un MTU de 9 9000 peuvent utiliser des trames jumbo, et les clients qui ne peuvent prendre en charge que 1514 peuvent négocier une valeur inférieure.

Les problèmes avec cet arrangement sont rares dans un environnement complètement commuté. Cependant, dans un environnement routé, veillez à ce qu'aucun routeur intermédiaire ne soit forcé de fragmenter des trames jumbo.

Trois paramètres sont souvent mal configurés : les horodatages TCP, l'acquittement sélectif (SACK) et la mise à l'échelle de la fenêtre TCP. De nombreux documents obsolètes sur Internet recommandent de désactiver un ou plusieurs de ces paramètres pour améliorer les performances. Cette recommandation a été très utile il y a de nombreuses années, lorsque les capacités du processeur étaient beaucoup plus faibles et qu'il y avait un avantage à réduire la surcharge sur le traitement TCP chaque fois que cela était possible.

Cependant, avec les systèmes d'exploitation modernes, la désactivation de l'une de ces fonctionnalités TCP n'entraîne généralement aucun avantage détectable, tout en pouvant nuire aux performances. Dans les environnements réseau virtualisés, les performances peuvent être endommagées, car ces fonctionnalités sont nécessaires pour gérer efficacement la perte de paquets et les modifications de la qualité du réseau.