Re: [Ice] Proposal for ICE "network cost"

[Emil Ivov <[e-mail]>]

On 7.04.16 г. 16:27, Peter Thatcher wrote:
>
>
> On Thu, Apr 7, 2016 at 10:50 AM, Emil Ivov <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 21.03.16 г. 19:07, Peter Thatcher wrote:
>
>         As an author (not a chair), I just submitted a draft for an idea I'd
>         like to propose for ICE: network cost.
>
>         Here's the draft:
>
>         https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/
>
>
>         The idea is basically to allow the controlled side to tell the
>         controlling side which candidates "cost" more than others (such as
>         cellular costing more than Wi-Fi).  This is different than candidate
>         priority for reasons explained in the draft.
>
>
>     I see the value here but I have a few problems with the current state.
>
>     To begin with, I find the "cost" name overly confusing. I realize
>     the draft already says this is not necessarily real cost but it
>     still leaves people with the wrong impression (and I've confirmed
>     this in conversations these days). So let's just go for bias or
>     something (I also like fondness).
>
>
> ​There are two question here:  the name and the direction.  The choice
> of direction is more important than the name.  I prefer the direction
> where 0 means "free/use-freely" and a big number means
> "expensive/restrained/last-resort".  This is because if we ever expand
> the range, I think it would be better in the direction of "I really
> don't want to use this" rather than "this is even more free to use".
> You'll note that this direction is the opposite of
> fondness/preference/priority.
>
> In other words, I think modeling this as "badness' is better than as
> "goodness".

OK, this makes sense.

> So if we're going to debate names, let's debate synonyms of "badness".
> The best I could come up with is cost.  But I'd love to hear good synonyms.​

Let's go with "handicap" then? (If not we always have aversion and 
reluctance).

>     The draft is not currently very explicit about exactly how this
>     works in the selection of candidates but I assume it basically
>     means: "if it's all the same to you, I'd much rather you get in
>     touch with me here than there."
>
>
> Close.  0 means "use this freely".  A small number means "I'd rather not
> use this".  A large number means "Only use this if nothing else works".​
> ​
>
>     The trickiest part here is how to assign importance to this new bias
>     as opposed to existing metrics such as RTT for example. We could say
>     it's up to implementations or try to come up with some
>     recommendation for a formula.
>
>
> ​That's exactly what I think we should do: standardized how information
> is conveyed from controlled to controlling, but then let the controlling
> side decided how to select and nominate.​

The problem here is that unless we give directions about how it should 
be used in practice, then we greatly limit the usefulness and 
interoperability.

I actually think we can be very helpful without going into the details 
that much. Like for example:

0: use freely as you say.
h>0: you MAY use if no valid pairs exist where the remote candidate has 
a lower handicap but you SHOULD/MUST switch if such a pair becomes valid.

Also, unless your nominated pair has pair.remoteCandidate.handicap==0, 
then you MUST continue running checks until either you run through all 
of them or at least one pair with zero handicap becomes valid. When that 
happens you must switch.

Also if your selected pair has a remoteCandidate with non-zero handicap 
H and another pair becomes valid where the remoteCandidate has a lower 
handicap h (i.e., h<H) then you SHOULD switch to that new pair.

>     The other thing is that I cannot at all see the value of the network
>     ID. Why is this necessary?
>
>
> ​Technically, I could make it a separate draft, but the kind of go well
> together (they both fit in one nice STUN attribute, for example).
>
> The value of network ID is the following:  if the remote side's network
> interface changes, it's wise to notify your bandwidth estimator, because
> the change may have been drastic (wifi to 2g).  ​ It could change either
> by TURN mobility, or by continual gathering, or by the use of backup
> candidate pairs (I realized the last two are not yet standardized).

I am not a huge fan of this. I think it requires the remote side to know 
more than it needs to. If you want to reinit your bwe engine then we 
should have a message that says that (and it should probably be in 
RTCP). There could be other reasons for this that cannot be directly 
mapped to changing interfaces.

An interface ID mainly bothers me as it delivers more knowledge than one 
needs for that sort of stuff and it encourages implementers to make 
assumptions ... and ICE is all about avoiding them.

Emil

-- 
https://jitsi.org