Re: [MMUSIC] Signaling trickle support

[Emil Ivov <[e-mail]>]

Hey Flemming,

On 08.11.12, 17:21, Flemming Andreasen wrote:
>>>> Since protocols like SIP don't really have things like XMPP disco and
>>>> Cap Neg that would have allowed it, we were considering other options.
>>>> One such option would be to send a trickle offer and format it in a way
>>>> that would cause a non-trickle answerer to reject it in a _predictable_
>>>> way. This would allow the offerer to retry with a regular ICE offer.
>>> I thought the point with trickle-ICE was to reduce call setup latency
>> It is.
>>
>>> and hence you would want to make sure that things complete in as few
>>> round-trips as possible. This doesn't seem to line up with that (?).
>> The thing is that in cases where trickle ICE support cannot be
>> pre-confirmed you have to fall back to half trickle. The probing
>> requests would hence allow for an optimisation compared to that.
> Somewhat unclear to me as it builds upon an assumption that it is 
> somehow "more efficient"to probe than to collect candidates.

Indeed, this would not always be the case and it would basically come
down to comparing one signalling RTT to the duration of candidate
gathering.

As you agreed in one of your previous mails, the relation may vary:

Executing a single STUN transaction is likely to be less time consuming
than a signalling RTT. Candidate gathering however may also last a lot
longer than a single offer/answer exchange.

However, an agent that has several interfaces and uses them to gather
candidates for three streams that don't have bundle nor RTCP muxing is
going to need quite some time to complete a harvest. Add to this UPnP
allocations and a second STUN server and you could easily find the
signalling RTT tens of times shorter than the candidate gathering.

In all cases the UA would have a fairly good idea of what to expect so
it could easily determine whether or not a probe would make sense.

> Clarifying 
> the criteria for something being "more efficient" would also be helpful 
> here (what is it truly that we are after; setup delay reduction, fewer 
> NAT bindings, ...)

I believe we can agree that in the context of trickle the only thing
that matters is call setup duration.

>> With half-trickle the offerer has to gather all candidates anyway so,
>> while doing so, they might as well try and check if they really need to
>> complete it before sending their first offer.
> Unclear to me since you can collect candidates before you know who to 
> send the offer to.

You could ... but not always. A hard phone can easily do this when
someone picks it up. A softphone however doesn't have a clear early cue
about a pending call initiation so the only way would be to always
maintain a set of active candidates and to keep them alive. Not
necessarily the most desirable option, especially for large deployments.

A web page could be even worse, especially in cases where the calling
functionality is only a side feature (e.g. a support or a customer
service call option).

Cheers,
Emil

> Thanks
> 
> -- Flemming
>>>>>> Besides, the failure modes all lead to an expenditure of time that is
>>>>>> worse than the simple candidate gathering scenarios (reflexive,
>>>>>> relay), though not "other" gathering methods (UPnP, etc...).
>>>>> Is there a requirement here that needs to be written down ?
>>>> The point that Martin is making is that sending an offer and then
>>>> waiting for the failure may potentially take longer than just gathering
>>>> your candidates. This is true especially in cases where the offerer is
>>>> only planning on using a single port, on a single interface, with a
>>>> single STUN/TURN server and no other candidate gathering mechanisms.
>>> I would agree with that.
>>>> But then, if this really is the case, the offerer knows it and can
>>>> choose not to do the probing.
>>> Agreed.
>>>>>> half-trickle is a reasonable solution.
>>>>> Sorry - what's half-trickle ?
>>>> We had that in the slides on Tuesday but it's not yet in the draft. The
>>>> idea is that if you can't confirm support for trickle in the answerer,
>>> Do you mean: if you don't know if the answerer supports it before
>>> sending an offer to him
>> Yes. That's what I meant. The offerer needs to know that in advance in
>> order to decide how to form their offer.
>>
>> Cheers,
>> Emil
>>
>>> [since confirming support in the answer should
>>> be easy]  ?
>>>> you just send a vanilla ICE offer and you also indicate you do support
>>>> trickle. A trickle ICE answerer can then trickle candidates and in
>>>> general you get half the optimizations of Trickle ICE. You even get more
>>>> than that in case the offerer is able to predictively gather candidates
>>>> before the call is initiated.
>>> Agreed.
>>>> We'll describe this in the next version.
>>> Ok - thanks for the explanation.
>>>
>>> -- Flemming
>>>> Cheers,
>>>> Emil
>>>>
>>>>> -- Flemming
>>>>>
>>>>>
>>>>>> On 8 November 2012 10:12, Emil Ivov <[e-mail]> wrote:
>>>>>>> I actually think this was supposed to be a joke. At least that's how I
>>>>>>> got it.
>>>>>>>
>>>>>>> Emil
>>>>>>>
>>>>>>> On 08.11.12, 10:01, Flemming Andreasen wrote:
>>>>>>>> This is very different from the way we normally handle extensions in SDP
>>>>>>>> both from a pure signaling and negotiation point of view. I share the
>>>>>>>> sentiment of others that this does not look like a good idea but would
>>>>>>>> like to understand if there were other considerations for suggesting
>>>>>>>> this radically different approach.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -- Flemming
>>>>>>>>
>>>>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Christer
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Miguel A. Garcia
>>>>>>>>> Sent: 8. marraskuuta 2012 9:30
>>>>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov
>>>>>>>>> Cc: [e-mail]
>>>>>>>>> Subject: Re: [MMUSIC] Signaling trickle support
>>>>>>>>>
>>>>>>>>> As an individual...
>>>>>>>>>
>>>>>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea.
>>>>>>>>>
>>>>>>>>> Let met quote RFC 4566:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         The "v=" field gives the version of the Session Description Protocol.
>>>>>>>>>         This memo defines version 0.  There is no minor version number.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works.
>>>>>>>>>
>>>>>>>>> /Miguel
>>>>>>>>>
>>>>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote:
>>>>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote:
>>>>>>>>>>> Matthew, Justin and I were discussing the problem of signaling
>>>>>>>>>>> trickle ICE support and the following proposal was made:
>>>>>>>>>>>
>>>>>>>>>>> The 24th bit in SDP is currently set to zero.  This bit is
>>>>>>>>>>> specifically reserved for forward compatibility purposes.  We can use
>>>>>>>>>>> this bit.  Set this bit to one to indicate support for trickle ICE.
>>>>>>>>>>>
>>>>>>>>>>> This meets the "works if supported, fails if it doesn't criteria".
>>>>>>>>>>>
>>>>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever.
>>>>>>>>>> After some side discussion, I guess you are talking about bits in the
>>>>>>>>>> value of the v= field ???
>>>>>>>>>>
>>>>>>>>>> If so, I still have no idea what you are talking about. The syntax for
>>>>>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary
>>>>>>>>>> and then choose bit 24 if you want, but that has no significance in 4566.
>>>>>>>>>>
>>>>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like
>>>>>>>>>> an incredibly bad idea.
>>>>>>>>>>
>>>>>>>>>>          Thanks,
>>>>>>>>>>          Paul
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mmusic mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Miguel A. Garcia
>>>>>>>>> [phone]
>>>>>>>>> Ericsson Spain
>>>>>>>>> _______________________________________________
>>>>>>>>> mmusic mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>> _______________________________________________
>>>>>>>>> mmusic mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>> .
>>>>>>>>>
>>>>>>> --
>>>>>>> https://jitsi.org
>>>>>> .
>>>>>>
>>>
> 
> 

-- 
https://jitsi.org