Draft: draft-ietf-ice-rfc5245bis

Commentary: Ta and RTO settings are now the same for real - time media and non - real - time media . An appendix has been , showing bandwidth consumption based on different values , and different ufrag value sizes .
During the gathering phase of ICE (sec-gathering) and while ICE is
performing connectivity checks (sec-connectivity_check), an agent
sends STUN and TURN transactions.  These transactions are paced at a
rate of one every Ta milliseconds, and utilize a specific RTO.  This
section describes how the values of Ta and RTO are computed.  This
computation depends on whether ICE is being used with a real-time
media stream (such as RTP) or something else.  When ICE is used for a
stream with a known maximum bandwidth, the computation in sec-rtp-
based MAY be followed to rate-control the ICE exchanges.  For all
other streams, the computation in sec-non-rtp MUST be followed.
The values of RTO and Ta change during the lifetime of ICE
processing.  One set of values applies during the gathering phase,
and the other, for connectivity checks.
where k is the number of media streams.  During the gathering phase,
Ta is computed based on the number of media streams the agent has
indicated in the candidate information, and the RTP packet size and
RTP ptime are those of the most preferred codec for each media
stream.  Once the candidate exchange is completed, the agent
recomputes Ta to pace the connectivity checks.  In that case, the
value of Ta is based on the number of media streams that will
actually be used in the session, and the RTP packet size and RTP
ptime are those of the most preferred codec with which the agent will
send.
where Num-Waiting is the number of checks in the check list in the
Waiting state, and Num-In-Progress is the number of checks in the In-
Progress state.  Note that the RTO will be different for each
transaction as the number of checks in the Waiting and In-Progress
states change.
These formulas are aimed at causing STUN transactions to be paced at
the same rate as media.  This ensures that ICE will work properly
under the same network conditions needed to support the media as
well.  See sec-pacing for additional discussion and motivations.
Because of this pacing, it will take a certain amount of time to
obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of
candidates that are gathered.
The formulas result in a behavior whereby an agent will send its
first packet for every single connectivity check before performing a
retransmit.  This can be seen in the formulas for the RTO (which
represents the retransmit interval).  Those formulas scale with N,
the number of checks to be performed.  As a result of this, ICE
maintains a nicely constant rate, but becomes more sensitive to
packet loss.  The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete
first.  This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs.  Implementors should be
aware of this consequence, but still should utilize the timer values
described here.
During the ICE gathering phase (sec-gathering) and while ICE is
performing connectivity checks (sec-connectivity_check), an agent
triggers STUN and TURN transactions.  These transactions are paced at
a rate indicated by Ta, and the retransmission interval for each
transaction is calculated based on the the retransmission timer for
the STUN transactions (RTO) RFC5389.
This section describes how the Ta and RTO values are computed during
the ICE gathering pahse and while ICE is performing connectivity
checks.
NOTE: Previously, in RFC 5245, different formulas were defined for
comupting Ta and RTO, depending on whether ICE was used for a real-
time media stream (e.g.  RTP) or not.
The formulas below result in a behavior whereby an agent will send
its first packet for every single connectivity check before
performing a retransmit.  This can be seen in the formulas for the
RTO (which represents the retransmit interval).  Those formulas scale
with N, the number of checks to be performed.  As a result of this,
ICE maintains a nicely constant rate, but becomes more sensitive to
packet loss.  The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete
first.  This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs.  Implementors should be
aware of this consequence, but still should utilize the timer values
described here.
In cases where ICE is used to establish some kind of session that is
not real time, and has no fixed rate associated with it that is known
to work on the network in which ICE is deployed, Ta and RTO revert to
more conservative values.  Ta SHOULD be configurable, SHOULD have a
default of 500 ms, and MUST NOT be configurable to be less than 500
ms.
If other Ta value than the default is used, the agent MUST indicate
the value it prefers to use in the ICE exchange.  Both agents MUST
use the higher out of the two proposed values.
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use
another value based on the characteristics of the associated media.
ICE agents MUST NOT use a Ta value smaller than 5 ms.
If an ICE agent wants to use another Ta value than the default value,
the agent MUST indicate the proposed value to its peer during the ICE
exchange.  Both agents MUST use the higher value of the proposed
values.  If an agent does not propose a value, the default value is
used for that agent when comparing which value is higher.
NOTE: sec-concheckbw shows examples of required bandwidth, using
different Ta values.
ICE agents MAY calculate the RTO value using other mechanisms than
those described above.  ICE agents MUST NOT use a RTO value smaller
than 500 ms.