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

[Peter Thatcher <[e-mail]>]

On Thu, Apr 7, 2016 at 3:14 PM, Emil Ivov <[e-mail]> wrote:

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


​I'm not a fan of any of those words.  I'd prefer "badness" over those.
​


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

I think such a rule is too restrictive of cost/badness > 0.  Perhaps such a
rules for cost/badness == MAX would make sense.  Basically, MAX would mean
"last resort".

However, we do need to be careful about the case where there are only two
candidate pairs available, one of which is (0, MAX) and the other (MAX,
0).  In other words, either the controlling side or the controlled side has
to end up using a "last resort".  Do we standardize which is picked, or
leave that up to the controlling side to decide (let it decide to be
gracious or not).
 ​


>
> 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.
>
>
​So, basically, don't prune less-bad networks just because a more-bad
network worked first?  That seems reasonable.  I'm not sure if it's
MUST-worthy, though.

And, again, be careful with the "must switch"​, since you need to remember
the case where only two candidate pairs exist: (N, 0) and (0, N) and the
controlling side needs to pick who pays more (and whether to be gracious or
not).



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


​Well, as mentioned, the badness of both sides needs to be balanced.  A
given candidate pair might be slight better for you but a lot worse for me.​
​


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


​It's not as simple as just "reinit the BWE".  The BWE wants to know *why*,
and knowing its because the remote network changed is important
information.​
​
And the other problem with message sent from the remote side is that the
local/controlling side may switch candidate pairs, and it needs to know if
doing so changes the remote network or not, so it can know if it should
reset or not.  If it had to wait for a message from the remote side, it
would have to wait for the remote side to receive a message from the local
side, and then for the remote side to send back a message saying "by the
way, that candidate pair changed my local network", which just adds an
extra round trip for no good reason.

(and it should probably be in RTCP).


​That's not going to work for data channels, which also use ICE.​

There could be other reasons for this that cannot be directly mapped to
> changing interfaces.


​In which case, the BWE would like to know which case it is, because it
might behave differently between them. ​


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


​It's basically the minimal information to know that the remote network
path is changing between two candidate pairs.  And the assumption that can
be made is that if the ID is different, the network is different, which is
exactly the information it is meant to convey.
​

>
> Emil
>
> --
> https://jitsi.org
>




​I mostly disagree here.  The controlled side is always at the mercy of the
controlling side, and t
he status-quo is that the controlled side has no way to say anything about
the networks it finds costly/bad.  Being able to communicate
0/max/something-in-between is very useful for the controlled side with any
reasonably implemented controlling side.

But for the values of things in between 0 and max, I agree.  ​The
difference between 100 and 200 are hard to nail down.  We tried to nail it
down according to how we think it would be useful, and we realized two
things:
1.  Everyone might not agree with how we were thinking to nail it down.
2.  We might change our minds 6-12 months from now anyway.

Being able to signal these things is valuable even if we haven't nailed
down what the difference between 100 and 200 means (if we ever nail it
down).  So I'd prefer standardizing the signaling of these things
(signaling here includes the STUN attribute) and the range of values, and
then leave the interpretation of the difference of particular values to
implementations or future specs once we have more implementation experience.