Résumé

  • ECMP indique qu’un routeur dispose de plusieurs prochains sauts de coût égal ; cela ne garantit pas des chemins identiques en MTU, latence, ordre d’arrivée ou fonction multicast.
  • La RFC 2991 compare des méthodes qui maintiennent les paquets d’un flux sur un chemin et limitent leur réaffectation quand l’ensemble des prochains sauts change.

Un traceroute raconte l’itinéraire de ses propres sondes. Il ne révèle pas nécessairement tous les prochains sauts que le routeur pouvait choisir, ni la règle qui a affecté les autres flux. La distinction est facile à manquer : « coût égal » décrit un classement dans le plan de routage, pas une égalité d’expérience sur le réseau.

Publiée en novembre 2000, la RFC 2991 examine le transfert multipath. OSPF et IS-IS autorisaient explicitement l’ECMP ; certaines implémentations l’utilisaient aussi avec RIP et d’autres protocoles. Dès que plusieurs prochains sauts devenaient valides pour une destination, le routeur devait encore en sélectionner un pour chaque paquet.

Le tourniquet entre plusieurs sorties paraît équilibré. Il peut pourtant faire traverser à une même conversation des chemins dont le MTU et le délai diffèrent. La découverte du MTU de chemin se retrouve alors confrontée à une valeur qui varie d’un paquet à l’autre. Un paquet tardif peut arriver après ceux qui le suivent ; TCP peut interpréter cet ordre comme une perte, déclencher une retransmission rapide et consommer de la capacité supplémentaire. Les outils de diagnostic peuvent, eux aussi, observer des branches différentes et suggérer une route trompeuse.

En multicast, la contrainte est structurelle : les protocoles décrits construisaient un arbre unique vers la source, le cœur ou le point de rendez-vous. Un seul prochain saut vers la racine empêchait boucles et doublons. Alterner les sorties paquet par paquet n’était donc pas une simple variante de présentation.

La RFC appelle « flux » la granularité à laquelle le routeur conserve éventuellement un état. Ce n’est pas nécessairement le microflux à cinq éléments défini par la RFC 2474. Une implémentation peut ne considérer que la destination, ou le triplet source-destination-protocole. Les ports peuvent être absents des fragments qui ne sont pas initiaux ; leur emploi comme clé peut également empêcher de réutiliser des informations de chemin, notamment sur le MTU, entre connexions d’un même couple d’hôtes. Le mot « flux » masque ici une décision de conception.

Maintenir les paquets d’un flux sur le même chemin réduit le problème de réordonnancement, mais ouvre une seconde question : quand un prochain saut apparaît ou disparaît, combien de flux actifs doivent changer de route ? L’ECMP expose le transfert à davantage de changements de membres qu’une route unique. La RFC 2991 demande donc à la fois une faible perturbation lors de ces changements et un calcul assez léger pour le chemin de transfert.

Le hachage modulo N est rapide : on hache le flux, puis on prend le résultat modulo le nombre de prochains sauts. Mais quand N change, la RFC estime que (N-1)/N des flux changent de chemin. Le hachage par seuil répartit l’espace des hachés en régions associées aux prochains sauts ; déplacer les frontières ne touche que certaines régions, même si entre un quart et la moitié des flux peuvent être réaffectés quand un membre arrive ou part. La RFC 2992 en analyse la perturbation. Avec le poids aléatoire maximal (HRW), chaque flux est haché avec chaque prochain saut candidat ; la modification d’un membre ne déplace qu’environ 1/N des flux, au prix d’un calcul environ N fois plus coûteux que modulo N.

Ces fractions sont des propriétés de modèles algorithmiques, non des mesures de routeurs en production. Elles portent sur des flux, pas sur des octets, des clients ou le niveau d’impact d’un service. Un petit nombre de flux très volumineux peut transporter plus de données qu’une foule de flux courts.

La présence d’un état par flux change le moment où le coût est payé. Un routeur qui conserve déjà cet état peut choisir le prochain saut à sa création, plutôt que recalculer le choix à chaque paquet. La RFC recommande HRW pour le transfert unicast avec état et pour le multicast, où l’état source-groupe existe ; sans état unicast par flux, le choix doit être calculé à l’arrivée du paquet, et le hachage par seuil est recommandé si le CPU compte davantage que la stabilité. C’est une recommandation conditionnelle, pas un algorithme gagnant en toutes circonstances.

Onze ans plus tard, la RFC 6438 décrit toujours une tension entre partage des chemins, ordre des paquets par flux et utilisation des liens. Elle atteste la persistance du problème, non l’adoption universelle des algorithmes de la RFC 2991.

L’enseignement historique tient en une séparation. Le coût de routage classe les candidats ; le sélecteur local affecte les flux ; les chemins physiques déterminent MTU et délai ; les extrémités de transport réagissent à ce qu’elles reçoivent. Une couche ne remplace pas l’autre. La stabilité a un prix de calcul ou de répartition ; le remappage a un prix de perturbation. L’étiquette « coût égal » ne tranche pas entre eux.

Sources