Re: [Ice] Thoughts on the "remote side gives 0 candidates" issue

[Justin Uberti <[e-mail]>]

Tracking the points raised here in
https://github.com/cdh4u/draft-ice-pac/issues/9 and
https://github.com/cdh4u/draft-ice-pac/issues/8


On Mon, Mar 11, 2019 at 9:30 AM Justin Uberti <[e-mail]> wrote:

>
>
> On Mon, Mar 11, 2019 at 9:06 AM Christer Holmberg <
> [e-mail]> wrote:
>
>> Hi,
>>
>>
>>
>> > Anyway, here's what I've thought of so far:
>>
>> >
>>
>> > 1.  Yes, these all are issues (the 3 scenarios described
>> in draft-holmberg-ice-premature.xml) for a strict ICE impl that is what you
>> might call "impatient".
>>
>>
>>
>> Ice will melt if you wait too long… ;)
>>
>>
>>
>> > 2.  I'm guessing that in practice all ICE impls will have some timeout
>> (be "patient"), but I agree that writing that down in an RFC is a good idea.
>>
>> >
>>
>> > 3.  Doing it in the ICE WG makes sense.
>>
>> >
>>
>> > 4.  I'd prefer to call it "ICE patience" or "Patient ICE" rather than
>> "no premature failure".  Then it's a virtue rather than a lack of a problem
>> :).
>>
>>
>>
>> So, just to clarify, you suggest “Interactive Connectivity Establishment
>> (ICE) Patience” as the title, not only in the draft name?
>>
>>
>>
>> Works for me.
>>
>>
>>
>> > 5.  The current draft says "MUST wait for" and "N SHOULD be X".  But
>> together, that amounts to "SHOULD wait for X", so the whole
>>
>> > RFC ends up being a big SHOULD.  Is that normal for an RFC to only
>> have SHOULDs and not MUSTs?  Seems less meaningful because
>>
>> > you can't rely on the remote side doing the right thing.
>>
>>
>>
>> We did not want to mandate a specific duration. An endpoint can determine
>> the duration value based on many things, including the number of candidates
>> it provides and/or the number of streams, the reliability of the network
>> (see below) etc etc etc.
>>
>
> This is a reasonable point. We could say that the implementation MUST wait
> for enough time to receive peer-reflexive candidates. This value SHOULD be
> the local connectivity check timeout.
>
>>
>>
>> > 6.  The more I think about the timeout should be, the more I think this
>> problem is bigger than the issues outlined in the draft.
>>
>> > If you have very slow signaling, it's possible that you will end up in
>> this same situation regardless of how many candidates are
>>
>> > signaled (since the slow signaling prevents the candidates from
>> getting there).    For example:
>>
>> >
>>
>> > - Caller initiates ICE with no candidates
>>
>> > - Callee receives offer with no candidates, sets a timer of N seconds,
>> and sends back an answer with several candidates
>>
>> > - Caller receives candidates after N seconds and sends connectivity
>> checks
>>
>> > - Callee times out and goes to failed state
>>
>> > - Callee receives connectivity checks, but it's too late
>>
>> >
>>
>> > To avoid this problem, the timeout the callee uses must be based on the
>> expected signaling delay.  So, I think our "SHOULD be X" should
>> incorporate signaling delay"
>>
>
>>
>> Absolutely. We can for sure add more guidance regarding things an
>> endpoint has to take into consideration when setting the N value.
>>
>
> Maybe, but this number will never be precise. The connectivity check
> timeout itself is fairly arbitrary, but large enough to effectively address
> the problem. The existing text has a mention of this.
>
>>
>>
>> > 7.  I wonder if we should include a suggested workaround for RFC 8445
>> clients that are "impatient".  For example, if you trickle, do not
>>
>> > send "end-of-candidates" to the remote side until after N seconds (to
>> prevent it from going to the failed state).
>>
>>
>>
>> Note that the draft text only covers the case when an endpoint receives
>> candidates, discards all of them, and waits for peer-reflexive candidates
>> to arrive. These could be initial candidates, or trickled candidates.
>>
>>
>>
>> But, when it comes to trickle, and how long an endpoint waits for the
>> peer to SIGNAL additional candidates, I think that shall be covered in
>> trickle.
>>
>
> TBH, I think it sort of invalidates end-of-candidates, since it's now
> clear that you can't start pruning upon receiving end-of-candidates. We
> might just want to never send it (and perhaps remove it in a future
> revision).
>