Re: [MMUSIC] Signaling trickle support

[Flemming Andreasen <[e-mail]>]

On 11/8/12 2:25 PM, Emil Ivov wrote:
> Hey Flemming,
>
> On 08.11.12, 14:07, Flemming Andreasen wrote:
>> On 11/8/12 11:29 AM, Emil Ivov wrote:
>>> Hey Flemming,
>>>
>>> On 08.11.12, 10:53, Flemming Andreasen wrote:
>>>> On 11/8/12 10:46 AM, Martin Thomson wrote:
>>>>> Trolled.
>>>>>
>>>>> Though to be honest, I don't see a way around this particular problem.
>>>>>     The idea of using a Require: trickle header is fraught with problems;
>>>>> the idea that you might use an a= line doesn't give you the
>>>>> characteristics you desire.  I just don't know how to cause the
>>>>> failure that is needed when this isn't supported.
>>>> Can we capture the desired characteristics and failure mode for starters ?
>>> The "really" desired characteristic is knowing in advance whether or not
>>> the remote party can do trickle so that you know whether you can afford
>>> to send an empty offer without causing it to freak out.
>> Why would you send an empty offer ?
> Normally the offer should contain only candidates that are readily
> available (such as host candidates). However if the offerer does not
> wish to disclose those for privacy reasons, then it would just send an
> offer with no candidates. This is for example how Chrome currently behaves.
>
> It also places 0.0.0.0:1 in the c= and m= lines.
>
> That's currently explain in section 4 of the draft:
>
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4
Ok (that's not an empty offer though).

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

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

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