Subject: Re: [Ice] Do we currently need functionality for removing candidates?

From: Peter Thatcher <[email-masked]>
Date: Mon, 3 Oct 2016 21:57:13 -0700

I proposed candidate removal as an extension to ICE in Berlin:

https://tools.ietf.org/html/draft-thatcher-ice-remove-candidate-00

But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can
be published without it and it can be published later as an extension, if
the ICE WG chooses to adopt it.

On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <[email-masked]>
wrote:

> I believe that removing candidates is very useful. Let me give an example.
> With TURN mobility, it is possible to retain pairs involving TURN
> candidates across interface changes. So if you leave a building and WLAN
> host candidates become unavailable, if you have cellular connectivity you
> can use TURN mobility to keep media flowing while looking for a better
> candidate pair. To avoid loss of consent that would invalidate Pairs
> involving the WLAN candidates, it is desirable to remove (and perhaps
> later, renominate) the WLAN host and srvflx candidates.
>
> The package of TURN mobility, removal, renomination and aspects of
> passive-aggressive nomination therefore enables efficient and effective ICE
> mobility.
>
> Code is available for inspection in ORTC Lib (http://ortclib.org/)
>
> On Sep 23, 2016, at 1:47 PM, Thomas Stach <[email-masked]> wrote:
>
> All,
>
> in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a
> question came up, if we need functionality for removing candidates.
>
> From list discussion in ICE, the minutes of the Berlin IETF and due to the
> lack of corresponding text in draft-ietf-ice-trickle-04, I have the
> impression that this is currently not in scope of the Trickle ICE work.
>
> Could anybody confirm that this impression is correct?
>
> If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-
> sip.
>
>
> Regards
>
> Thomas
>
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Thomas Stach <[email-masked]>
Date: Tue, 4 Oct 2016 14:12:45 +0200

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing the 
ICE documents.

Regards

Thomas

On 2016-10-04 06:57, Peter Thatcher wrote:
> But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) 
> can be published without it and it can be published later as an 
> extension, if the ICE WG chooses to adopt it.
>
>
> On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I believe that removing candidates is very useful. Let me give an
>     example. With TURN mobility, it is possible to retain pairs
>     involving TURN candidates across interface changes. So if you
>     leave a building and WLAN host candidates become unavailable, if
>     you have cellular connectivity you can use TURN mobility to keep
>     media flowing while looking for a better candidate pair. To avoid
>     loss of consent that would invalidate Pairs involving the WLAN
>     candidates, it is desirable to remove (and perhaps later,
>     renominate) the WLAN host and srvflx candidates.
>
>     passive-aggressive nomination therefore enables efficient and
>     effective ICE mobility.
>
>     On Sep 23, 2016, at 1:47 PM, Thomas Stach <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     All,
>>
>>     in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in
>>     MMUSIC a question came up, if we need functionality for removing
>>     candidates.
>>
>>     >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in
>>     draft-ietf-ice-trickle-04, I have the impression that this is
>>     currently not in scope of the Trickle ICE work.
>>
>>     If yes, we would be about ready for WGLC of
>>     draft-ietf-mmusic-trickle-ice-sip.
>>
>>
>>     Regards
>>
>>     Thomas
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/ice>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ice>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 12:14:31 +0000

Hi,

My issue was not whether removing of candidates is documented in trickle or not, but whether trickle assumes that candidates will not be removed.

Regards,

Christer

From: Thomas Stach <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 4 October 2016 at 15:12
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Do we currently need functionality for removing candidates?

Peter,

thanks!

That confirms my impression and looks like a good plan for finishing the ICE documents.

Regards

Thomas

But I believe that trickle ICE documents (in both ICE and MMUSIC WGs) can be published without it and it can be published later as an extension, if the ICE WG chooses to adopt it.

On Fri, Sep 23, 2016 at 3:52 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
I believe that removing candidates is very useful. Let me give an example. With TURN mobility, it is possible to retain pairs involving TURN candidates across interface changes. So if you leave a building and WLAN host candidates become unavailable, if you have cellular connectivity you can use TURN mobility to keep media flowing while looking for a better candidate pair. To avoid loss of consent that would invalidate Pairs involving the WLAN candidates, it is desirable to remove (and perhaps later, renominate) the WLAN host and srvflx candidates.

The package of TURN mobility, removal, renomination and aspects of passive-aggressive nomination therefore enables efficient and effective ICE mobility.

On Sep 23, 2016, at 1:47 PM, Thomas Stach <[email-masked]<mailto:[email-masked]>> wrote:

All,

in preparation of WGLC for draft-ietf-mmusic-trickle-ice-sip in MMUSIC a question came up, if we need functionality for removing candidates.

>From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding text in draft-ietf-ice-trickle-04, I have the impression that this is currently not in scope of the Trickle ICE work.

If yes, we would be about ready for WGLC of draft-ietf-mmusic-trickle-ice-sip.

Regards

Thomas

_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice

_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice

---

From: Thomas Stach <[email-masked]>
Date: Tue, 4 Oct 2016 15:10:08 +0200

Christer,

isn't that implied when draft-ice-trickle does not mention removal of 
candidates and Peter's draft proposes that as an extension?

Regards

Thomas

On 2016-10-04 14:14, Christer Holmberg wrote:
> Hi,
>
> My issue was not whether removing of candidates is documented in 
> trickle or not, but whether trickle assumes that candidates will not 
> be removed.
>
> Regards,
>
> Christer
>
> To: "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>     The package of TURN mobility, removal, renomination and aspects
>>     of passive-aggressive nomination therefore enables efficient and
>>     effective ICE mobility.
>>
>>     On Sep 23, 2016, at 1:47 PM, Thomas Stach
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>     All,
>>>
>>>     >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of corresponding
>>>     text in draft-ietf-ice-trickle-04, I have the impression that
>>>     this is currently not in scope of the Trickle ICE work.
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 13:29:45 +0000

Hi,

>isn't that implied when draft-ice-trickle does not mention removal of candidates and Peter's draft proposes that as an extension?

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

Regards,

Christer

Peter,

thanks!

Regards

Thomas

All,

Regards

Thomas

---

From: Thomas Stach <[email-masked]>
Date: Tue, 4 Oct 2016 15:52:35 +0200

Christer,

the cited text is from draft-ietf-mmusic-trickle-ice-sip-05, which is 
handled in MMUSIC.

Would it be more appropriate to restate your questions there?

Regards

Thomas

On 2016-10-04 15:29, Christer Holmberg wrote:
> 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
>
>
>
>
>>> But I believe that trickle ICE documents (in both ICE and MMUSIC 
>>> WGs) can be published without it and it can be published later as an 
>>>     I believe that removing candidates is very useful. Let me give
>>>     an example. With TURN mobility, it is possible to retain pairs
>>>     media flowing while looking for a better candidate pair. To
>>>     avoid loss of consent that would invalidate Pairs involving the
>>>     WLAN candidates, it is desirable to remove (and perhaps later,
>>>>     MMUSIC a question came up, if we need functionality for
>>>>     removing candidates.
>>>>
>>>>     >From list discussion in ICE, the minutes of the Berlin IETF and due to the lack of
>>>>     corresponding text in draft-ietf-ice-trickle-04, I have the

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 13:55:54 +0000

My apologies. My main issues were with that document :)

As far as I remember I don’t have any removal-of-candidate issues with the base document, but I’ll double check.

Regards,

Christer

From: Thomas Stach <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 4 October 2016 at 16:52
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Do we currently need functionality for removing candidates?

Christer,

the cited text is from draft-ietf-mmusic-trickle-ice-sip-05, which is handled in MMUSIC.

Regards

Thomas

Thanks!

Regards,

Christer

Regards,

Christer

Peter,

thanks!

Regards

Thomas

All,

Regards

Thomas