7. Contrôle de congestion
La retransmission RTP présente un risque d'accroître la congestion du réseau. Dans un environnement best-effort, la perte de paquets est causée par la congestion. Réagir à une perte par la retransmission d'anciennes données sans diminuer le débit du flux d'origine accroîtrait donc encore la congestion. Les implémentations SHOULD suivre les recommandations ci-dessous pour utiliser la retransmission.
Le profil RTP sous lequel le schéma de retransmission est utilisé définit un mécanisme de contrôle de congestion approprié dans différents environnements. En suivant les règles du profil, une application RTP peut déterminer son débit binaire et son débit en paquets acceptables afin d'être équitable vis-à-vis des autres flux TCP ou RTP.
Si une application RTP utilise la retransmission, le débit en paquets et le débit binaire acceptables incluent à la fois les données d'origine et retransmises. Cela garantit qu'une application utilisant la retransmission atteint la même équité qu'une application qui ne l'utilise pas. Une telle règle se traduirait en pratique par les actions suivantes :
Si un service amélioré est utilisé, il faut s'assurer que le débit binaire total et le débit en paquets ne dépassent pas ceux du service demandé. Il faut en outre surveiller que les services demandés sont effectivement fournis. Dans un environnement best-effort, l'émetteur SHOULD NOT envoyer de paquets de retransmission sans réduire le débit en paquets et le débit binaire du flux d'origine (par exemple en encodant les données à un débit inférieur).
En outre, l'émetteur MAY retransmettre sélectivement uniquement les paquets qu'il juge importants et ignorer les messages NACK pour les autres paquets afin de limiter le débit binaire.
Ces mécanismes de contrôle de congestion devraient maintenir le taux de perte de paquets dans des paramètres acceptables. Dans le contexte du contrôle de congestion, la perte de paquets est considérée acceptable si un flux TCP sur le même chemin réseau et subissant les mêmes conditions réseau obtiendrait, sur une échelle de temps raisonnable, un débit moyen au moins égal à celui qu'obtient le flux RTP. Si la congestion n'est pas maîtrisée, la retransmission SHOULD NOT être utilisée.
Des retransmissions MAY encore être envoyées dans certains cas, par exemple sur des liaisons sans fil où les pertes de paquets ne sont pas causées par la congestion, si le serveur (ou le client qui formule la demande de retransmission) estime qu'un paquet ou une image particulier est important pour poursuivre la lecture, ou si une commande RTSP PAUSE a été émise pour permettre à la mémoire tampon de se remplir (RTSP PAUSE n'affecte pas l'envoi des retransmissions).
Enfin, il peut être nécessaire d'adapter le débit d'émission (ou le nombre de couches souscrites pour une session multicast en couches), ou d'organiser le départ du récepteur de la session.