Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-sip-sdp regarding explicit removal of candidites

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 11:43:40 +0000

Hi,

I first sent the comments on draft-ietf-mmusic-ice-sip-sdp below to the ICE list, but then realised they belong on the MMUSIC list.

It’s related to the current suggestion that it should be possible to explicitly remove candidates in ICE, and whether trickle assumes that candidates can NOT be removed.

It has been suggested that removal of candidates should not be part of trickle, but rather be defined in a separate future extension draft. The comments below are based on that such “extension” may exist at some point.

The text in section 4.2 says:

   "In every INFO request agents MUST include all local candidates they
   have signaled previously.  This is necessary in order to more easily
   avoid problems that would arise from unreliable transports.  Mis-
   ordering can be detected through the CSeq: header field in the INFO
   request.  As a consequence candidates cannot be removed unless an ICE
   restart is performed.  Note that extension might be specified in the
   future that enable such removal without a restart.”

Q1: Assuming someone does define an extension which allows removal of candidates without a restart, do such candidates still have to be included in the INFO, as they have been “previously signalled"? What is the scope of “previously”? Previously since when?

Q2: What if an INFO does NOT contain a local candidate that has previously been signaled? Do we assume it has been removed using some “extension”? Do we assume it’s still there?

Q3: What if a candidate has bee removed using some “extension”, and then it still shows up in an INFO? Does it mean it’s automatically added back?

At one point I suggested that the INFO should ONLY contain the added candidates, and would say nothing about existing candidates. But, as that was not accepted I think Q1-Q3 needs to be clarified in the document.

Thanks!

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Wed, 5 Oct 2016 16:08:59 +0200

Christer,

I took the liberty to adjust the subject since the cited text is
is from draft-ietf-mmusic-trickle-ice-sip-05,
not from draft-ietf-mmusic-ice-sip-sdp.

more inline

On 2016-10-05 13:43, Christer Holmberg wrote:
> Hi,
>
> I first sent the comments on draft-ietf-mmusic-ice-sip-sdp below to 
> the ICE list, but then realised they belong on the MMUSIC list.
>
> It’s related to the current suggestion that it should be possible to 
> explicitly remove candidates in ICE, and whether trickle assumes that 
> candidates can NOT be removed
Trickle-ICE as specified in draft-ietf-ice-trickle-04 is about 
incremental provisioning of candidates. The draft does not mention 
removal of already trickled candidates anywhere in the document. This 
leads me to the conclusion that _currently_ you cannot signal that a 
candidate is to be removed again.

>
> It has been suggested that removal of candidates should not be part of 
> trickle, but rather be defined in a separate future extension draft. 
> The comments below are based on that such “extension” may exist at 
> some point.
>
> Q1: Assuming someone does define an extension which allows removal of 
> candidates without a restart, do such candidates still have to be 
> included in the INFO, as they have been “previously signalled"?
This would have to clarified in that future extension document together 
with corresponding backward compatibility issues and/or indication of 
support for such an extension. I don't want to do design here, but 
a=ice-options might be something to look at.
> What is the scope of “previously”?
The current ICE generation (as defined by the currently used/exchanged 
ufrag/pwd)
> Previously since when?
Since current ufrag/pwd was signalled.
>
> Q2: What if an INFO does NOT contain a local candidate that has 
> previously been signaled? Do we assume it has been removed using some 
> “extension”? Do we assume it’s still there?
We could either treat this case as an error and ignore the content of 
that INFO.
Probably not the best idea, e.g. in case that a=end-of-candidates was 
included.
Or we can assume (in absence of any "removal extension") that it is 
still there. That would allow to still make use of any newly trickled 
candidates in such an INFO. This makes more sense to me.
If this is agreable I would be happy to put corresponding text into 
section 4.2.
>
> Q3: What if a candidate has bee removed using some “extension”, and 
> then it still shows up in an INFO? Does it mean it’s automatically 
> added back?
This is probably the easiest way to deal with that, as it does not 
require housekeeping. But again I see this as something that the future 
extension document has to deal with.

Regards
Thomas
>
> At one point I suggested that the INFO should ONLY contain the added 
> candidates, and would say nothing about existing candidates. But, as 
> that was not accepted I think Q1-Q3 needs to be clarified in the document.
>
> Thanks!
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 14:56:55 +0000

Hi,

>I took the liberty to adjust the subject since the cited text is is from draft-ietf-mmusic-trickle-ice-sip-05,

Thanks!

>> The comments below are based on that such "extension" may exist at 
>> some point.
>>
>>     future that enable such removal without a restart."
>> included in the INFO, as they have been "previously signalled"?
>
> This would have to clarified in that future extension document together with corresponding backward
> compatibility issues and/or indication of support for such an extension. I don't want to do design here, 
> but a=ice-options might be something to look at.

How you indicate support of such extension is outside the scope of this thread. I want to clarify the exact semantics of a candidate in an INFO.

>> What is the scope of "previously"?
>
>The current ICE generation (as defined by the currently used/exchanged ufrag/pwd)
>> Previously since when?

Is that said anywhere?

Also, an "extension" could have removed candidiates since the ufrag/pwd was signalled. So, you cannot simply say "since current ufrag/pwd was signalled". You also need to say something like "and are still active/in use", or something like that.

>> "extension"? Do we assume it's still there?
>
> We could either treat this case as an error and ignore the content of that INFO.
> Probably not the best idea, e.g. in case that a=end-of-candidates was included.
> Or we can assume (in absence of any "removal extension") that it is still there. That 
> would allow to still make use of any newly trickled candidates in such an INFO. This makes more sense to me.
> If this is agreable I would be happy to put corresponding text into section 4.2.

...or, we could go back to my previous proposal, and say that we *ONLY* signal the new candidates, and that the INFO has no impact on any other candidates :)

Also, assuming all current candidates are present in INFOs, what about peer reflexive candidates? Will they be present in INFOs?

>>> Q3: What if a candidate has bee removed using some "extension", and 
>>> then it still shows up in an INFO? Does it mean it's automatically 
>>> added back?
>>
>>This is probably the easiest way to deal with that, as it does not require housekeeping. 
>>But again I see this as something that the future extension document has to deal with.

...or, we could go back to my previous proposal, and say that we *ONLY* signal the new candidates, and that the INFO has no impact on any other candidates :)

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Tue, 11 Oct 2016 08:58:36 +0200

Christer,

>> Since current ufrag/pwd was signalled.
Not explicitly, but provided that all INFOs MUST also include the 
current ufrag/pwd (see the preceding paragraph in that section), what 
other interpretation of "previously" would make sense?
> Also, an "extension" could have removed candidiates since the ufrag/pwd was signalled. So, you cannot simply say "since current ufrag/pwd was signalled". You also need to say something like "and ar…
Why would I have to?
As long as we remain within the currently specified Trickle-ICE 
functionality, all candidates that where exchanged within the scope of 
the current ufrag/pwd
are "active/in use" in the sense of being subject to 
pairing/pruning/connectivity checking.
A potential  future extension would have to deal with such issues and 
provide appropriate text.
> ...or, we could go back to my previous proposal, and say that we *ONLY* signal the new candidates, and that the INFO has no impact on any other candidates :)
Well, there is consensus since  2013 that the INFO carries all candidates.
It was one outcome of the thread that started here
https://mailarchive.ietf.org/arch/search/?email_list=mmusic&gbt=1&index=T7R18RumQQJrmtHRh1lmcf9wcqs 

I can't remember that this consensus was not challenged since then, but 
I guess that all implementations will expect all candidates in the INFO.
> Also, assuming all current candidates are present in INFOs, what about peer reflexive candidates? Will they be present in INFOs?
Actually there is no real need to put peer reflexive candidates into the 
INFO package since the ICE Agents learn them from the STUN checks.
However,  the current text does not preclude that you signal the peer 
reflexives redundantly in the INFO package.
Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Oct 2016 07:39:19 +0000

Hi,

>>> compatibility issues and/or indication of support for such an
>>>extension. I don't want to do design here,
>> How you indicate support of such extension is outside the scope of this
>>thread. I want to clarify the exact semantics of a candidate in an INFO.

Again, I agree that how candidates are removed is outside the scope. But,
that doesn¹t change the fact that trickle needs to define exactly what the
semantic of the signalled candidates. I do NOT want a future extension to
change that semantic.

>other interpretation of "previously" would make sense?

I don¹t know - we have to ask the implementers that have not been involved
in the IETF work about that.

We shall not make assumptions that readers will interpret things in a
certain way - the text shall be clear, and not open for interpretation.

>> Also, an "extension" could have removed candidiates since the ufrag/pwd
>>was signalled. So, you cannot simply say "since current ufrag/pwd was
>>signalled". You also need to say something like "and are still active/in
>>use", or something like that.
>Why would I have to?

Because I assume we only want to signal candidates that are still in use.

That is what I meant by the semantic comment earlier. I don¹t want the
semantic of a signalled candidate to be ³It was signalled at some point
with the current ufrag/pwd, but it may no longer be in use². I want it to
be ³It was signalled at some point with the current ufrag/pwd, and it is
still in use².

>provide appropriate text.

We KNOW that there is a wish to be able to remove candidates, so while
trickle doesn't specify how it is done we shall assume it can be done some
way. Otherwise we may end up in a situation where we¹ll either have to
update trickle and/or do some dirty hacks in order to get things to work.

>>>still there. That
>> ...or, we could go back to my previous proposal, and say that we *ONLY*
>>signal the new candidates, and that the INFO has no impact on any other
>>candidates :)

We didn¹t discuss removal of candidates back in 2013, so I think we shall
re-ask the community.

>> Also, assuming all current candidates are present in INFOs, what about
>>peer reflexive candidates? Will they be present in INFOs?

Again - that needs to be clarified.

Regards,

Christer

>>>>require housekeeping.
>> ...or, we could go back to my previous proposal, and say that we *ONLY*
>>signal the new candidates, and that the INFO has no impact on any other
>>candidates :)
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>

---

From: Thomas Stach <[email-masked]>
Date: Wed, 12 Oct 2016 13:01:22 +0200

inline

> semantic of the signalled candidates. I do NOT want a future extension to
I don't how you want to preclude an arbitrary future extension to do 
such a change,
but in case of a "candidate removal" extension I don't see a problem 
with the current concept.
The current concept is (as I understand it):
- An INFO always carries all candidates that belong to the currently 
valid ufrag/pwd.
- We have the restriction that in subsequent INFOs the number of these 
candidates can
  only increase or remain constant until end-of-candidates is signalled.

If someone wants to define a "candidate removal" extension, he/she can keep
the semantics of the first item, i.e.
- An INFO always carries all candidates that belong to the currently 
valid ufrag/pwd.
  and would have to do the following
- modify the constraint to something like  "In subsequent INFOs the 
number of these candidates can increase, _decrease_ or remain constant "
- define how support for the "candidate removal" extension is 
negotiated  and how backward compatibility is achieved
-  define how candidates are actually removed

<snip/>
> be ³It was signalled at some point with the current ufrag/pwd, and it is
Does my answer from above work for you?
If yes, then I think we are not to far apart from each other and I could 
work on some improved text.

> We didn¹t discuss removal of candidates back in 2013, so I think we shall
I still think that the current concept works, so will you want to ask 
that then?
> Again - that needs to be clarified.
I can mention that
Thanks
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 19:51:00 +0000

Hi,

>>>>>>> It has been suggested that removal of candidates should not be 
>>>>>>> part of trickle, but rather be defined in a separate future extension draft.
>>>>>>>       "In every INFO request agents MUST include all local 
>>>>>>>       candidates they have signaled previously.  This is necessary in order to 
>>>>>>>       more easily avoid problems that would arise from unreliable transports.  Mis-
>>>>>>> Q1: Assuming someone does define an extension which allows removal 
>>>>>>> of candidates without a restart, do such candidates still have to 
>>>>>>> be included in the INFO, as they have been "previously signalled"?
>>>>>>
>>>>>> This would have to clarified in that future extension document 
>>>>>> together with corresponding backward compatibility issues and/or 
>>>>>> indication of support for such an extension. I don't want to do 
>>>>>> design here, but a=ice-options might be something to look at.
>>>>>
>>>>> How you indicate support of such extension is outside the scope of 
>>>>> this thread. I want to clarify the exact semantics of a candidate in an INFO.
>>> Again, I agree that how candidates are removed is outside the scope. 
>>> But, that doesn¹t change the fact that trickle needs to define exactly 
>>> what the semantic of the signalled candidates. I do NOT want a future 
>>> extension to change that semantic.
> I don't how you want to preclude an arbitrary future extension to do such a change, 
> but in case of a "candidate removal" extension I don't see a problem with the current >concept.
> - An INFO always carries all candidates that belong to the currently valid ufrag/pwd.

But that is not what the text is saying. "That belong" is not the same as "Previously signalled". "That belong" means they are still valid/active - at least in my ears.

> - We have the restriction that in subsequent INFOs the number of these candidates can

I think we should remove that restriction.

Even if we don't have a defined mechanism for removing candidates, they can disappear anyway. The TURN server may crash, etc. Why should we keep signalling such candidates? We could of course do an ICE re-start whenever a candidate is removed (one way or another), but I don't think we want to do that...

But, again, by ONLY signalling the added candidates we don't have the issue with removed candidates to begin with. 

>If someone wants to define a "candidate removal" extension, he/she can keep the semantics of the first item, i.e.
>- An INFO always carries all candidates that belong to the currently valid ufrag/pwd.

Again, I don't think that is what "previously signalled" means.

>- modify the constraint to something like  "In subsequent INFOs the number of these candidates can increase, _decrease_ or remain constant "

I see no reason to have that constraint to begin with.

>- define how support for the "candidate removal" extension is negotiated  and how backward compatibility is achieved

I agree the negotiation and mechanism should be defined elsewhere.

But, again again, I'd like to hear whether people would be ok to only signal the added candidates in INFO.

<snip/>
>>>> Also, an "extension" could have removed candidiates since the 
>>>> ufrag/pwd was signalled. So, you cannot simply say "since current 
>>>> ufrag/pwd was signalled". You also need to say something like "and 
>>>> are still active/in use", or something like that.
>>> Why would I have to?
>> semantic of a signalled candidate to be ³It was signalled at some 
>> point with the current ufrag/pwd, but it may no longer be in use². I 
>> want it to be ³It was signalled at some point with the current 
>> ufrag/pwd, and it is still in use².

Partly. But, again, I don't think what you are saying is what is written in the draft :)

>>>>>> previously been signaled? Do we assume it has been removed using 
>>>>>> some "extension"? Do we assume it's still there?
>>>>> still there. That would allow to still make use of any newly 
>>>>> trickled candidates in such an INFO. This makes more sense to me.
>>>> ...or, we could go back to my previous proposal, and say that we 
>>>> *ONLY* signal the new candidates, and that the INFO has no impact on 
>>>> any other candidates :)
>>> I can't remember that this consensus was not challenged since then, 
>>> but I guess that all implementations will expect all candidates in the INFO.
>> We didn¹t discuss removal of candidates back in 2013, so I think we 
>> shall re-ask the community.
>I still think that the current concept works, so will you want to ask that then?

I am asking as we speak. Anyone who does not agree with the suggestion should speak up :)

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 17 Oct 2016 10:41:35 +0200

Christer,

sorry for the delay i was busy with other stuff.

more inline

> But that is not what the text is saying. "That belong" is not the same as "Previously signalled". "That belong" means they are still valid/active - at least in my ears.
Taking into account that draft-ice-trickle does not provide  any 
mechanism for removal in my ears both sound the same -  currently that is.
Would then changing  "... Previously signalled ..." to "That belong" in 
the body of draft-mmusic-trickle-ice-sdp be fine then?
> I think we should remove that restriction.
Taking into account that draft-ice-trickle does not provide  any 
mechanism for removal in my ears such a restriction is implied - 
currently that is again.
However I would be fine with not explicitly mentioning this in 
draft-mmusic-trickle-ice-sdp.

>
> Even if we don't have a defined mechanism for removing candidates, they can disappear anyway. The TURN server may crash, etc.
Would that be detected via the failed connectivity checks?
> Why should we keep signalling such candidates?
I doesn't do any harm. Section 4.2 specifies that only new candidates 
are relayed to the ICE agent.
> We could of course do an ICE re-start whenever a candidate is removed (one way or another), but I don't think we want to do that...
Probably not, but that is the way that Trickle-ICE inherited from 5245.
> But, again, by ONLY signalling the added candidates we don't have the issue with removed candidates to begin with.
There  will certainly be other issues.
> I am asking as we speak. Anyone who does not agree with the suggestion should speak up :)
Nicely replied :)
However, it certainly takes more than silence to change the current 
procedure in the document.
There needs to be explicit support for such a change from a larger 
number of participants.
I also believe that we first need to see some elaborated text that deals 
with issues like reordering and other corner cases.

The current concept is mature and I also showed a path how it could be 
extended to deal with candidate removal.
So, I don't see a need to change, especially considering that we were 
asked to get things finished rather quickly.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 09:17:50 +0000

Hi,

>>>with the current >concept.
>> But that is not what the text is saying. "That belong" is not the same
>>as "Previously signalled". "That belong" means they are still
>>valid/active - at least in my ears.

Let’s talk about a mechanism that DOES exist: continous consent.

According to RFC 7675, if consent is lost for specific candidates an ICE
re-start is required in order to use the candidate pair.

So, before such ICE re-start occur, why should we keep signalling such
candidates in INFOs?

Also note that 7675 defines a mechanism to explicitly signal that consent
has been removed. Whether we call that “removal of candidate” or not can
be discussed, but why should such candidates continue to be signalled?

...

>>Even if we don't have a defined mechanism for removing candidates, they
>>can disappear anyway. The TURN server may crash, etc.

Yes. Or, if coninous consent is used, when consent expires.

>> We could of course do an ICE re-start whenever a candidate is removed
>>(one way or another), but I don't think we want to do that...
>> But, again, by ONLY signalling the added candidates we don't have the
>>issue with removed candidates to begin with.

Please present those issues so we can discuss them.

...

>asked to get things finished rather quickly.

I assume we are also asked to get things finished properly :)

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 17 Oct 2016 15:49:27 +0200

inline

> So, before such ICE re-start occur, why should we keep signalling such
Now I'm lost.
Can you please explain what 7675 has to do with the INFO messages from 
Trickle-ICE?
These INFOs are used during the early dialog phase of the session in 
order to get the candidates exchanged until end-of-candidates is received.
7675 comes into the game  after a candidate pair is nominated and the 
dialog is confirmed.
> be discussed, but why should such candidates continue to be signalled?
The signalling of candidates has long finished at that point.
> Please present those issues so we can discuss them.
I'd rather wait until some elaborated text for your proposal appears and 
then start from there.
> I assume we are also asked to get things finished properly :)
Which we certainly will do.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 10:20:56 +0000

Hi Thomas,

>7675 comes into the game  after a candidate pair is nominated and the

You are right. The continuous consent (CC) checks start once ICE has
concluded (at least that’s how I also read 7675). To me that sounds
strange, because media can be sent on candidates before ICE is concluded.
It even that someone could “disable” CC simply by never concluding ICE to
begin with. But, that discussion belongs elsewhere.

Also, if we move forward with the continuous nomination (CN) proposal,
where ICE is never concluded, I assume we would have to modify RFC 7675 so
that CC checks begin earlier. But, that would also mean that CC checks and
trickle could be used at the same time.

...

>I'd rather wait until some elaborated text for your proposal appears and

Ok, I’ll work on some text.

But, I’d still like to know what the issues with ONLY signalling the added
candidates were. If there were some issues, it would probably be good to
document in the draft, to justify the sending of ALL candidates.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 07:33:59 +0000

Hi Thomas,

>>>>>>>>>>>> The comments below are based on that such "extension" may
>>>>>>>>>>>>exist
>>>>>>>>>>>> at
>>>>>>>>>>>> some point.
>>>>>>>>>>>>
>>>>>>>>>>>>         ordering can be detected through the CSeq: header
>>>>>>>>>>>>field
>>>>>>>>>>>> in the INFO
>>>>>>>>>>>>         request.  As a consequence candidates cannot be
>>>>>>>>>>>>removed
>>>>>>>>>>>> unless an ICE
>>>>>>>>>> this thread. I want to clarify the exact semantics of a
>>>>>>>>>>candidate
>>>>>>>>>> in an INFO.

I had some off-line discussions, and it seems like the idea is that CC
checks begin once a pair has been validated. People agree the RFC text is
not very clear.

But, that means that CC checks and trickle CAN be used at the same time.

Regards,

Christer