Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16

[Flemming Andreasen <[e-mail]>]

On 10/24/11 2:06 PM, Hadriel Kaplan wrote:
> On Oct 17, 2011, at 9:58 PM, Flemming Andreasen wrote:
> [snip]
>    
>>   Again, to recap the concerns with the old approach:
>> - We have a general and Standards Track NAT traversal solution in the form of ICE so we should use it
>>      
> And we are - the loopback draft explicitly says to do ICE if both sides can do so.  It doesn't ignore ICE.  The question is if the loopback draft can also say what to do if ICE isn't supported. (and no, saying "well then go support ICE" isn't an option for the reasons explained previously in the email threads)
>
>    
I'm not sure which previous part you are referring to since many 
different points have been made by different people.

However, can we change the above to say that loopback implementations 
MUST still support ICE, but then add text/procedures around what to do 
in case ICE procedures cannot be used per the points made by Emil in 
http://www.ietf.org/mail-archive/web/mmusic/current/msg08788.html, or 
are you objecting to the "MUST support ICE" part ?

>    
>> - If there is a need for an ICE alternative, then we need to discuss that more generally and come up with a proper solution
>> - If latching is indeed needed as an alternative solution to ICE, then it needs to be properly documented and the limitations of it spelled out clearly. Furthermore, the loopback draft does not seem like the right place for this.
>>      
> You make it sound like latching is some new thing - it's not - it's been around since long before ICE.  I don't disagree it's not documented in an RFC, though it is somewhat documented in draft-ietf-mmusic-media-path-middleboxes.
>    
We'll need more than that I think. As I've stated before, we have asked 
the working group on multiple occasions if there is interest in 
exploring alternatives to the ICE NAT traversal mechanisms (e.g. 
latching) and then get those discussed and documented properly. So far, 
we haven't seen any takers (and no, the loopback draft is not the right 
place to put it since it needs proper attention and discussion).

> But I'm not sure latching even needs to be documented for loopback-draft to state something like "send packet out".  Something like what Dan Wing suggested here:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html
>    
We are going in circles here. Dan's proposed text was:
<quote>

   "If the network is using media latching, the endpoint MUST emit
    a UDP packet (in order for media latching to work) towards the
    remote endpoint and it SHOULD send several packets to accommodate
    packet loss.  If the network is using ICE or media latching, the
    endpoint SHOULD emit packets every 15 seconds to accommodate
    stateful middleboxes (e.g., NATs) [RFC6263]."

</quote>

Again, media latching needs to be discussed and documented properly if 
you want to reference it, and it cannot be part of the loopback draft. 
Example questions that come to mind here:
- How does an endpoint know the "network" is using latching and hence 
whether to send this UDP packet or not ?
- Is the remote endpoint involved in this latching operation, and if so 
what does it need to do ?
- Under what circumstances should you use this media latching mechamism ?

We need something more solid to reference to move us forward, or some 
alternative concrete text proposal to the above that doesn't lead to 
open questions, e.g. along the lines of Emil's proposal, (however I'm 
not sure it goes to the extent that you are looking for in terms of 
removing ICE dependencies, but you tell me).

Thanks

-- Flemming


> -hadriel
>
>
>