Re: [MMUSIC] immortal candidates in ICE nombis

[Christer Holmberg <[e-mail]>]

Hi,

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