Subject: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Feb 2013 10:00:07 -0500

Hi

I took a look the trickle-ice draft and have a couple of questions/comments:

1) Section 1 says
<quote>
    This specification does not define usage of trickle ICE with any
    specific signalling protocol, contrary to [RFC5245] which contains a
    usage for ICE wht SIP.  Such usages would have to be specified in
    separate documents.
</quote>
however you do define it specifically using SDP and Offer/Answer (I 
believe). It would be worthwhile calling that out.

2) Section 5.1 says
<quote>
    As mentioned earlier in this section, Offers and Answers can contain
    any set of candidates, which means that a trickle ICE session
    description MAY contain no candidates at all.  In such cases the
    agent would still need to place an address in the "c=" line(s). If
    the use of a host address there is undesirable (e.g. for privacy
    reasons), the agent MAY set the connection address to 0.0.0.0. In
    this case it MUST also set the port number to 1.  There is no need to
    include a fictitious 0.0.0.0 candidate when doing so.
<quote>
I had to read this several times before I (think) I understood that when 
you say "the agent MAY set the connection address to 0.0.0.0", you are 
referring to the connection address in the "a=candidate" attribute, not 
the "c=" line. Can you clarify and rephrase accordingly.

3) Section 9.1
I'm confused about this whole section and it's premise that 
"a=candidate" attributes and media descriptions are not clearly linked. 
The "a=candidate" attribute is defined as a media-level attribute only 
and describes as such in RFC 5245, so I must be missing something here.

4) Section 9.2. Rather than talking about sending "end of candidates" 
via "the signalling channel" (which is not defined), could we change 
this to say and "end of candidates" need to be sent to the peer, and the 
only mechanism defined to do so in this document is through an O/A 
exchange (new exchange or answer to an offer) ?

5) Section 14 (Example)
The exchange of the "additional candidates" does not use an O/A 
exchange. As for comment 4), this assumes some other un-defined 
mechanism somewhere - would it be useful to show it as an O/A exchange 
as well, but note that other mechanisms may be defined ?

6) Section A.1 (MID/Stream Indicates in SDP)
I'm still unclear on this (per comment 3).

Thanks

-- Flemming (as Individual)

On 1/30/13 11:38 AM, Emil Ivov wrote:
> Hey all,
>
> Justin, Eric and I have just submitted an update to the trickle ICE
> draft, accommodating comments from Atlanta:
>
> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00
>
> More details about the changes here:
> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B
>
> Diff2:
> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00
>
> During the MMUSIC presentation and the mailing list discussions it was
> also pointed out that it is important for this work to happen in
> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have
> therefore submitted the following document:
>
> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00
>
> As always, comments are welcome!
>
> Cheers,
> Emil
>
> -------- Original Message --------
> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt
> Date: Mon, 28 Jan 2013 11:39:21 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked], [email-masked]
>
>
> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt
> has been successfully submitted by Emil Ivov and posted to the
> IETF repository.
>
> Filename:	 draft-ivov-mmusic-trickle-ice
> Revision:	 00
> Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
> Interactive Connectivity Establishment (ICE) Protocol
> Creation date:	 2013-01-28
> WG ID:		 Individual Submission
> Number of pages: 20
> URL:
> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice
> Htmlized:        http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00
>
>
> Abstract:
>     This document describes an extension to the Interactive Connectivity
>     Establishment (ICE) protocol that allows ICE agents to send and
>     receive candidates incrementally rather than exchanging complete
>     lists.  With such incremental provisioning, ICE agents can begin
>     connectivity checks while they are still gathering candidates and
>     considerably shorten the time necessary for ICE processing to
>     complete.
>
>     The above mechanism is also referred to as "trickle ICE".
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Feb 2013 10:10:51 -0500

On 2/7/13 10:00 AM, Flemming Andreasen wrote:
> I had to read this several times before I (think) I understood that 
> when you say "the agent MAY set the connection address to 0.0.0.0", 
> you are referring to the connection address in the "a=candidate" 
> attribute, not the "c=" line. Can you clarify and rephrase accordingly.
>
> 3) Section 9.1
> "a=candidate" attributes and media descriptions are not clearly 
> linked. The "a=candidate" attribute is defined as a media-level 
> attribute only and describes as such in RFC 5245, so I must be missing 
> something here.
>
>
> this to say and "end of candidates" need to be sent to the peer, and 
> the only mechanism defined to do so in this document is through an O/A 
7) It seems the inclusion of the "trickle" ice-options is what will 
trigger the use of tricke-ICE. I think this is a slight overloading of 
the ice-options semantics inasmuch as it is intended to indicate support 
for a given extension, which does not necessarily imply you actually 
want to use that extension. I think it would be useful to have a 
separate way of indicating you also want to use trickle-ICE.

Thanks

-- Flemming

>> From:[email-masked]
>> To:[email-masked]
>> CC:[email-masked],[email-masked]
>>
>>
>> Htmlized:http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00
>>
>>
>> Abstract:

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Feb 2013 10:19:31 -0500

On Thu, Feb 7, 2013 at 10:10 AM, Flemming Andreasen <[email-masked]> wrote:

> 7) It seems the inclusion of the "trickle" ice-options is what will trigger
> the use of tricke-ICE. I think this is a slight overloading of the
> ice-options semantics inasmuch as it is intended to indicate support for a
> given extension, which does not necessarily imply you actually want to use
> that extension. I think it would be useful to have a separate way of
> indicating you also want to use trickle-ICE.
>

Why wouldn't just starting trickle-ICE be sufficient indication, given
that it has been indicated as supported?  I think the half-trickle
option covers the case where you don't know that it is supported, but
it may be I am misunderstanding the issue.

regards,

Ted

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Feb 2013 10:27:03 -0500

On 2/7/13 10:19 AM, Ted Hardie wrote:
> Why wouldn't just starting trickle-ICE be sufficient indication,
How would you know you started trickle-ICE or vanilla ICE ?

-- Flemming
> given

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Feb 2013 11:02:16 -0500

On Thu, Feb 7, 2013 at 10:27 AM, Flemming Andreasen <[email-masked]> wrote:
>>> trigger

Well, you'd have a very strong indication if the candidate list were
empty, and a reasonable indication if it contained only host
candidates.   If that weren't the case, you'd have to keep open the
possibility that more candidates might come in.

But I think I've been thinking of this the other way around--if both
sides are known to support trickle-ICE, the client sends
a=end-of-candidates whenever it's done *even if that is on the first
candidate set sent*.  Perhaps that is "vanilla ICE with sprinkles",
but it seems to solve the problem without another indicator/round of
negotiation.  As you note, that may overload the the ice-option
semantics, but it seems likely to work reasonable well.

regards,

Ted

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Feb 2013 11:09:52 -0500

> possibility that more candidates might come in.
The above would seem to favor an explicit indication.

> candidate set sent*.
Not sure I follow - this would terminate trickle-ICE prematurely, no ?

> Perhaps that is "vanilla ICE with sprinkles",
I don't think it does since it would seem to terminate trickle-ICE 
prematurely, but maybe we should wait for the authors to clarify.

Thanks

-- Flemming

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Feb 2013 11:18:31 -0500

On Thu, Feb 7, 2013 at 11:09 AM, Flemming Andreasen <[email-masked]> wrote:
>  If that weren't the case, you'd have to keep open the
It would terminate it, but not prematurely.  The client sends
a=end-of-candidates whenever it's done sending candidates; it just
allows you to send that indicator if you already had the full list on
the first use.  So if it did the blocking version of candidate
gathering, it sends that as the indicator that it is done.

> prematurely, but maybe we should wait for the authors to clarify.

Well, I'd certainly be happy to have the authors or others chime in.
But I am personally okay with the presumption that you always use
Trickle-ICE if Trickle-ICE is available at both ends, because it is
easy to get Vanilla ICE semantics using Trickle-ICE syntax.  I agree,
though, that this overloads the ice-option.

regards,

Ted Hardie

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 07 Feb 2013 08:53:56 -0800

> gathering, it sends that as the indicator that it is done.

Isn't part of the point of trickle-ICE that you potentially are never 
done sending candidates? (Interface and connectivity changes and the 
like, avoiding a complete session restart by testing and switching to 
new candidates on the fly)

Matthew Kaufman

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Feb 2013 11:58:35 -0500

On Thu, Feb 7, 2013 at 11:53 AM, Matthew Kaufman <[email-masked]> wrote:
> Isn't part of the point of trickle-ICE that you potentially are never done
> sending candidates? (Interface and connectivity changes and the like,
> avoiding a complete session restart by testing and switching to new
> candidates on the fly)

You could use it that way, but it supports modes that allow you to
claim you are done.  The "send host candidates first, then trickle
server reflexive and call it done" is one called out in the draft.
Since you can claim you are done, getting the semantics of vanilla ICE
seems easy enough.

Just my two cents,

Ted

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Feb 2013 12:27:55 -0500

Hey all,

> Since you can claim you are done, getting the semantics of vanilla ICE

Yup that's the idea. The whole point of having end-of-candidates
indications is to basically say: I am not done till I say I am done (and
I really am when I say I am).

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 07 Feb 2013 13:00:45 -0500

Hey Flemming, Ted, all,

> separate way of indicating you also want to use trickle-ICE.

The intention of the current trickle ICE text is to say the following:

1. When your (the offerer's) intention is to do half trickle you include
the "trickle" ice-options token and you are prepared to have the
answerer trickling. You are also prepared to have them do vanilla ICE.
In either case you can either include end-of-candidates in your offer or
you can choose to not include it depending on how you intend to behave
if the answerer turns out to support trickle.

1.1. If the answer does indicate support trickle ICE by the answerer,
then you are both abiding by the trickle-ice spec. You can both still
choose to behave like vanilla ICE agents and send complete sets of
candidates from the start but you know that you have to handle trickle
semantics and you know that you have to send end-of-candidates when you
are done.

1.2 If the answerer does not support trickle, then there's no "trickle"
ice-options token in the answer and the offerer knows that trickling is
no longer possible (regardless of whether or not there was
end-of-candidates in the offer).

2. If the offerer's intention is to generate a vanilla ICE offer then it
does not include the "trickle" ice-options token and everyone just uses
vanilla ICE semantics.

I believe that this is the part in 5245 that you had a problem with and
I think that this is the text you are referring to:

    First, ICE provides the a=ice-options SDP attribute.  Each extension
    or change to ICE is associated with a token.  When an agent
    supporting such an extension or change generates an offer or an
    answer, it MUST include the token for that extension in this
    attribute.  *This allows each side to know what the other side is
    doing*.  This attribute MUST NOT be present if the agent doesn't
    support any ICE extensions or changes.

I am not sure exactly what the intention of this text was (maybe we
could clarify this in 5245bis) but that highlighted part makes me think
the point was to make sure everyone knows what behaviour to expect
rather than what features they have in their ICE stack even if they are
not planning on using them.

In that sense, if I send what I intend to be a vanilla offer then you
can count on me not to use any trickle semantics and you would make me
really unhappy if you did it yourself (because I might be gateway-ing
your stuff to a vanilla agent). In that sense I'd really like you to
behave as if I were a vanilla ICE agent.

In other words, I believe it would be legitimate for me not to include
the "trickle" token in ice-options.

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Feb 2013 20:33:10 -0500

Hi Emil

As noted at the Interim meeting, I think it's cleaner to have 
ice-options used to strictly indicate features supported, and then have 
a separate way of indicating their use.

However, in taking another look at RFC 5245, it's somewhat unclear what 
semantics were intended. Section 15.5 for example suggests "supported" 
semantics, however Section 21.1.7 suggests "used" semantics. There are a 
few more examples of each throughout the doc so I agree with you that 
5245bis should clarify this (and depending on that clarification, we 
should use it the same way here).

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Feb 2013 12:04:31 +0000

Hi,

When a SIP dialog is established, entities normally don't indicate support for features that they don't want to use within that dialog.

However, if the semantics of ice-options is unclear, another alternative is to define a SIP option-tag, which provides more freedom to specify the semantics for individual option-tags.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 12. helmikuuta 2013 3:33
To: Emil Ivov
Cc: Ari Keränen; MMUSIC IETF WG
Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]

Hi Emil

As noted at the Interim meeting, I think it's cleaner to have ice-options used to strictly indicate features supported, and then have a separate way of indicating their use.

However, in taking another look at RFC 5245, it's somewhat unclear what semantics were intended. Section 15.5 for example suggests "supported" 
semantics, however Section 21.1.7 suggests "used" semantics. There are a few more examples of each throughout the doc so I agree with you that 5245bis should clarify this (and depending on that clarification, we should use it the same way here).

Thanks

-- Flemming

On 2/7/13 1:00 PM, Emil Ivov wrote:
>> trigger the use of tricke-ICE. I think this is a slight overloading 
>> of the ice-options semantics inasmuch as it is intended to indicate 
>> support for a given extension, which does not necessarily imply you 
>> actually want to use that extension. I think it would be useful to 
>> have a separate way of indicating you also want to use trickle-ICE.
> 1. When your (the offerer's) intention is to do half trickle you 
> include the "trickle" ice-options token and you are prepared to have 
> the answerer trickling. You are also prepared to have them do vanilla ICE.
> In either case you can either include end-of-candidates in your offer 
> or you can choose to not include it depending on how you intend to 
> behave if the answerer turns out to support trickle.
>
> semantics and you know that you have to send end-of-candidates when 
> you are done.
>
> ice-options token in the answer and the offerer knows that trickling 
> is no longer possible (regardless of whether or not there was 
> 2. If the offerer's intention is to generate a vanilla ICE offer then 
> it does not include the "trickle" ice-options token and everyone just 
> uses vanilla ICE semantics.
>
> I believe that this is the part in 5245 that you had a problem with 
> and I think that this is the text you are referring to:
>
> could clarify this in 5245bis) but that highlighted part makes me 
> think the point was to make sure everyone knows what behaviour to 
> expect rather than what features they have in their ICE stack even if 
> they are not planning on using them.
>
>>>> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-
>>>> 01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00
>>>>
>>>> During the MMUSIC presentation and the mailing list discussions it 
>>>> was also pointed out that it is important for this work to happen 
>>>> in parallel with a SIP usage for trickle ICE. Enrico, Christer and 
>>>> I have therefore submitted the following document:
>>>>
>>>> has been successfully submitted by Emil Ivov and posted to the IETF 
>>>> repository.
>>>>

---

From: Ari Keränen <[email-masked]>
Date: Wed, 13 Feb 2013 16:14:21 +0200

Hi,

This clearly needs to be clarified in ICE-bis.

Regarding which way ("just support" or "support and will use") it should 
be clarified, we have one precedent. RTP+ECN RFC says 
(http://tools.ietf.org/html/rfc6679#section-6.4):

>    The answering party includes this same attribute at the session level
>    in the SDP answer if it also has the capability and removes the
>    attribute if it does not wish to use ECN or doesn't have the
>    capability to use ECN.

This seems to imply that it should be "support and will use" to be 
consistent with current registration(s). And this would be consistent 
with the current Trickle ICE too.

Then, should we have also "ice-supported" attribute, or SIP option-tag, 
or nothing? I wonder in what case would one use only the "supported"? 
Would the semantics be "I support but will not use unless you indicate 
that you want to use", or something else?

Cheers,
Ari
(as individual)

On 2/12/13 2:04 PM, Christer Holmberg wrote:
> Hi,
>
> When a SIP dialog is established, entities normally don't indicate
> support for features that they don't want to use within that dialog.
>
> However, if the semantics of ice-options is unclear, another
> alternative is to define a SIP option-tag, which provides more
> freedom to specify the semantics for individual option-tags.
>
> Regards,
>
> Christer
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Flemming Andreasen
> Sent: 12. helmikuuta 2013 3:33 To: Emil Ivov Cc: Ari Keränen; MMUSIC
> IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE
> update and a new SIP usage draft.]
>
> Hi Emil
>
> ice-options used to strictly indicate features supported, and then
> have a separate way of indicating their use.
>
> However, in taking another look at RFC 5245, it's somewhat unclear
> what semantics were intended. Section 15.5 for example suggests
> "supported" semantics, however Section 21.1.7 suggests "used"
> semantics. There are a few more examples of each throughout the doc
> so I agree with you that 5245bis should clarify this (and depending
> on that clarification, we should use it the same way here).
>
> Thanks
>
> -- Flemming
>
>
>>> 7) It seems the inclusion of the "trickle" ice-options is what
>>> will trigger the use of tricke-ICE. I think this is a slight
>>> overloading of the ice-options semantics inasmuch as it is
>>> intended to indicate support for a given extension, which does
>>> not necessarily imply you actually want to use that extension. I
>>> think it would be useful to have a separate way of indicating you
>>> also want to use trickle-ICE.
>> include the "trickle" ice-options token and you are prepared to
>> have the answerer trickling. You are also prepared to have them do
>> vanilla ICE. In either case you can either include
>> end-of-candidates in your offer or you can choose to not include it
>> depending on how you intend to behave if the answerer turns out to
>> support trickle.
>>
>> 1.1. If the answer does indicate support trickle ICE by the
>> answerer, then you are both abiding by the trickle-ice spec. You
>> can both still choose to behave like vanilla ICE agents and send
>> complete sets of candidates from the start but you know that you
>> have to handle trickle semantics and you know that you have to send
>> end-of-candidates when you are done.
>>
>> 1.2 If the answerer does not support trickle, then there's no
>> "trickle" ice-options token in the answer and the offerer knows
>> that trickling is no longer possible (regardless of whether or not
>> there was end-of-candidates in the offer).
>>
>> 2. If the offerer's intention is to generate a vanilla ICE offer
>> then it does not include the "trickle" ice-options token and
>> everyone just uses vanilla ICE semantics.
>>
>> I believe that this is the part in 5245 that you had a problem
>> with and I think that this is the text you are referring to:
>>
>> First, ICE provides the a=ice-options SDP attribute.  Each
>> extension or change to ICE is associated with a token.  When an
>> agent supporting such an extension or change generates an offer or
>> an answer, it MUST include the token for that extension in this
>> I am not sure exactly what the intention of this text was (maybe
>> we could clarify this in 5245bis) but that highlighted part makes
>> me think the point was to make sure everyone knows what behaviour
>> to expect rather than what features they have in their ICE stack
>> even if they are not planning on using them.
>>
>> In that sense, if I send what I intend to be a vanilla offer then
>> you can count on me not to use any trickle semantics and you would
>> make me really unhappy if you did it yourself (because I might be
>> gateway-ing your stuff to a vanilla agent). In that sense I'd
>> really like you to behave as if I were a vanilla ICE agent.
>>
>> In other words, I believe it would be legitimate for me not to
>> include the "trickle" token in ice-options.
>>
>> Does this make sense?
>>
>> Emil
>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>
>>>> Thanks
>>>>
>>>>> Justin, Eric and I have just submitted an update to the
>>>>> trickle ICE draft, accommodating comments from Atlanta:
>>>>>
>>>>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendi
>>>>>
>>>>>
x-B
>>>>>
>>>>> During the MMUSIC presentation and the mailing list
>>>>> discussions it was also pointed out that it is important for
>>>>> this work to happen in parallel with a SIP usage for trickle
>>>>> ICE. Enrico, Christer and I have therefore submitted the
>>>>> following document:
>>>>>
>>>>>
>>>>> Cheers, Emil
>>>>>
>>>>> -------- Original Message -------- Subject: New Version
>>>>> Notification for draft-ivov-mmusic-trickle-ice-00.txt Date:
>>>>> Mon, 28 Jan 2013 11:39:21 -0800 From:
>>>>> [email-masked] To: [email-masked] CC:
>>>>> [email-masked], [email-masked]
>>>>>
>>>>>
>>>>> has been successfully submitted by Emil Ivov and posted to
>>>>> the IETF repository.
>>>>>
>>>>> Filename:	 draft-ivov-mmusic-trickle-ice Revision:	 00 Title:
>>>>> Trickle ICE: Incremental Provisioning of Candidates for the
>>>>> Creation date:	 2013-01-28 WG ID:		 Individual Submission
>>>>> Number of pages: 20 URL:
>>>>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-0
>>>>>
>>>>>
0.txt
>>>>>
>>>>>
>>>>> Abstract: This document describes an extension to the
>>>>> Interactive Connectivity Establishment (ICE) protocol that
>>>>> allows ICE agents to send and receive candidates
>>>>> incrementally rather than exchanging complete lists.  With
>>>>> such incremental provisioning, ICE agents can begin
>>>>> connectivity checks while they are still gathering candidates
>>>>> and considerably shorten the time necessary for ICE
>>>>> processing to complete.
>>>>>
>>>>> _______________________________________________ mmusic
>>>>> mailing list [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic .
>>>>>
>>>>
>>>>
>>>> _______________________________________________ mmusic mailing
>>>> list [email-masked]
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>