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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jul 2008 09:20:34 -0400

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.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Adam Fisk" <[email-masked]>
Date: Fri, 18 Jul 2008 10:12:55 -0400

I definitely think this is useful.  To me, we need to standardize
NAT/firewall traversal for as many protocols as possible with as few
rewrites as possible.  ICE should be able to work with everything from
XMPP to JXTA to Flash Media Server rendezvous.  Deployments should
ideally be able to swap signaling/session protocols without touching
ICE, although I understand that's unlikely to happen.

In my case, I'm seriously considering swapping SIP for XMPP, and I'd
imagine that's a common scenario.

Best,
-Adam

On Fri, Jul 18, 2008 at 9:20 AM, Jonathan Rosenberg <[email-masked]> wrote:
> 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.
>

-- 
http://www.littleshoot.org
Open Source, Open Standards, Open Data
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Jul 2008 16:31:39 +0200

> Comments on details welcome too, though secondary I think to the main 

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 +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 21 Jul 2008 17:46:22 +0300

Le vendredi 18 juillet 2008 17:12:55 Adam Fisk, vous avez écrit :
> rewrites as possible.

Wait... this goes way beyond the scope of an ICE for non-SIP document... 
because it goes way beyond the scope of ICE.

No joking. If there were to be one standard way to do NAT traversal, that 
would be the client-server model. The server has a public IP, or at least a 
static unfirewalled public IP/port mapping. ICE requires a rendez-vous point. 
In particular, that is why I remain heavily unconvinced of the adequation of 
ICE for RTSP NAT traversal.

Now, I guess (I hope) you were refering to peer-to-peer NAT traversal. Even 
there, we need to keep in mind that ICE has advantages but also nasty 
disadvantages over other solutions, such as Teredo (an IETF standard as well) 
or UPnP (and NAT-PMP).

I don't know the requirements for MIP6 or HIP traversals, but I would expect 
Teredo to provide a lot more natural solution. And then, I wonder what to do 
with TCP (including... RTSP), with ICE-TCP dead-born :(

-- 
Rémi Denis-Courmont

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 01 Aug 2008 00:12:48 +0100

Unfortunately I'm flying out Friday morning before the session, but I 
want to state for the record that:

- as a reload co-author, I find this work very useful.  If it doesn't 
exist elsewhere (here), I will have to write/update/maintain/edit much 
of the same information separately anyway.
- I believe that given that there are at least two existence proofs for 
interested audience now, and a strong likelihood of later audience, I 
believe even two drafts that don't have to do this separately justifies 
creating a common source for the same knowledge.
- therefore I support adding this as a work item for mmusic
- I am willing to do work to see this happen.

Bruce