Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Christer,

On 12.10.12, 14:55, Christer Holmberg wrote:
> 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.

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.

>>>> Now, we could rely on Bob not doing anything rash and waiting 
>>>> patiently for reINVITEs from Alice in order to get more
>>>> candidates ...
>>> 
>>> The peer reflexive candidates will not come in a re-INVITE, they
>>> will be created based on the STUN requests.
>> 
>> That's kind of a corner case. Learning peer-reflexive candidates
>> implies that Bob can get Alice's conn checks which would only
>> happen if Bob's addresses are directly reachable from Alice (e.g.
>> Bob has a public address or a NAT with no endpoint dependent
>> filtering).
> 
> I assume that Bob (since he doesn't support trickle) has provided ALL
> his available candidates (server reflexive, relay etc) in the SDP
> answer.
> 
> (Just because Bob only got a host candidate in the offer, it doesn't
> mean he will only return a host candidate in the answer.)

Yes of course, however I don't think this would help in the cases I
describe above. In all of them Bob can still prematurely fail the session.

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.

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.

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

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

> Based on the discussion above, I believe there are cases where things
> will work even if Bob doesn't support trickle, and in other case
> we'll just have to send a new non-trickle offer.

Supporting non-trickle is definitely a MUST for whoever cares for
interop. I agree with this.

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

>>>>> Now, if the browser is communicating with a ICE terminating
>>>>> gateway, and if the browser performs SIP registration, then
>>>>> the gateway can indicate trickle-ICE during registration.
>>>>> 
>>>>> But, in the peer-to-peer case I don't know how it would
>>>>> work. It's not even sure OPTIONS would reach the same remote
>>>>> peer as the INVITE...
>>>> 
>>>> I agree. Not sure what to say other than, I agree that SIP does
>>>> not have good mechanisms for XMPP like negotiation of entity
>>>> caps but, personally, I do believe that finding one would be
>>>> helpful here.
>>>> 
>>>> Maybe we can work on making sure that 3840 (or some other 
>>>> mechanism) would better allow for caps to be discovered in
>>>> advance.
>>>> 
>>>> At the very least, if we can't find a way to do this gracefully
>>>> with SIP, we can RECOMMEND it whenever the protocol allows it
>>>> and try to devise a fall back strategy when it does not (e.g.
>>>> with SIP).
>>> 
>>> There ARE ways to do it, but they all suck :)
>> 
>> Is it realistic to expect that we can improve any of them to do the
>> job? Or add a new one?
> 
> This is not the first time we realize that it would be good to know
> what the remote peer supports :)
> 
> 
> Q3: Enough is enough: ---------------------------
> 
>>>>>>>>> I think it could be useful for the answerer to tell
>>>>>>>>> the offerer that it doesn't want/need any more
>>>>>>>>> candidates.
>>>>>>>> 
>>>>>>>> Yes, sounds useful. Do you have any specific use cases
>>>>>>>> in mind?
>>>>>>> 
>>>>>>> Well, I guess any case where the remote peer knows it has
>>>>>>> a public
>>>>>> IP address (it will most likely be an ICE lite entity).
>>>>>> 
>>>>>> Right, but in such cases the offerer would also know that
>>>>>> a certain pair has succeeded so if they continue it might
>>>>>> be with the purpose of finding a better RTT or a higher
>>>>>> priority local candidate.
>>>>>> 
>>>>>> I guess what I am trying to say is that a Binding Response
>>>>>> is enough of an indication that trickling can stop. If it
>>>>>> doesn't then maybe it's for a reason.
>>>>> 
>>>>> Maybe it is enough... In any case I think it would be good
>>>>> to document :)
>>>> 
>>>> OK. Agreed.
>>>> 
>>>>> Also, at least in cases where the remote peer only provide a
>>>>> host candidate (because it has a public IP address), one
>>>>> should be smart enough to figure out that there most likely
>>>>> will be no better alternative.
>>>> 
>>>> I am not sure I got this.
>>> 
>>> If the remote peer only provides a host candidate, and it works,
>>> I think there won't be any better alternatives.
>> 
>> I don't know about that. Well, what if the host candidate is
>> actually an IPv6 (or VPN) tunnel with poor latency and bandwidth
>> and the SR candidate works better? Or what if it's the address of
>> an 802.11g/b interface and the same machine has a NATed Ethernet
>> connection with, again, better bandwidth and latency?
>> 
>> 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.


Cheers,
Emil

-- 
https://jitsi.org