Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 14:18:35 +0000

Hi Ekr,

Thank You for the review and comments! Please see inline.

Note that I will address your comments on the Security Considerations in a separate reply.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Review in context at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3312

> IMPORTANT:
>
> *  If the agent's tie-breaker value is larger than or equal to the contents of the ICE-CONTROLLING attribute, the agent generates
> IMPORTANT: This algorithm seems like it's not going to work properly.
> Consider the case where A and B happen to have the same tie-breaker and both think they are controlling, and the 
> Binding Requests cross. Each now sends a 487 and then they switch to controlled. Ugh. Unless I'm missing something, 
> if the tie-breakers match, you are stuck. Given that the chance is 2^{-64} this seems to not be a critical failing, but the algorithm 
> still seems wrong.

The algorithm hasn't changed since RFC 5245, and nobody indicated that it doesn't work. I guess people assume that due to the random characteristics, the chance of both agents using the same value is extremely small.

Also note that it is only in special cases where both endpoints will indicate the same role to begin with.

---

REST:

>   single solution that is flexible enough to work well in all
>   situations.
> This section seems pretty dated. Aren't ICE and ICE-style solutions pretty much the de facto standard now.

I suggest to remove the sentence.

---

>   may not be aware of it.  The type of NAT and its properties are also
>  unknown.  L and R are capable of engaging in an candidate exchange
>   process, whose purpose is to set up a data session between L and R.
> Nit: a candidate exchange. This appears to be a result of changing offer/answer (where "an" was appropriate) to "candidate"

Correct. I will fix as suggested.

---

>   At least one viable candidate has a transport address obtained
>   directly from a local interface.  Such a candidate is called a host
> Nit: this is awkward. Perhaps "The first category of candidates are those with a transport ..."

I will fix as suggested.

---

>   When the agent sends the TURN Allocate request from IP address and
>   port X:x, the NAT (assuming there is one) will create a binding
>Nit: "a TURN Allocate"

I will fix as suggested.

---

>   the next candidate pair on the list periodically.  These are called
>   ordinary checks.  When a STUN transaction succeeds, one or more
>   candidate pairs will become so called valid pairs, and will be added
> Nit: I would quote "ordinary check" here and "triggered check" below.

I will fix as suggested.

---

>   provide means to exchange candidate information between the ICE
>   agents.  The specific details of (i.e how to encode candidate
>   information and the actual candidate exchange process) for different
> Nit: i.e -> i.e.,

I will fix as suggested.

---

>   Nomination, Regular Nomination:  The process of the controlling agent
>      indicating to the controlled agent which candidate pair the ICE Given that you have 
>      removed Aggressive Nomination, do you still need to refer to "Regular Nomination"

People asked to keep it in the Terminology section, to make it clear that "nomination" is 5245bis refers to what was called "regular nomination" in RFC 5245.

However, I suggest to s/regular nomination/nomination in section 13.

---

>   candidate gathering, (2) candidate prioritization, (3) redundant
>  candidate elimination, and (4) sending of the candidates to the peer.
> This is an odd diagram. There's no reason why these have to happen in sequence and in fact in Trickle ICE, they don't, so 
> this diagram seems misleading., as well as potentially contradicting the beginning of S 5.1.1.
>
> "An ICE agent gathers candidates when it believes that communication is imminent. "

I think the sequence applies to core ICE, and is also how it's done in 5245. 

The fact that trickle ICE does it differently I think shall be described in the trickle spec.

However, it if helps, I could add the following note:

"NOTE: This specification assumes that all candidates are gathered before they are sent to the peer. The trickle ICE extensions define procedures
where gathered candidates can be sent to the peer as soon as they have been gathered, while additional candidates are still gathered."

---

>   When candidates are obtained, unless the agent knows for sure that
>   RTP/RTCP multiplexing will be used (i.e. the agent knows that the
>   other agent also supports, and is willing to use, RTP/RTCP
> Nit: "i.e.,"

I will fix as suggested.

---

>      addresses that do allow location tracking, that are configured on
>      the same interface, and are part of the same network prefix MUST
>      NOT be gathered.
> You need to remove both of these commas, because they indicate a nonrestrictive clause, but this is a restrictive clause.

I will fix as suggested.

---

>   The gathering process is controlled using a timer, Ta.  Every time Ta
>   expires, the agent can generate another new STUN or TURN transaction.
> No comma here.

I will fix as suggested.

---

>   The agent will receive a Binding or Allocate response.  A successful
>   Allocate response will provide the agent with a server reflexive Or nothing or an error.
>
>              (2^8)*(IP precedence) +
>              (2^0)*(256 - component ID) 
>
> Isn't this the same formula as in S 5.1.2.1.

Section 5.1.2.1 defines the generic formula. This instance is when it is used by a Lite implementation.

Of course, in order to align, I could replace "IP precedence" with "local preference".

---

>      Foundation:  A sequence of up to 32 characters.
>
> The Foundation is never transmitted, AFAIK. So why does it have to be up to 32 characters? It certainly wasn't exchanged in 5245.

It is included in the candidate attribute defined in 5245 (Section 15.1):

    candidate-attribute   = "candidate" ":" foundation SP component-id SP
                               transport SP
                               priority SP
                               connection-address SP     ;from RFC 4566

    foundation            = 1*32ice-char

---

>   data stream, and for updating the peer with the ICE's selection, when
>   needed.  The controlled agent is told which candidate pairs to use
>   for each data stream, and does not require updating the peer to
>
> Told by who?

The text seems to be a leftover.

In fact, my suggestion would be to only keep the following:

   "For each session, each ICE agent (Initiating and Responding) takes on
   a role.  There are two roles -- controlling and controlled.  The
   controlling agent is responsible for the choice of the final
   candidate pairs used for communications. The sections below
   describe in detail the  actual procedures followed by controlling and 
   controlled agents."

What a full and lite implementation do is described in the text below.

---

>   pair priorities, orders pairs by priority, prunes pairs, removes
>   lower-priority pairs, and sets check list states.  If candidates are
>   added to a check list (e.g, due to detection of peer reflexive 
>
> Please fix your subject verb agreement here.

I will remove the s:es.

---

>      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 
>
> This was kinda terrible in 5245. Given that you use it once, maybe just have + GT(G, D)
>
> And then say GT(G, D) == 1 if G>D and 0 otherwise.

I probably just don't see it, but what is the difference?

---

>                       Figure 8: Initial Pair State This figure caption is kind of a mess. I suggest just removing it.

I will remove it.

---

>   state in the check list set has been processed, the first check list
>   is picked again.  Etc.
> Nit: "again, etc."

I will fix as suggested.

---

>   pair to the remote candidate of the pair, as described in
>   Section 7.2.4.
> IMPORTANT: You don't just send a STUN request, you start a STUN transaction,

There are multiple instances in the spec where it talks about sending STUN requests or Binding requests.

Section 7.2 provides the STUN client details, including how to process the response etc.

---

>   lists.  On the other hand the responding agent either performs the
>   triggered or ordinary checks as described above.
>
> I don't understand this paragraph. What distinction are you trying to draw.

I don't understand the text either. I suggest to remove the whole paragraph.

---

>   o  The base is local candidate of the candidate pair from which the
>      Binding request was sent.
> Nit: "is the local"

I will fix as suggested.

---

>   The ICE agent constructs a candidate pair whose local candidate
>   equals the mapped address of the response, and whose remote candidate
>
> IMPORTANT: When does this happen?

The last sentence of the parent section (7.2.5.3)  says:

"If a check is considered a success, the ICE agent performs (in order) the actions described in the following sections."

---

>   a different check list than the one to which the pair that generated
>   the connectivity checks), or it may be a pair not currently in any
>   check list.
> IMPORTANT: How would a valid pair be on some other check list?

That seems like an error, but I will think a little more about it.

---

>      this specification.  There may be a conflict, but it cannot be
>      detected.
> What previous version? This was required in 5245. Maybe at this point we can just deprecate this?

I suggest to remove the whole bullet.

---

> 7.3.1.3.  Learning Peer Reflexive Candidates 
>
>This entire section seems to duplicate 7.2.5.3.1

Section 7.2.5.3.1 describes how a STUN client detects a peer reflexive candidate then it receives a STUN response.

Section 7.3.1.3 describes how a STUN server detects a peer reflexive candidate when it receives a STUN request.

Sure, the text is similar, but separate procedures.

---

>         in-progress transaction.  Cancellation means that the agent
>         will not retransmit the request, will not treat the lack of
>         response to be a failure, but will wait the duration of the 
>
> Why are you cancelling In-Progress checks when you receive a peer-reflective check? 
> If you receive two in a row, then it seems like this delays a successful check. 

True.

So, I will remove the cancel part.

Do you still think it should create a new binding request, or is the ongoing In-Progress check enough to check the pair?

---

> More generally, this document should explain how you end up in this
> situation: you only get here when "the source transport address of the request 
> does not match any existing remote candidate", so how can it be on a check list 
> unless this is the second observation of a peer reflexive.

I am not sure I understand. The source transport sentence you refer to is related to detection of peer reflexive candidates.

---

>   Prior to nominating, the controlling agent let connectivity checks
>   continue until some stopping criterion is met.  After that, based on lets.
>   The criterion details for stopping the connectivity checks and for
>   selecting a pair for nomination, are outside the scope of this "criterion details" seems ungrammatical. 
>
>   5245 had "criteria". What's wrong with that?

I have no idea. At some point someone has most likely requested that "criteria" is replaced with "criterion details". I can change back to "criteria".

---

>   have ceased using a given local candidate (a candidate may be used by
>   multiple ICE sessions, e.g. in forking scenarios), the agent can free
>   that candidate.  The three-second delay handles cases when aggressive
> Nit: "e.g.,"

I will fix as suggested.

---

>   Session Description Protocol (SDP) [RFC4566] is defined in
>   [I-D.ietf-mmusic-ice-sip-sdp].
> Presumably you want to cite 5245 S 14, which states:
>
>Consequently, when a controlling agent is communicating with a peer that supports options it doesn't know about, the agent MUST run a regular nomination algorithm.  When regular nomination is used, ICE will converge perfectly even when both agents use different pair prioritization algorithms.

I am not sure it is related to SDP.

I suggest to modify the first paragraph:

OLD:

 "For example, the agent will not use the aggressive nomination procedure defined in RFC 5245."

NEW:

 "For example, the agent will not use the aggressive nomination procedure defined in RFC 5245. In addition,
   It will ensure that an RFC 5245-compliant peer does not use aggressive nomination either, as described in
   Section 14 of RFC 5245."

---

>   15 seconds.  Agents MAY use a bigger value, but MUST NOT use a value
>   smaller than 15 seconds.
> This is a very old number. Is it supported by an modern measurement?

I don't know. The number is used in 5245, and there were never any suggestions to change it.

---

>   will converge perfectly even when both agents use different pair
>   prioritization algorithms.  One of the keys to such convergence is
>   triggered checks, which ensure that the nominated pair is validated 
>
> Given that you have removes aggressive, you presumably want to revise this section

I suggest the following modification:

OLD:

   "One of the complications in achieving interoperability is that ICE
   relies on a distributed algorithm running on both agents to converge
   on an agreed set of candidate pairs.  If the two agents run different
   algorithms, it can be difficult to guarantee convergence on the same
   candidate pairs.  The regular nomination procedure described in
   Section 8 eliminates some of the tight coordination by delegating the
   selection algorithm completely to the controlling agent.
   Consequently, when a controlling agent is communicating with a peer
   that supports options it doesn't know about, the agent MUST run a
   regular nomination algorithm.  When regular nomination is used, ICE
   will converge perfectly even when both agents use different pair
   prioritization algorithms.  One of the keys to such convergence is
   triggered checks, which ensure that the nominated pair is validated
   by both agents.  Consequently, any future ICE enhancements MUST
   preserve triggered checks."

NEW:

   One of the complications in achieving interoperability is that ICE
   relies on a distributed algorithm running on both agents to converge
   on an agreed set of candidate pairs.  If the two agents run different
   algorithms, it can be difficult to guarantee convergence on the same
   candidate pairs.  The nomination procedure described in
   Section 8 eliminates some of the tight coordination by delegating the
   selection algorithm completely to the controlling agent, and ICE
   will converge perfectly even when both agents use different pair
   prioritization algorithms. One of the keys to such convergence is
   triggered checks, which ensure that the nominated pair is validated
   by both agents.  Consequently, any future ICE enhancements MUST
   preserve triggered checks."

---

>16.  STUN Extensions
>None of the stuff here is "New" any longer, as it was allocated in RFC 5245.

I'll change it to "STUN Attributes".

---

>   First and foremost, ICE makes use of TURN and STUN servers, which
>   would typically be located in the data centers.  The STUN servers
>   require relatively little bandwidth.  For each component of each data
> Nit: this used to read "the network operators data centers" and when you removed "network operators" this became ungrammatical

I will remove "the" and say "in data centers".

---

>   there will be four transactions per call (one for RTP and one for
>   RTCP, for both caller and callee).  Each transaction is a single
>   request and a single response, the former being 20 bytes long, and Is this currently true? 
>
> How many people still don't support RTP-MUX?

I don't know. But, unless you use mux exclusive the offerer still has to gather and provide RTCP candidates.

Maybe we could add the following new paragraph to the end of the section:

"NOTE: As the usage of RTP/RTCP multiplexing is becoming more common in VoIP deployments, it will reduce the need for separate STUN transaction for RTP and RTCP."

---

>   can and will vary over time.  In a network with 100% behave-compliant
>   NAT, it is exactly zero.  At time of writing, large-scale consumer
>   deployments were seeing between 5 and 10 percent of calls requiring 
>
> This text dates to 5245. Is that still true?

I have no idea. I suggest to remove the sentence.

---

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 06:42:28 -0800

On Mon, Feb 19, 2018 at 6:18 AM, Christer Holmberg <
[email-masked]> wrote:

> > *  If the agent's tie-breaker value is larger than or equal to the
> contents of the ICE-CONTROLLING attribute, the agent generates
> > Binding Requests cross. Each now sends a 487 and then they switch to
> controlled. Ugh. Unless I'm missing something,
> > if the tie-breakers match, you are stuck. Given that the chance is
> 2^{-64} this seems to not be a critical failing, but the algorithm
> > still seems wrong.
>
> The algorithm hasn't changed since RFC 5245, and nobody indicated that it
> doesn't work.

I just explained why it doesn't work. Do you think this analysis is wrong?

I guess people assume that due to the random characteristics, the chance of
> both agents using the same value is extremely small.

Yes, I agree that the chance of experiencing the problem in the field is
very low. But that doesn't make the algorithm right, and it's not sensible
to (a) specify the edge case behavior (b) specify it so that it doesn't
work correctly. Better would be to return a *different* error that says you
have unresolvable role conflict.

> People asked to keep it in the Terminology section, to make it clear that
> "nomination" is 5245bis refers to what was called "regular nomination" in
> RFC 5245.
>

OK, but then you should explain why you are using "regular" here.

> > This is an odd diagram. There's no reason why these have to happen in
> sequence and in fact in Trickle ICE, they don't, so
> "NOTE: This specification assumes that all candidates are gathered before
> they are sent to the peer. The trickle ICE extensions define procedures
> where gathered candidates can be sent to the peer as soon as they have
> been gathered, while additional candidates are still gathered."
>

The issue here isn't that all candidates are gathered before they are sent
to the peer but rather  that the diagram implies that no gathering happens
before the peer's candidates are received. That's not a requirement of
5245, and, as I said, contradicts the beginning of S 5.1.1.

> used by a Lite implementation.

Of course, in order to align, I could replace "IP precedence" with "local
> preference".

My suggestion is to have one copy.

> > The Foundation is never transmitted, AFAIK. So why does it have to be up
> to 32 characters? It certainly wasn't exchanged in 5245.
>

My mistake.

> What a full and lite implementation do is described in the text below.

Fine.

> I probably just don't see it, but what is the difference?

It has the same semantics but it's easier to read. I mean, either you think
the C syntax is self-explanatory or you
don't. If you do, then you don't need to explain it. If you don't, it's
opaque in the expression,

> requests or Binding requests.

I agree, but this statement is still confusing. Is there a reason not to
change it?

> "If a check is considered a success, the ICE agent performs (in order) the
> actions described in the following sections."
>

Please add a reverse reference.

> That seems like an error, but I will think a little more about it.

Thanks.

> Section 7.2.5.3.1 describes how a STUN client detects a peer reflexive
> candidate then it receives a STUN response.
>
> Section 7.3.1.3 describes how a STUN server detects a peer reflexive
> candidate when it receives a STUN request.
>

This would benefit from consolidation.

> Do you still think it should create a new binding request, or is the
> ongoing In-Progress check enough to check the pair?
>

My initial reaction is you don't need to do anything extra, but I could
easily be wrong here.

> I am not sure I understand. The source transport sentence you refer to is
> related to detection of peer reflexive candidates.
>

My question is what sequence of events can lead to this situation, as it is
surprising to the readers.

> >Consequently, when a controlling agent is communicating with a peer that
> supports options it doesn't know about, the agent MUST run a regular
> nomination algorithm.  When regular nomination is used, ICE will converge
> perfectly even when both agents use different pair prioritization
> algorithms.
>

Perhaps:
"as required by Section 14 of RFC 5245 for peers which receive unknown ICE
options"

> I don't know. The number is used in 5245,

Right, that's my point.

and there were never any suggestions to change it.

OK.

>    Section 8 eliminates some of the tight coordination by delegating the

some of the need for tight

> gather and provide RTCP candidates.

Right, but then there will be three transactions per call in the common
case.

> I have no idea. I suggest to remove the sentence.

WFM.

-Ekr

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Feb 2018 11:19:12 -0600

On Feb 19, 2018, at 8:42 AM, Eric Rescorla <[email-masked]> wrote:
>> The algorithm hasn't changed since RFC 5245, and nobody indicated that it doesn't work.
>> 
>> I guess people assume that due to the random characteristics, the chance of both agents using the same value is extremely small.
>> 
> Yes, I agree that the chance of experiencing the problem in the field is very low. But that doesn't make the algorithm right, and it's not sensible to (a) specify the edge case behavior (b) specify it so that it doesn't work correctly. Better would be to return a *different* error that says you have unresolvable role conflict.
> 
> 

This was a fix that the WG did not choose to pursue in this particular bis draft. That may very well be because no one noticed it before. Unless one of you sees an obvious fix, this will probably need some WG discussion.

Given that this problem 1) only matters for certain 3PCC like scenarios, 2) only has (as Ekr mentions) a 2^-64 chance of happening does anyone think it is worth delaying this draft to fix it? Would it be acceptable to note the potential problem and move on?

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 17:58:17 +0000

Hi,

>>>>> Consider the case where A and B happen to have the same 
>>>>> tie-breaker and both think they are controlling, and the Binding 
>>>>> Requests cross. Each now sends a 487 and then they switch to 
>>>>> controlled. Ugh. Unless I'm missing something, if the tie-breakers match, you are stuck. 
>>>>> Given that the chance is 2^{-64} this seems to not be a critical failing, but the algorithm still seems wrong.
>>>> 
>> Yes, I agree that the chance of experiencing the problem in the field is very low. But that doesn't make the algorithm right, 
>> and it's not sensible to (a) specify the edge case behavior (b) specify it so that it doesn't work correctly. Better would be to 
>> return a *different* error that says you have unresolvable role conflict.
> 
> This was a fix that the WG did not choose to pursue in this particular bis draft. That may very well be because no one noticed
> it before. Unless one of you sees an obvious fix, this will probably need some WG discussion.
>
> Given that this problem 1) only matters for certain 3PCC like scenarios, 2) only has (as Ekr mentions) a 2^-64 chance of happening
> does anyone think it is worth delaying this draft to fix it? Would it be acceptable to note the potential problem and move on?

I don't see how a new error code would help. The agents know that both use the same value. The question is what they do after that.

IF we really want to solve this, one simple solution be to say that, if this happens, and endpoint simply calculates a new tie-breaker value, and tries again? BUT, then we would have to change section 16.1, which says that a new value can only be calculated at an ICE restart.

So, could we simply say that, if this happens, the agent MUST do an ICE restart, and it MUST calculate a new tie-breaker value? 

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 10:01:53 -0800

On Mon, Feb 19, 2018 at 9:58 AM, Christer Holmberg <
[email-masked]> wrote:

> >>>>> Given that the chance is 2^{-64} this seems to not be a critical
> failing, but the algorithm still seems wrong.
> >>>>
> >>> I guess people assume that due to the random characteristics, the
> chance of both agents using the same value is extremely small.
> >>>
> >> Yes, I agree that the chance of experiencing the problem in the field
> is very low. But that doesn't make the algorithm right,
> >> and it's not sensible to (a) specify the edge case behavior (b) specify
> it so that it doesn't work correctly. Better would be to
> > This was a fix that the WG did not choose to pursue in this particular
> bis draft. That may very well be because no one noticed
> > Given that this problem 1) only matters for certain 3PCC like scenarios,
> 2) only has (as Ekr mentions) a 2^-64 chance of happening
> > does anyone think it is worth delaying this draft to fix it? Would it be
> acceptable to note the potential problem and move on?
>
> I don't see how a new error code would help. The agents know that both use
> the same value.

This is not necessarily correct. Consider what happens in the case where A
has sent a check but has not yet received any checks, but B has received
A's check. Then B knows but A does not. Presumably this is why the spec
uses an error for this. What I'm talking about here is just using an error
to indicate "this is broken"

The question is what they do after that.

I agree that that's a new question.

> IF we really want to solve this, one simple solution be to say that, if
> this happens, and endpoint simply calculates a new tie-breaker value, and
> tries again? BUT, then we would have to change section 16.1, which says
> that a new value can only be calculated at an ICE restart.
>
> So, could we simply say that, if this happens, the agent MUST do an ICE
> restart, and it MUST calculate a new tie-breaker value?
>

Now both sides might do a simultaneous restart. Is that going to work?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 10:02:47 -0800

On Mon, Feb 19, 2018 at 9:19 AM, Ben Campbell <[email-masked]> wrote:

> >>> > Consider the case where A and B happen to have the same tie-breaker
> and both think they are controlling, and the
> This was a fix that the WG did not choose to pursue in this particular bis
> draft. That may very well be because no one noticed it before. Unless one
> of you sees an obvious fix, this will probably need some WG discussion.
>

Yes, probably.

> 2) only has (as Ekr mentions) a 2^-64 chance of happening does anyone think
> it is worth delaying this draft to fix it? Would it be acceptable to note
> the potential problem and move on?
>

Given that this probably creates failure, I'd rather have an explicit
failure than an algorithm which is supposed to fix it, but does not.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 18:12:01 +0000

Hi,

...

>> IF we really want to solve this, one simple solution be to say that, if this happens, and endpoint simply calculates a 
>> new tie-breaker value, and tries again? BUT, then we would have to change section 16.1, which says that a new value can only be calculated at an ICE restart.
>>

We could say that the initiating agent MUST do the restart.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 10:24:34 -0800

On Mon, Feb 19, 2018 at 10:12 AM, Christer Holmberg <
[email-masked]> wrote:

> this happens, and endpoint simply calculates a
> >> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated at
> an ICE restart.
> >>

In this scenario, don't both sides believe they are the initiating peer,
hence the need for the tiebreaker?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 18:29:51 +0000

Hi,

...

> In this scenario, don't both sides believe they are the initiating peer, hence the need for the tiebreaker?

Probably...

But, then I don't see what we could do. If both agents send a check, and receive 487, we can't define a procedure for one of the agents.

Perhaps we should then change the must-not-change-the-value-unless-restart and say that an agent changes the tie-breaker value and try again.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 10:33:05 -0800

On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restart
> and say that an agent changes the tie-breaker value and try again.
>

As you say, the problem is inherently that the situation is symmetrical.

At this point in the design process, I don't think it's worth trying to
actually make the call succeed; a 2^{-64} failure rate is much lower than
organic call failure rates from other causes, even in non-3PCC scenarios.
Rather, I think the spec should just prescribe a clean failure mode via a
new error code, rather than having both sides wildly oscillate between
controlled and controlling

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 19:19:35 +0000

Hi,

(I have removed the tie-breaker comment, since it is covered in a separate thread)

Review in context at:

NEW:

Nomination:  The process of the controlling agent
      indicating to the controlled agent which candidate pair the ICE
      agents will use for sending and receiving data. The nomination
      process defined in this specification was referred to "regular nomination"
      in RFC 5245.

---

> The issue here isn't that all candidates are gathered before they are sent to the peer but rather  that the diagram implies that no gathering happens before the peer's 
> candidates are received. That's not a requirement of 5245, and, as I said, contradicts the beginning of S 5.1.1.

I could add the following sentence: "Note that an agent can begin gathering candidates at any point, even if it has not received any candidates (or even been contacted) by its peer."

---

> My suggestion is to have one copy.
 
I can keep the formula in section 5.1.2.1.

But, in the case of Lite, we still need to say what values are used for the different formula parts - even if we don't show the formula.

---
 
> It has the same semantics but it's easier to read. I mean, either you think the C syntax is self-explanatory or you
> don't. If you do, then you don't need to explain it. If you don't, it's opaque in the expression,

Personally I think the formula is clear, and we could remove the following sentence:

"where G>D?1:0 is an expression whose value is 1 if G is greater than D, and 0 otherwise."

---

> I agree, but this statement is still confusing. Is there a reason not to change it?

I could say "by initiating a STUN transaction", but I'd prefer to have common terminology.

---

> Please add a reverse reference.

All 7.2.5.3.X. sections happens after the check has been considered a success, so exactly where do you want a reference?

---

> This would benefit from consolidation.

We did a choice to keep the client and server procedures separated, so I'd like to keep it. 

Also, there ARE differences in the procedures, so we still need to cover the client- and the server cases separately.
 
---

> My initial reaction is you don't need to do anything extra, but I could easily be wrong here.

I had the same reaction, but I've asked Ari to think about this too.

---

> My question is what sequence of events can lead to this situation, as it is surprising to the readers.

Are you asking what events can lead to a triggered request?

---

>>> Consequently, when a controlling agent is communicating with a peer that supports options it doesn't know about, 
>>> the agent MUST run a regular nomination algorithm.  When regular nomination is used, ICE will converge perfectly 
>>> even when both agents use different pair prioritization algorithms.
>>
> "as required by Section 14 of RFC 5245 for peers which receive unknown ICE options"

Looks good.

---

> some of the need for tight

Looks good.

--- 

> Right, but then there will be three transactions per call in the common case.

Assuming you are using offer/answer, yes. 

Maybe something like:

"In a typical VoIP deployment, where RTP/RTCP multiplexing is used, there will be 2-3 transactions 
per call, depending on whether fallback to non-multiplexing is supported."

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2018 11:29:39 -0800

On Mon, Feb 19, 2018 at 11:19 AM, Christer Holmberg <
[email-masked]> wrote:

> > People asked to keep it in the Terminology section, to make it clear
> that "nomination" is 5245bis refers to what was called "regular nomination"
> in RFC 5245.
> >

Perfect.

> >> "NOTE: This specification assumes that all candidates are gathered
> before they are sent to the peer. The trickle ICE extensions define
> procedures
> > The issue here isn't that all candidates are gathered before they are
> sent to the peer but rather  that the diagram implies that no gathering
> happens before the peer's
> > candidates are received. That's not a requirement of 5245, and, as I
> said, contradicts the beginning of S 5.1.1.
>
> I could add the following sentence: "Note that an agent can begin
> gathering candidates at any point, even if it has not received any
> candidates (or even been contacted) by its peer."
>

My point is that the diagram just doesn't help.

> But, in the case of Lite, we still need to say what values are used for
> the different formula parts - even if we don't show the formula.
>

I agree.

> > It has the same semantics but it's easier to read. I mean, either you
> think the C syntax is self-explanatory or you
> Personally I think the formula is clear,

I do too, but I note that a number of modern C-like languages don't have
this (e.g., neither Go nor Rust does)

> "where G>D?1:0 is an expression whose value is 1 if G is greater than D,

I think that would probably be fine.

> I could say "by initiating a STUN transaction", but I'd prefer to have

"starting a check"

> >> "If a check is considered a success, the ICE agent performs (in order)
> the actions described in the following sections."
> >
> All 7.2.5.3.X. sections happens after the check has been considered a
> success, so exactly where do you want a reference?
>

At the beginning of the section that describes how to form a success.

> Also, there ARE differences in the procedures, so we still need to cover
> the client- and the server cases separately.
>

I agree it's a WG decision.

> >> I am not sure I understand. The source transport sentence you refer to
> is related to detection of peer reflexive candidates.
> >

No. What sequence of events can lead to a valid pair being on some other
check list.

> per call, depending on whether fallback to non-multiplexing is supported."

SGTM

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Feb 2018 21:37:56 +0000

Hi,

Review in context at:

---

>>> "NOTE: This specification assumes that all candidates are gathered before they are sent to the peer. 
>>> The trickle ICE extensions define procedures where gathered candidates can be sent to the peer as 
>>> soon as they have been gathered, while additional candidates are still gathered."
>>>
>>> The issue here isn't that all candidates are gathered before they are sent to the peer but rather  that 
>>> the diagram implies that no gathering happens before the peer's candidates are received. That's not a 
>>> requirement of 5245, and, as I said, contradicts the beginning of S 5.1.1.
>>
>> I could add the following sentence: "Note that an agent can begin gathering candidates at any point, even 
>> if it has not received any candidates (or even been contacted) by its peer."
>

Ok. So, I'll remove the diagram, and only keep the following text:

5.  ICE Candidate Gathering and Exchange

   As part of ICE processing, both the initiating and responding agents
   gather candidates, prioritize and eliminate redundant candidates,  
   and exchange candidate information with the peer as defined by the 
   Usage Protocol (ICE Usage).  Specifics of the candidate encoding 
   mechanism and the semantics of candidate information exchange is out 
   of scope of this specification.

---
 
>> I could say "by initiating a STUN transaction", but I'd prefer to have common terminology.

Ok.

---

> At the beginning of the section that describes how to form a success.

Section 7.2.5.3 defines how a success is formed, and then states that the procedures in the following sub sections are performed. Do you want to add explicit references to those sub sections?

Maybe I'm too tired, but I'm going to have to ask you to provide text, because I still don't understand exactly what you want.

---

> No. What sequence of events can lead to a valid pair being on some other check list.

Aah, gotcha. Most likely it can't, and unless I figure out how I will remove the associated text.

---

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 20 Feb 2018 14:51:30 -0800

The tie-breaker collision problem has come up a few times before, actually.
As I've said, I believe it could be fixed very easily by saying "pick a new
tie-breaker if this happens."

As for the "MUST not change tie-breaker" rule in section 16.1, requiring an
ICE restart is overkill. We can just change it to "MUST not change
tie-breaker* unless there's a collision*."

On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Feb 2018 15:06:55 -0800

I wouldn't object if someone produced a principled fix. I just don't want
to create a lot of work for people

On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter <[email-masked]>
wrote:

> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
>>> >>>> IF we really want to solve this, one simple solution be to say
>>> that, if this happens, and endpoint simply calculates a

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Feb 2018 20:17:32 +0000

Hi,

Based on Ekr's non-security IESG comments, I have updated the pull request:

https://github.com/ice-wg/rfc5245bis/pull/59

Still to do:

- Addition of IPv6 addresses to example
- Fix role conflict issue

Regards,

Christer