4. Media Prioritization (Priorisation des médias)
Dans le modèle de priorisation WebRTC, l'application informe le point de terminaison WebRTC de la priorité des médias et des données contrôlés depuis l'API.
Dans ce contexte, un « flux (Flow) » est utilisé pour les unités auxquelles une priorité spécifique est attribuée via l'API WebRTC.
Pour les médias, un « flux média (Media Flow) », qui peut être un « flux audio (Audio Flow) » ou un « flux vidéo (Video Flow) », est ce que [RFC7656] appelle une « source média (Media Source) », qui se traduit par un « flux RTP source (Source RTP Stream) » et un ou plusieurs « flux RTP de redondance (Redundancy RTP Streams) ». Cette spécification ne décrit pas la priorisation entre les flux RTP provenant d'une seule source média.
Tous les flux médias dans WebRTC sont supposés être interactifs, comme défini dans [RFC4594] ; il n'y a pas de support d'API de navigateur pour indiquer si les médias sont interactifs ou non interactifs.
Un « flux de données (Data Flow) » est les données sortantes sur un seul canal de données WebRTC.
La priorité associée à un flux média ou flux de données est classée comme « very-low (très faible) », « low (faible) », « medium (moyen) » ou « high (élevé) ». Il n'y a que quatre niveaux de priorité dans l'API.
Les paramètres de priorité affectent deux éléments de comportement : les décisions de séquence d'envoi des paquets et les marquages des paquets. Chacun est décrit dans sa propre section ci-dessous.
4.1. Local Prioritization (Priorisation locale)
La priorisation locale est appliquée au nœud local, avant l'envoi du paquet. Cela signifie que la priorisation a un accès complet aux données sur les paquets individuels et peut choisir un traitement différent en fonction du flux auquel appartient un paquet.
Lorsqu'un point de terminaison WebRTC a des paquets à envoyer sur plusieurs flux qui sont contrôlés par la congestion sous le même régime de contrôle de congestion, le point de terminaison WebRTC devrait (SHOULD) faire émettre les données de manière à ce que chaque flux à chaque niveau de priorité reçoive environ deux fois la capacité de transmission (mesurée en octets de charge utile) du niveau inférieur.
Ainsi, lorsqu'une congestion se produit, un flux à haute priorité aura la capacité d'envoyer 8 fois plus de données qu'un flux à très faible priorité si les deux ont des données à envoyer. Cette priorisation est indépendante du type de média. Les détails du paquet à envoyer en premier sont définis par l'implémentation.
Par exemple, s'il y a un flux audio à haute priorité envoyant des paquets de 100 octets et un flux vidéo à faible priorité envoyant des paquets de 1000 octets, et qu'une capacité sortante existe pour envoyer > 5000 octets de charge utile, il serait approprié d'envoyer 4000 octets (40 paquets) d'audio et 1000 octets (un paquet) de vidéo comme résultat d'un seul passage de décisions d'envoi.
Inversement, si le flux audio est marqué de faible priorité et que le flux vidéo est marqué de haute priorité, le planificateur peut décider d'envoyer 2 paquets vidéo (2000 octets) et 5 paquets audio (500 octets) lorsqu'une capacité sortante existe pour envoyer > 2500 octets de charge utile.
S'il y a deux flux audio à haute priorité, chacun pourra envoyer 4000 octets dans la même période où un flux vidéo à faible priorité est capable d'envoyer 1000 octets.
Deux exemples de stratégies de mise en œuvre sont :
-
Lorsque la bande passante disponible est connue de l'algorithme de contrôle de congestion, configurer chaque codec et chaque canal de données avec un taux d'envoi cible approprié à sa part de bande passante disponible.
-
Lorsque le contrôle de congestion indique qu'un nombre spécifié de paquets peut être envoyé, envoyer les paquets disponibles à envoyer en utilisant un schéma de tourniquet pondéré (weighted round-robin) à travers les connexions.
Toute combinaison de ceux-ci, ou d'autres schémas ayant le même effet, est valide, tant que la distribution de la capacité de transmission est approximativement correcte.
Pour les médias, il est généralement inapproprié d'utiliser des files d'attente profondes pour l'envoi ; il est plus utile, par exemple, de sauter les images intermédiaires qui n'ont pas de dépendances sur elles afin d'atteindre un débit binaire inférieur. Pour les données fiables, les files d'attente sont utiles.
Notez que cette spécification ne dicte pas quand les flux disparates doivent être « contrôlés par la congestion sous le même régime de contrôle de congestion ». La question du couplage des contrôleurs de congestion est explorée plus en détail dans [RFC8699].
4.2. Usage of Quality of Service -- DSCP and Multiplexing (Utilisation de la qualité de service -- DSCP et multiplexage)
Lorsque le paquet est envoyé, le réseau prendra des décisions sur la mise en file d'attente et/ou l'élimination du paquet qui peuvent affecter la qualité de la communication. L'expéditeur peut tenter de définir le champ DSCP du paquet pour influencer ces décisions.
Les implémentations devraient (SHOULD) tenter de définir la QoS sur les paquets envoyés, selon les directives de [RFC8837]. Il est approprié de s'écarter de cette recommandation lors de l'exécution sur des plateformes où le marquage QoS n'est pas implémenté.
L'implémentation peut (MAY) désactiver l'utilisation des marquages DSCP si elle détecte des symptômes de comportement inattendu tels que l'inversion de priorité ou le blocage de paquets avec certains marquages DSCP. Quelques exemples de tels comportements sont décrits dans [ANRW16]. La détection de ces conditions dépend de l'implémentation.
Un problème particulièrement difficile est lorsqu'un transport média utilise plusieurs DSCP, où l'un peut être bloqué et un autre peut être autorisé. Ceci est autorisé même au sein d'un seul flux média pour la vidéo dans [RFC8837]. Les implémentations doivent diagnostiquer ce scénario ; une implémentation possible consiste à envoyer des sondes ICE initiales avec DSCP 0, et à envoyer des sondes ICE sur tous les DSCP destinés à être utilisés une fois qu'une paire de candidats a été sélectionnée. Si une ou plusieurs des sondes marquées DSCP échouent, l'expéditeur basculera le type de média vers l'utilisation de DSCP 0. Cela peut être effectué simultanément avec le trafic média initial ; en cas d'échec, les données initiales peuvent nécessiter d'être renvoyées. Ce basculement invalidera, bien sûr, toute information de congestion collectée jusqu'à ce point.
Les défaillances peuvent également commencer à se produire pendant la durée de vie de l'appel ; ce cas devrait être plus rare et peut être géré par les mécanismes normaux pour l'échec du transport, qui peuvent impliquer un redémarrage ICE.
Notez que lorsqu'un DSCP cause une non-livraison, il faut basculer l'ensemble du flux média vers DSCP 0, car tout le trafic pour un seul flux média doit être sur la même file d'attente à des fins de contrôle de congestion. D'autres flux sur le même transport, utilisant des DSCP différents, n'ont pas besoin de changer.
Tous les paquets transportant des données de l'association SCTP supportant les canaux de données doivent (MUST) utiliser un seul DSCP. Le point de code utilisé devrait (SHOULD) être celui recommandé par [RFC8837] pour le canal de données de plus haute priorité transporté. Notez que cela signifie que tous les paquets de données, quelle que soit leur priorité relative, seront traités de la même manière par le réseau.
Tous les paquets sur une connexion TCP, quel que soit ce qu'elle transporte, doivent (MUST) utiliser un seul DSCP.
Plus de conseils sur l'utilisation des DSCP avec RTP, ainsi que la relation entre DSCP et contrôle de congestion, sont donnés dans [RFC7657].
Il existe un certain nombre de schémas pour atteindre la qualité de service qui ne dépendent pas uniquement des DSCP. Certains de ces schémas dépendent de la classification du trafic en flux basés sur le 5-tuple (adresse source, port source, protocole, adresse destination, port destination) ou le 6-tuple (5-tuple + DSCP). Dans des conditions différentes, il peut donc être judicieux pour une application d'envoi de choisir l'une des configurations suivantes :
- Chaque flux média transporté sur son propre 5-tuple
- Flux médias regroupés par type de média en 5-tuples (comme transporter tout l'audio sur un 5-tuple)
- Tous les médias envoyés sur un seul 5-tuple, avec ou sans différenciation en 6-tuples basés sur les DSCP
Dans chacune des configurations mentionnées, les canaux de données peuvent être transportés dans leur propre 5-tuple ou multiplexés avec l'un des flux médias.
Des configurations plus complexes, telles que l'envoi d'un flux vidéo à haute priorité sur un 5-tuple et l'envoi de tous les autres flux vidéo multiplexés ensemble sur un autre 5-tuple, peuvent également être envisagées. Plus d'informations sur le mappage des flux médias aux 5-tuples peuvent être trouvées dans [RFC8834].
Une implémentation d'envoi doit (MUST) être capable de prendre en charge les configurations suivantes :
- Multiplexer tous les médias et données sur un seul 5-tuple (entièrement regroupé)
- Envoyer chaque flux média sur son propre 5-tuple et les données sur leur propre 5-tuple (entièrement non regroupé)
L'implémentation d'envoi peut (MAY) choisir de prendre en charge d'autres configurations, telles que le regroupement de chaque type de média (audio, vidéo ou données) dans son propre 5-tuple (regroupement par type de média).
L'envoi de données de canal de données sur plusieurs 5-tuples n'est pas pris en charge.
Une implémentation de réception doit (MUST) être capable de recevoir des médias et des données dans toutes ces configurations.