Subject: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin

From: Peter Thatcher <[email-masked]>
Date: Tue, 12 Jul 2016 07:35:08 -0700

I submitted draft-thatcher-ice-remove-candidate and would like to speak
about in my allotted time on the agenda when I will also be speaking
about draft-thatcher-ice-network-cost
and draft-thatcher-ice-renomination.

It's a very simple draft. Basically it says you can "remove" candidates
just like trickle-ice allows you to add candidates. You could probably read
it in 3 minutes. Please do so:

https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt

Thanks,
Peter (Chair hat off)

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jul 2016 09:39:14 -0700

"Removal" and "Renomination" have both come up as implementation issues, so
these drafts seem useful to me.

In the "removal" draft, I had questions about these paragraphs:

   When a removal signal [is received], the Receiving Agent MUST NOT
pair the Removed
   Candi[d]ates with any future candidates gathered by the Receiving Agent.
   The Receiving Agent MAY keep the existing candidate pairs that use
   the Removed Candidates and behave as though the Removed Candidates
   had not been removed for those candidate pairs.

   Why would an Receiving Agent choose not to immediately remove
   existing candidate pairs?  Because the Removing Agent MAY choose to
   keep the Removed Candidate capable of receiving ICE checks and
   sending responses so that any ICE checks already sent by the
   Receiving Agent may continue to work briefly so that media can flow
   as quickly as possible, even if over a candidate pair that will soon
   be discarded.

[BA] When an interface is "going down", having the Receiving Agent not
immediately remove existing candidate pairs can avoid a media glitch.

However there are consequences to not removing the pair immediately
because when the interface goes down, consent checks will subsequently
fail and RFC 7675 Section 5.1 indicates that the pair cannot be used
with the same ICE credentials, even if the interface comes up again:

   After consent is lost, the same ICE credentials MUST NOT be used on
   the affected 5-tuple again.  That means that a new session, or an ICE
   restart, is needed to obtain consent to send on the affected
   candidate pair.

One way to deal with this would be for the removing party to revoke
consent before bringing the interface down.  However, that would only
work if consent revocation was not considered the same as "consent is
lost" in the above paragraph from RFC 7675.

On Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher <[email-masked]>
wrote:

> about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost
> just like trickle-ice allows you to add candidates. You could probably
> read it in 3 minutes. Please do so:
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Jul 2016 17:07:15 +0000

Hi,

The text says:

“The Receiving Agent MAY keep the existing candidate pairs that use
              the Removed Candidates and behave as though the Removed Candidates
              had not been removed for those candidate pairs.”

What is meant by “behave”? Sending keep-alives? Sending media? That will obviously not work.

I think it would be good to state wether the usage/support of the mechanism must be negotiated before it is used.

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: 12 July 2016 17:35
To: [email-masked]
Subject: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin

I submitted draft-thatcher-ice-remove-candidate and would like to speak about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.

It's a very simple draft. Basically it says you can "remove" candidates just like trickle-ice allows you to add candidates. You could probably read it in 3 minutes. Please do so:

Thanks,
Peter (Chair hat off)

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 12 Jul 2016 10:14:25 -0700

Thanks for the grammar/spelling fixes.  I'll update those with quickly with
a new draft version.

On Tue, Jul 12, 2016 at 9:39 AM, Bernard Aboba <[email-masked]>
wrote:

> "Removal" and "Renomination" have both come up as implementation issues,
> so these drafts seem useful to me.
>
>    When a removal signal [is received], the Receiving Agent MUST NOT pair the Removed
> [BA] When an interface is "going down", having the Receiving Agent not immediately remove existing candidate pairs can avoid a media glitch.
>
> However there are consequences to not removing the pair immediately because when the interface goes down, consent checks will subsequently fail and RFC 7675 Section 5.1 indicates that the pair cannot be used with the same ICE credentials, even if the interface comes up again:
>
> One way to deal with this would be for the removing party to revoke consent before bringing the interface down.  However, that would only work if consent revocation was not considered the same as "consent is lost" in the above paragraph from RFC 7675.
>
> ​If the interface comes back after consent is lost (after many seconds),
then I think either an ICE restart or gathering new candidates (if
gathering isn't already complete) would be the right thing to do.  Do you
see a problem with that?

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 12 Jul 2016 10:21:06 -0700

> What is meant by “behave”? Sending keep-alives? Sending media? That will

​Both keep-alives and media.  If the removed candidate is a TURN candidate
that the removing agent wishes to deallocate, it may work for a short
period of time before the removing agent actually deallocates it.  So the
Receiving Agent may choose to keep sending media until it finds a different
candidate pair to use instead.   Or it may not.

>
>
> I think it would be good to state wether the usage/support of the
> mechanism must be negotiated before it is used.
>
​
​
​Signaling the removal of candidate never does any harm, so I don't see a
need in negotiating that your going to signal removal (modulo a specific
signaling protocol needing to figure out how to send new messages if it
chooses to do so).  The real question is whether the removing agent needs
to know whether the receiving agent is going to do anything with the
signal.  And since everything will continue to work even if the receiving
​agent ignores the signal (simply with some perhaps wasted resources), then
it's not necessary for negotiation at all.

You are correct that this should be clear in the draft.  I will add it.

>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Ice [mailto:[email-masked]] *On Behalf Of *Peter Thatcher
> *Sent:* 12 July 2016 17:35
> *To:* [email-masked]
> *Subject:* [Ice] I submitted and plan to present
> draft-thatcher-ice-remove-candidate in Berlin
>
>
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 12 Jul 2016 20:38:31 +0300

Are there any cases where you think this would be useful other than abetter
connection with a server?

If all that is changing is the connection with the server then it sounds to
me like we should rather come up with a way to update the local side of the
binding and not bother the remote agent with it.

Emil

-- 
sent from my mobile

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jul 2016 11:13:43 -0700

Peter Thatcher said:

"​If the interface comes back after consent is lost (after many seconds),
then I think either an ICE restart or gathering new candidates (if
gathering isn't already complete) would be the right thing to do.  Do you
see a problem with that?"

[BA] What is in RFC 7675 seems ok.  But if a candidate is "removed" both
peers should have the same understanding of whether the same ICE
credentials can ever be used on the 5-tuple again.

Based on what is in RFC 7675, it appears that an immediate removal would
not automatically require new ICE credentials if the pair is subsequently
to be used.  However, if the receiving agent chose not to immediately
remove the pair and consent subsequently failed this would leave the
receiving agent believing that the pair was no longer usable without a
restart, while the sending side might believe it could be added back
without new ICE credentials. It is not clear to me whether the situation
would be different if the sending side revoked consent on the pair before
taking the interface down (e.g. whether consent revocation is equivalent to
consent loss in RFC 7675).

On Tue, Jul 12, 2016 at 10:14 AM, Peter Thatcher <[email-masked]>
wrote:

> Thanks for the grammar/spelling fixes.  I'll update those with quickly
> with a new draft version.
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jul 2016 14:20:20 -0700

Peter said:

"The real question is whether the removing agent needs to know whether the
receiving agent is going to do anything with the signal.  And since
everything will continue to work even if the receiving ​agent ignores the
signal (simply with some perhaps wasted resources), then it's not necessary
for negotiation at all."

[BA] The removing agent only needs to know if the receiving agent
understands removal if that will make a difference in subsequent behavior.
If a removed candidate will never be re-added, I don't think it matters,
because a receiving agent not understanding removal will eventually figure
out that the removed candidate is inactive, and that pairs involving the
removed candidate are unusable. But if it is desired to be able to re-add a
removed candidate without an ICE restart, then it might make a difference.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 13 Jul 2016 12:22:12 -0700

On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <[email-masked]> wrote:

> Are there any cases where you think this would be useful other than
> abetter connection with a server?
>
>
​Yes: continual gathering (aka continuous nomination) would benefit from
this.​

> If all that is changing is the connection with the server then it sounds
> to me like we should rather come up with a way to update the local side of
> the binding and not bother the remote agent with it.
>

​That would be TURN mobility, or some new equivalent (​
​
​the TURN mobility draft has expired).  That is an option that we'd like to
explore implementing, but it's much more work to standardize, implement,
and deploy (both on client and server).  Whereas this is a simply mechanism
that is quick to standardize, implement, and deply, and it's useful for
other things (as mentioned above).

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 13 Jul 2016 12:27:03 -0700

On Tue, Jul 12, 2016 at 2:20 PM, Bernard Aboba <[email-masked]>
wrote:

> Peter said:
>
> "The real question is whether the removing agent needs to know whether
> the receiving agent is going to do anything with the signal.  And since

​That's a good point about re-adding a candidate.  But isn't the question
of re-adding a candidate also relevant to normal trickle, independent of
removal?  For example, what happens if I re-trickle a candidate to you
after you lose consent for a candidate pair with that candidate?  Does that
allow you to re-establish consent?

​

>> ​Both keep-alives and media.  If the removed candidate is a TURN
>> candidate that the removing agent wishes to deallocate, it may work for a
>> short period of time before the removing agent actually deallocates it.  So
>> the Receiving Agent may choose to keep sending media until it finds a
>> different candidate pair to use instead.   Or it may not.
>>
>>
>>>
>>>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 13 Jul 2016 22:45:07 +0300

On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <[email-masked]> wrote:
> Yes: continual gathering (aka continuous nomination) would benefit from
> this.

Last time we discussed continuous nomination (in Prague last year) it
sounded to me that there were no arguments about what it was bringing
on top of simple ICE restarts. It is my understanding that optimizing
those (if at all necessary) was a more acceptable direction.

So I don't think continuous nomination is a good argument here even if
we keep waving it all over the place :) .

> That would be TURN mobility, or some new equivalent (
> the TURN mobility draft has expired).

Something like that yes.

> That is an option that we'd like to
> explore implementing, but it's much more work to standardize, implement, and
> deploy (both on client and server).  Whereas this is a simply mechanism that
> is quick to standardize, implement, and deply, and it's useful for other
> things (as mentioned above).

On a first glance the whole ICE idea is very simple and easy to
standardise, implement and deploy: gather and try everything. pick
what works.

I think 13 years after the initial idea was being floated on the IETF
we know better.

In other words:

First I don't think it's that simple at all. I am particularly
concerned about potential race conditions with the ICE state machine
and the trickling itself. Same for interactions with aggressive
nomination.

Second, while we may be able to solve the above, I am worried that the
increased complexity will not justify something that is a very limited
solution to a more general problem. So we are setting the stage for
redundancy and that's not something we need with ICE.

Also, have you done any measurements or estimates on exactly what we
are trying to optimize here? Some several hundred milliseconds of
streaming over TCP rather than UDP?

Emil

>>> about in my allotted time on the agenda when I will also be speaking about
>>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.
>>>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 21:18:24 +0000

Hi,

>> What is meant by “behave”? Sending keep-alives? Sending media? That will obviously not work.
​> Both keep-alives and media.  If the removed candidate is a TURN candidate that the removing agent wishes to deallocate, it may work for a short period 
> of time before the removing agent actually > deallocates it.  So the Receiving Agent may choose to keep sending media until it finds a different candidate pair to use instead.   
> Or it may not.  
 
The removed candidate MAY work for a short period, but there is no guarantee, is there? So, if the receiver understands the mechanism, shouldn't it switch to another candidate as soon as it receives the indication that the candidate has been removed (if the removed candidate is the one currently being used, that is).

>> I think it would be good to state whether the usage/support of the mechanism must be negotiated before it is used.
​>
​> Signaling the removal of candidate never does any harm, so I don't see a need in negotiating that your going to signal removal (modulo a specific signaling protocol needing to figure out how to send 
> new messages if it chooses to do so).  The real question is whether the removing agent needs to know whether the receiving agent is going to do anything with the signal.  And since everything will 
> continue to work even if the receiving ​agent ignores the signal (simply with some perhaps wasted resources), then it's not necessary for negotiation at all.

If the removed candidate cannot be used once it has been removed, and the remote endpoint keep sending media towards it (e.g. because the remote endpoint does not understand the removal indication), there will be media clipping until the remote endpoint realizes that the candidate no longer works.

Regards,

Christer

 

 
 
Thanks,
Peter (Chair hat off)

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 13 Jul 2016 15:06:46 -0700

> we keep waving it all over the place :) .
​Continual gathering is a separate topic that we can save for another day.

> and

> redundancy and that's not something we need with ICE.
​It sounds like you are making the argument that ICE has reached some kind
of "peak complexity" and can no longer be changed because it's already too
complex.  Is that what you're claiming?

> streaming over TCP rather than UDP?

​I don't know what this has to do with TCP vs. UDP.​

The real world problem here is that if you have two network interfaces
(WiFi and Cell) and ​ipv4 and ipv6 and 2 TURN servers and try to connect to
each over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates
(at least; this ignores TCP w/ TLS).  Then both sides do that, and you have
16 * 16 = 256 TURN-TURN candidate pairs.  That's a lot.  So how do you
avoid that problem?   TURN mobility is one option, and I'd like to see TURN
mobility happen.  But candidate removal is also an option, and it's a lot
more simple.

> about

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jul 2016 16:21:14 -0700

Emil said:

"So I don't think continuous nomination is a good argument here even if
we keep waving it all over the place :) ."

[BA] It has always seemed to me that continuous nomination is not a "thing"
per se, but an inextricable part of Trickle ICE in that it is an
implementation decision as to when the gathering process is considered
complete.  So an implementation can choose to provide a local
"end-of-candidates" indication once it has gathered on existing interfaces,
or it could delay some arbitrary (perhaps infinite) time to allow new
interfaces to come up or for interfaces to go down.

If there are considerations relating to this that an implementation needs
to consider (such as implications for unfreezing) they are currently not
being articulated in the Trickle ICE specification. So either the
specification is negligent in this regard, or "continuous nomination" is an
optional capability that implementations can choose to support (or not),
with no interoperability implications.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 14 Jul 2016 06:26:09 +0000

-.-
P?l-Erik

On 13 Jul 2016, at 21:23, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:
Are there any cases where you think this would be useful other than abetter connection with a server?

?Yes: continual gathering (aka continuous nomination) would benefit from this.?

If all that is changing is the connection with the server then it sounds to me like we should rather come up with a way to update the local side of the binding and not bother the remote agent with it.

?That would be TURN mobility, or some new equivalent (?
?
?the TURN mobility draft has expired).

https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

Actually the TRAM WG have asked IESG to publish it.

That is an option that we'd like to explore implementing, but it's much more work to standardize, implement, and deploy (both on client and server).  Whereas this is a simply mechanism that is quick to standardize, implement, and deply, and it's useful for other things (as mentioned above).

Agree on that as well.

Emil

On Tuesday, 12 July 2016, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
I submitted draft-thatcher-ice-remove-candidate and would like to speak about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.

Thanks,
Peter (Chair hat off)

--
sent from my mobile

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 14 Jul 2016 08:50:40 -0700

On Wed, Jul 13, 2016 at 11:26 PM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> -.-
> Pål-Erik
>
> On 13 Jul 2016, at 21:23, Peter Thatcher <[email-masked]> wrote:
>
>
>
> ​the TURN mobility draft has expired).
>
>

​Oh, well that's good news.  I had no idea it had progressed.  Thanks for
updating me.

>
>
> That is an option that we'd like to explore implementing, but it's much
> more work to standardize, implement, and deploy (both on client and
> server).  Whereas this is a simply mechanism that is quick to standardize,
> implement, and deply, and it's useful for other things (as mentioned above).
>
>
>
> Agree on that as well.
>
>
>
>
>>
>> Emil
>>
>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 14 Jul 2016 19:19:02 +0300

On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher <[email-masked]> wrote:
> Continual gathering is a separate topic that we can save for another day.
>
>>
> It sounds like you are making the argument that ICE has reached some kind of
> "peak complexity" and can no longer be changed because it's already too

And question the existence of this wonderful working group? No, of course not ;)

What I am claiming is that ICE is too complex for *frivolous* updates
that are likely to be superseded by newer more complete solutions like
the one you mentioned in TRAM.

> I don't know what this has to do with TCP vs. UDP.
>
> The real world problem here is that if you have two network interfaces (WiFi
> and Cell) and ipv4 and ipv6 and 2 TURN servers and try to connect to each
> over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates (at
> least; this ignores TCP w/ TLS).  Then both sides do that, and you have 16 *
> 16 = 256 TURN-TURN candidate pairs. That's a lot.

Except that it's not (necessarily) 256.

> So how do you avoid that problem?

Well to begin with you can simply apply the same logic as the one you
propose in your draft, but rather than doing it after sending
candidates, you apply it before. That is, you start by sending your
"better" candidates (the ones you wouldn't "deallocate" otherwise) and
you only send your less desirable ones if you fail to obtain the prime
candidates. This means that you would only end up with 256 if all of
your prime candidates failed during gathering but then suddenly
started working. Not a great likelihood for that to happen. On average
you'll probably have one or two that leak out (and when that happens
it might actually be an indication that your connection is better
there).

So, to be clear, I do agree that ending up with 256 candidates would
be a problem, especially given the 100 pairs MAX constraint 5245.

What bothers me with this draft is not the problem though: it's that
the solution doesn't appear well thought out. For example: depending
on your timing it is not at all clear that you will be able to remove
candidates before you hit 100 pairs, before they start stun
transactions or before you've already wasted the time you want to
save.

In other words, this whole thing may well turn out to be useless half
the time. That's the sort of extra complexity we don't need with ICE.

> TURN mobility is one option, and I'd like to see TURN mobility
> happen.  But candidate removal is also an option, and it's a lot more
> simple.

Again, I am not at all convinced of its purported simplicity and even
less its efficiency.

Emil

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Sat, 16 Jul 2016 07:58:28 -0700

On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov <[email-masked]> wrote:

> >> >> to me like we should rather come up with a way to update the local
> side
> >> >> of
> >> > deploy (both on client and server).  Whereas this is a simply
> mechanism
> >> > that
While I'm happy that TURN mobility is progressing, I expect it will be some
time before wide deployments TURN servers​
​
​ will have support for it.  And clients working with TURN servers that
don't support mobility will find it useful to signal candidate removal.

And I thought of another case outside of TURN candidates and continual
gathering where this is useful: when a network interface goes away at the
beginning of ICE setup.  It's useful to tell the remote side when this
happens to possibly avoid checking useless candidates.

Oh, and another:  if you have many TURN servers (say, 8), then you'll have
8*8 = 64 TURN-TURN candidates pairs, unless you are capable of removing
candidates for worse TURN servers.  TURN mobility doesn't help across TURN
servers (does it?)

> (WiFi
> candidates.

​Are you proposing to delay signaling the worse candidates?  I never like
the idea of delaying candidates because you don't know that the "better"
ones will succeed or not.  For example, if only TCP candidates work, how
long do you wait before you give up on UDP candidates?   Or if only cell
works, how long do you wait to give up on WiFi candidates?​

> This means that you would only end up with 256 if all of

> transactions or before you've already wasted the time you want to

​Actually, we did quite a lot of thinking through it.

We determined that if both sides remove worse TURN candidates and also
don't signal worse candidates, and also signal removal of worse candidates
before the addition of better candidates, then in the worst case scenario,
there are 2*N candidate pairs instead of N^2 candidates pairs.  Which means
in this example you would have 32 instead of 256.  And that's the absolute
worst case when all of your candidates are allocated in the worst possible
order, on both sides.  In more normal circumstances, it would reduce to far
fewer.
​

> the time.
> ​ T
> hat's the sort of extra complexity we don't need with ICE.

> Again, I am not at all convinced of its purported simplicity and even
The whole draft is approximately one sentence if you subtract the boiler
plate.  It's very easy to implement (it took us perhaps one day).  And it's
just an optimization, so it's not going to break anything.  I don't know
how much more simple it can get.

​In a world where TURN mobility is widely deployed and no one wants to do
continual gathering and WiFi never turns off in the beginning of call
setup, then perhaps this is useless.​    But we have use cases in which we
have already found this useful.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 18 Jul 2016 14:38:12 +0300

Hey Peter,

On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher <[email-masked]> wrote:
> time before wide deployments TURN servers
> will have support for it.  And clients working with TURN servers that don't
> support mobility will find it useful to signal candidate removal.

Sure.

> happens to possibly avoid checking useless candidates.

This would be a bad way to handle if down events as it would only work
in a very limited window of time (at least the way it's currently
defined).

> candidates for worse TURN servers.  TURN mobility doesn't help across TURN

This makes no sense to me. If you are going to remove TURN candidates
as soon as you send them, then why the heck do you have 8 TURN servers
to begin with?

> Are you proposing to delay signaling the worse candidates?

No.

> I never like the
> idea of delaying candidates because you don't know that the "better" ones
> will succeed or not.  For example, if only TCP candidates work, how long do
> you wait before you give up on UDP candidates?   Or if only cell works, how
> long do you wait to give up on WiFi candidates?

You don't need to implement explicit delays. You only need to order
your gathering and trickling according to the priority you desire.
Pacing will take care of the actual delays.

> Actually, we did quite a lot of thinking through it.

I am sure you have but this is not obvious from reading the document.

> We determined that if both sides remove worse TURN candidates and also don't
> signal worse candidates, and also signal removal of worse candidates before
> the addition of better candidates,

I am having trouble parsing this sentence but "don't signal worse
candidates" sounds to me as the opposite of "signal removal".

My guess at this stage is that once you implement "non-signalling of
worse candidates" removal of worse candidates is going to have a very
marginal benefit.

> then in the worst case scenario, there
> are 2*N candidate pairs instead of N^2 candidates pairs.  Which means in
> this example you would have 32 instead of 256.  And that's the absolute
>> T
> plate.

Yup. And that's pretty much my main problem.

I am very much missing a description of all possible states where a
removal signal can arrive and how the agent should behave under those
circumstances.

I am also missing guidelines for when exactly removal signals should be sent.

>  It's very easy to implement (it took us perhaps one day).  And it's
> just an optimization, so it's not going to break anything.  I don't know how
> much more simple it can get.
>
> In a world where TURN mobility is widely deployed and no one wants to do
> continual gathering and WiFi never turns off in the beginning of call setup,
> then perhaps this is useless.    But we have use cases in which we have
> already found this useful.

If twelve months from now you decide this wasn't worth doing, you'll
simply go and take it out of your code. If by that time the document
is out of editor's queue it will stay there.

Emil

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 18 Jul 2016 08:56:19 -0700

On Mon, Jul 18, 2016 at 4:38 AM, Emil Ivov <[email-masked]> wrote:

> >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <
> [email-masked]>
> >> >> wrote:
> >> >> >
> >> >> >
> >> And question the existence of this wonderful working group? No, of
> course
> >> not ;)
> >>

> >> > least; this ignores TCP w/ TLS).  Then both sides do that, and you
> have
> >> > 16 *

​What does "order the gathering" mean?  If I gather all the TURN candidates
in parallel, I can't control which comes back first.  And if I don't gather
them all in parallel, then I'm delaying the gathering of some, which I
don't want to do.​
​

> I am sure you have but this is not obvious from reading the document.
​
I take that as a sign that the document is simple.​ :)

> don't

It depends on the order a candidate gets gathered in (which candidate
returns from the server first).  Assume A is better than B.  If A comes
before B, then signal A but not B.  If B comes before A, signal B, then
signal removal of B, then signal A.  ​

> worse candidates" removal of worse candidates is going to have a very
​
​As long as the best candidates always finish first, you're then removal is
useless.  But if they don't, then removal is beneficial.   That's all there
is to it.  If you think your best TURN candidates will always return first
(or close), then don't bother with candidate removal.
​
It's one of those "you don't need it until you do" type of things.

Also, this is just one use case.  We find the continual gathering use case
even more compelling.

> Yup. And that's pretty much my main problem.
​First you said it's too complex.  Now you say it's too simple?​

> removal signal can arrive and how the agent should behave under those

​This mechanism can be used for many different situations.  It's not
specific to gathering TURN candidates, so I don't think adding a bunch of
TURN-gathering-specific text makes sense, if that's what you mean.  ​
​

I also think we don't need to specify exactly what the receiving agent's
behavior is, other than it SHOULD not pair with that candidate any more.
The rest is up to the receiving agent.

> I am also missing guidelines for when exactly removal signals should be
​We don't need to specify that, because there are many different situations
where this could be used.   It should send it when it wants the receiving
agent to stop making new pairs with that candidate :).

> setup,

​I don't quite follow you point here.  You don't thing we should work on
this because we might change our mind about this being useful?  Isn't that
true of *every* RFC (that we might change our minds)?

But, to be clear: if no one else in the WG finds this useful, then it won't
become a WG work item.   But if other people *do* find it useful, then even
if we change our minds, then someone else will still find it useful.
Unless we all change our minds.  Which is true of any draft/RFC.

And even though it doesn't matter, I think we'll be keeping the code around
because we find it an important part of continual gathering, and we find
continual gathering important.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 18 Jul 2016 18:23:45 +0200

On Mon, Jul 18, 2016 at 5:56 PM, Peter Thatcher <[email-masked]> wrote:
>> >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher
>> >> >> <[email-masked]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
> What does "order the gathering" mean?  If I gather all the TURN candidates
> them all in parallel, then I'm delaying the gathering of some, which I don't
> want to do.

You might want to check this as a memory refresher:
https://tools.ietf.org/html/rfc5245#appendix-B.1

Once you start pacing the gathering, ordering is pretty much implied.

Once you have ordering and pacing in place, then better candidates
will come first. If they don't, then why are you assuming they are
better?

> I take that as a sign that the document is simple. :)

This discussion is becoming more and more productive with every mail.

> signal removal of B, then signal A.

So you sent an AR to A first (because that's the one you prefered),
then applied your pacing timeout, then sent an AR to B.

1. It is most likely that A *will* come back before B which means that
the likelyhood of you needing to remove B is low and hence the gain
from that removal is low.
2. If B did come back before A, then is it really a good idea to
remove A given that it obviously didn't perform great?

> As long as the best candidates always finish first, you're then removal is

I expect that most of the time they will come first and I expect that
when they don't then my assumption that they were best is potentially
flawed.

> Also, this is just one use case.  We find the continual gathering use case

Continual gathering? Do you mean continuous nomination?

If you do then I  thought we agreed not to go down that rabbit hole
... mostly because there is currently no such thing as continuous
nomination.

> First you said it's too complex.  Now you say it's too simple?

Yes. The document is way too simple for a problem and a solution that
are significantly more complex.

> This mechanism can be used for many different situations.  It's not specific
> to gathering TURN candidates, so I don't think adding a bunch of
> TURN-gathering-specific text makes sense, if that's what you mean.

Well, let's show at least some clearly defined cases where this
indisputably makes sense then explain why it does and exactly how it
should be done.

> The rest is up to the receiving agent.

Well, if we only care about syntax and are not going to hold ourselves
to a standard where demonstrating gain is a requirement then ...

In that case I suggest we also specify a document that let's you add
an ICE signal for advertising your favorite spaghetti brand.

> We don't need to specify that, because there are many different situations
> I don't quite follow you point here.  You don't thing we should work on this
> because we might change our mind about this being useful?  Isn't that true
> of *every* RFC (that we might change our minds)?
> become a WG work item.
> But if other people *do* find it useful, then even
> if we change our minds, then someone else will still find it useful.  Unless
> we all change our minds.  Which is true of any draft/RFC.

This argument makes no sense to me. The fact that some rockets may
explode during a launch is not a reason to stop making every possible
effort that they don't.

The IETF certainly does try to minimize the number of unused RFCs even
if that goal would never be 100% achieved.

Emil

>> >> >> >>> I submitted draft-thatcher-ice-remove-candidate and would like
>> >> >> >>> to
>> >> >> >>> speak

-- 
https://jitsi.org