Re: [MMUSIC] Faster ICE by role reversal?

On Sun, Nov 9, 2014 at 11:22 AM, Emil Ivov <emcho@jitsi.org> wrote:
>
>
> On 9.11.14, 20:29, Martin Thomson wrote:
>>
>> On 9 November 2014 09:41, Bernard Aboba <bernard_aboba@hotmail.com> 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

do you mean: switching between paths with ICE signalling?

In the case of MPRTP, the scheduling algorithm/congestion controller
can make the decision on which paths to use.
However, if it is single RTP, then switching from one to another makes sense.

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

+1 for the rest.

> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
http://www.netlab.tkk.fi/~varun/