Draft: draft-ietf-ice-rfc5245bis

Commentary: The text and procedures associated with aggressive nomination has been removed . The spec now only talks about nomination , which refers to regular nomination . 
 LGTM , apart from apparent branch conflicts . 
 The text just says it needs to be unique . It does n't unique within what scope . I think it should be unique within the scope of a single component of a single media stream within a single session . But whatever we decide , it should be clear in the spec . Right now , it 's not . 
 Section 4.1.2 says " Each candidate for a media stream MUST have a unique priority " ( ) I think I 've always read that as in " unique within a media stream " , but indeed it can also be interpreted as " candidates in general " since all are part of some media stream . But I think media stream is the right scope . Uniqueness across components is taken care of by the " Component ID " part of the formula . I 'd suggest changing that text into " Each candidate for a media stream MUST have a unique priority in the scope of a media stream . " 
 I agree that we need to define the scope of the uniqueness - it 's something the IESG reviewers ( and sometimes also the Gen - ART reviewers ) ask about if unclear . 
 The problem with relying on the formula is that it 's only SHOULD strength . But the uniqueness is MUST strength . Which means that an implementation is free to use a different formula , but it must preserve the uniqueness , so the MUST - level text needs to clarify the uniqueness , not the SHOULD - level text . I like  's idea of adding to the MUST - level text to make it clear and not rely on the formula . So , two questions about that : Do we need to specify that it 's within the scope of a single session ( ICE restart ) ? I think it 's what is currently assumed by the text ( else ICE restarts would have to keep track of the priorities of past generations , which it does n't say needs to be done ) , but I think it would be nice to be explicit . Do we need to have uniqueness across components ? I do n't really see any reason for it , but maybe I 'm missing something . On the other hand , it does n't seem very difficult to keep them unique across components . So I do n't think it matters too much . 
 Related to this , note that the local preference value must also be unique - without any description of the scope of the uniqueness . Regarding your questions : 1 ) I assume " scope of an ICE session " means that the priority value is unique among all media streams associated with that session ? 2 ) Not sure I understand . If all candidates have unique priority values , that means the components will have unique priority values too . 
 Regarding " scope of an ICE session " , what I meant is that if you have an ICE restart , you can re - use values from the previous round of gathering . You do n't have to remember values from the past and avoid reusing them . I did not mean that a value has to be unique across all media streams ( that would be crazy ) . Regarding candidates having unique priorities across components , what I mean is : is it OK for two candidates to be for the same stream but different components and have the same priority ? I do n't see why not . But again , I do n't see it as big restriction to say that they have must be different . 
 I think this is still not resolved , and  pointed out that in IESG review they might ask about this . 
 Is n't this covered with the modified text in section 5.2 ? " In addition , each candidate MUST be assigned a unique priority amongst all candidates for the same data stream . " 
 " For the same data stream " is great ! I did n't realize that was in there . In that case , I think we can close the issue .
Consequently, ICE assigns one of the agents in the role of the
CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
controlling agent gets to nominate which candidate pairs will get
used for media amongst the ones that are valid.  It can do this in
one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION.
With regular nomination, the controlling agent lets the checks
continue until at least one valid candidate pair for each media
stream is found.  Then, it picks amongst those that are valid, and
sends a second STUN request on its NOMINATED candidate pair, but this
time with a flag set to tell the peer that this pair has been
nominated for use.  This is shown in fig-regular-select.
In aggressive nomination, the controlling agent puts the flag in
every connectivity check STUN request it sends.  This way, once the
first check succeeds, ICE processing is complete for that media
stream and the controlling agent doesn't have to send a second STUN
request.  The selected pair will be the highest-priority valid pair
whose check succeeded.  Aggressive nomination is faster than regular
nomination, but gives less flexibility.  Aggressive nomination is
shown in fig-aggressive-select.
Consequently, ICE assigns one of the agents in the role of the
CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
controlling agent gets to nominate which candidate pairs will get
used for media amongst the ones that are valid.
When nominating, the controlling agent lets the checks continue until
at least one valid candidate pair for each media stream is found.
Then, it picks amongst those that are valid, and sends a second STUN
request on its NOMINATED candidate pair, but this time with a flag
set to tell the peer that this pair has been nominated for use.  This
is shown in fig-regular-select.
The process of picking a valid candidate pair for media traffic by
including a flag in every connectivity check STUN request, such
that the first one to produce a valid candidate pair is used for
media.
In this state, ICE checks have produced nominated pairs for each
component of the media stream.  Consequently, ICE has succeeded
and media can be sent.
In this state, ICE checks have produced nominated pairs for each
component of the media stream.
The controlling agent MAY include the USE-CANDIDATE attribute in the
Binding request.  The controlled agent MUST NOT include it in its
Binding request.  This attribute signals that the controlling agent
wishes to cease checks for this component, and use the candidate pair
resulting from the check for this component. sec-choose-favor
provides guidance on determining when to include it.
The controlling agent includes the USE-CANDIDATE attribute in order
to nominate a candidate pair sec-choose-favor.  The controlled agent
MUST NOT include the USE-CANDIDATE attribute in its Binding request.
If the agent was a controlling agent, and it had included a USE-
CANDIDATE attribute in the Binding request, the valid pair generated
from that check has its nominated flag set to true.  This flag
indicates that this valid pair should be used for media if it is the
highest-priority one amongst those whose nominated flag is set.  This
may conclude ICE processing for this media stream or all media
streams; see sec-conclude.
If the agent was a controlling agent, and it had included a USE-
CANDIDATE attribute in the Binding request, the valid pair generated
from that check has its nominated flag set to true.  This flag
indicates that this valid pair SHOULD be used for media, unless the
sending agent detects that the candidiate pair does not work.  This
concludes the ICE processing for this media stream or all media
streams; see sec-conclude.
An agent MUST NOT select a candidate pair until it has sent a Binding
request, and received the corresponding Binding response, associated
with the candidiate pair.
The controlling agent nominates pairs to be selected by ICE by using
one of two techniques: regular nomination or aggressive nomination.
If its peer has a lite implementation, an agent MUST use a regular
nomination algorithm.  If its peer is using ICE options (present in
an ice-options attribute from the peer) that the agent does not
understand, the agent MUST use a regular nomination algorithm.  If
its peer is a full implementation and isn't using any ICE options or
is using ICE options understood by the agent, the agent MAY use
either the aggressive or the regular nomination algorithm.  However,
the regular algorithm is RECOMMENDED since it provides greater
stability.
With regular nomination, the agent lets some number of checks
complete, each of which omit the USE-CANDIDATE attribute.  Once one
or more checks complete successfully for a component of a media
stream, valid pairs are generated and added to the valid list.  The
agent lets the checks continue until some stopping criterion is met,
and then picks amongst the valid pairs based on an evaluation
criterion.  The criteria for stopping the checks and for evaluating
the valid pairs is entirely a matter of local optimization.
When nominating, the controlling agent lets some number of checks
complete, each of which omit the USE-CANDIDATE attribute.  Once one
or more checks complete successfully for a component of a media
stream, valid pairs are generated and added to the valid list.  The
agent lets the checks continue until some stopping criterion is met,
and then picks amongst the valid pairs based on an evaluation
criterion.  The criteria for stopping the checks and for evaluating
the valid pairs is entirely a matter of local optimization.
Regular nomination provides the most flexibility, since the agent has
control over the stopping and selection criteria for checks.  The
only requirement is that the agent MUST eventually pick one and only
one candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute present.  Regular nomination also improves ICE's
resilience to variations in implementation (see sec-futureproof).
Regular nomination is also more stable, allowing both agents to
converge on a single pair for media without any transient selections,
which can happen with the aggressive algorithm.  The drawback of
regular nomination is that it is guaranteed to increase latencies
because it requires an additional check to be done.
With aggressive nomination, the controlling agent includes the USE-
CANDIDATE attribute in every check it sends.  Once the first check
for a component succeeds, it will be added to the valid list and have
its nominated flag set.  When all components have a nominated pair in
the valid list, media can begin to flow using the highest-priority
nominated pair.  However, because the agent included the USE-
CANDIDATE attribute in all of its checks, another check may yet
complete, causing another valid pair to have its nominated flag set.
ICE always selects the highest-priority nominated candidate pair from
the valid list as the one used for media.  Consequently, the selected
pair may actually change briefly as ICE checks complete, resulting in
a set of transient selections until it stabilizes.
If certain connectivity check messages are lost, ICE agents using
aggressive nomination may end up with different views on the selected
candidate pair.  In this case, if a security protocol that is able to
authenticate the communicating parties (e.g., DTLS) is used, the
controlled agent may receive valid secured traffic or handshake
initialization originating from the controlling agent on a candidate
pair that is different from the one the controlled agent considers as
the selected pair.  If this happens, the controlled agent MUST
consider the pair with the secured traffic as the correct selected
pair.  If such security protocol is not used, both agents SHOULD
continue sending connectivity check messages on the selected pair
even after a pair has already been selected for use.  In order to
prevent the problem described here, at least one check from both
agents needs to fully succeed on the selected pair.
The controlling agent has control over the stopping and selection
criteria for checks.  The only requirement is that the agent MUST
eventually pick one and only one candidate pair and generate a check
for that pair with the USE-CANDIDATE attribute present.
The controlled agent SHOULD select the nominated candidate pair if
the agent is receiving Binding responses associated with that
candidiate pair.  Before the agent has received Binding responses
associated with the candidiate pair, the agent can send media on any
candidiate for which it has received Binding responses.  If more than
one candidate pair is nominated by the controlling agent, the
controlled agent SHOULD select the candidate pair with the highest
priority.
NOTE: A controlling agent that does not support this speification
(i.e. it is implemented according to RFC 5245) might nominate more
than one candidiate pair.  This was referred to as aggressive
nomination in RFC 5245.  The usage of the 'ice2' ice option by
endpoints supporting this specifcation should prevent such
controlling agents from using aggressive nomination.
If the controlling agent is using an aggressive nomination
algorithm, this may result in several updated candidate
exchanges as the pairs selected for media change.  An agent MAY
delay sending its candidates for a brief interval (one second
is RECOMMENDED) in order to allow the selected pairs to
stabilize.