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

[Bernard Aboba <[e-mail]>]

Peter Thatcher said:

"​If the interface comes back after consent is lost (after many seconds),
then I think either an ICE restart or gathering new candidates (if
gathering isn't already complete) would be the right thing to do.  Do you
see a problem with that?"

[BA] What is in RFC 7675 seems ok.  But if a candidate is "removed" both
peers should have the same understanding of whether the same ICE
credentials can ever be used on the 5-tuple again.

Based on what is in RFC 7675, it appears that an immediate removal would
not automatically require new ICE credentials if the pair is subsequently
to be used.  However, if the receiving agent chose not to immediately
remove the pair and consent subsequently failed this would leave the
receiving agent believing that the pair was no longer usable without a
restart, while the sending side might believe it could be added back
without new ICE credentials. It is not clear to me whether the situation
would be different if the sending side revoked consent on the pair before
taking the interface down (e.g. whether consent revocation is equivalent to
consent loss in RFC 7675).



On Tue, Jul 12, 2016 at 10:14 AM, Peter Thatcher <[e-mail]>
wrote:

> Thanks for the grammar/spelling fixes.  I'll update those with quickly
> with a new draft version.
>
> On Tue, Jul 12, 2016 at 9:39 AM, Bernard Aboba <[e-mail]>
> wrote:
>
>> "Removal" and "Renomination" have both come up as implementation issues,
>> so these drafts seem useful to me.
>>
>> In the "removal" draft, I had questions about these paragraphs:
>>
>>    When a removal signal [is received], the Receiving Agent MUST NOT pair the Removed
>>    Candi[d]ates with any future candidates gathered by the Receiving Agent.
>>    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.
>>
>>    Why would an Receiving Agent choose not to immediately remove
>>    existing candidate pairs?  Because the Removing Agent MAY choose to
>>    keep the Removed Candidate capable of receiving ICE checks and
>>    sending responses so that any ICE checks already sent by the
>>    Receiving Agent may continue to work briefly so that media can flow
>>    as quickly as possible, even if over a candidate pair that will soon
>>    be discarded.
>>
>> [BA] When an interface is "going down", having the Receiving Agent not immediately remove existing candidate pairs can avoid a media glitch.
>>
>> However there are consequences to not removing the pair immediately because when the interface goes down, consent checks will subsequently fail and RFC 7675 Section 5.1 indicates that the pair cannot be used with the same ICE credentials, even if the interface comes up again:
>>
>>    After consent is lost, the same ICE credentials MUST NOT be used on
>>    the affected 5-tuple again.  That means that a new session, or an ICE
>>    restart, is needed to obtain consent to send on the affected
>>    candidate pair.
>>
>> One way to deal with this would be for the removing party to revoke consent before bringing the interface down.  However, that would only work if consent revocation was not considered the same as "consent is lost" in the above paragraph from RFC 7675.
>>
>> ​If the interface comes back after consent is lost (after many seconds),
> then I think either an ICE restart or gathering new candidates (if
> gathering isn't already complete) would be the right thing to do.  Do you
> see a problem with that?
>
>
>>
>> On Tue, Jul 12, 2016 at 7:35 AM, Peter Thatcher <[e-mail]>
>> wrote:
>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ice
>>>
>>>
>>
>