Re: [MMUSIC] Signaling trickle support

["Pal Martinsen (palmarti)" <[e-mail]>]

On Nov 9, 2012, at 24:24 AM, Emil Ivov <[e-mail]> wrote:

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

>From our experience single allocation takes aprox 30ms. This includes one redirect due to alternate server and one extra roundtrip because of authentication. The time the TURN server is using to process the request is neglicable and so  it is RTT that is important. If the RTT is to large media would be troublesome anyway due to excessive jitter and delay.

Number of media lines and interfaces does not matter as this is done in parallel (or pretty close to). Our implementation have 5 media lines (Audio, 2x Video, BFCP, FECC), resulting in 9 TURN allocations. 

What we have been struggling with is delay in the signaling path. We have seen delays in the range of 3-5 seconds for the 200OK to traverse the signaling path. That caused some failing ICE calls due to to large skew and we did not complete the transactions in what we have set as a reasonable time. 

> 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.
> 
My understanding is that UPnP or PCP can be used to open pinholes without the need for keepalives.
So in theory this can be done when the endpoints registers. At least if we are not overly concerned about the extra port allocations on the NAT.

But I agree with the point. Additional steps to gather "better" candidates can take time.


> 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.
> 
Personally I see great benefit in having the ability to add candidates (and remove them) without doing a update or re-invite. This would make mobility scenarios easier, and developing a smarter and more optimized media experience can be a lot easier.  

.-.
Pål-Erik


>>> 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
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic