Subject: [MMUSIC] ICE-10 Issue #4: When is ICE done?

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Sep 2006 17:04:12 -0400

ICE-10 has the notion of ICE being "done". This occurs after there is a 
candidate pair in the valid list for each component of each media 
stream. When ICE finishes, an agent ceases performing any more checks 
and an updated offer is generated.

In -09 and earlier versions, the definition of 'done' was more or less 
the same, except that we also had this timer Tws to deal with packet 
losses. THis allowed time for higher priority checks to complete, if 
they were slow to do so as a consequence of packet loss.

I removed this in -10 in order to simplify ICE. I reasonsed that this 
timer would always introduce delays, and it added complexity, but it 
only helped in a small number of cases. In such cases, ICE still 
produced a valid result, it might just be suboptimal. Today on the call, 
Tim Moore indicated that they are in fact seeing this case on their 
network, but only on dialup links.

Interestingly, there are other cases besides packet loss in which giving 
ICE 'more time' might turn up higher priority candidates. As a 
consequence of the trimming of the check list (originally in -09), one 
agent might have far fewer checks in its check list than another. One of 
its low priority checks might succeed, producing a triggered check in 
the reverse direction which also succeeds. This triggered check may be 
low on the priority list; lower than higher priority ones which might 
succeed. Here again, giving ICE more time might pop out these more 
optimal pairs, at the expense of latency.

So, ultimately its a tradeoff on optimality vs. latency. For the voip 
use cases, I think the latency trumps especially if these are mostly 
corner cases (which they are). However, there might be other uses of ICE 
(for file transfer for example), where optimality is more important and 
its worth the wait.

One suggestion was to have the offerer pick whether it wants to wait. 
So, when the offerer concludes ICE, it sends an updated offer. The 
answerer keeps doing ICE checks until it gets the updated offer. The 
problem with this kind of approach is that it doesn't work with early 
media, a use case that came up alot on the call today. I think its very 
important that ICE end up with some key properties:

1. answerer is able to decide that ICE is done, so it can start sending 
media, as soon as possible

2. the candidate pairs selected by the answerer match those selected by 
the offerer

3. we avoid changing the pairs used to send media. I'd like ICE to 
'finish' and then we can start sending media. I think its generally bad 
to send media on one pair for a little bit, change to another, and then 
change to another. This mucks up jitter buffers, is probably noticeable 
to the user, and causes brief bursts of traffic to certain destinations 
(like a turn server) which aren't otherwise used.

Unfortunately I don't yet have a concrete suggestion here on what to do. 
  Still noodling a few ideas and will post some of them once I bake them 
a bit longer. In the mean time if folks have ideas please post them.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 5 Sep 2006 17:27:48 -0400

Howdy,
I think a dialup line shouldn't really be too concerned with whether an
optimal path is found or not - the constrained hop is the local one (i.e.,
the dialup itself) - as long as it finds a working path, good.  Unless
you're saying a multi-homed UA with both a dialup and LAN interface will end
up using the dial-up when it could have used the LAN interface, which was
not my interpretation of Tim's comment.

I think setup/completion latency trumps optimality, period.  ICE isn't doing
path quality checking - just raw connectivity. (right?)  Optimality is in
the eye of the beholder (or ear of the caller, as the case may be).  They
already check connectivity in "priority" order, so why make it more
complicated and try again, unless no successful pair is found at all?  My 2
cents.

-hadriel
p.s. not sure why you care about using a turn server for a "short burst" -
it's already allocated its resources to relay the media, right?  If it can't
handle them actually being used then it shouldn't have allocated them.  But
the switching jitter is something probably worth avoiding.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 5:04 PM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-10 Issue #4: When is ICE done?
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 7 Sep 2006 08:05:34 -0400

For a quick phone call, speed and completion latency is often important.

But for other applications, optimality is often more important.
Imagine a two-hour video conference. Would you be willing to have an
extra half second in setup time in order to have a more optimal path
which might give better jitter and latency? Certainly I would.
And I think there will be other applications of ICE where connections
will be up for days or weeks and an extra half second or so of setup
time is immaterial.

Of course, all this assumes that we have to make this tradeoff in the  
first place.

- Philip

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 7 Sep 2006 12:52:01 -0400

Some short notes on this thread:

1.  Defining that "ICE is done" means that it becomes more stateful and
deliberate, and hence allow for simple, which is good for simple low-cost
devices where such optimality is not a factor.  In real world
implementations when one side decides it is done despite the possibility of
a better alternative it will likey do the same on a re-offer, so I suggest
that once one side decides it is done, things are done, and ICE must be
restarted from scratch with new candidates.  It keeps things clean and
simple and more stateful.

2. A nailed up SIP session could renegotiate ICE underneath a bazillion
times given the above.

3. The above allows a SIP device that gains a new capability on-the fly
(bluetooth, USB and Plug and Play are but two examples) to suggest a new
media pair while maintaining a session.

It falls into how devices and agents really work.  The SIP session should
survive all sorts of changes in the underlying media capabilities.  It also
allows for simpler code that is easier to test, and will allow for plug and
play media components in SIP endpoints.

"ICE is Done" is important because it allows that to be easy, but only if
ICE can be restarted at some later time without interrupting existing
media.   Thoughts?

 M

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 8 Sep 2006 21:23:52 -0400

Hi Phillip, 
You're making the assumption that further ICE checking results in a lower
latency/jitter path.  ICE doesn't do that, AFAIK.  It only finds the path
which has the highest priority values, where the UA's decide what priority
means without latency/jitter path knowledge.

If they decide that a TURN server is lower priority, then they'll find any
other alternate path that works.  But there is absolutely no guarantee that
a non-TURN path is more optimal from a latency, jitter, nor bandwidth/loss
perspective.  The TURN path could be better, or worse, or the same, for any
or all of those characteristics.  And of course those characteristics may be
fluctuating on any "path" at any time.  It may even be fewer router hops to
go through a TURN server. (not that router hops are tied to those
characteristics either)

-hadriel

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 8:06 AM
> To: Hadriel Kaplan
> Cc: IETF MMUSIC WG; Jonathan Rosenberg
> Subject: Re: [MMUSIC] ICE-10 Issue #4: When is ICE done?
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Sep 2006 08:25:46 -0400

Hi Hadriel:

I assume that the endpoints choose the priority values based on the best
information they have available. It is true that ICE has no  
provisions to
test various candidate paths for latency, jitter, etc (perhaps a future
enhancement), but still I feel that, if time permits, ICE should  
select the best path given
the information available.

Otherwise, I think ICE becomes non-deterministic in its choice, which
frustrates attempts by endpoints to assign good priority values
(and by humans to understand which paths will be selected).

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 11:43:49 -0400

inline.

Michael Slavitch wrote:

> deliberate, and hence allow for simple, which is good for simple 
> low-cost devices where such optimality is not a factor.  In real world 
> implementations when one side decides it is done despite the possibility 
> of a better alternative it will likey do the same on a re-offer, so I 
> suggest that once one side decides it is done, things are done, and ICE 
> must be restarted from scratch with new candidates.  It keeps things 
> clean and simple and more stateful.

THe core issue here, is whether the answerer also decides that ICE is 
done on its own, or waits for the updated offer.

If it waits for the updated offer, we run into all of these nasty issues 
with early media and call setup delays that have motivated the feature 
where the answerer can send media before receiving an offer.

If it doesn't wait for the updated offer, what happens if the answerer 
decides its done, but the offerer wants to keep going? If that happens, 
the answerer will end up sending media on one set of candidates, and 
then when the updated offer comes, it will change the candidates it 
uses. THis is bad IMHO. Changing media destinations after a few hundred 
milliseconds will probably result in worse overall call quality (think 
jitter buffer retuning) than if you just waited.

So, I really wanted to make sure that the offerer and answerer both 
agreed on the same candidates that would get used.

ANother option I've been noodling is to define a flag in the STUN checks 
called the 'done' flag. The offerer would get to decide when ICE is 
done. When it decides it, it includes this flag in a check. When the 
answerer sees it, if the reverse check works (or had already been done 
and worked), the answerer considers ICE done too.

I don't think it would require an extra check just to send the flag; you 
could include the flag in what would naturally be the last check anyway, 
assuming it succeeds.

This would give the offerer total control over when things are done, 
allow it flexibility in whether it continues with checks or stops as 
soon as something works, etc. It would have no impact on call setup 
delays or early media. It comes at the cost of more complexity.

> It falls into how devices and agents really work.  The SIP session 
> should survive all sorts of changes in the underlying media 
> capabilities.  It also allows for simpler code that is easier to test, 
> and will allow for plug and play media components in SIP endpoints.
> 
> "ICE is Done" is important because it allows that to be easy, but only 
> if ICE can be restarted at some later time without interrupting existing 
> media.   Thoughts?

RIght. I've been thinking about that too. I think the answer is easy 
actually.

ICE gets restarted when you see a re-invite without the 
a=remote-candidates attribute. That is, an offer with this attribute 
signals that ICE is to be restarted, and with it, means ICE is done. 
Note that, when restarting, I think you would retain check states for 
any check you had done previously, but they would time out after about 30s.

-Jonathan R.

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 12 Sep 2006 13:01:06 -0400

Inline again.

I think this is close.

1.  There will be certain circumstances and certain services where the
answerer will want to decide. My answerer may not want to
     accept a TURN relay as a matter of local policy, no matter what the
offerer thinks.  This will likely be the case with enterprise CPE.
     Some acceptance of that will be required up front.  Perhaps again this
is a place for an options tag that describes the ICE support
     and how an endpoint accepts being done.

2.  I like your idea on how ICE restarts.
    The re-invites could also contain a new "options tag" describing new
capabilities and a new status on who accepts "done".
    In this case options is a form of versioning as additional options will
be added over time as ICE evolves.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 13:45:08 -0400

Michael Slavitch wrote:

> offerer thinks.  

I disagree. If the answerer will never accept a relay, it shouldnt 
include a relayed candidate. If the offerer uses a relay, why would the 
answerer REFUSE to us it? Its no the answerers relay services that are 
being used. Indeed, there is nothing that can stop usage of the relay if 
the offerer places it in the m/c-line as happens today.

This will likely be the case with enterprise CPE.
>      Some acceptance of that will be required up front.  Perhaps again 
> this is a place for an options tag that describes the ICE support

No. Options tags are not meant for this kind of signaling.

> capabilities and a new status on who accepts "done".

I don't know what you mean by new capabilities or 'a new status on who 
accepts done', nor why we'd want to signal it.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 14:07:10 -0400

Philip Matthews wrote:

> information they have available. It is true that ICE has no  provisions to
> enhancement), but still I feel that, if time permits, ICE should  select 
> the best path given

I think you are pointing at something which is a very key issue. It came 
up on the call yesterday.

The truth is, we are really guessing at this point what constitutes the 
right criteria for the 'best' set of candidates. Philip points to a 
different criteria entirely - path based measurements, perhaps done by 
the stun checks themselves. I've also heard it suggested to use TTL 
measurements.

It would be nice to be able to allow those to happen later, but this 
introduces a big interoperability problem. If these improvements require 
that BOTH the offerer and answerer agree on the definition of 'best', it 
becomes exponentially harder to introduce such an enhancement. It would 
be really nice if ICE made it easier to add these things in the future.

What ultimately makes it hard to introduce these things later is that 
ICE is requiring the offerer and answerer to agree on an algorithm for 
(1) determining when to stop, and (2) determining what is the best 
choice. Furthermore, requiring them to agree for proper operation opens 
the door to problems when, for some oddball reason things go wrong and 
they don't get the same results from their checks.

The way to fix this is to give control to one endpoint, and let it drive 
the algorithm. Set it up so that distributed agreement is only needed 
for better performance, not for ultimate correctness and consistency of 
pair selection.

That is achieved through a combination of what I suggest below (a 'done' 
flag in the STUN checks) along with my proposed algorithm in Issue #13:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04595.html, 
which proposes that after the reinvite comes the answerer always sends 
media to whats in the m/c-line.

To illustrate why my proposals on these two issues bring this 
extensibility feature (and are simpler I think too), let me give an 
example. Lets say an implementation decides that it would like to choose 
the pairs which have the fewest router hops, and optimality of this 
parameter is important, so it wants to let the ICE checks run for 
another 2 seconds after they would otherwise be done. This agent acts as 
the offerer. It does its checks, which discover a set of pairs for each 
media streams. However, it keeps the checks running. The answerer will 
also keep them running till it sees the flag, which it hasn't. When 2 
seconds more elapse, the very next check the offerer sends includes this 
flag. This tells the answerer to stop.

Now, the offerer had also gone and done TTL measurements, perhaps using 
an ICMP ping (I dont think it can be done through the STUN messages 
themselves unless we have the STUN resposnes include the TTL from the 
request). So, it has selected a set of pairs which happen to NOT be the 
same as the highest priority pairs. The answerer will have selected the 
highest priority pairs, and begins to send media to them. However, when 
the updated offer shows up, the m/c-lines (and remote-candidates 
attribtue) indicate different pairs. As far as the answerer can tell, 
these are also fine, since they validated, they are just lower priority. 
Thats OK - it uses what its told and then switches media destinations to 
whats in the m/c-line.

Thus, we have allowed the offerer to drive selection of the pairs, and 
the penalty was that we had a brief glitch in the media when it switched 
over to the pairs preferred by the offerer.

Now, the drawback here is that this won't work when this new agent is 
the answerer. However, I think its much harder to design a system that 
tries to signal and negotiate the algorithm that gets used, than it is 
to simply let it be a local implemetnation choice. Those also tend to be 
much more brittle and less flexible. Thus, I think this is a good 
tradeoff to make.

Cullen had suggested an alternative to the 'done' flag on the call 
yesterday, which was to have each side independently decide when its 
done. If you do that, the overall definition of done is the smaller of 
the two sets of checks that were done by each side. Such an algorithm 
can be made to work (it requires some additional mechanisms to ensure 
consistency on the set of checks that have been completed). However, it 
has the problem that its putting neither side in control. I think we get 
better guarantees of consistency and better ability to add new 
algorithms in the future if we allow one side to drive. So, I'd still 
prefer a 'done' flag.

Thanks,
Jonathan R.

---

From: <[email-masked]>
Date: Thu, 14 Sep 2006 13:09:02 +0300

Hi,

I found the following conflict within section 4.2 while 
reading through ICE-10:

> The type preference for peer reflexive candidates MUST be
> lower than that of server reflexive candidates.

and a bit later:

> Indeed, it is RECOMMENDED that in this case, host candidates have a
> type preference of nine, server reflexive candidates have a type
> preference of 5, peer reflexive have a type prefence of 6

which recommends the peer reflexive candidate to have a higher
type preference than server reflexive. Which one is correct ?

P.S. When fixing this, I suggest to use numbers (9, 6, 5, 0) for
describing the recommended preferences of each candidate type 
rather than using mixed representation like "nine, 6, 5, zero". 
Further on it would be logical to have all those candicates given 
in a descending order of preference.

Regards,

Erkki

---

From: <[email-masked]>
Date: Thu, 14 Sep 2006 14:28:55 +0300

Hi, 

On 13 September 2006, Jonathan Rosenberg wrote:
>It would be nice to be able to allow those to happen later, 
>but this introduces a big interoperability problem. If these 
>improvements require that BOTH the offerer and answerer agree 
>on the definition of 'best', it becomes exponentially harder 
>to introduce such an enhancement. It would be really nice if 
>ICE made it easier to add these things in the future.

yes, I think this is a very important point. Complexity of ICE 
will get out of hand if the spec tries to cover all interesting ways
a client could use to evaluate candidate pairs.

In general, I'm constantly benchmarking ICE (especially with regards to 
implementation complexity) against a "simplified ICE" algorithm:

- client can freely send media on ANY validated candidate pair
- one or more candidate pairs are kept alive with STUN keep-alives
- client can freely switch between candidate pairs (challenge to RTP 
  implementations, but allows to freely adapt to changes in 
  network environment)
- no second round of offer/answer
- candidate preferences are only guidelines (offerer and answered need 
  not agree on which pair is the best)

Now the above of course doesn't meet the requirements we have for ICE,
so
it's purely academic on this forum, but it's worth noting that the 
"NAT traversal power" of the solution is the same, but with
_significantly_ 
reduced complexity. We have some good reasons (especially A.11) why ICE
needs to be more complex, but I worry about any extensions to defined 
functionality which are not related to solving the core NAT traversal
issues.

> The way to fix this is to give control to one endpoint, and let it
drive the 
> algorithm. Set it up so that distributed agreement is only needed for
better 
> performance, not for ultimate correctness and consistency of pair
selection.

I think this is a great idea, and helps a lot in keeping the complexity
gap 
towards the "simple ICE" at a sane level! So ++votes.

-- 
[email-masked] (Kai Vehmanen)
Networking Technologies Laboratory, Nokia Research Center

---

From: <[email-masked]>
Date: Thu, 14 Sep 2006 14:28:55 +0300

Hi, 

drive the 
better 
selection.