Résumé

  • RFC 5290 défend un service commun qui exige peu d’état partagé. Les services différenciés peuvent le compléter, mais leur réussite ne prouve ni la disponibilité ni la qualité du socle ordinaire.
  • Une égalité de débit entre flux dépend de la définition du flux, de l’intervalle, de l’unité et du point d’exécution. Elle ne prouve pas une égalité entre personnes, organisations ou usages.

Le coût évité par le socle

RFC 5290 appelle « simple best-effort » un trafic qui ne dépend ni d’un traitement différencié dans les routeurs, les polices ou les boîtiers intermédiaires, ni d’un contrôle d’admission. La simplicité ne décrit pas l’ensemble de l’Internet : contrats bilatéraux, tarification au volume, pare-feu et politiques complexes subsistent. Elle décrit la condition d’entrée du paquet. Le transport de base ne suppose pas que tous les acteurs du chemin aient adopté la même classe commerciale.

Ce socle évite trois coûts de coordination. Il n’impose pas un ordonnanceur par flux à chaque routeur. Il n’impose pas un registre interopérable de prix de congestion. Il n’attend pas une réservation complète avant le démarrage de l’application. Il offre moins de certitude qu’un service garanti, mais franchit plus facilement des frontières administratives.

Le RFC est un document Informational de 2008, et non une norme Internet. Il observait qu’un service imparfait avait porté fichiers, courriels, Web, audio, vidéo et voix, tout en donnant généralement aux utilisateurs une chance d’obtenir une part de ressource. Cette observation historique ne mesure aucun réseau actuel. Elle identifie néanmoins une propriété durable : une infrastructure commune peut être précieuse parce qu’elle reporte l’intelligence et la négociation vers les extrémités.

Le supplément n’est pas le remplacement

Le service au mieux ne garantit pas, en période de congestion, la bande passante, le délai, la gigue, les pertes, le démarrage rapide ou le refus préalable d’un appel impossible à servir. Il existe donc des besoins légitimes de différenciation. RFC 2475 formalise une architecture DiffServ ; RFC 2212 décrit un service garanti ; RFC 3662 place une classe sous le niveau best-effort. Chaque mécanisme a son propre état, ses propres acteurs et son propre mode d’échec.

La question politique commence lorsque la classe premium concurrence le socle. Un service supérieur peut protéger une application critique et financer l’infrastructure. Sans capacité minimale pour la classe ordinaire, il peut aussi permettre aux clients les plus solvables d’épuiser la ressource disponible. La preuve pertinente n’est pas l’existence du marquage, mais la capacité encore utilisable par ceux qui ne bénéficient pas du traitement privilégié.

Il faut alors séparer classification, reconnaissance du marquage, action de l’ordonnanceur, disponibilité de capacité et résultat applicatif. Un paquet correctement classé peut traverser un domaine qui ignore la classe. Une file bien configurée peut manquer de capacité. Un contrat peut être honoré localement tandis que l’application échoue plus loin. Un compteur vert à une étape n’hérite pas de l’autorité des étapes suivantes.

Le mot « flux » choisit déjà le bénéficiaire

RFC 5290 présente l’équité approximative des débits comme un objectif acceptable, non comme une définition optimale ou une garantie. Dans l’Internet qu’il observait, l’approximation provenait surtout de la prédominance de TCP et de comportements de congestion largement conformes. C’est une coopération massive, pas une police universelle.

Le calcul ne choisit pas son sujet. Une connexion TCP constitue-t-elle un flux ? Faut-il agréger toutes les connexions entre deux hôtes, celles d’un abonné, d’une application ou d’une entreprise ? Dix connexions peuvent recevoir dix parts quand une autre personne n’en ouvre qu’une. L’égalité entre objets techniques produit alors une inégalité entre acteurs.

La durée et l’unité changent aussi le verdict. Paquets et octets ne racontent pas la même histoire. Un RTT long, plusieurs routeurs congestionnés, un trafic en rafales ou un protocole différent modifient le débit reçu. L’équité pendant dix minutes n’est pas l’équité sur une journée. Aucun nombre ne mérite le mot « équitable » sans sa clé de regroupement, sa fenêtre, son unité, son goulot, son signal de congestion et son point d’exécution.

Quand la coopération ne suffit plus

RFC 2914 attribue aux extrémités une responsabilité face à la congestion. RFC 2309 traite des files et des flux non réactifs. RFC 896 rappelle que l’effondrement par congestion impose parfois aux passerelles de se défendre. Le socle commun n’est donc pas une absence de contrôle. Il fonctionne à faible coût tant que la coopération domine, puis exige des mécanismes défensifs lorsque cette hypothèse se brise.

Une exploitation honnête distingue au moins trois régimes : approximation obtenue par des transports coopératifs ; détection et limitation des émetteurs agressifs ; allocation explicitement imposée par des files par flux ou un dispositif comparable. On ne peut pas transformer le résultat du premier régime en garantie du troisième.

Une attaque distribuée ou une foule soudaine rend cette différence visible. La limitation d’un agrégat peut être nécessaire, mais elle ajoute une décision : quelle clé regroupe les paquets, quel seuil s’applique, comment repérer les faux positifs, quand lever la mesure ? La défense est peut-être légitime ; elle doit néanmoins laisser une trace de son autorité.

La chaîne de déploiement fait partie du produit

RFC 5290 insiste sur le déploiement incrémental. Un dispositif qui nécessite du marquage ECN, des polices aux deux extrémités, des changements de routeurs et une nouvelle comptabilité entre opérateurs n’est pas une option isolée. C’est une chaîne. Si un maillon manque, la promesse de bout en bout devient une propriété locale.

RFC 1958 rappelle l’absence de propriétaire unique et de commande centrale de l’Internet. Les applications changent plus facilement que l’infrastructure partagée et les accords économiques. Une solution moins précise mais tolérante à la coordination partielle peut donc rester plus accessible qu’un système supérieur après déploiement universel.

Une revue sérieuse demande quels équipements et partenaires doivent changer, qui paie, comment les marquages sont traités aux frontières et quel repli reste sûr dans un domaine non équipé. Supposer silencieusement une adoption complète, c’est cacher un risque de disponibilité dans la feuille de route.

Limites de la conclusion

RFC 5290 ne démontre pas qu’un opérateur contemporain protège assez le trafic ordinaire, que TCP domine encore de la même manière, qu’une offre premium nuit nécessairement au public, ni qu’une métrique unique d’équité doit s’imposer. Le best-effort ne garantit pas davantage la livraison : retard, perte, réordonnancement et panne restent possibles.

Sa contribution est une discipline de preuve. Être admis sur le socle est un fait d’accès. Recevoir un traitement de file défini est un fait d’exécution. Obtenir un résultat utile et juste est un jugement qui exige une identité, un groupe de comparaison et une observation applicative. Les fusionner donne au symbole plus d’autorité que le système qui l’a produit.

Sources