Amélioration de la qualité de transmission vidéo dans les réseaux IEEE 802.11

3.4.2 Le contrôle de congestion multimédia

Le contrôle de congestion regroupe l'ensemble des mécanismes permettant d'adapter le débit des flux à la bande passante disponible dans le réseau. Les propriétés fondamentales d'un schéma de contrôle de congestion sont la stabilité, l'équité et la réactivité.

La stabilité signifie que la congestion est contrôlée et que le réseau fonctionne avec un état satisfaisant, sans oscillation excessive. Le concept d'équité est plus complexe, on dit qu'un algorithme est équitable lorsque, en régime stable, la bande passante est allouée de manière identique à tous les flots qui traversent une liaison congestionnée. Enfin, la réactivité porte sur la vitesse de convergence vers un état stable.

Le contrôle de congestion s'apparente alors à un processus adaptif impliquant source et récepteur qui, en surveillant l'état du réseau, peut détecter l'apparition de congestion ou les phénomènes d'évanouissement sur réseaux et réduire le débit de l'émetteur. À l'inverse, un état peu "chargé" du réseau va déclencher une augmentation du débit.

Deux solutions peuvent être envisagées suivant les contraintes applicatifs, une pour les applications point à point et une autre pour les applications multipoints.

3.4.2.1 Le contrôle de congestion point-à-point

Le contrôle de congestion dans les communications s'effectue à la source. Le principe est basé sur l'échange de message de contrôle entre le récepteur et la source. Ce dernier adapte son débit en fonction des informations collectées.

Les informations renvoyés par le récepteur peuvent être le temps aller retour RTT ou bien le taux de pertes. D'une part, en cas de congestion, le remplissage de la file d'attente entraîne l'accroissement du RTT. D'autre part, en cas de congestion, il y a aura des pertes des paquets due à la saturation des files d'attente du réseau. Le récepteur peut calculer son taux de pertes sur un intervalle donné et revoie cette valeur à la source en utilisant le protocole RTCP.

La première solution proposée était une émulation du protocole TCP en utilisant l'algorithme Additive-Increase Multiplicative-Decrease (AIMD). Comme TCP, Rate Adaptation Protocole RAP [22], les paquets envoyés par la source seront acquittés par le récepteur. La seule différence entre TCP et RAP est que la source ne revoie pas de nouveau les paquets perdus. Une autre approche vise le partage équitable des ressources avec les connexions TCP. Floyd et al [23] propose une équation permettant d'adapter

le débit en fonction de l'état du réseau en se comportant de la même manière que TCP.

DTCP =

RT T × _L. (3.1)

MTU

Avec RTT est le temps aller retour, MTU la taille des paquets et L est le taux de pertes calculés par le récepteur. Les rapports RR du protocole RTCP fournissent l'information de taux de pertes ainsi que l'information nécessaire au calcul du délai aller- retour RTT.

Padye et al.[24] ont proposé un modèle plus robuste et plus fiable tenant en compte de la retransmission et l'effet du timeouts sur TCP. L'équation de prédiction de la bande passante s'exprime alors sous la forme:

DT CP = 1.22 S

/ 2Dl /3Dl (3.2)

tRT T 3 + tRT Omin(1, 3 8 )l(1 + 32l²)

Où S est la taille des paquets, l le taux de pertes, tRTT est le temps aller-retour. Le

terme tRT O représente la valeur du timeouts régissant les demandes de retransmission de TCP estimée par quatre fois le temps aller retour:

tRTO = 4 X tRT T (3.3)

Ainsi l'équation peut être simplifié ainsi:

DT CP = 1.22 S

/ 2Dl /3Dl (3.4)

tRT T [ 3 + 12 ₈ l(1 + 32l²)]

LDA+, Loss-Delay Based Adustement Algorithm [25] proposé par Dorgham Sisalem et Hening Schulzrinne permet d'adapter le débit de transmission pour les applications multimédia. La source commence la session RTP avec un débit initiale r0 et une valeur initiale pour le A0. Après la réception an RTCP du récepteur, la source calcule de nouveau A_m avec:

A_m = min(Aadd_m, Aexp_m, ATCP_m) (3.5)

rm_1

Aadd m = Am_1 + (1 - R ) X Am_1 (3.6)

rm-1 Aexp m = (1 - exp1_ ^R ) X rm_ 1		(3.7)
ATCP m = M X	^T+1 ô (3.8) 2Xô

Avec R est le goulot d'étranglement,M la taille de paquets, ô est le RTT et rm_1 est le débit courant. Si un taux de perte est indiqué dans le paquet RTCP alors de débit est

réduit à:

v

r_m = max(rm_1 X (1 - l), rTCP) (3.9)

Dans le cas contraire, la source calcule de nouveau A_m et augmente le débit:

r_m = rm_1 + A_m (3.10) En adaptant le modèle du throughput TCP proposé par [22], TCP-Friendly Rate Control (TFRC) est introduit afin d'éviter les comportements oscillatoires. La mesure du taux de pertes est remplacée par une mesure d'événement de pertes afin de modéliser plus

finement la réaction à des rafales des pertes. Un événement de pertes est défini comme plusieurs paquets consécutifs perdus et afin d'améliorer la stabilité les variations de RTT sont lissées par un filtre glissante.

Cho et Al[26] proposent une amélioration de TFRC avec un protocole plus robuste appelé Adaptive TCP Friendly Rate Control Protocol AFTRC. ATFRC distingue entre le calcule de débit des périodes de pertes ainsi que la périodes sans perdes. Il garde la même formule [22] pour les périodes avec pertes et proposent une nouvelle équation pour les périodes sans pertes.