Re: [MMUSIC] non-SIP ICE: useful or not?

[Magnus Westerlund <[e-mail]>]

Jonathan Rosenberg skrev:
> I'd like to get some discussion going around this question prior to the 
> meeting. Please take a look at:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-ice-nonsip-01.txt 
> 
> 
> The main question: is a draft like this sufficiently useful to produce 
> or not? Given its main audience are the (relatively few) protocol 
> designers of things using ICE, there is an argument to be made we don't 
> really need this. I'd especially welcome comments from Miika, Magnus, 
> Hannes and other folks actually producing documents that would use the 
> contents here.
> 
> Comments on details welcome too, though secondary I think to the main 
> question.
> 

Okay, lets start with the main question.

I find this document quite useful as a guide to what points to think 
about. It takes some work to figure this out, even when one is quite 
used to ICE operations. I think it will help others that are talking the 
ICE route for NAT traversal.


Other comments:

- In section 2, the draft talks about the need for a rendezvous server. 
Looking at RTSP, it currently doesn't fulfill the requirement in this 
aspect. To get the full functionality to reach a server behind a NAT 
something like a RTSP proxy in which a server can register is one 
possible solution. In which case one would fulfill the requirements. I 
wonder if one should soften the wordings in the last paragraphs of 2 to 
also protocols that has more limited rendevous mechanisms but traversal 
problems for there direct traffic.

- Figure 2, has two "client 1"

- Section 3, isn't a goal to have reuse on the media plane when possible.

- Section 5.1.2: "However, they may be overly conservative
    for certain applications."

I think that this text should be rewritten to be a little less positive 
to respecifying the pacing parameters. I am quite okay that if one 
really have certain requirements that one discuss this.

- Section 5.1.3: I think that multiple STUN and TURN servers make more 
sense to talk about in the context of multihoming, than for multilayer 
NAT. This because of the inherent addressing problems in the 
intermittent layer with potentially overlapping private address spaces.

- Section 5.1.6: I actually think Capability Query is on of the better 
as it reduces the resource utilization for everyone. However, there are 
clearly cases when that round-trip may become problematic. But there are 
quite many cases where capability exchange can be done in registration 
and lookup phases of the signaling protocols.

- Section 5.3: I think that one should have some discussion on the 
possibility to use only triggered checks if one ICE agent always is 
reachable. Very similar considerations to the Lite deployment, but in 
this case with DDoS protection. First of all having that sender verify 
routability, and secondly to reduce the inherent risk ICE enabled server 
represent when actively initiating STUN connectivity checks.

- Section 5.4.1: In the RTSP context we have realized that depending on 
the general RTSP state it is optimal to use different type of 
nominations. When in a non-media sending state aggresive is better as we 
can use the RTSP PLAY signalling to determine when to start using the 
aggressively nominated candidates. When in a media sending state regular 
seems better to remove the glitches. Maybe something to add to the 
considerations.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic