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

[Justin Uberti <[e-mail]>]

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).