La décision

Que l’organe de décision se trouve du côté des machines d’extrémité, donc hors du réseau, ou dans le réseau maîtrisé par l’opérateur, le déclenchement de la décision de traiter la congestion se fait à l’examen des informations notifiées ou inférées du réseau et une fois ces informations jugées assez alarmantes pour devoir agir afin de prévenir une dégradation de la qualité de service.

La décision peut être très rapide comme pour TCP qui décide de réduire son débit dès la réception de la première information de marquage ECN. Mais le risque avec un déclenchement trop rapide de la décision, après juste une information ponctuelle sur la congestion, est d’activer une réaction qui ne modifie pas la qualité de service de l’utilisateur voire qui le limite inutilement et mène à une sous-exploitation des ressources du réseau, ce qui n’est pas non plus dans l’intérêt de l’opérateur.

Une décision trop tardive est également superflue, puisque la réaction pourrait venir alors que la congestion est déjà passée. Ou alors, bien que la réaction tardive vînt tout de même résoudre la congestion encore présente, cette dernière aurait déjà dégradé suffisam- ment la qualité de service pour nuire à l’expérience du client de l’opérateur.

Plusieurs possibilités s’offrent à l’organe de décision pour se prononcer sur la congestion au moment opportun. Les informations qu’il reçoit de la part du réseau sur le marquage peuvent servir de base à un calcul de moyenne pondérée sur un intervalle de temps pour avoir une vision plus lissée de ce qui se passe dans le réseau. C’est sur la valeur de la moyenne que sera prise la décision de réagir ou non à la congestion.

La décision qui est prise par les machines d’extrémité est plutôt une décision de niveau flux et généralement rapide à effectuer, alors qu’une décision de niveau réseau, c.-à-d. par l’opérateur, est plutôt une décision par utilisateur ou par agrégat de flux, et souvent moins réactive sur les informations d’utilisation du réseau.

Service Level Agreement

Dans le cas où le client a signé un contrat avec son opérateur appelé Service Level Agreement (SLA), ses statistiques peuvent être surveillées pour réagir quand la qualité de service risque de ne plus satisfaire le contrat comme par exemple lorsque les pertes dépassent le pourcentage précisé dans celui-ci, ou si la latence devient trop importante. En pratique, cette approche complexe est réservée à des services spécifiques, typiquement aux services à destination des entreprises.

Volume de données

Une autre possibilité est que les données d’utilisation du réseau par le client puissent être comparées à ce qui a été précisé dans son contrat de souscription avec l’opérateur pour réagir au bout d’une certaine limite. C’est ce qui est fait actuellement par exemple dans les réseaux mobiles où le client souscrit à une certaine quantité de données à consommer au-delà de laquelle il peut payer le surplus, voire son débit limité, ou bien encore ne plus avoir accès au réseau [33]. Le but est de prévenir la congestion et de garantir l’équité entre clients puisqu’en incitant l’utilisateur à modifier son comportement, il peut lisser lui- même son utilisation du réseau pour ne pas consommer son volume de données limité. Mais prendre une décision uniquement sur la quantité de données ne préviendra pas forcément la congestion dans le réseau puisqu’elle ne prend pas en compte les informations sur l’état du réseau. Un utilisateur peut très bien consommer son volume de données alors que le réseau est soumis à une grosse charge de trafic, par exemple pendant les heures chargées du soir entre 19 heures et 22 heures [34], tandis que consommer son volume de données pendant les heures non chargées n’est ni nécessaire ni utile car il n’affecte en rien l’état du réseau. De plus, la limitation en volume de données est une pratique très impopulaire chez les clients de l’opérateur [35]. Elle est également combattue par les autorités de régulation comme la Federal Communications Commission (FCC) [36] aux États-Unis qui reçoit plusieurs plaintes des clients des opérateurs américains.

Volume de congestion

Une stratégie de décision similaire est possible mais cette fois-ci en limitant les utili- sateurs seulement selon leur impact sur le réseau. Lorsque celui-ci est non chargé, aucune congestion n’est détectée, aucune information sur celle-ci n’est engendrée, les utilisateurs peuvent alors utiliser le réseau comme il leur sied, sans limitation sur un volume de données. Mais quand le réseau est encombré, des signaux sur la congestion (comme le marquage) sont générés pour le trafic des utilisateurs, idéalement proportionnellement au volume de congestion généré, et c’est selon la quantité de ces informations qu’on les limite. On ne déclenche alors une décision de traitement de la congestion que pour les utilisateurs ayant un impact important sur le réseau.

Pour cela, il faudrait obtenir les informations sur la contribution de chaque utilisateur à la congestion du réseau. Dans une approche collaborative, l’IETF a proposé un méca- nisme, appelé ConEx [7], où l’utilisateur lui-même notifie à l’opérateur le marquage qu’il a subi sur le chemin des données. Par exemple, l’information sur le marquage ECN que

l’expéditeurTCPreçoit du destinataire à travers les accusés de réception est réinjecté dans le réseau par l’expéditeur à travers des messages appelés Re-Echo [37] (cf. figure 1.9). À chaque utilisateur est attribué un volume de congestion (et non un volume de données) qui est consommé par les messages Re-Echo et au-delà duquel la décision de réagir est prise par l’opérateur. Avec cette approche, l’utilisateur est incité à ne pas encombrer le réseau pendant les périodes chargées de la journée en reportant ses téléchargements les moins importants, comme les mises à jour des systèmes par exemple, aux heures où le réseau est le moins chargé. À l’inverse, quand le réseau n’est pas chargé, l’utilisateur peut envoyer sans limitation du trafic.

Figure 1.9 – Message Re-Echo de ConEx

Les mêmes effets peuvent être atteints au niveau du réseau de l’opérateur sans l’inter- vention de l’utilisateur avec une architecture centralisée telle que le SDN. Sans centrali- sation, ConExnotifie des informations de marquage (l’impact de l’utilisateur sur l’utilisa- teur) directement en entrée de réseau où se situe l’organe de décision (valeur du volume de congestion) de l’opérateur et où la réaction a lieu. Avec un contrôleur SDN centralisé, l’opérateur peut récupérer le marquage spécifique à un utilisateur directement en sortie de réseau à travers le protocole de commande et le comparer au volume de congestion qui lui est attribué, information située également au niveau du contrôleur, pour prendre la décision d’agir lorsque le volume de congestion est consommé.