Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>>>>>>>> Also, I guess I still haven't completely understood the
>>>>>>>> backward compatibility issue, but I guess I need to do
>>>>>>>> some more reading.
>>>>>>>
>>>>>>> We describe these in Section 3 but the main problem is that
>>>>>>> a vanilla ICE agent that gets a first subset of candidates
>>>>>>> (that may also be empty) would declare failure
>>>>>>> prematurely.
>>>>>>
>>>>>> The text gives an example where the receiver (Bob) receives a
>>>>>>  host-candidate-only offer, and start checks which fail.
>>>>>>
>>>>>> I think it's quite strange if Bob would reject the call at
>>>>>> that point. Because, no matter how many candidates the offer
>>>>>> contains, there might still be peer reflexive candidates
>>>>>> created later,
>>>>>
>>>>> How does Bob know that there's going to be a "later" ? It's
>>>>> just a vanilla ICE agent that assumed it received a full set of
>>>>> candidates, it checked them all, all checks failed.
>>>>
>>>> Bob knows that there will be STUN requests coming, and based on
>>>> those additional candidates (peer reflexive) might be created.
>>>
>>> Chances are that no STUN requests will be arriving unless Bob is
>>> also making simultaneous checks toward Alice's SR candidates, which
>>> he isn't because he doesn't have them.
>>
>> Since Alice supports trickle, we can specify that Alice shall not
>> wait for Bob's checks :)
>
> It's Bob that I was worrying about. As soon as all his checks fail
> (which can happen quite quickly if a similar host address also exists in
> Bob's network and returns ICMP unreachable), all his check lists will be
> in the failed state, and then its entire ICE processing will hence also
> move to failed.

Correct.

But, my point is that Bob might get additional candidates (peer reflexive ones) once he gets the STUN checks from Alice, so if he is smart he will wait for those before he declares failure :)

But, again, I agree that Bob may not do that, and will declare failure as soon as the host candidate present in the offer fails.

> The whole thing may even fail before that. Bob would probably reject the
> offer outright if it didn't contain any candidates. He may also do the
> same if it only has IPv6 candidates while Bob is an IPv4 only host.
>
> I am sure that one can also find other cases where lack of connectivity
> can be precluded before actually running the checks and in all of them
> it is entirely possible that Bob won't even send his candidates.

I don't disagree. Without doubt there will be cases where Bob will reject the offer "too early" :)

> And yes, 5245 does say that the controlling agent should terminate the
> session when ICE processing fails, which may partially alleviate the
> first case above although I am not sure all ICE implementations would
> behave properly and accept new candidates once all their check lists
> have moved into failed.

My dream and vision is that they don't move to fail until they have received a STUN check, in case it will create additional candidates :)

> Even if they did, it still wouldn't help with the other two cases (i.e.
> no candidates, or different address families) where lack of connectivity
> can be determined without any checks at all.

Sure.

(Of course, if Alice is dual stack, she can provide both IPv4 and v6 host candidates in the offer)


>>>> Having said that, I agree that legacy ICE endpoints might not
>>>> behave that way, and reject the call, but then we would simply do
>>>> a fallback to legacy ICE.
>>>
>>> The problem is that in this case Bob might have been alerted of the
>>> call and witnessed the failure, so a fallback to vanilla ICE would
>>> not be particularly smooth.
>>
>> I think that's an implementation issue, whether Bob is alerted before
>> a working ICE pair has been found.
>
> True. Still, 5245 allows for it and people have argued it has sometimes
> been presented as a protection of privacy: I won't advertise any of my
> user's addresses before I am sure my user actually wants to talk to the
> caller. I believe one of the Jingle XEPs have a similar statement.

It may happen, yes. But, even if the user is alerted, keep in mind that Alice may
also terminate the call establishment.


>>>>>> In my opinion, if one has to do something extra (e.g. send
>>>>>> OPTIONS), the whole idea of trickle-ICE goes away, because at
>>>>>> the end of the day you won't save any time in call
>>>>>> establishment.
>>>>>
>>>>> The OPTIONS request does not need to be sent right before the
>>>>> call. It can be done once, upon bootstrap.
>>>>
>>>> Yes, but in that case there is an even less chance that the
>>>> OPTIONS and INVITE requests will reach the same remote peer (in
>>>> case of forking).
>>>
>>> True. Maybe adding gruu-s into the mix could help ... This would
>>> indeed imply that the caller needs prior knowledge of the callee
>>> (e.g. adding them to a contact list) but maybe we can have this and
>>> then another solution for the first call/unknown callee case.
>>>
>>> I am pretty much out of ideas for the time being anyway, so if you,
>>> or anyone else, can think of something that would miraculously
>>> solve the issue, I'd be very happy to hear it.
>>
>> I think we simply need to accept the fact that the offer may be
>> rejected.
>
> Personally, I am OK with this, especially as far as SIP is concerned
> (given the deficiencies in the caps neg support). However if we go for
> this it may be best to agree exactly how things should fail so that:
>
> 1 - time is not wasted
> 2 - reasons for the failure are easily related to non-support of trickle ICE
> 3 - failures happen in a predictable way
> 4 - users are not bothered with them

I agree we should have text about it.

And, I have no problem to give examples on how all this can be avoided. It's the "SHOULD use them" that is my main issue :)

>> Of course, people CAN use OPTIONS, or whatever mechanisms they want
>> to figure out before sending the offer, but I don't think we should
>> have that as a SHOULD.
>
> OK, I can agree with making the "check support in advance" a MAY.
> However defining a try and fallback procedure for usages (including SIP)
> seems quite important to me.

I agree.

Q3: Enough is enough: 
----------------------

>>> All in all, making assumptions on the receiving end is always a
>>> risk. If the host sending the candidates knows that they are its
>>> best/only candidates, then it could indicated so by sending the
>>> end-of-candidates message we describe in the draft.
>>
>> In case Bob has a public IP address, why does Alice need to send an
>> offer with the additional candidates in the first place? Why not
>> simply start using them, and Bob will process them as peer reflexive
>> candidates?
>>
>> (I can understand that signaling is needed in case per-candidate
>> ufag/pwd values are used, but let's assume a case where the same
>> values are used for all candidates.)
>
> My point was that Bobs IP address being public:
>
> * does not mean it is the best option: VPN, tunnelling, and multiple
> interfaces can all generate public host IP addresses that are a lot less
> preferable to server reflexive ones.
> * does not even guarantee that it's reachable. Connectivity may be
> administratively prohibited, routes can be down.

Alice CAN continue to gather candidates, in case there are better ones. My question was why she needs to signal them to Bob in a new offer, instead of simply start sending STUN checks associated with the candidates? Bob will then process them as peer reflexive candidates.

Regards,

Christer