Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin

On Tue, Jul 12, 2016 at 2:20 PM, Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> Peter said:
>
> "The real question is whether the removing agent needs to know whether
> the receiving agent is going to do anything with the signal.  And since
> everything will continue to work even if the receiving agent ignores the
> signal (simply with some perhaps wasted resources), then it's not necessary
> for negotiation at all."
>
> [BA] The removing agent only needs to know if the receiving agent
> understands removal if that will make a difference in subsequent behavior.
> If a removed candidate will never be re-added, I don't think it matters,
> because a receiving agent not understanding removal will eventually figure
> out that the removed candidate is inactive, and that pairs involving the
> removed candidate are unusable. But if it is desired to be able to re-add a
> removed candidate without an ICE restart, then it might make a difference.
>

That's a good point about re-adding a candidate.  But isn't the question
of re-adding a candidate also relevant to normal trickle, independent of
removal?  For example, what happens if I re-trickle a candidate to you
after you lose consent for a candidate pair with that candidate?  Does that
allow you to re-establish consent?

>
> On Tue, Jul 12, 2016 at 10:21 AM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>>
>>
>> On Tue, Jul 12, 2016 at 10:07 AM, Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> The text says:
>>>
>>>
>>>
>>> “The Receiving Agent MAY keep the existing candidate pairs that use
>>>
>>>               the Removed Candidates and behave as though the Removed
>>> Candidates
>>>
>>>               had not been removed for those candidate pairs.”
>>>
>>>
>>>
>>> What is meant by “behave”? Sending keep-alives? Sending media? That will
>>> obviously not work.
>>>
>>
>> Both keep-alives and media.  If the removed candidate is a TURN
>> candidate that the removing agent wishes to deallocate, it may work for a
>> short period of time before the removing agent actually deallocates it.  So
>> the Receiving Agent may choose to keep sending media until it finds a
>> different candidate pair to use instead.   Or it may not.
>>
>>
>>>
>>>
>>> I think it would be good to state wether the usage/support of the
>>> mechanism must be negotiated before it is used.
>>>
>> 
>> 
>> Signaling the removal of candidate never does any harm, so I don't see a
>> need in negotiating that your going to signal removal (modulo a specific
>> signaling protocol needing to figure out how to send new messages if it
>> chooses to do so).  The real question is whether the removing agent needs
>> to know whether the receiving agent is going to do anything with the
>> signal.  And since everything will continue to work even if the receiving
>> agent ignores the signal (simply with some perhaps wasted resources), then
>> it's not necessary for negotiation at all.
>>
>> You are correct that this should be clear in the draft.  I will add it.
>>
>>
>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter Thatcher
>>> *Sent:* 12 July 2016 17:35
>>> *To:* ice@ietf.org
>>> *Subject:* [Ice] I submitted and plan to present
>>> draft-thatcher-ice-remove-candidate in Berlin
>>>
>>>
>>>
>>> I submitted draft-thatcher-ice-remove-candidate and would like to speak
>>> about in my allotted time on the agenda when I will also be speaking about draft-thatcher-ice-network-cost
>>> and draft-thatcher-ice-renomination.
>>>
>>>
>>>
>>> It's a very simple draft. Basically it says you can "remove" candidates
>>> just like trickle-ice allows you to add candidates. You could probably read
>>> it in 3 minutes. Please do so:
>>>
>>>
>>>
>>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Peter (Chair hat off)
>>>
>>
>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>
>>
>