Résumé

  • La révision 21 de QUIC multipath définit les états AVAILABLE et BACKUP, mais elle laisse à l’extrémité la politique d’ordonnancement ; si tous les chemins sont de secours, aucune règle commune ne désigne le premier.
  • Une préférence transmise par le pair ne prouve ni un accord commercial, ni un consentement de l’utilisateur, ni une hiérarchie de sécurité, ni la capacité réelle du chemin.
  • L’exploitation doit conserver la préférence reçue, la décision locale, ses entrées et le résultat applicatif afin de distinguer conformité protocolaire et qualité de service.

À 03 h 17, le lien fixe n’était plus exploitable. Le terminal disposait encore de deux chemins validés : un accès cellulaire avec un plafond de données et un tunnel d’entreprise à forte latence. Tous deux avaient été marqués BACKUP. Le trafic est parti sur le cellulaire. Le service a survécu ; la facture, elle, a raconté une autre histoire.

Chercher dans le protocole la règle qui aurait dû départager les deux chemins ne résout pas l’incident. La règle n’y est pas. Ce silence n’est ni un oubli ni une panne d’interopérabilité. C’est la frontière assumée entre une mécanique de transport commune et une politique qui dépend du terminal, de l’application et de l’organisation.

La révision 21 du projet « Managing multiple paths for a QUIC connection » a été approuvée par l’IESG en mars 2026 puis transmise à la file du RFC Editor. Au 2 octobre, son traitement indiquait « Awaiting Second editor ». Le texte n’est donc pas encore un RFC et ne doit pas être présenté comme tel. Son état avancé autorise néanmoins une lecture précise de la responsabilité qu’il répartit.

Le projet spécifie comment négocier le multipath, attribuer des identifiants de chemin, associer les identifiants de connexion, valider les adresses et maintenir des espaces de numéros de paquets distincts. Il définit PATH_ACK, l’abandon d’un chemin et des états de récupération et de congestion par chemin. Ces éléments rendent possible une conversation interopérable sur plusieurs routes.

Puis viennent deux signaux de préférence. AVAILABLE indique qu’un chemin peut être utilisé ; le pair emploie sa propre logique pour y répartir du trafic. BACKUP demande de ne pas utiliser ce chemin tant qu’un autre chemin utilisable existe. Le texte prévoit aussi qu’une extrémité puisse ne pas suivre la préférence reçue. Et lorsque tous les chemins sont BACKUP, il ne fournit pas de règle particulière pour choisir entre eux.

Une préférence n’est pas une délégation complète

Le signal exprime quelque chose de réel : le pair préférerait que ce chemin reste en réserve. Il ne transporte pas toutes les raisons possibles. Il ne dit pas si le chemin est facturé au mégaoctet, si l’abonné a donné son accord, si une politique interdit une catégorie de données, si le tunnel franchit une juridiction donnée, ou si l’application préfère perdre quelques secondes plutôt que consommer une ressource rare.

Il ne certifie pas non plus la capacité. La validation démontre qu’un pair peut recevoir à l’adresse considérée et participe à la maîtrise de l’amplification. Un chemin validé peut rester saturé, fluctuant ou commun avec un autre chemin jusqu’au même goulot d’étranglement. Plusieurs identifiants de chemin peuvent même employer le même quadruplet d’adresses et de ports. Deux identités de protocole ne constituent donc pas nécessairement deux ressources physiques.

L’erreur de gouvernance consiste à traiter BACKUP comme si les deux extrémités avaient signé la même politique de service. L’une peut signaler une préférence fondée sur sa topologie ; l’autre choisit avec des informations sur la batterie, le coût, le contenu ou l’état de l’application. L’issue est coproduite par deux politiques qui ne partagent pas forcément les mêmes objectifs.

Cette asymétrie est légitime. Un serveur ne connaît pas nécessairement le forfait mobile d’un client. Un client ne connaît pas toutes les contraintes de capacité d’un service. L’interopérabilité ne doit pas imposer une fonction d’utilité universelle. En revanche, l’organisation qui promet un résultat ne peut pas faire disparaître cette fonction locale de ses preuves.

Le dossier d’incident doit commencer avant le basculement

Un journal utile ne se contente pas de noter « failover réussi ». Il enregistre le chemin préféré par chaque partie, l’instant et la direction du signal, l’âge de la validation, les adresses et identifiants, les états de congestion, la perte, la PMTU et les contraintes économiques. Il nomme la version de l’ordonnanceur et la règle qui a départagé les candidats. Enfin, il mesure le résultat vu par l’application.

Cette chaîne permet de répondre à des questions différentes :

  • le chemin était-il encore joignable au moment de la décision ?
  • un autre chemin utilisable existait-il réellement ?
  • la préférence du pair a-t-elle été ignorée, et pour quelle raison ?
  • le chemin choisi partageait-il un goulot avec celui qui venait d’échouer ?
  • l’accusé de réception est-il revenu par une autre route ?
  • la reprise du transport a-t-elle rendu les octets utiles avant l’échéance applicative ?
  • quelle dépense, quel quota ou quelle contrainte réglementaire ont été engagés ?

PATH_ACK mérite une attention particulière. L’accusé peut revenir sur un chemin différent de celui du paquet reconnu. Une mesure de temps aller-retour réunit alors le trajet aller, le trajet de l’accusé et la décision de l’ordonnanceur. Le nombre est précis ; l’étiquette « latence du chemin X » peut être fausse. Une politique qui choisit sur cette étiquette peut renforcer sa propre erreur.

La récupération laisse elle aussi un choix local. La révision 21 autorise une retransmission sur le même chemin, un autre ou plusieurs ; la stratégie détaillée reste hors du périmètre commun. Des PMTU différentes et la livraison ordonnée d’un flux compliquent le récit. Une retransmission rapide peut arriver derrière un trou antérieur et ne rien accélérer pour l’application.

Les états verts ne répondent pas à la question économique

Supposons que le cellulaire et le tunnel aient tous deux sauvé la session. Le premier entraîne un surcoût ; le second manque une échéance. Lequel est « meilleur » ? Le protocole ne peut pas le savoir sans convertir les priorités de l’organisation en politique locale. La disponibilité ne vaut pas autorisation de dépenser. Une préférence de chemin ne vaut pas consentement. La continuité de la connexion ne vaut pas accomplissement du service.

Ce constat protège aussi le standard contre une attente excessive. Les débats de l’IESG ont abordé la politique de planification, le nombre de chemins, les quotas et le consentement. Le texte a pu être approuvé tout en maintenant ces décisions aux extrémités. L’approbation atteste le parcours du document ; elle n’homologue ni l’ordonnanceur d’un fournisseur ni la promesse commerciale d’un opérateur.

La formulation honnête d’un résultat doit conserver quatre niveaux : le chemin était admissible selon le protocole ; telle politique locale l’a sélectionné ; avec telles contraintes observées ; l’application a obtenu tel résultat. « Le multipath a choisi le meilleur chemin » efface précisément les éléments qu’il faudrait auditer.

Le cas où tous les chemins sont BACKUP est donc un bon test de maturité. Il retire le candidat évident. Si la plateforme ne sait pas expliquer son départage, si l’opérateur n’a pas défini les contraintes de coût et si le produit n’a pas nommé l’issue acceptable, la technologie ne crée pas la décision. Elle ne fait que l’exécuter en silence.

Sources