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

[Peter Thatcher <[e-mail]>]

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



>
> >> 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.​ :)


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



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


>
> > 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?​



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

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

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)
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> sent from my mobile
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> https://jitsi.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> https://jitsi.org
> >
> >
>
>
>
> --
> https://jitsi.org
>