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

From: Peter Thatcher <[email-masked]>
Date: Fri, 8 Mar 2019 22:32:48 -0800

Sorry for the slow reply to this issue, but I wanted to think it through
thoroughly.  I started a new mail thread since there were already so many I
wasn't sure which was the right one and which people wouldn't notice mail
to.

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

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

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.

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"

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Mar 2019 16:06:07 +0000

Hi,

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

> 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:
>
> - Callee receives offer with no candidates, sets a timer of N seconds, and sends back an answer with several candidates
> 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.

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

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 11 Mar 2019 09:30:17 -0700

On Mon, Mar 11, 2019 at 9:06 AM Christer Holmberg <
[email-masked]> wrote:

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

> 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
>
> > - Callee receives offer with no candidates, sets a timer of N seconds,
> and sends back an answer with several candidates
>
> 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.

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