Subject: [MMUSIC] Notes from Continuous Nomination discussion

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Nov 2014 01:44:20 -0800

Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today to
discuss the goals for the work to improve ICE nomination.

In short, there was good consensus that the goals outlined in
http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html
(updated since the meeting)
are the correct goals to be shooting for, even if the exact mechanisms
aren't completely nailed down. We think the goals enumerated by Emil in his
email earlier this week are all covered by the goals in this document.

It also seemed reasonable to adopt the work to merge Regular and Aggressive
Nomination in ICE-bis, and have the Continuous Nomination change be its own
document. While there was some interest in figuring out how ICE could
support multiple selected pairs simultaneously, this was agreed to be out
of scope for now.

We can discuss more in the WG meeting; Ari, can you set aside some agenda
time?

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Nov 2014 02:47:55 -0800

One other note - although Dan wasn't present, the consensus was that the
continuous nomination solution provides an effective solution to the ICE
issues raised in draft-singh-avtcore-mprtp, draft-wing-ice-mobility, and
draft-williams-peer-redirect.

On Tue, Nov 11, 2014 at 1:44 AM, Justin Uberti <[email-masked]> wrote:

> Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today
> to discuss the goals for the work to improve ICE nomination.
>
> It also seemed reasonable to adopt the work to merge Regular and
> Aggressive Nomination in ICE-bis, and have the Continuous Nomination change
> be its own document. While there was some interest in figuring out how ICE
> could support multiple selected pairs simultaneously, this was agreed to be
> out of scope for now.
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Nov 2014 13:31:58 +0100

On 11.11.14, 10:44, Justin Uberti wrote:
> aren't completely nailed down. We think the goals enumerated by Emil in
> his email earlier this week are all covered by the goals in this document.

Hm? I might have missed something but how does it cover the need to 
detect an end of currently available candidates? How does one know when 
it is safe to release unused candidates?

Whether we call it an ICE restart or not, the mechanism we come up with 
would need to support these things.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Nov 2014 13:51:10 +0100

One more comment here:

> (updated since the meeting)

While I agree with the majority of the goals expressed in the above 
document there is one that sounds a bit naïve.

Section 3.4 says:

    While this could
    be done using an ICE restart, as described in [RFC5245], Section 9.1,
    the ICE restart may have unintended consequences, such as causing the
    remote side to regather all candidates.  Instead, it would be best if
    the new candidates could be trickled, as discussed in
    [I-D.ietf-mmusic-trickle-ice], but even after ICE processing has
    completed.

Unless you are planning on mandating that every ICE agent on the planet 
must never release a single port number and must continuously block NAT 
and TURN resources it is not using, then the remote side will have to 
re-gather candidates regardless of whether you call your scheme an ICE 
restart or not.

This is not so hard to resolve so I am not sure how to explain the 
insistence to not address it.

Emil

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 11 Nov 2014 19:35:04 +0000

On 11 Nov 2014, at 00:47, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

One other note - although Dan wasn’t present, the consensus was that the continuous nomination solution provides an effective solution to the ICE issues raised in draft-singh-avtcore-mprtp, draft-wing-ice-mobility, and draft-williams-peer-redirect.

Regarding MICE.

The main goal there is to try out any of the old remote candidates before you actually trickle your new local candidates. There is a chance that the old NAT binding on the remote side might work if the NAT is of the type “good”. Idea is to get media flowing without the use of the signalling channel.  The trickling of the new local candidates should happen in parallel.

We will update the draft to fit into the continuous nomination and trickle scheme once the dust settles.

.-.
Pål-Erik

On Tue, Nov 11, 2014 at 1:44 AM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met today to discuss the goals for the work to improve ICE nomination.

In short, there was good consensus that the goals outlined in
http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html (updated since the meeting)
are the correct goals to be shooting for, even if the exact mechanisms aren't completely nailed down. We think the goals enumerated by Emil in his email earlier this week are all covered by the goals in this document.

It also seemed reasonable to adopt the work to merge Regular and Aggressive Nomination in ICE-bis, and have the Continuous Nomination change be its own document. While there was some interest in figuring out how ICE could support multiple selected pairs simultaneously, this was agreed to be out of scope for now.

We can discuss more in the WG meeting; Ari, can you set aside some agenda time?

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Nov 2014 21:05:54 +0100

Hey Pal,

On 11.11.14, 20:35, Pal Martinsen (palmarti) wrote:
>> One other note - although Dan wasn’t present, the consensus was that
>> the continuous nomination solution provides an effective solution to
>> the ICE issues raised in draft-singh-avtcore-mprtp,
>> draft-wing-ice-mobility, and draft-williams-peer-redirect.
>
> Regarding MICE.
>
> The main goal there is to try out any of the old remote candidates
> before you actually trickle your new local candidates.

As discussed off-list I am in favour of this, provided we focus on the 
right use case. (more below)

> There is a chance
> that the old NAT binding on the remote side might work if the NAT is of
> the type “good”.

I think you are asking for more than a "good" NAT. Normally NATs with 
endpoint-dependent filtering are considered "good" as long as they don't 
do endpoint-dependent mapping.

You are asking for NATs that don't do filtering and let anyone come in 
on an existing binding. I haven't seen NATs behave this way in years ... 
unless they had been manually configured with port-forwarding. Even if 
the NAT does allow packets to come in, the FW features in many modern 
OSes would drop them.

So I think there is really little incentive to optimize for that use 
case (i.e., the one where both nodes are behind NATs).

That said, the same optimization also solves the case of a mobile node 
talking to a media service (e.g., a multi-party video conferencing 
application).

In that case it is also much more reasonable to expect that all original 
candidates would be kept alive. Very often those would be limited to the 
in-use UDP candidates and potentially a shared TCP host candidate using 
port 443. In other words, they would likely be in-use regardless and 
there won't be any resource wasting involved.

I think that use case is definitely worth optimizing. I also think the 
entire draft would be much easier to define if it focuses on this use case.

> Idea is to get media flowing without the use of the
> signalling channel.

This comes down to allowing peer-reflexive candidates to be discovered 
at any point of the communication. I believe that stated this way, the 
problem is relatively easy to solve.

Emil

>  The trickling of the new local candidates should
> happen in parallel.
>

>>     Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met
>>     today to discuss the goals for the work to improve ICE nomination.
>>
>>     are the correct goals to be shooting for, even if the exact
>>     mechanisms aren't completely nailed down. We think the goals
>>     enumerated by Emil in his email earlier this week are all covered
>>     by the goals in this document.
>>
>>     Aggressive Nomination in ICE-bis, and have the Continuous
>>     Nomination change be its own document. While there was some
>>     interest in figuring out how ICE could support multiple selected
>>     pairs simultaneously, this was agreed to be out of scope for now.
>>

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Nov 2014 12:06:26 -0800

On 11 November 2014 04:51, Emil Ivov <[email-masked]> wrote:
> Unless you are planning on mandating that every ICE agent on the planet must
> never release a single port number and must continuously block NAT and TURN
> resources it is not using, then the remote side will have to re-gather
> candidates regardless of whether you call your scheme an ICE restart or not.

It was my conclusion at least that ICE restart is going to be
necessary to avoid the pairing of stale and fresh candidates.  That
is, it is useful - maybe even necessary - in providing agents a way to
control which candidates are used on an ongoing basis.  Being able to
remove a candidate from consideration is hugely valuable.

I think that the problem Justin cites can be ameliorated by having
guidance about candidate reuse from previous phases (or generations).
Slapping a new ufrag/pwd on an existing candidate avoids the need for
gathering, but there are risks.  You need to be certain that the
candidates you are providing are "fresh", which means either that you
have active traffic or checks on them, or that you have recently
acquired them.

---

From: Ari Keränen <[email-masked]>
Date: Tue, 11 Nov 2014 10:07:11 -1000

> We can discuss more in the WG meeting; Ari, can you set aside some

Yes, let's take this as part of the ICE bis slot. I was planning to have 
this and the updated offer as the main topics.

Cheers,
Ari

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Nov 2014 12:26:22 -0800

On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov <[email-masked]> wrote:

> Hm? I might have missed something but how does it cover the need to detect
> an end of currently available candidates? How does one know when it is safe
> to release unused candidates?
>

These questions are addressed specifically in the draft - Section 5.2,
paragraphs 5 and 4, respectively.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Nov 2014 12:31:32 -0800

On Tue, Nov 11, 2014 at 4:51 AM, Emil Ivov <[email-masked]> wrote:

> must never release a single port number and must continuously block NAT and
> TURN resources it is not using, then the remote side will have to re-gather

Continuous Nomination allows pairs to be kept alive; see Section 5.2,
paragraph 4; this is a key part of the approach, since it allows quick
switching between pairs.

But even if only the selected pair is kept alive, it will often be possible
to use new candidates from the local side without a regather on the remote
side.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Nov 2014 21:55:22 +0100

On 11.11.14, 21:26, Justin Uberti wrote:
>
>
> On Tue, Nov 11, 2014 at 4:31 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>         http://juberti.github.io/__draughts/nombis/draft-uberti-__mmusic-nombis.html
>         <http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html>
>         mechanisms
>     detect an end of currently available candidates? How does one know
>     when it is safe to release unused candidates?
>
>
> paragraphs 5

Indeed. That wasn't in the google doc however so I didn't realise you 
had changed it. It would have been nice to mention this.

Anyways. Glad we are making progress.

> and 4, respectively.

OK, nice, almost there!

What this doesn't yet say is that the released candidates would need to 
be regathered once new remote candidates start trickling in again.

This is when it turns effectively in an ICE restart.

I agree with Martin that guidance on implementing restarts and handling 
existing pairs should address most concerns.

Emil

>     Whether we call it an ICE restart or not, the mechanism we come up
>     with would need to support these things.
>
>     Emil
>
>     --
>     https://jitsi.org
>
>

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Nov 2014 16:47:17 -0800

On Tue, Nov 11, 2014 at 12:55 PM, Emil Ivov <[email-masked]> wrote:

> Indeed. That wasn't in the google doc however so I didn't realise you had
> changed it. It would have been nice to mention this.
>
> What this doesn't yet say is that the released candidates would need to be
> regathered once new remote candidates start trickling in again.
>

> This is when it turns effectively in an ICE restart.

Yes, we need to figure out how this should work. Released candidates won't
always need to be regathered; the new candidates might just be 'hey, try
these also'. But there are certainly mobility scenarios where one side
wants to inform the other that 'hey, my existing candidates are about to go
away, so we want to do a restart'.

> existing pairs should address most concerns.

Yes. It probably would be useful to walk through a few flows and see if
some patterns emerge.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Nov 2014 12:36:23 -0800

> Yes. It probably would be useful to walk through a few flows and see if

Quick update - Emil and I synced up yesterday and I think we are overall in
agreement. As a next step I am going to add Emil's examples to my document
along with a few other examples we thought of and use that to figure out
whether we are overlooking anything.