Résumé

  • Les RFC 9621 à 9623 séparent les contraintes impératives d’une application de ses préférences ; la mise en œuvre les combine ensuite avec la politique du système, l’historique conservé et les possibilités du réseau présent.
  • L’événement Ready atteste qu’une pile admissible est établie. Il n’explique ni l’arbitrage, ni les préférences sacrifiées, ni le résultat obtenu par l’application distante.

Un cahier des charges demandait de « privilégier le chemin à faible latence ». Le logiciel s’est connecté, le contrôle de disponibilité est passé au vert et personne n’a vu d’erreur. Pourtant, la facture a montré l’usage d’un accès facturé au volume. La phrase du cahier des charges n’était pas fausse ; elle était trop faible pour porter l’obligation qu’on lui prêtait.

RFC 9622 définit cinq degrés pour la plupart des propriétés de sélection : Require, Prefer, No Preference, Avoid et Prohibit. Require élimine tout chemin ou protocole qui ne possède pas la propriété et impose l’échec s’il ne reste rien. Prohibit fait l’inverse. Prefer et Avoid modifient l’ordre des candidats, mais autorisent une solution moins souhaitée.

Cette gradation est au cœur de l’architecture. RFC 9621 permet à l’application de décrire le service de transport recherché sans figer une adresse, une interface ou une pile. La mise en œuvre peut résoudre plusieurs destinations, observer plusieurs chemins et essayer plusieurs protocoles derrière un seul objet Connection. RFC 9623 détaille la construction et la course de ces candidats.

L’avantage est réel : une application ne doit plus réinventer son propre arbre TCP, UDP, IPv4, IPv6, Wi-Fi ou cellulaire. Un nouveau transport peut être adopté sous l’interface existante. Mais l’abstraction déplace aussi une décision. Ce qui était autrefois choisi explicitement par l’application peut désormais résulter d’une politique et d’un historique qu’elle ne voit pas entièrement.

Une préférence ne devient pas une garantie par répétition

La norme exige que le résultat respecte toutes les propriétés Require et Prohibit. Elle dit aussi qu’un même ensemble de propriétés Prefer et Avoid peut produire des choix différents selon la plate-forme et le contexte. Cette variabilité n’est pas une anomalie : elle permet l’adaptation.

Elle interdit toutefois une lecture paresseuse des libellés. Une interface Wi-Fi n’est pas une preuve d’accès non facturé, privé ou rapide. Une interface cellulaire n’est pas automatiquement chère. RFC 9622 demande de ne pas utiliser le type d’interface comme substitut d’une caractéristique telle que le caractère mesuré du réseau. Si le coût est une frontière, il faut l’exprimer comme telle.

Trois formulations conduisent donc à trois produits différents. « Préférer l’accès non mesuré » protège d’abord la continuité. « Interdire l’accès mesuré » protège d’abord le coût et accepte l’indisponibilité. « Ne pas exprimer de préférence » délègue l’arbitrage à la politique courante. Une équipe commerciale ne peut promettre la deuxième option lorsque le logiciel n’a demandé que la première.

La décision appartient à plusieurs couches

RFC 9623 énumère au moins trois sources : les préférences de l’application, la politique dynamique du système et la politique par défaut de la mise en œuvre. Une règle d’administration peut interdire une interface. Un réglage de la plate-forme peut favoriser un proxy. L’état du réseau peut rendre un protocole indisponible. Tous les chemins retenus doivent satisfaire les contraintes applicables de ces trois couches.

Or RFC 9621 précise que l’API abstraite ne normalise pas la lecture ou l’écriture de la politique du système. Ce choix protège la portabilité au niveau de l’application : deux systèmes peuvent offrir le même contrat sans partager le même moteur de décision. Il ne fournit pas, à lui seul, une justification portable du choix effectué.

L’erreur PolicyProhibited peut signaler qu’une action est bloquée. Le succès ne livre pas son symétrique détaillé. Ready ne contient pas la version de la politique, la liste des candidats ni le poids donné à chaque préférence. Un résultat peut donc être conforme et difficile à expliquer.

La bonne réponse n’est pas d’imposer une politique mondiale unique. Elle consiste à définir deux objets distincts : un contrat commun, assez étroit pour être déterministe, et une preuve locale de sélection, assez précise pour attribuer la décision.

L’arbre ne calcule pas un optimum universel

RFC 9623 recommande de construire les branches dans un ordre : d’abord les chemins réseau, ensuite les options de protocole, enfin les points de terminaison dérivés. Cette hiérarchie modifie le sens pratique de plusieurs préférences.

Le document donne un cas où l’application préfère le Wi-Fi et préfère aussi SCTP. Si l’historique indique que SCTP n’est pas disponible sur le Wi-Fi, la branche Wi-Fi peut seulement proposer TCP, tandis que la branche LTE propose SCTP puis TCP. Le choix du chemin étant traité avant celui du protocole, Wi-Fi/TCP peut partir avant LTE/SCTP.

Aucune des deux préférences n’a disparu. Leur ordre de résolution a décidé. Un compte rendu qui note uniquement « Wi-Fi préféré » et « SCTP préféré » ne permet pas de reconstituer l’arbitrage. Il faut aussi connaître les branches absentes, les nœuds éliminés et la règle de priorité.

La résolution ajoute une autre variation. Deux interfaces peuvent recevoir des réponses DNS différentes. L’ajout d’un proxy peut changer l’adresse et le port effectivement visés. Un protocole peut exister sur un chemin et manquer sur l’autre. La liste des candidats est donc une observation située, pas un inventaire éternel.

Courir vite sans courir hors de la politique

RFC 9623 distingue la course simultanée, la course décalée et le basculement après échec. L’essai simultané minimise parfois l’attente, mais crée des états inutilisés et consomme davantage de ressources ; le texte déconseille d’en faire le comportement par défaut. La course décalée lance les alternatives après un délai. Le basculement attend l’échec du choix privilégié.

Cette dernière forme protège une préférence forte. Si un proxy doit normalement porter le trafic, lancer en même temps la voie directe risque de contourner le proxy pour quelques millisecondes. Attendre son échec conserve la hiérarchie voulue.

RFC 8305 applique une logique connue aux familles d’adresses dans Happy Eyeballs. Le modèle TAPS l’étend aux interfaces, aux piles et aux destinations. Le premier succès n’a de valeur que si la sélection préalable a admis les bons candidats.

La sécurité en est l’exemple le plus dur. RFC 8922 rattache les paramètres de sécurité au service de transport. RFC 9623 avertit qu’un attaquant peut bloquer la première tentative afin de provoquer la suivante. Si celle-ci est moins sûre, la course devient un mécanisme de déclassement. Les alternatives doivent rester dans une classe de sécurité équivalente et respecter toutes les contraintes impératives.

Le passé prend part à la course

Le moteur peut conserver les réponses DNS, les tickets de reprise TLS, les cookies TCP Fast Open, le temps d’établissement, le taux de réussite et le RTT observé. RFC 9040 fournit le contexte plus général du partage d’état TCP. Ces données réduisent les délais, mais elles peuvent aussi prolonger une croyance devenue fausse.

Un échec ancien peut écarter aujourd’hui un protocole réparé. Un RTT mesuré hier peut favoriser un chemin congestionné aujourd’hui. Deux appels identiques n’ont donc pas nécessairement le même arbre ni le même gagnant. L’application ne doit pas compter sur un comportement précis du cache ; elle doit déclarer explicitement ce qui lui est indispensable.

Le cache peut aussi relier des activités que l’utilisateur voulait séparer. RFC 9621 prévoit des contextes de connexion distincts afin de limiter la réutilisation de tickets ou le multiplexage révélateur. Une preuve de sélection utile doit enregistrer l’espace de cache, l’âge des mesures et leur règle d’expiration, sans copier les secrets de session ni les identifiants personnels.

Ready ferme une étape, pas le dossier

Pour RFC 9623, l’établissement est achevé lorsqu’au moins une pile peut transmettre et recevoir les données de l’application. RFC 9622 matérialise cette transition par Ready. C’est une attestation importante : une pile admissible a été établie localement.

Ce n’est pas une attestation que toutes les préférences ont gagné, que le coût attendu a été respecté, que la destination a traité un message ou que l’utilisateur a reçu son résultat. Le reçu complet doit séparer l’intention, la politique, le cache, les candidats, la course, la pile gagnante, les événements de message et l’effet applicatif.

RFC 9623 cite Network.framework d’Apple, NEAT, NEATPy et PyTAPS comme des mises en œuvre qui, à des degrés divers, suivaient l’approche lors de la rédaction. La documentation Network d’Apple montre l’intérêt concret d’associer protocoles et contraintes de chemin dans une API. Cette existence ne certifie ni une conformité totale ni une trace identique sur toutes les plates-formes.

Sources