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

[Emil Ivov <[e-mail]>]

On Mon, Jul 18, 2016 at 5:56 PM, Peter Thatcher <[e-mail]> wrote:
>
>
> On Mon, Jul 18, 2016 at 4:38 AM, Emil Ivov <[e-mail]> wrote:
>>
>> Hey Peter,
>>
>> On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher <[e-mail]>
>> wrote:
>> >
>> >
>> > On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov <[e-mail]> wrote:
>> >>
>> >> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher <[e-mail]>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov <[e-mail]> wrote:
>> >> >>
>> >> >> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher
>> >> >> <[e-mail]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <[e-mail]>
>> >> >> > 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.
>> >> >>
>> >> >> 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 :) .
>> >> >>
>> >> >
>> >> > Continual gathering is a separate topic that we can save for another
>> >> > day.
>> >> >
>> >> >>
>> >> >> >> 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).
>> >> >>
>> >> >> 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.
>> >> >>
>> >> >
>> >> > 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?
>> >>
>> >> 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.
>> >>
>> >
>> > 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.
>>
>> Sure.
>>
>> > 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.
>>
>> 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).
>>
>> > 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?)
>>
>> 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?
>
>
>>
>> >> >> 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?
>> >> >
>> >> >
>> >> > 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.
>> >
>> >
>> > 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.
>
>
> 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.

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?

>> >> 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.
>> >
>> >
>> > Actually, we did quite a lot of thinking through it.
>>
>> 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. :)

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

>> > 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".
>
> 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.

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?

>> 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.
>
>
> 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.

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.

> 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.

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.

>> > 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.
>> >
>> >>
>> >> In other words, this whole thing may well turn out to be useless half
>> >> the time.
>> >> T
>> >> hat'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.
>> >>
>> >
>> > The whole draft is approximately one sentence if you subtract the boiler
>> > plate.
>>
>> Yup. And that's pretty much my main problem.
>>
>
> 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.

>> 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.
>
>
> 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.

> 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.

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.

>> I am also missing guidelines for when exactly removal signals should be
>> sent.
>>
>
> 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 :).
>
>>
>> >  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.
>
>
> 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.

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

> 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.




>
>
>>
>>
>> Emil
>>
>> >> Emil
>> >>
>> >> >>
>> >> >> Emil
>> >> >>
>> >> >>
>> >> >> >> Emil
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tuesday, 12 July 2016, Peter Thatcher <[e-mail]>
>> >> >> >> 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.
>> >> >> >>>
>> >> >> >>> 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)




-- 
https://jitsi.org