Subject: [MMUSIC] immortal candidates in ICE nombis

From: Emil Ivov <[email-masked]>
Date: Fri, 27 Mar 2015 11:23:16 -0500

One of the choices that ICE nombis will have to make is what to do with 
candidates that did not get used or that did not work. This is going to 
have important implications in terms of what gets signalled throughout a 
session so it is important to resolve this early on.

Therefore it would be important to get a sense on what the groups feels 
on the following question:

Would you mind if ICE applications NEVER released any candidates at all?

Answering "yes" to the above question would imply that devices would NOT 
be able to shut down radios or release TURN candidates. They'd have to 
keep everything alive.

I've personally heard people express energy and cost concerns and I've 
also heard others say that those aren't significant. So I'd be very 
curious to know what people here think.

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Mar 2015 12:42:06 -0700

Emil said: 
> candidates that did not get used or that did not work. 
[BA] "Did not work" or "stopped working" can be a temporary condition, but one that could stretch out over a substantial period of time.  For example, when you leave the coffee shop, the WLAN interface could go down and stay down until you become connected again.  
I believe that the "nombis" draft describes how that "now invalid" WLAN candidate can be removed, but not how it might be added back when it comes up again.  Would it be trickled again, and if so, in what circumstances?  
Answering this would also apply to other scenarios, such as the WWAN scenario where an interface is put to sleep.  Yes, the NAT bindings would not necessarily be kept up to date, so that the host, srvflx and relay candidates would expire.  That might be fine as long as there was another interface available that is working.  But when that other interface becomes shaky or goes down, it would be nice to be able to bring the WWAN interface back up, trickle the host, srvflx and relay candidates and bring it back up. 
> Would you mind if ICE applications NEVER released any candidates at all?
[BA] I would mind if it implied that all those candidates (and associated pairs) needed to be kept alive by sending traffic (and expending energy).  
> curious to know what people here think.

[BA] Rather than having a "general" discussion on this, I'd suggest it would be useful to understand how the proposal works in specific scenarios.  Personally, I'm most interested in understanding how "continuous nomination" works with interfaces going up and down over a long period of time.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Mar 2015 21:48:06 +0000

Hi,

>[BA] "Did not work" or "stopped working" can be a temporary condition, but one that could stretch out over >a substantial period of time.  For example, when you leave the coffee shop, the WLAN interface could go >down and stay down until you become connected again.
>
>I believe that the "nombis" draft describes how that "now invalid" WLAN candidate can be removed, but not >how it might be added back when it comes up again.  Would it be trickled again, and if so, in what >circumstances?
>
>Answering this would also apply to other scenarios, such as the WWAN scenario where an interface is put to >sleep.  Yes, the NAT bindings would not necessarily be kept up to date, so that the host, srvflx and relay >candidates would expire.  That might be fine as long as there was another interface available that is >working.  But when that other interface becomes shaky or goes down, it would be nice to be able to bring the >WWAN interface back up, trickle the host, srvflx and relay candidates and bring it back up.
>
>[BA] I would mind if it implied that all those candidates (and associated pairs) needed to be kept alive by >sending traffic (and expending energy).
>
>[BA] Rather than having a "general" discussion on this, I'd suggest it would be useful to understand how the >proposal works in specific scenarios.  Personally, I'm most interested in understanding how "continuous >nomination" works with interfaces going up and down over a long period of time.
Note the following text in the consent freshness draft:

        "After consent is lost for any reason, 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."

So, if you are using cons fresh, doesn't that mean that, even if the candidate "comes back" you can't use it without an ICE restart?

Because, the cons fresh draft does not seem to recognize the case of a candidate becoming "invalid" - it assumes that if there is no STUN reply then consent has expired.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 Mar 2015 15:19:09 -0700

Christer said: 
Note the following text in the consent freshness draft:         “After consent is lost for any reason, 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.” So, if you are using cons fresh, doesn’t that mean that, even if the candidate “comes back” you can’t use it without an ICE restart? Because, the cons fresh draft does not seem to recognize the case of a candidate becoming “invalid” – it assumes that if there is no STUN reply then consent has expired.
[BA] Thanks for pointing this out.  Reading it and other related text in the consent freshness document (see below), it is not clear to me that it applies to interfaces that are taken out of service prior to the expiration of consent (e.g. make before break).  On the other hand, the consent-freshness timing (30 seconds) is consistent with intervals typically used to detect failure (e.g. WLAN re-transmission timers typically implemented, as opposed to those recommended in the IEEE 802.11 specification), so it is quite possible that the interface would not be marked down until after consent is considered revoked.  
As a result, while consent-freshness might not be considered a constraint in switching from WWAN to WLAN (e.g. detect WLAN, bring it up and switch over before the WWAN interface exhibits problems just because WLAN is typically faster), the opposite case (e.g. leaving the coffee shop, detecting eminent loss of WLAN and bringing up WWAN) might not work without an ICE re-start.   Don't think that is necessarily the end of the world, though, especially given some of the typical delays in such a scenario.  
BTW, the consent freshness draft has some other related text, such as: 
   Initial consent to send traffic is obtained using ICE.  Consent
   expires after 30 seconds.  That is, if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.  STUN consent responses
   received after consent expiry do not re-establish consent, and may be
      discarded or cause an ICMP error.....
   Consent expiration causes
   immediate termination of all outstanding STUN consent transactions.
[BA] The reason for this advice is not articulated in the draft.  Perhaps it has to do with ensuring that consent will be revoked in event of a denial of service attack that might delay arrival of consent responses for a significant period.  But again, I don't think it prohibits taking an interface out of service while consent freshness is still functioning.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Mar 2015 22:45:31 +0000

Hi,

>So, if you are using cons fresh, doesn't that mean that, even if the candidate "comes back" you can't use it without an ICE >restart?
>
>Because, the cons fresh draft does not seem to recognize the case of a candidate becoming "invalid" - it assumes that if >there is no STUN reply then consent has expired.
>
>[BA] Thanks for pointing this out.  Reading it and other related text in the consent freshness document (see below), it is not >clear to me that it applies to interfaces that are taken out of service prior to the expiration of consent (e.g. make before >break).  On the other hand, the consent-freshness timing (30 seconds) is consistent with intervals typically used to detect >failure (e.g. WLAN re-transmission timers typically implemented, as opposed to those recommended in the IEEE 802.11 >specification), so it is quite possible that the interface would not be marked down until after consent is considered >revoked.
>
>As a result, while consent-freshness might not be considered a constraint in switching from WWAN to WLAN (e.g. detect >WLAN, bring it up and switch over before the WWAN interface exhibits problems just because WLAN is typically faster), >the opposite case (e.g. leaving the coffee shop, detecting eminent loss of WLAN and bringing up WWAN) might not work >without an ICE re-start.   Don't think that is necessarily the end of the world, though, especially given some of the typical >delays in such a scenario.
>

>
>[BA] The reason for this advice is not articulated in the draft.  Perhaps >it has to do with ensuring that consent will be revoked in event of a >denial of service attack that might delay arrival of consent responses >for a significant period.  But again, I don't think it prohibits taking >an interface out of service while consent freshness is still functioning.

I for sure think it would be good to not having to send consent requests on candidates that are currently not used (for whatever reason) for sending data/media.

But, assume you would take an interface out of service, and stop sending consent requests from the associated candidate. The remote endpoint does not know what you did - it will keep sending consent requests to that interface, and revoke consent when it doesn't get any replies.

Of course, the remote endpoint could be smart enough and, once it starts receiving consent requests from the interface again, also start re-sending consent requests to that interface itself, and retrieve new consent. But, such behaviour is not defined in the consent freshness draft.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 Mar 2015 16:10:23 -0700

On Mar 29, 2015, at 3:45 PM, Christer Holmberg <[email-masked]> wrote:
> But, assume you would take an interface out of service, and stop sending consent requests from the associated candidate. The remote endpoint does not know what you did - it will keep sending consent requests to that interface, and revoke consent when it doesn’t get any replies.

[BA] Yes - which is why there needs to be a way to indicate that the candidate has been removed (e.g. The timeout == 0 indication Justin spoke about). 

> Of course, the remote endpoint could be smart enough and, once it starts receiving consent requests from the interface again, also start re-sending consent requests to that interface itself, and re…

[BA] Prior to the consent expiration that might work. But afterward even absent the draft language the lack of NAT binding maintenance would likely become a problem preventing 
one side from restarting things by itself.  In that case the candidate would need to be trickled again, which is not possible without an ICE restart today.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Mar 2015 23:29:29 +0000

Hi,
 
>>I for sure think it would be good to not having to send consent requests on candidates that are currently not used (for >>whatever reason) for sending data/media.
>>
>>But, assume you would take an interface out of service, and stop sending consent requests from the associated >>candidate. The remote endpoint does not know what you did - it will keep sending consent requests to that interface, and >>revoke consent when it doesn’t get any replies.
>
>[BA] Yes - which is why there needs to be a way to indicate that the candidate has been removed (e.g. The timeout == 0 >indication Justin spoke about). 

Shouldn't it be enough to send consent requests on *one* of the candidate pairs associated a virtual connection - instead of having to send on each associated candidate pair? Then, if an interface is taken out of service, you simply switch to another candidate pair. Similar, if you don't receive consent responses from the remote endpoint (e.g. because it has taken the interface out of service) you simply try another candidate pair.

(Keep-alives of course need to be sent on each candidate pair, in order to maintain NAT bindings.)

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 Mar 2015 16:56:43 -0700

> (Keep-alives of course need to be sent on each candidate pair, in order to maintain NAT bindings.)

[BA] I sent a similar comment earlier.  While testing all pairs you want to keep alive ensures consent, it is also expensive in terms of energy consumption.  The question is what is required to keep NAT bindings open, assure consent, and verify connectivity prior to a switch if all desired live pairs are not tested. 

You cannot just switch to another candidate pair if there is no indication the remote candidate is still live (e.g. No recent response to a consent check from any local candidate, no indication via a timeout attribute that it is still alive, etc.)  At a minimum re-trickling the local candidates you want to re-use would be needed, to restart pair formation and testing after the candidate pair was pruned.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Mar 2015 10:04:22 +0000

Hi,

>> Shouldn't it be enough to send consent requests on *one* of the candidate pairs associated a virtual connection - instead of having to send
>> on each associated candidate pair? Then, if an interface is taken out of service, you simply switch to another candidate pair. Similar, if you 
>> don't receive consent responses from the remote endpoint (e.g. because it has taken the interface out of service) you simply try another candidate pair.
>>
> [BA] I sent a similar comment earlier.  While testing all pairs you want to keep alive ensures consent, it is also expensive in terms of energy consumption.  
> The question is what is required to keep NAT bindings open, assure consent, and verify connectivity prior to a switch if all desired live pairs are not tested. 
>
> You cannot just switch to another candidate pair if there is no indication the remote candidate is still live (e.g. No recent response to a consent check from 
> any local candidate, no indication via a timeout attribute that it is still alive, etc.)  At a minimum re-trickling the local candidates you want to re-use would be 
> needed, to restart pair formation and testing after the candidate pair was pruned.

I agree that there needs to be *A* way to determine whether a remote candidate is still alive before the switch. The keep-alive does not provide that information, as there are no responses to the keep-alive requests. Also, we cannot assume that STUN requests are received from the remote candidate, as it may belong to an ICE lite endpoint.

Perhaps one way would be to send consent requests on all candidate pair, but less frequent on candidate pairs currently not used for sending data?

Regards,

Christer