Re: [MMUSIC] Faster ICE by role reversal?

[Emil Ivov <[e-mail]>]

On 9.11.14, 20:29, Martin Thomson wrote:
> On 9 November 2014 09:41, Bernard Aboba <[e-mail]> wrote:
>> For example, say two peers are initially on the same WiFi LAN so that host candidate checks work.  As a result, there is no reason for either peer to keep unused relay candidates. Media is flowing, then one peer senses WiFi signal strength decreasing so it brings up an LTE interface. While it can trickle the new host, srflx and relay candidates, the other peer no longer has functioning relay candidates so the checks could fail.  While the peer could have kept its LTE interface hot all along and used it to ensure that the other peer kept its relay candidates that would have a high cost in terms of energy usage.
>
>
> I think that this is the key problem.  And we need to start to
> concentrate on the properties that we are looking for, rather than
> looking dogmatically at one solution or other.  We need clear rules
> (or an acknowledgment that there is a policy decision) around when a
> given candidate can be released.  We probably also need rules or
> mechanisms to support a reduction in testing of candidate pairs.
>
> Emil's suggestion that you have some sort of explicit marker to
> declare candidates dead or unusable is definitely worthwhile.  I
> wonder if that's not better suited to something on the media path
> though.

So how about the following:

1. Ability for ICE to yield multiple paths
2. The ability to use these paths simultaneously or exclusively
3. Switching between available paths with no non-ICE signalling
4. (?) If paths are used exclusively, the ability for either path to do 
a switch (we may want to limit this to switches that only change the 
local candidate and not the remote one.
5. As interfaces come up: ability to add new candidates without 
disrupting ongoing communication
6. As interfaces go down: ability to update without disrupting the 
communication (well ... to whatever extent that is possible).

I think those are the main set. And then there's also one that is more 
MICE-specific:

7. In the case of a mobility event: the ability to attempt to quickly 
recover at least partial connectivity (as opposed to restoring all paths).

I think the value that MICE brings here, and that is not addressed by 
points 1-6 is that it optimizes cases where a NATed mobile node is 
talking to a public media server (e.g., a tablet in a 
WebEx/Hangouts/Jitsi Meet conference). In those cases, MICE allows the 
mobile conference participant to move to a new location and just 
continue streaming to the media server. The server would latch onto the 
new address of the mobile and the disruption time would be very low.

The reason I kept it as a separate item is because it has different 
constraints than regular ICE updates. It is an optimization for some 
cases. It tries to recover any form of connectivity as quickly as 
possible in order to reduce handover latency. Period.

There are many cases where this specific MICE optimization wouldn't work 
(e.g., when both peers are behind common types of NATs) but this is not 
a problem since MICE would then do a proper update through signalling 
anyway (e.g., an ICE restart) in order to re-establish other paths of 
communication or cover the cases that didn't connect with the optimization.

Dan, Pal, Tiru, is the above summary correct?

If so, I think we have the option of addressing this case separately. 
The following is vague but, for example, we could allow for 
peer-reflexive candidates to be discovered at any point, with the 
possibility to replace a pre-existing path.I am not even sure we need 
the extra ICE attributes defined by MICE in that case ... but I am 
likely missing something.

Anyways, the importance here is that agents would not attempt to pair 
these late peer reflexive candidates anything else than the address that 
they were received on. They would just latch onto them and do nothing 
else until a restart is triggered.

Thoughts?

Emil

-- 
https://jitsi.org