Zum Hauptinhalt springen

16. Setting Ta and RTO (Einstellen von Ta und RTO)

Während der Erfassungsphase von ICE (Abschnitt 4.1.1) und während ICE Konnektivitätsprüfungen durchführt (Abschnitt 7), sendet ein Agent STUN- und TURN-Transaktionen. Diese Transaktionen werden mit einer Rate von einer alle Ta Millisekunden getaktet und verwenden ein spezifisches RTO. Dieser Abschnitt beschreibt, wie die Werte von Ta und RTO berechnet werden. Diese Berechnung hängt davon ab, ob ICE mit einem Echtzeit-Medienstrom (wie RTP) oder etwas anderem verwendet wird. Wenn ICE für einen Strom mit einer bekannten maximalen Bandbreite verwendet wird, MAY der Berechnung in Abschnitt 16.1 gefolgt werden, um die ICE-Austausche ratenzusteuern. Für alle anderen Ströme MUST der Berechnung in Abschnitt 16.2 gefolgt werden.

16.1. RTP Media Streams (RTP-Medienströme)​

Die Werte von RTO und Ta ändern sich während der Lebensdauer der ICE-Verarbeitung. Ein Satz von Werten gilt während der Erfassungsphase und der andere für Konnektivitätsprüfungen.

Der Wert von Ta SHOULD konfigurierbar sein und SHOULD einen Standardwert haben von:

Für jeden Medienstrom i:

Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime

                       1
 Ta = MAX (20ms, ------------------- )
                       k
                     ----
                     \        1
                      >    ------
                     /       Ta_i
                     ----
                      i=1

wobei k die Anzahl der Medienströme ist. Während der Erfassungsphase wird Ta basierend auf der Anzahl der Medienströme berechnet, die der Agent in seinem Angebot oder seiner Antwort angegeben hat, und die RTP-Paketgröße und RTP-ptime sind die des am meisten bevorzugten Codecs für jeden Medienstrom. Sobald ein Angebot und eine Antwort ausgetauscht wurden, berechnet der Agent Ta neu, um die Konnektivitätsprüfungen zu takten. In diesem Fall basiert der Wert von Ta auf der Anzahl der Medienströme, die tatsächlich in der Sitzung verwendet werden, und die RTP-Paketgröße und RTP-ptime sind die des am meisten bevorzugten Codecs, mit dem der Agent senden wird.

Darüber hinaus SHOULD der in [RFC5389] definierte Neuübertragungs-Timer für die STUN-Transaktionen, RTO, konfigurierbar sein und während der Erfassungsphase einen Standardwert haben von (SHOULD):

RTO = MAX (100ms, Ta * (number of pairs))

wobei number of pairs sich auf die Anzahl der Paare von Kandidaten mit STUN- oder TURN-Servern bezieht.

Für Konnektivitätsprüfungen SHOULD RTO konfigurierbar sein und einen Standardwert haben von (SHOULD):

RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))

wobei Num-Waiting die Anzahl der Prüfungen in der Prüfliste im Status Waiting ist und Num-In-Progress die Anzahl der Prüfungen im Status In-Progress ist. Beachten Sie, dass das RTO für jede Transaktion unterschiedlich sein wird, da sich die Anzahl der Prüfungen in den Status Waiting und In-Progress ändert.

Diese Formeln zielen darauf ab, dass STUN-Transaktionen mit der gleichen Rate wie Medien getaktet werden. Dies stellt sicher, dass ICE unter denselben Netzwerkbedingungen ordnungsgemäß funktioniert, die auch für die Unterstützung der Medien erforderlich sind. Siehe Anhang B.1 für zusätzliche Diskussionen und Motivationen. Aufgrund dieser Taktung wird es eine gewisse Zeit dauern, bis alle Server-Reflexive- und Relayed-Kandidaten erhalten wurden. Implementierungen sollten sich der Zeit bewusst sein, die dafür erforderlich ist, und wenn die Anwendung ein Zeitbudget erfordert, die Anzahl der erfassten Kandidaten begrenzen.

Die Formeln führen zu einem Verhalten, bei dem ein Agent sein erstes Paket für jede einzelne Konnektivitätsprüfung sendet, bevor er eine Neuübertragung durchführt. Dies ist in den Formeln für das RTO (das das Neuübertragungsintervall darstellt) zu sehen. Diese Formeln skalieren mit N, der Anzahl der durchzuführenden Prüfungen. Infolgedessen behält ICE eine schön konstante Rate bei, wird jedoch empfindlicher gegenüber Paketverlusten. Der Verlust des ersten einzelnen Pakets für eine Konnektivitätsprüfung führt wahrscheinlich dazu, dass dieses Paar lange braucht, um validiert zu werden, und stattdessen wird eine Prüfung mit niedrigerer Priorität (aber eine, für die kein Paketverlust aufgetreten ist) viel wahrscheinlicher zuerst abgeschlossen. Dies führt dazu, dass ICE suboptimal arbeitet und Paare mit niedrigerer Priorität gegenüber Paaren mit höherer Priorität wählt. Implementierer sollten sich dieser Konsequenz bewusst sein, sollten aber dennoch die hier beschriebenen Timer-Werte verwenden.

16.2. Non-RTP Sessions (Nicht-RTP-Sitzungen)​

In Fällen, in denen ICE verwendet wird, um eine Art von Sitzung aufzubauen, die nicht in Echtzeit ist und keine feste Rate damit verbunden hat, von der bekannt ist, dass sie in dem Netzwerk funktioniert, in dem ICE bereitgestellt wird, kehren Ta und RTO zu konservativeren Werten zurück. Ta SHOULD konfigurierbar sein, SHOULD einen Standardwert von 500 ms haben und MUST NOT so konfigurierbar sein, dass es weniger als 500 ms beträgt.

Darüber hinaus SHOULD der Neuübertragungs-Timer für die STUN-Transaktionen, RTO, konfigurierbar sein und während der Erfassungsphase einen Standardwert haben von (SHOULD):

RTO = MAX (500ms, Ta * (number of pairs))

wobei number of pairs sich auf die Anzahl der Paare von Kandidaten mit STUN- oder TURN-Servern bezieht.

Für Konnektivitätsprüfungen SHOULD RTO konfigurierbar sein und einen Standardwert haben von (SHOULD):

RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
Letztes Update am