Configuration de la file EF pour codec à débit variable 134

Lors des expériences précédentes, pour la configuration des files TC, nous avons considéré le débit IP du flux audio (21.6 kbps) puisqu’un codec à débit constant est utilisé mais nous avons utilisé le débit IP crête estimé du flux vidéo (130 kbps) qui utilise un codec à débit variable (débit IP entre 60 kbps et 130 kbps, avec un débit IP moyen entre 85 et 90 kbps).

Cependant, même si, effectivement, se baser sur le débit moyen impliquerait des délais de transmission de paquets trop importants particulièrement lorsque le lien satellite se trouverait surchargé, se baser uniquement sur le débit crête serait aussi extrêmement pénalisant en termes d’efficacité globale du système puisque, la plupart du temps, le débit réel serait bien moins important.

Pour cette expérience, nous considérons donc que, dans le cas d’un flux vidéo, le débit moyen ET le débit crête estimés correspondants au codec utilisé sont obtenus depuis la table de codecs locale ou le MTR, le but étant alors d’étudier comment la quantité de CRA allouée

135 à un ST donné et la taille des files DiffServ peuvent être configurées de façon optimale à partir des débits moyen et crête, dans le cas d’une vidéo utilisant le codec H 263 (issue d’une session de vidéoconférence).

Pour cela, nous étudions le taux de paquets dont le délai est inférieur à 400 ms en fonction d’une part, du débit considéré (qui varie entre le débit moyen et le débit crête) pour la reconfiguration des files DiffServ et la quantité de CRA requise auprès de l’ARC et, d’autre part, de la charge du ST considéré. Les résultats sont résumés sur la Figure 55 et montrent que le choix du débit considéré est important par rapport à la charge du lien satellite correspondant au ST concerné qui n’influence que légérement le délai de transmission des paquets.

Figure 55 – Evolution du taux de paquets ayant un délai inférieur à 400 ms en fonction du débit considéré et de la charge du ST

En effet, on voit que, si la file EF et la quantité de CRA sont configurées en tenant compte du débit moyen (90 kbps), si on tient compte du pire des cas (lien surchargé en permanence), on aura 67 % des paquets seulement qui respecteront les recommandations de l’ITU-T. Par contre, dès qu’on les configure en tenant compte d’une valeur un peu supérieure au débit moyen (95 kbps), on voit que cela permet d’augmenter de façon non négligeable le nombre de paquets conformes (88,6 % dans le pire des cas). Ensuite, le taux augmente progressivement avec l’augmentation du débit considéré pour la quantité de CRA et la reconfiguration de la file EF. On peut d’ailleurs noter que le taux de paquets dont le délai est inférieur à 400 ms semble saturer aux alentours de 97,5 %, ce qui semble anormal mais en regardant de plus près les résultats obtenus, on peut repérer que le délai des premiers paquets correspondants au flux vidéo est supérieur à 400 ms pendant les premiers instants de l’expérience, certainement à cause d’un problème de configuration de la plateforme d’émulation satellite. Si l’on ajoute ces 2,5% à chacune des valeurs du graphique, pour s’assurer dans tous les cas que par exemple 95% des paquets ont un délai inférieur à 400 ms, il faudra configurer la file à 115 kbps, ce qui correspond à environ 0,6*(débit crête – débit moyen) + débit moyen ou encore à 0,6*débit crête + 0,4*débit moyen.

Nos expériences indiquent aussi qu’en cas de sous-estimation du débit considéré pour un flux vidéo, la qualité ressentie au niveau de l’utilisateur en sera grandement pénalisée. Par

136 exemple, dans le cas du codec H263, configurer la file EF et la quantité de CRA avec une valeur de 80 kbps fait chuter le taux de paquets dont le délai est inférieur à 400 ms à 0,07 %.

Jusqu’à présent, nous avons considéré que les valeurs prises pour l’allocation de CRA et la configuration de la taille de la file EF (ainsi que la diminution de la taille de la file BE) étaient les mêmes. Mais, dans ce cas là, la file EF ne peut pas utiliser de requêtes RBDC en plus de l’allocation CRA. Nous allons donc maintenant étudier le cas où la quantité de CRA est fixe mais où la taille de la file EF peut être supérieure et donc utiliser des requêtes RBDC si nécessaire. Le Tableau 11 présente alors l’évolution du taux de paquets dont le délai est supérieur à 400 ms en fonction de la taille de la file EF en considérant que 90K de CRA sont alloués.

Tableau 11 – Etude de l’influence des requêtes RBDC sur le taux de paquets dont le délai est inférieur à 400 ms

Dans le cas d’une allocation CRA de 90K, l’utilisation de requêtes RBDC n’est donc pas suffisante pour atteindre des taux supérieurs à 90%, même si l’on configure la taille de la file EF avec une valeur supérieure au débit crête de l’application, mais elle permet tout de même une amélioration significative du taux de paquets conformes aux recommandations de l’ITU- T.

Finalement, la quantité de CRA allouée au ST et la configuration de la taille de la file EF doivent donc dépendre de la politique de l’opérateur et des engagements qu’il a pris vis à vis de ses clients. Ainsi dans le cas d’une vidéoconférence, l’opérateur peut proposer différents types d’abonnements variant par exemple entre le service de faible qualité offrant une quantité de CRA (et une reconfiguration des files DiffServ) correspondante au débit moyen estimé du codec utilisé (indiqué dans la base du MTR) et le service le plus cher offrant une quantité de CRA correspondante au débit crête estimé du codec utilisé (indiqué dans la base du MTR), avec entre les deux, un service offrant, par exemple, un débit égal à 0,6*débit crête + 0,4*débit moyen et un autre offrant une quantité de CRA égal au débit moyen mais permettant en plus l’utilisation par la file EF de requêtes RBDC (la quantité étant aussi fixée par l’opérateur).

Ensuite, l’opérateur doit globalement définir quels types de services doivent être associés à une allocation CRA (nous avons par exemple considéré que les applications audio et vidéo nécessitent du CRA tandis que les applications de type messagerie instantanée n’en nécessite pas) et quelle est la politique adoptée en cas de congestion si une nouvelle demande d’allocation CRA intervient (refus du nouveau flux, acceptation du flux mais en RBDC, acceptation du flux et renégociation d’autres flux, etc…). Dans tous les cas, ces politiques d’acceptation d’admission de connexion peuvent être mise en œuvre dans le cadre de notre architecture de QoS basée sur des proxies SIP améliorés.

137