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

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 29 Jul 2008 03:40:29 -0600

Find my thoughts inline (marked with [S])...

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? 

[S] I think it is useful.

<snip>

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

[S] There are deployments where SIP-based architectures also plan (or
need) to support non-SIP clients. In such cases, it will be useful to
employ a single NAT traversal mechanism which will facilitate the reuse
of the existing infrastructure (with minimal changes). 

- S

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 13:29:23 +0300

Can you tell us why you think it is useful?
In what way did it help you?

Sumanth Channabasappa wrote:
> 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
>  
>
> employ a single NAT traversal mechanism which will facilitate the 
> reuse of the existing infrastructure (with minimal changes).
>
>  
>
> - S
>
>  
>  
>
>  
>
> ------------------------------------------------------------------------
>

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 29 Jul 2008 04:36:31 -0600

Hannes,

Can you tell us why you think it is useful?
In what way did it help you?
[S] Are you asking for more details on what I added earlier regarding
its usefulness, reproduced below (or did you miss it)? 

- S

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 13:41:02 +0300

I missed that part.

There aren't too many standardized protocols other than SIP and XMPP 
being used. XMPP already uses ICE.
For whom would that document be?

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 29 Jul 2008 06:47:34 -0600

I was thinking about two types of clients that would benefit from this:
clients using communication mechanisms such as RESTful web services
(HTTP for outgoing and incoming messages), and media clients for session
establishment (peer-to-peer or peer-to-network element). 

(When SIP-based deployments support such clients, it would be good to
reuse the same NAT traversal mechanism and components.)

- S 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 11:41 AM
To: Sumanth Channabasappa
Cc: [email-masked]
Subject: Re: [MMUSIC] non-SIP ICE: useful or not?

I missed that part.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 16:05:08 +0300

Did someone tried to chat with folks working in this application space 
whether they care about the work we do here?

Producing documents for unknown customers can often be challenging.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jul 2008 16:45:25 +0300

On Tuesday 29 July 2008 15:47:34 ext Sumanth Channabasappa, you wrote:
> (HTTP for outgoing and incoming messages),

ICE will not work with anything remotely close to HTTP.

> and media clients for session establishment (peer-to-peer

I think Hannes is asking *what* specifically.

> or peer-to-network element).

Using ICE for peer-to-network is silly. Plain dumb client-to-server hole 
punching will work always, with much less effort from the network, and much 
less complexity on the client.

> (When SIP-based deployments support such clients,
> it would be good to reuse the same NAT traversal mechanism and components.)

You seem to suffer from a widespread misconception that ICE solves *all* NAT 
traversal problems. ICE only solves NAT traversal for UDP-based protocol this 
far, which excludes, say HTTP. ICE only solves NAT traversal when there is a 
pre-existing full-duplex signaling protocol between nodes, excluding say RTSP 
and similar protocols.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miika Komu <[email-masked]>
Date: Tue, 29 Jul 2008 14:53:47 +0100

Rémi Denis-Courmont wrote:

Hi,

> ICE will not work with anything remotely close to HTTP.

Could you elaborate please? I though there was also a TCP-based ICE version.

> pre-existing full-duplex signaling protocol between nodes, excluding say RTSP 

That's were HIP NAT traversal comes into play. There we have the 
application (TCP/UDP) traffic encapsulated inside UDP-ESP traffic.

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 29 Jul 2008 07:58:32 -0600

...

Using ICE for peer-to-network is silly. Plain dumb client-to-server hole 
punching will work always, with much less effort from the network, and much 
less complexity on the client.
[S] Ok, I should have been clear with my terminology. When I said peer-to-network, I was speaking about potential network-provided-clients (e.g., web client) that can be behind a NAT as well.

You seem to suffer from a widespread misconception that ICE solves *all* NAT 
traversal problems. ICE only solves NAT traversal for UDP-based protocol this far, which excludes, say HTTP. 
[S] I am not saying that ICE solves everything. I was offering my take on whether the work is useful, and provided an *example* as to where this has been discussed by application vendors. 

ICE only solves NAT traversal when there is a pre-existing full-duplex signaling protocol between nodes, excluding say RTSP  and similar protocols.
[S] Yes, but that does not mean that the pre-existing full-duplex signaling protocol has to be SIP. Are we opposed to using ICE outside of SIP (perhaps I am missing something)? 

...

- S

---

From: Ari Keranen <[email-masked]>
Date: Tue, 29 Jul 2008 15:00:12 +0100

Hi,

> For whom would that document be?

I think this document is and will be useful. If someone comes up with a 
new network protocol, foo, it quite likely needs at least *some* NAT 
traversal mechanism. One could come up with a new traversal mechanism 
for foo, which would likely be inferior to ICE, or simply re-use the 
effort used for creating ICE with the guidance from the non-sip draft.

And at least I find this guidance useful since when someone reads the 
ICE draft the first time, he's likely overwhelmed with the amount of 
details (and/or page count) without realizing that many of them are 
there just because of some features of SIP. An also there's the issue 
with the timers in non-RTP scenarios that I would like to see getting 
more attention and this draft would be a good place for it.

As a side note, I think it would make more sense to do the whole NAT 
traversal at a lower layer, but before everybody sees the light and 
starts using something like HIP, this kind of draft is needed.

Cheers,
Ari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 17:32:50 +0300

We shouldn't write documents with the intention that it might be useful 
for someone, maybe sometime in the future.  In case that folks would do 
that then publish such a document. I wouldn't do that I would just work 
with them. This is also scalable given that these type of session 
establishment protocols aren't published on a monthly basis.

Ari Keranen wrote:
> I think this document is and will be useful. If someone comes up with 
> a new network protocol, foo, it quite likely needs at least *some* NAT

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jul 2008 08:41:41 -0600

> being used. XMPP already uses ICE.

Instead of thinking about hypothetical uses of ICE by hypothetical 
signalling protocols, perhaps it would be more useful for folks to first 
review the XMPP usage of ICE:

http://www.xmpp.org/extensions/xep-0176.html

(Indeed, we're close to finishing work on the Jingle suite of specs, so 
if you have extra time you could review them all -- we'll be publishing 
updated versions in the next few days based on the XMPP Summit we held 
last week.)

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 18:00:00 +0300

That's exactly what I am saying.
Instead of writing things for folks we don't know let's chat with the 
guys we know and review their work.
Much better time investment.

Peter Saint-Andre wrote:
> signalling protocols, perhaps it would be more useful for folks to 
> first review the XMPP usage of ICE:
>
> (Indeed, we're close to finishing work on the Jingle suite of specs, 
> so if you have extra time you could review them all -- we'll be 
> publishing updated versions in the next few days based on the XMPP 
> Summit we held last week.)
>
> Peter
>
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jul 2008 17:54:50 +0300

> Could you elaborate please? I though there was also a TCP-based ICE

There is a thread in BEHAVE on this.

ICE-TCP just does not work with a large proportion of existing NATs, and a 
majority of statefull firewalls.

> application (TCP/UDP) traffic encapsulated inside UDP-ESP traffic.

No disagreement, but I don't think that's what Sumanth is referring to, 
failing to refer to.

---

From: Ari Keranen <[email-masked]>
Date: Thu, 31 Jul 2008 17:56:20 +0100

Hi,

Actually, I think we should make our protocols, if possible, generic and 
understandable enough so that they might be useful for someone, maybe 
sometime in the future, too. And ice-non-sip can help achieving this.

Especially if someone who is not active in the IETF creates a new 
protocol that needs NAT traversal, he will not likely be sending 
requests to the IETF mailing lists asking for this kind of document.

Cheers,
Ari