Re: [MMUSIC] Notes from Continuous Nomination discussion

[Emil Ivov <[e-mail]>]

Hey Pal,

On 11.11.14, 20:35, Pal Martinsen (palmarti) wrote:
>
>> On 11 Nov 2014, at 00:47, Justin Uberti <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> One other note - although Dan wasn’t present, the consensus was that
>> the continuous nomination solution provides an effective solution to
>> the ICE issues raised in draft-singh-avtcore-mprtp,
>> draft-wing-ice-mobility, and draft-williams-peer-redirect.
>
> Regarding MICE.
>
> The main goal there is to try out any of the old remote candidates
> before you actually trickle your new local candidates.

As discussed off-list I am in favour of this, provided we focus on the 
right use case. (more below)

> There is a chance
> that the old NAT binding on the remote side might work if the NAT is of
> the type “good”.

I think you are asking for more than a "good" NAT. Normally NATs with 
endpoint-dependent filtering are considered "good" as long as they don't 
do endpoint-dependent mapping.

You are asking for NATs that don't do filtering and let anyone come in 
on an existing binding. I haven't seen NATs behave this way in years ... 
unless they had been manually configured with port-forwarding. Even if 
the NAT does allow packets to come in, the FW features in many modern 
OSes would drop them.

So I think there is really little incentive to optimize for that use 
case (i.e., the one where both nodes are behind NATs).

That said, the same optimization also solves the case of a mobile node 
talking to a media service (e.g., a multi-party video conferencing 
application).

In that case it is also much more reasonable to expect that all original 
candidates would be kept alive. Very often those would be limited to the 
in-use UDP candidates and potentially a shared TCP host candidate using 
port 443. In other words, they would likely be in-use regardless and 
there won't be any resource wasting involved.

I think that use case is definitely worth optimizing. I also think the 
entire draft would be much easier to define if it focuses on this use case.


> Idea is to get media flowing without the use of the
> signalling channel.

This comes down to allowing peer-reflexive candidates to be discovered 
at any point of the communication. I believe that stated this way, the 
problem is relatively easy to solve.

Emil

>  The trickling of the new local candidates should
> happen in parallel.
>
> We will update the draft to fit into the continuous nomination and
> trickle scheme once the dust settles.


>
> .-.
> Pål-Erik
>
>>
>> On Tue, Nov 11, 2014 at 1:44 AM, Justin Uberti <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Several of us (Bernard, Jonathan, Varun, Martin, Brandon, Pal) met
>>     today to discuss the goals for the work to improve ICE nomination.
>>
>>     In short, there was good consensus that the goals outlined in
>>     http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html
>>     (updated since the meeting)
>>     are the correct goals to be shooting for, even if the exact
>>     mechanisms aren't completely nailed down. We think the goals
>>     enumerated by Emil in his email earlier this week are all covered
>>     by the goals in this document.
>>
>>     It also seemed reasonable to adopt the work to merge Regular and
>>     Aggressive Nomination in ICE-bis, and have the Continuous
>>     Nomination change be its own document. While there was some
>>     interest in figuring out how ICE could support multiple selected
>>     pairs simultaneously, this was agreed to be out of scope for now.
>>
>>     We can discuss more in the WG meeting; Ari, can you set aside some
>>     agenda time?
>>
>>
>

-- 
https://jitsi.org