Subject: [rtcweb] What I think we need to do about ICE

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jun 2012 01:32:40 -0700

To recap what I was saying on the list:

1. Some method of determining when a candidate pair has failed.

2. Some method of failing over to another candidate pair after
failure in as clean a fashion as possible, preferably exploiting
the fact that we already know about other valid candidate pairs,
if possible. Example: I had a direct and relayed pair that worked
and I chose direct. Is there a way to fall back to relayed without
doing a total re-ice.

3. When I discover a new candidate pair, some way of investigating
it and maybe changing to it w/o interfering with my current active
candidate pair.

I think we need to do (1) and probably (2) now and (3) is a nice to have.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jun 2012 01:53:29 -0700

Issue 1 is addressed via continuing consent, no? 

WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, depending on what you know. If an interface is down, no need to try those host candidates. Similarly, no need to retry pairs that just failed. The question with relay fail back is whether the allocation is still valid.

3. It seems sensible to be able to cache recent tests and not rerun them. If that were done then full offer/answers might only generate delta tests.

On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" <[email-masked]> wrote:

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2012 07:36:36 -0400

> Issue 1 is addressed via continuing consent, no?

Is this frequent enough? We probably need to be able to detect failures in
~5 seconds or so.

>
> WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken,
> depending on what you know. If an interface is down, no need to try those
> host candidates. Similarly, no need to retry pairs that just failed. The
> question with relay fail back is whether the allocation is still valid.
>

How does this work at the wire level? Is this a new USE-CANDIDATE ping on
the new pair from the controlling side?

>
> 3. It seems sensible to be able to cache recent tests and not rerun them.
> If that were done then full offer/answers might only generate delta tests.
>

This assumes that both sides are keeping all unused candidates alive during
the session.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jun 2012 06:57:16 -0700

Justin said:

On Tue, Jun 12, 2012 at 4:53 AM, Bernard Aboba <[email-masked]> wrote:

Is this frequent enough? We probably need to be able to detect failures in ~5 seconds or so. 

[BA] Depends on the kind of failure.  Removal/addition of an interface can be detected very quickly (e.g. RFC 4436 can run in 5 ms).  Detection of a failure in the middle of the network will take longer; route flaps can cause transient loss, but often resolve themselves quickly (under 30 seconds) so switch in less than 15 seconds will risk false positives. 

How does this work at the wire level? Is this a new USE-CANDIDATE ping on the new pair from the controlling side?

[BA] In the event of a failure, it would make sense to be aggressive to restore media quickly. If you have a working pair, but are just looking for a better one, you might not want to set flags until you've confirmed that the pair is actually better. 

This assumes that both sides are keeping all unused candidates alive during the session. 

[BA] I doubt that implementations would keep relay candidates alive if they weren't chosen.  But one could cache the list of candidates from both sides minus the relays, update the host  and server reflexive candidates and prioritize pairs. 
The question is whether you could skip any tests. If a pair has been recently demonstrated to be working (e.g. it is working currently, but you've gotten new pairs) you can skip the test.  Similarly, if it's been marked as down. 

rtcweb mailing list

[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2012 10:55:32 -0400

On Tue, Jun 12, 2012 at 9:57 AM, Bernard Aboba <[email-masked]>wrote:

> [BA] Depends on the kind of failure.  Removal/addition of an interface can
> be detected very quickly (e.g. RFC 4436 can run in 5 ms).  Detection of a
> failure in the middle of the network will take longer; route flaps can
> cause transient loss, but often resolve themselves quickly (under 30
> seconds) so switch in less than 15 seconds will risk false positives.
>

I understand what you are saying, but most people will hang up the call
after ~10 seconds of silence. Given that the downside of an ICE restart is
minimal, we probably want to be more aggressive here.

> [BA] In the event of a failure, it would make sense to be aggressive to
> restore media quickly. If you have a working pair, but are just looking for
> a better one, you might not want to set flags until you've confirmed that
> the pair is actually better.
>

> [BA] I doubt that implementations would keep relay candidates alive if
> they weren't chosen.  But one could cache the list of candidates from both
> sides minus the relays, update the host  and server reflexive candidates
> and prioritize pairs.
> The question is whether you could skip any tests. If a pair has been
> recently demonstrated to be working (e.g. it is working currently, but
> you've gotten new pairs) you can skip the test.  Similarly, if it's been
> marked as down.
>
>
>
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jun 2012 08:26:42 -0700

Justin said:

I understand what you are saying, but most people will hang up the call after ~10 seconds of silence. Given that the downside of an ICE restart is minimal, we probably want to be more aggressive here.

[BA] If you're asking whether you can start testing alternative pairs quickly, sure.  With the built-in rate limiting there won't be any damage done by that, and it will take some time to confirm a working alternative pair anyway.

My comment was just about the likelihood that the issue with the existing pair is just a temporary glitch.  That would suggest that flags not be set on the alternative exploration until you decide the existing pair is down.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Jun 2012 16:03:17 -0400

>From the point of view of RFC 5245, during an ICE Restart "media can continue to be sent to the previously validated pair." (9.1.1.1 and 11.1.1).  So 3) should come for free, if implementations are written properly.

Here's the model of ICE as I understand it.  An endpoint is always free to gather as many or as few candidates as it wants, at any time before it starts ICE or an ICE Restart.  This includes the currently-selected candidate, and any other previously-validated candidates that happen to still be live.

Thus, an ICE Restart doesn't have to be a "total re-ice", necessarily.  If you send (e.g.) your current selected candidate, and one other newly-discovered candidate, as your candidate set for an ICE restart, the restart's connectivity checking should be lighter-weight than one where you give the list of every possible candidate (which you presumably would do for the session's initial ICE exchange).  But it's still a full and compliant ICE connectivity check.

That said, ICE says that once you're in "ICE Completed" state, the only way to change a component's selected candidate pair is by doing an ICE restart.

Trickle candidates are equivalent to candidates sent in an updated offer or answer in the "ICE Running" state (9.1.2.1 / 9.2.2.1).  Thus, they're ignored once an endpoint enters "ICE Completed" state.

ICE leaves a lot of endpoint behavior up to endpoint implementors, and in the webrtc context I think many of these behaviors will need to be controllable by the javascript applications.  I think the following APIs may be needed.  (Some of them may exist already in the w3 draft, I haven't followed all its details).

* Some way to know when something interesting has happened to network connectivity, above and beyond EKR's 1).  This includes a new network interface coming up, or even potentially (if possible) a something more interesting like a captive portal becoming unblocked.

* Some way to configure the set of interfaces on which address gathering should be done, and the priority among them.  (This implies there also needs to be way to interrogate the set of interfaces.)

* Some way to start address gathering, both for the initial PeerConnection setup and for an ICE restart.  Note that this needs to be done both by the offerer and the answerer, and in many cases an answerer won't know it needs to do so until it receives an offer with an ICE restart in it.

* If you're a controlling endpoint, whether to use regular or aggressive nomination.  For regular nomination, once one or more candidate pairs have been validated, a way for the controlling endpoint to select the one to use.  (Note that the controlling endpoint may not necessarily be the offerer, if you receive an ice-lite offer.)

--
Jonathan Lennox
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 14 Jun 2012 21:41:44 +0000

> Trickle candidates are equivalent to candidates sent in an updated offer or answer in the "ICE Running" state (9.1.2.1 / 9.2.2.1).  Thus, they're ignored once an endpoint enters "ICE Completed" sta…

These sound like great reasons to not bake a full ICE state machine into the browser but instead provide primatives to Javascript which allow for the sending and receiving of STUN connectivity tests. That way an endpoint talking to another one that didn't care about this "ICE Completed" state could add innovation around rapid recovery from network changes.

Matthew Kaufman

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 19 Jun 2012 21:20:44 +0000

I think the word "restart" is causing some confusion. Better words might be "reboot" meaning you want throw away everything you have, get new local ports, and start over. And "continue" meaning you have new interfaces, or relays, or want more components or something but want to do some more gathering and/or checking.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 19 Jun 2012 21:20:44 +0000

> 3. It seems sensible to be able to cache recent tests and not rerun them. If that were done then full offer/answers might only generate delta tests.

Depending on what sort of test you are thinking of, I don't think this will work. 

draft-jennings-behave-test-results-04 showed that for many nats, the primary and secondary behavior is different. This makes caching any recent tests fraught with disaster. (I'll note some major voip products had really nasty hard to debug voice connectivity failures due to this)

---

From: Randell Jesup <[email-masked]>
Date: Wed, 20 Jun 2012 01:11:23 -0400

> draft-jennings-behave-test-results-04 showed that for many nats, the primary and secondary behavior is different. This makes caching any recent tests fraught with disaster. (I'll note some major vo…

Agreed.  Especially since some other app or port use may push you into 
"secondary" without warning.

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jun 2012 00:04:18 -0700

> > Depending on what sort of test you are thinking of, I don't think this will work.

[BA] I was referring to RFC 5245 Section 9.1.1.1:

   An agent sets the rest of the fields in the SDP for this media stream
   as it would in an initial offer of this media stream (see
   Section 4.3).  Consequently, the set of candidates MAY include some,
   none, or all of the previous candidates for that stream and MAY
   include a totally new set of candidates gathered as described in
   Section 4.1.1. 
This gives the implementation considerable flexibility in determining what candidates to include in an ICE re-start.