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

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 <bernard.aboba@gmail.com>
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 <pthatcher@google.com>
> 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
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>
>>
>