Mon blog

L'Internet a toujours fonctionné sur le principe du « fais au mieux » (best effort), c'est-à-dire que les applications qui l'utilisent n'ont aucune garantie sur les caractéristiques quantitatives du réseau qui sera à leur disposition. Le débit, par exemple, ne peut pas être connu à l'avance ; lorsqu'on commence un transfert de fichiers, on ne sait pas quand il se terminera. Ce principe a assuré le succès de l'Internet, par rapport à des réseaux concurrents qui se vantaient de leurs « garanties de qualité de service » et qui, en conséquence, offraient un service moyen nettement inférieur. Mais il est contesté par certains qui voudraient la possibilité de garantir une « qualité de service » (QoS pour « Quality of Service ») dans le réseau. Ce nouveau RFC ne tranche pas sur la question de savoir si la QoS est une bonne idée ou pas, il rappelle uniquement l'intérêt qu'il y a à disposer d'un mécanisme équivalent au « fais au mieux », une offre très efficace et qui correspond à beaucoup d'usages.

À l'époque où l'Internet avait du mal à s'imposer face aux réseaux prônés par les gens des télécommunications, appuyés par les gouvernements, un des reproches qui lui étaient le plus souvent fait était de ne pas garantir de « qualité de service » (QoS). Avant un appel téléphonique avec SIP, en effet, on ne peut pas savoir quel sera la capacité disponible, quel sera le RTT ou quelle sera la gigue. On peut les mesurer mais rien ne garantit que ces grandeurs resteront constantes pendant l'appel. Cela peut gêner certaines applications. C'est pour cela que des mécanismes visant à gérer la QoS ont été développés sur Internet comme intserv (RFC 1633) ou bien diffserv (RFC 2475). En pratique, ces mécanismes ont été très peu déployés, ce qui relativise la soi-disant demande de QoS. En général, il est moins coûteux d'augmenter le débit des tuyaux que de déployer ces mécanismes complexes. Mais certains vont plus loin et réclament le déploiement généralisé de QoS dans Internet, au point de ne plus garder de service « fais au mieux ». C'est là qu'intervient notre RFC 5290.

Sa thèse de base est que le socle de l'Internet doit rester un service « fais au mieux » (quitte à ajouter quelques mécanismes de QoS par dessus). Ce service est défini comme « tout ce qui ne bénéficie pas d'un service différencié » (section 1). Un moyen simple d'assurer ce service est l'« équité entre les flux » (flow-rate fairness).

La section 2 expose les propriétés de ce service simple best effort. En 2.1, les auteurs listent les forces de ce service :

• Il ne demande pas trop d'efforts de la part de l'infrastructure réseau : les routeurs, par exemple, ont ainsi le minimum de travail. Ce service libère ainsi des ressources pour, par exemple, augmenter la capacité (les réseaux télécoms traditionnels passaient tellement de temps à gérer la QoS que leur débit total était sérieusement réduit).
• Il ne demande pas trop de mécanismes économiques entre les opérateurs. Une des principales raisons du très faible déploiement de diffserv est qu'il nécessite des mécanismes de compensation entre opérateurs. Autrement, tout le monde enverrait ses paquets avec la classe la plus favorisée ! Ces compensations sont complexes et nécessitent des accords entre opérateurs qui vont plus loin que les mécanismes actuels entre opérateurs, ou entre un opérateur et son client.
• Et, surtout, ce service « fais au mieux » est utile dans le monde réel. Il marche, pour une grande variété d'applications, et il propulse l'Internet depuis trente ans, malgré les affirmations (qu'on trouve par exemple dans la quasi-totalité des ouvrages universitaires sur les réseaux informatiques publiés en France) comme quoi un réseau sans QoS ne servait à rien.

Évidemment, tout n'est jamais uniformément rose. Le service « fais au mieux » a aussi des limites, que détaille la section 2.2. D'abord, certains utilisateurs veulent de la QoS et sont prêts à payer pour cela (section 2.2.1). Il ne faut pas les en priver mais cette demande soulève des questions très diverses. Par exemple, l'ensemble des ressources réservées pour les services « à garantie » ne doit pas mener à l'épuisement des ressources pour le service de base, autrement les riches utilisateurs pourraient s'approprier tout le réseau pour eux. Il existe une abondante littérature (le RFC donne quelques références) sur l'économie de l'Internet, la légitimité et l'efficacité de faire payer de manière différenciée, etc. Ensuite, les services avec QoS peuvent interférer avec la « transparence du réseau ». En effet, il n'est pas difficile d'imaginer des cas où, pour certaines applications, celui qui ne paierait pas le surcoût de la QoS serait, en pratique, exclu du réseau. Mais le débat est loin d'être clos sur la question de savoir quel niveau de QoS reste compatible avec cette transparence du réseau. (Le RFC 2990 donne des éléments de départ sur l'architecture de QoS.)

Une autre faiblesse du « fais au mieux » est sa sensibilité aux incivilités (section 2.2.2). Si un certain nombre d'utilisateurs ne jouent pas le jeu, le réseau peut s'effondrer puisqu'il n'y a pas de limites à l'allocation de ressources. Dans cette optique, les services différenciés ne seraient pas tant un moyen de « donner plus à ceux qui paient plus » qu'un mécanisme de contrôle de la congestion, même en présence d'implémentations « agressives » de TCP/IP, qui ne respecteraient pas les règles énoncées dans le RFC 2914.

Enfin, la dernière faiblesse (section 2.2.3) est le cas de « pics » de trafic brutaux (suite à une DoS ou tout simplement en cas de grand succès d'un site Web), pour lesquels le mécanisme « fais au mieux » mène en général à ce que personne ne soit servi...

Après ce tour des forces et faiblesses du mécanisme « fais au mieux », le RFC aborde, dans la section 3, le concept d'« équité entre les flux ». L'idée est que cette équité ne serait certes pas parfaite, mais assurerait un service « fais au mieux » qui soit convenable pour tout le monde. Notre RFC paraphrase Winston Churchill en disant que l'équité entre les flux est le plus mauvais des services, à l'exception de tous les autres.

En effet (section 3.1), cette équité serait relativement facile à mettre en œuvre (pour TCP, qui forme la grande majorité du trafic actuel, elle est déjà implémentée dans ses algorithmes), elle ne nécessite pas de calculs de facturation complexes, elle marche aujourd'hui et elle satisfait une notion sommaire, mais raisonnable, de la « justice » puisque chaque flot aura une part de la capacité du réseau.

Elle a par contre des limitations (section 3.2). Elle est difficile à faire respecter (section 3.2.1). En effet, dans l'Internet actuel, son respect dépend des machines aux extrémités du réseau, machines qui sont sous le contrôle d'un utilisateur qui peut être un méchant égoïste. Changer ce système pour que les routeurs fassent le contrôle serait un changement considérable d'architecture. Et, après tout, l'Internet s'en est passé jusqu'à présent.

Une deuxième question est qu'il n'existe pas de définition claire et consensuelle de ce qu'est l'équité entre les flux. Tout le monde est pour l'équité, c'est lorsqu'on essaie de la définir que les ennuis commencent (section 3.2.2). D'abord, « flux » (flow) n'est pas bien défini (cf. RFC 2309, RFC 2914, RFC 3124 et bien d'autres). Est-ce par connexion ? (Un concept qui n'existe pas pour tous les protocoles, par exemple UDP.) Ou bien pour tout trafic entre deux machines ? Ou bien, à une granularité intermédiaire, faut-il mettre toutes les connexions TCP démarrées par le même navigateur Web ou bien le même client BitTorrent dans le même flux ? Et l'équité doit-elle se mesurer en nombre de paquets ou en octets/seconde ? (Les protocoles interactifs comme SSH préféreraient certainement la première solution.) Et que faire avec les protocoles où le trafic tend à être très irrégulier ? Faut-il une équité « en moyenne » ? Si oui, sur quelle période ? Bref, si l'objectif politique est clair, le traduire en chiffres précis semble très difficile.

La section 4 du RFC 5290 s'attaque à un problème sur lesquels bien des protocoles se sont brisés : le déploiement. Pour reprendre l'exemple traditionnel du fax, celui qui a acheté le premier fax a fait preuve d'une confiance aveugle dans le succès de la technologie. Son fax ne lui servait à rien. Ce n'est qu'une fois qu'un nombre suffisant d'acheteurs s'en sont procuré un que son achat avait un sens. De même, une bonne partie des difficultés d'IPv6 s'explique par cet effet « œuf et poule ». Les premiers à déployer IPv6 n'ont aucun intérêt à le faire (ils ne pourront communiquer avec personne). Résultat, le déploiement ne se fait pas.

Et pour la QoS ? C'est le même problème : déployer un réel système de QoS sur l'Internet nécessiterait des actions par un certain nombre d'acteurs différents et ceux-ci ne voient pas de motivation à le faire. Voici pourquoi presque tous les déploiements actuels de QoS sont restés limités à une seule organisation.

Enfin, la section 5 décrit le travail qui a été fait, à l'IETF et ailleurs, sur ce problème. L'histoire de la qualité de service sur l'Internet est vieille, on trouve déjà une discussion dans le RFC 896, mais aussi, plus tard, dans le RFC 2212 et RFC 2475. Le RFC 2309 traite du cas où certains flux ne jouent pas le jeu et tentent d'occuper toute la capacité disponible et le RFC 3714 de la notion d'équité. La référence reste le RFC 2914 sur les principes de contrôle de congestion sur l'Internet.

La section 5.2 contient plusieurs autres références sur le travail fait à l'extérieur de l'IETF comme les articles Flow Rate Fairness: Dismantling a Religion ou Pricing the Internet.