7. Staukontrolle

RTP-Retransmission birgt das Risiko, die Netzüberlastung zu verstärken. In einer Best-Effort-Umgebung entsteht Paketverlust durch Überlastung. Reaktion auf Verlust durch Retransmission älterer Daten ohne Senkung der Rate des Originalstroms würde die Überlastung weiter erhöhen. Implementierungen SHOULD die folgenden Empfehlungen befolgen, um Retransmission zu nutzen.

Das RTP-Profil, unter dem das Retransmissionsschema eingesetzt wird, definiert in verschiedenen Umgebungen einen geeigneten Staukontrollmechanismus. Nach den Regeln des Profils kann eine RTP-Anwendung ihre akzeptable Bitrate und Paketrate bestimmen, um fair gegenüber anderen TCP- oder RTP-Strömen zu sein.

Nutzt eine RTP-Anwendung Retransmission, umfassen die akzeptable Paketrate und Bitrate sowohl Original- als auch retransmittierte Daten. Damit erreicht eine Anwendung mit Retransmission dieselbe Fairness wie eine ohne. In der Praxis ergeben sich daraus etwa folgende Maßnahmen:

Wird ein erweiterter Dienst genutzt, sollte sichergestellt werden, dass Gesamtbitrate und Paketrate denen des angeforderten Dienstes nicht übersteigen. Zusätzlich sollte überwacht werden, ob die angeforderten Dienste tatsächlich geliefert werden. In einer Best-Effort-Umgebung SHOULD der Sender keine Retransmission-Pakete senden, ohne Paketrate und Bitrate des Originalstroms zu senken (z. B. durch Kodierung mit niedrigerer Rate).

Zusätzlich MAY der Sender selektiv nur Pakete retransmitieren, die er für wichtig hält, und NACK-Nachrichten für andere ignorieren, um die Bitrate zu begrenzen.

Diese Staukontrollmechanismen sollten die Paketverlustrate in akzeptablen Grenzen halten. Im Kontext der Staukontrolle gilt Paketverlust als akzeptabel, wenn ein TCP-Strom über denselben Netzpfad unter denselben Bedingungen auf einer angemessenen Zeitskala einen mittleren Durchsatz erreicht, der nicht geringer ist als der des RTP-Stroms. Wird die Überlastung nicht unter Kontrolle gehalten, SHOULD Retransmission nicht verwendet werden.

Retransmissionen MAY in manchen Fällen dennoch gesendet werden, z. B. bei drahtlosen Verbindungen, bei denen Paketverluste nicht durch Überlastung verursacht werden, wenn der Server (oder der Client, der die Retransmission anfordert) schätzt, dass ein bestimmtes Paket oder Frame für die weitere Wiedergabe wichtig ist, oder wenn ein RTSP PAUSE ausgegeben wurde, um den Puffer füllen zu lassen (RTSP PAUSE beeinflusst das Senden von Retransmissionen nicht).

Schließlich kann es nötig sein, die Senderate anzupassen (oder die Anzahl der abonnierten Schichten bei geschichtetem Multicast) oder den Empfänger das Verlassen der Session zu ermöglichen.