From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Date: Fri, 12 Oct 2012 14:55:39 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2obD/l5WjDlW9DR/SoPpuN4Wb0DQAAH+HA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>,
 <5075864F.3030700@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,
 <5075FB20.6070408@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
 <5076B8E4.6050307@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
 <50773B73.6060508@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se>
 <5077FE17.3010800@jitsi.org>
In-Reply-To: <5077FE17.3010800@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
Precedence: list

Hi,

Q1: Remote endpoint support (SIP):=20
--------------------------------------------
=20
>>>>>> Also, I guess I still haven't completely understood the backward=20
>>>>>> compatibility issue, but I guess I need to do some more reading.
>>>>>=20
>>>>> We describe these in Section 3 but the main problem is that a=20
>>>>> vanilla ICE agent that gets a first subset of candidates (that may=20
>>>>> also be empty) would declare failure prematurely.
>>>>=20
>>>> The text gives an example where the receiver (Bob) receives a=20
>>>> host-candidate-only offer, and start checks which fail.
>>>>=20
>>>> I think it's quite strange if Bob would reject the call at that=20
>>>> point. Because, no matter how many candidates the offer contains,=20
>>>> there might still be peer reflexive candidates created later,
>>>=20
>>> How does Bob know that there's going to be a "later" ? It's just a=20
>>> vanilla ICE agent that assumed it received a full set of candidates,=20
>>> it checked them all, all checks failed.
>>=20
>> Bob knows that there will be STUN requests coming, and based on those=20
>> additional candidates (peer reflexive) might be created.
>
> Chances are that no STUN requests will be arriving unless Bob is also mak=
ing simultaneous checks toward Alice's SR candidates, which he isn't becaus=
e he doesn't have them.

Since Alice supports trickle, we can specify that Alice shall not wait for =
Bob's checks :)

>>> Now, we could rely on Bob not doing anything rash and waiting=20
>>> patiently for reINVITEs from Alice in order to get more candidates=20
>>> ...
>>=20
>> The peer reflexive candidates will not come in a re-INVITE, they will=20
>> 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 publ=
ic address or a NAT with no endpoint dependent filtering).

I assume that Bob (since he doesn't support trickle) has provided ALL his a=
vailable candidates (server reflexive, relay etc) in the SDP answer.

(Just because Bob only got a host candidate in the offer, it doesn't mean h=
e will only return a host candidate in the answer.)


>> Having said that, I agree that legacy ICE endpoints might not behave=20
>> that way, and reject the call, but then we would simply do a fallback=20
>> 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 partic=
ularly smooth.

I think that's an implementation issue, whether Bob is alerted before a wor=
king ICE pair has been found.

>>>> In my opinion, if one has to do something extra (e.g. send OPTIONS),=20
>>>> the whole idea of trickle-ICE goes away, because at the end of the=20
>>>> day you won't save any time in call establishment.
>>>=20
>>> The OPTIONS request does not need to be sent right before the call.
>>> It can be done once, upon bootstrap.
>>=20
>> Yes, but in that case there is an even less chance that the OPTIONS=20
>> and INVITE requests will reach the same remote peer (in case of=20
>> forking).
>
> True. Maybe adding gruu-s into the mix could help ... This would indeed i=
mply that the caller needs prior knowledge of the=20
> callee (e.g. adding them to a contact list) but maybe we can have this an=
d 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 an=
yone 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.

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.

Of course, people CAN use OPTIONS, or whatever mechanisms they want to figu=
re out before sending the offer, but I don't think we should have that as a=
 SHOULD.

>>>> Now, if the browser is communicating with a ICE terminating gateway,=20
>>>> and if the browser performs SIP registration, then the gateway can=20
>>>> indicate trickle-ICE during registration.
>>>>=20
>>>> 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=20
>>>> INVITE...
>>>=20
>>> I agree. Not sure what to say other than, I agree that SIP does not=20
>>> have good mechanisms for XMPP like negotiation of entity caps but,=20
>>> personally, I do believe that finding one would be helpful here.
>>>=20
>>> Maybe we can work on making sure that 3840 (or some other
>>> mechanism) would better allow for caps to be discovered in advance.
>>>=20
>>> At the very least, if we can't find a way to do this gracefully with=20
>>> SIP, we can RECOMMEND it whenever the protocol allows it and try to=20
>>> devise a fall back strategy when it does not (e.g. with SIP).
>>=20
>> 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 th=
e remote peer supports :)


Q3: Enough is enough:=20
---------------------------
=20
>>>>>>>> I think it could be useful for the answerer to tell the offerer=20
>>>>>>>> that it doesn't want/need any more candidates.
>>>>>>>=20
>>>>>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>>>>>=20
>>>>>> 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).
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>> Maybe it is enough... In any case I think it would be good to
>>>> document :)
>>>=20
>>> OK. Agreed.
>>>=20
>>>> 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.
>>>=20
>>> I am not sure I got this.
>>=20
>> 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 w=
ith the additional candidates in the first place? Why not simply start usin=
g them, and Bob will process them as peer reflexive candidates?

(I can understand that signaling is needed in case per-candidate ufag/pwd v=
alues are used, but let's assume a case where the same values are used for =
all candidates.)

Regards,

Christer