Subject: [MMUSIC] New I-D on ICE for non-SIP protocols: NICE

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2008 14:48:09 -0500

I just submitted:
http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-ice-nonsip-00.txt

This basically defines a subset of ICE for usage with other non-SIP, 
non-offer-answer protocols. It defines its own object for conveying in a 
protocol to carry the candidate parameters, and throws out a bunch of 
stuff in ICE that is there for O/A. For example, a=remote-candidates, 
updated offer/answers, multiple streams.

Comments welcome.

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]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Feb 2008 09:38:12 +0200

> updated offer/answers, multiple streams.

Looks like an excellent idea to me, as SIP really made ICE overly intricate.

I wonder if this would work for RTSP-NAT by the way - I think it would, 
provided that:
- rtcp-mux is mandated when doing (N)ICE,
  so that there is no need for multiple components,
- multiple medias are negociated one by one, via separate SETUP requests
  or whatever, so they're effectively independent (N)ICE sessions.

Other obvious protocols to try to port would be IPsec-in-UDP and Teredo, but 
backward compatibility is likely to be a major problem there.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Feb 2008 18:03:31 +0100

Hi,

Jeff and I are currently active working on provided a new version of
RTSP-NAT specification with much more details on how to use ICE. We have
so far realized a few things about what cuts can and can not be made.

>   or whatever, so they're effectively independent (N)ICE sessions.

But defining it in such a way are likely to result in a more chatty
solution with increase server load and the only benefit a simplified
specification.

Looking at NICE changes and its motivation in the context of RTSP
quickly results in that most of the ICE O/A mechanisms still are needed:

>    o  ICE has the notion of a default candidate.  This default candidate
>       is used for backwards compatibility with pre-ICE SIP
>       implementations.  That mechanism is very specific to SDP backwards
>       compatibility techniques, and is not used here.  Instead, if the
>       protocol using NICE requires backwards compatibility, it needs to
>       define its own mechanisms for such.

Well RTSP requires some type of backwards compatibility. Yes, one can
probably remove the default candidate due to that one can use a feature
tag and "required" and "proxy-required" header to ensure that the
functionality is present in the whole RTSP signalling chain. However, to
get through non ICE aware proxies we are likely to need to use a default
address anyway. However, I expect to be able to detect ICE unaware
proxies.

> 
>    o  ICE supports the notion of updated offers and answers that can
>       modify information.  Indeed, it requires such an update when the
>       pair selected by ICE does not match the default.  The notion of
>       default has been removed in NICE, as has the ability to update the
>       ICE information.  This update allowed for mid-call changes in
>       connectivity, a frequent occurrence in events like call transfer.
>       If a protocol using NICE requires a connection to a different
>       host, it has to start a totally new and unrelated ICE session.
>       This can result in discontinuous connectivity while the checks re-
>       run.  Continuous operation is needed for real-time usage, but not
>       more generally.

As RTSP supports the concept of changing destination addresses and other
transport parameters, it seems evident that ICE restart capability are
needed. In addition to handle lost bindings or other error cases.

> 
>    o  Simllarly, ICE restarts are not supported in NICE.  Restarts are
>       an artifact of sending updated offers and answers.

As above.

> 
>    o  ICE provides some guidance for handling SIP forking.  This is a
>       case where a single offer elicits multiple answers.  Forking is
>       specific to SIP, and so this capability is removed from NICE.
>       NICE allows connectivity to be set up only between a pair of
>       hosts.

We at least does not need this functionality.

> 
>    o  ICE defines a lite mode of operation for supporting ease of
>       implementation.  Since NICE is already simpler by the removal of
>       several large ICE features (most notably updated offers and
>       answers), this simplified mode seems unneeded.  It seems better to
>       simplify NICE overall rather than define complexity in the normal
>       mode in order to introduce a simplified lite mode.

This I agree. However, for RTSP it is desired to only provide a server
optimization that only are deployed when server has public addresses.
And it still is a ICE-full implementation as it can send STUN requests
for the DDOS protection.

> 
>    o  ICE supports the notion of multiple streams and multiple
>       components per stream.  This was done specifically to address the
>       needs of multimedia.  NICE provides the ability to establish a
>       single connection between a pair of hosts.  Consequently, that
>       capability is not present in NICE.

This is needed in RTSP as we commonly have multiple media streams.

> 
>    o  ICE defines an algorithm called the Frozen algorithm.  This
>       algorithm exists to speed up completion of ICE in cases where
>       multiple candidates share similar properties.  For example, when
>       an audio and video candidate are on the same host IP address.
>       Since NICE only supports a single candidate and a single
>       component, the use cases for the Frozen algorithm diminish
>       significantly.  Furthermore, the Frozen algorithm is entirely
>       about speed and is not as much an issue for more general non-real
>       tiem protocols .  Thus, this algorithm is not used by NICE.  It
>       falls out by using the algorithm defined in ICE, but by setting
>       each foundation to a unique value.

Also needed to reduce the amount of STUN traffic as multiple media
streams are norm rather than exception for multi-media streaming.

> 
>    o  ICE defines SDP attributes for "remote-candidates".  These are
>       used to resolve a race condition between a subsequent offer/answer
>       and the ICE checks.  Since NICE does not use any subsequent
>       rendezvous signaling, this attribute and its procedures are not
>       used in NICE.

Well, as RTSP can update transport connections this is still needed.

> 
>    o  ICE defines an SDP attribute called "ice-mismatch".  This detects
>       an ICE failure case due to the presence of signaling
>       intermediaries that don't support ICE.  This problem is specific
>       to SIP and thus this attribute and associated procedures are not
>       used in NICE.

If this particular problem may occur in RTSP still need more analysis.
It might be possible to detect this other ways.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Feb 2008 20:08:20 +0200

> solution with increase server load and the only benefit a simplified

Well, ICE is chatty. It just is. Each sides need to exchange their candidates. 

I prefer chatty yet simple protocols to bloated protocols. The latter one 
result in bloated implementations, which strongly tend to result in bugs, 
missing "required" features, bad interoperability, and last but not least, 
criminally braindead support from middleboxes. It is fairly clear that 
RTSP/1.0 has had severe problems with this already. I humbly claim it would 
be a severe mistake to not tackle this issue in RTSP/2.0, lest we further 
encourage developpers to use HTTP for streaming.

Anyway, I am chiefly concerned that, by making RTSP ICE support almost as 
complicated as SIP ICE, there will be a strong incentive for server vendors 
NOT to implement ICE, especially if they don't care about the 
server-behind-NAT scenario...

> quickly results in that most of the ICE O/A mechanisms still are needed:

O/A is a painful idea whenever some kind of feature negociation is required, 
because it is so inflexible: one offer, one answer. RTSP is not like that. 
Also much (most) of the intricacies of SIP comes from the existing SIP 
middleboxes. I am not going to close my eyes and pretend RTSP has no 
middleboxes, but it would seem that these are quite different (due to O/A and 
the different deployment legacy of each protocols).

> address anyway. However, I expect to be able to detect ICE unaware

I assume ICE would be a hop-to-hop thing, where the client, any media-proxying 
proxies and the server are the hops, right?

ICE can simply be a preferred Transport. If the proxy does not handle it, it 
will try to use the next Transport. I don't see the need for a 
(Proxy-)Require, though it's definition-dependant. My point is, you can use 
already use "fallback" transports in RTSP/1.0. which should cover this issue.

In any case, default ICE is not a big complication. From my experience as an 
ICE implementor, restart, frozen algo, multiple components and multiple 
streams are where most problems lie.

By the way, keeping this will make the protocol even more chatty, should you 
consider chattiness an issue.

> needed. In addition to handle lost bindings or other error cases.

Restart was needed for the SIP middleboxes to know what transport address was 
finally selected, as they don't terminate ICE.

An RTSP proxy would terminate ICE, would it not?

By the way, keeping this will also make the protocol yet more chatty.

> As above.

RTSP already has re-SETUP for this, whereas SIP needs re-INVITE. Each SETUP 
can simply use a brand-new ICE session (with a different ICE username).
I don't see the need for extra ICE-specifics. But...?

By the way, more chattiness yet again.

> We at least does not need this functionality.

I hope so.

> And it still is a ICE-full implementation as it can send STUN requests

That is kind of the point I've been trying to make for almost a year.

> This is needed in RTSP as we commonly have multiple media streams.

RTSP does indeed have multiple medias. *But*, as I said earlier, each media 
can be setup independently. For example, XMPP NAT traversal (jingle) does 
support multiple streams (audio/video), each as indenpendent ICE sessions.

The need for this in ICE is an artifact of the strict O/A model of SIP, that 
does not "affect" RTSP.

> streams are norm rather than exception for multi-media streaming.

That one is sure to be messed/ignored up by every second implementors and help 
RTSP/2.0 have as bad IOP as its predecessor. All the more as it does not 
match what RTSP/1.0 does, thus further increasing the cost of RTSP ICE (and 
making proprietary HTTP look even more attractive in comparison).

I would claim that RTSP ICE does not need multiple streams anyhow.

And it should really really mandate rtprtcp-mux when ICE is used (thus killing 
the need for multiple components as far as ICE is concerned).

> Well, as RTSP can update transport connections this is still needed.

That is a side effect of SIP/ICE Restart. IMHO, one more reason to stick to 
plain RTSP re-SETUP.

And again, more chattiness if we allow this.

> It might be possible to detect this other ways.

I don't know, but it does not really make sense outside SDP O/A as it is 
specified in ICE, meaning it would have to be re-specified differently.

And again and again, more chattiness would ensue.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Feb 2008 13:35:26 +0100

Hi Rémi,

See comments inline. Thanks for discussing this, as it helps in the 
specification work and ensure that we find a good solution.

> encourage developpers to use HTTP for streaming.

I mostly agree, but making things simpler than they are also doesn't not 
  help. I think ICE in RTSP can be done more straight forward than in 
SIP O/A. There will clearly be a few situations where one can make make 
trade-offs.

> server-behind-NAT scenario...

This is clearly a valid concern.

> the different deployment legacy of each protocols).

Yes, I also think O/A is painful without providing enough to make real 
negotiation possible. RTSP is in this sense more limited. Get a media 
description, have the client offer what transport alternatives include 
its side of the configuration for that are supported, then the server 
selects its most preferred and return its part of the configuration.

> proxies and the server are the hops, right?

Yes, when media proxying is in effect then you need to split the ICE 
into two parts. We need to write text on this.

What needs to work is the non-media proxying RTSP proxy. This should 
preferably work without needing upgrades to that device. I also wonder 
how common RTSP ALGs are, that control NAT or FW's. But I think we can 
ignore that consideration as long as they do not damage the necessary 
signalling.

> already use "fallback" transports in RTSP/1.0. which should cover this issue.

Yes, this is very dependent on how you include this in the SETUP 
request. Okay, lets do a thought experiment with what you propose and 
what limitations it will enforce.

My interpretation is that one would define a new transport:
SETUP for which you also can have a "default" fall back transport 
specification.
Transport: RTP/AVP/D-ICE;uniceast;candiates="list of candidates UDP, 
TURN over UDP, TURN TCP-UDP",
            RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"

The RTP/AVP/D-ICE would require the use of RTCP-MUX. D-ICE for that it 
provides a single channel of datagram clean transport. D-ICE would be 
unable to support multiple channels, other than if what ever is put on 
it is self-demultiplexing, like RTP and RTCP following [RTP-MUX].

If one like to use RFC 4571 to have TCP provide reliability for RTP then 
one would need to have another type of ICE. This due to the needed 
framing layer. This also needs to mesh with ICE-TCP. I have no clue how 
you could combine these two due to the different framing needed.

Then we also have the problem that the server needs to select one of the 
transport specifications when answering. And before answering no 
connectivity checks from client to server can be done.

When using D-ICE as lower layer transport each media stream will find 
the most prioritized candidate combination that works and use that. This 
will also mean that all STUN checks are done in parallel over the same 
candidate pairs as they are likely to have the same prioritizes for all 
media streams. This now becomes a congestion control issue, that would 
be resolved if one used checkboards across the media streams and the 
frozen algorithm. I am not comfortable to remove this protection of the 
network.

The RTSP client will not issue a PLAY request until all its media stream 
has found a candidate. So from that perspective the frozen algorithm 
isn't needed.

There also needs to be a way of handling if one likes to change the 
transport parameters and add additional candidates. I get the impression 
that you would say that in this case you simply delete all the current 
ICE state and start from scratch with a new ICE setup reflecting the new 
parameters. Which would be problematic considering that what you might 
need to get both peers behind NAT case to work is to add additional 
reflex candidates using the signalling channel.

> streams are where most problems lie.

Understood, but hard for me to quantify.

> consider chattiness an issue.

It isn't the chattiness in itself that are problematic. It is network 
load and that loads characteristic in combination with ensuring that 
things actually work. Sure, we like to get as quick as possible 
completion of the checks.

> An RTSP proxy would terminate ICE, would it not?

Yes, the proxy would terminate. However, we still have the case where 
new interfaces become available and the client likes to move the stream 
delivery to these new interfaces. To be able to support this type of use 
cases some sort of restart would be needed.

> I don't see the need for extra ICE-specifics. But...?

Well, if you only change the username and not the actual ports used, I 
think it will work. I have a hard time seeing what the difference 
between this and restart as specified in ICE today are.

>> We at least does not need this functionality.

Although I should say that I have heard some demands to support server 
side failover using different explicit IP addresses. But hopefully that 
case if ever specified can be considered a new completely new transport.

> The need for this in ICE is an artifact of the strict O/A model of SIP, that 

Well, as currently specified and with RTP as the example case, a single 
media transport may require multiple transport "connections". I think I 
am fine with going the RTP-RTCP MUX way for now. As I don't know of any 
other case of this really used in RTSP.

> the need for multiple components as far as ICE is concerned).

As I touched upon above. The issue I see is the congestion control angle 
of this. As each media stream will generate concurrent connectivity 
checks and in the same order for all media streams it will become very 
bursty over each candiate pair. That is why I think freezing all media 
streams except one would reduce this issue. The alternative would be to 
ensure that all connectivity checks are run by the same pacer in a joint 
queue.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 19 Feb 2008 19:38:25 +0200

> SIP O/A. There will clearly be a few situations where one can make make

Sure. I assume what we want is NAT (and stateful firewall) traversal, 
conenctivity error detection and return routability checks.

Now that I think about it more... There is one thing is, "plain" ICE would be 
clearly be overkill whenever the server is in the unencumbered public 
Internet. On the other hand, if I understand ICE-Lite is not sufficient (no 
return routability checks/DoS protection).

As for when the server is behind a NAT, "plain" ICE will NOT be sufficient: 
UPnP, NAT-PMP or static port forwarding will be needed for the RTSP control 
connections in the first place. That is yet another (unavoidable) extra 
intricacy and limitation that is not dealt with in RTSP-NAT, as far as I 
remember (the I-D has expired). As much as I don't like to rely on any of 
these 3, it would seem we have to :-( I wonder why not use these same port 
forwarding scheme for the media flows. Now, this essentially turns the NATted 
RTSP server into a public RTSP server, which is a HUGE simplification of the 
problem. Am I missing something?

> > complicated as SIP ICE, there will be a strong incentive for server
> > vendors NOT to implement ICE, especially if they don't care about the

All the more considering the above, I did not think about it yesterday,

> > I assume ICE would be a hop-to-hop thing, where the client, any
> > media-proxying proxies and the server are the hops, right?
>

> What needs to work is the non-media proxying RTSP proxy.

I wonder if it would not be sufficient for these to discard ICE transports, 
altogether, and force a downgrade to ??

> This should preferably work without needing upgrades to that device.
> I also wonder how common RTSP ALGs are, that control NAT or FW's.

> But I think we can ignore that consideration as long as they do not damage
> the necessary signalling.

If the ICE transport does not match the syntax of "normal" RTP/UDP, NAT 
ALG "should" leave it unmodified it, so it "should" work out of the box. That 
might be a bit optimistic though :(

> > ICE can simply be a preferred Transport. If the proxy does not handle it,
> > it will try to use the next Transport. I don't see the need for a
> > (Proxy-)Require, though it's definition-dependant. My point is, you can
> > use already use "fallback" transports in RTSP/1.0. which should cover
> > this issue.
>

Yep.

I assume we can also get rid of the ICE role negotiation. I would expect the 
RTSP client should always be the ICE-controlling side. This also removes an 
unlikely ICE error case.

> it is self-demultiplexing, like RTP and RTCP following [RTP-MUX].

Right. That should be sufficient for all variants of RTP/AVP as well as the 
yet-to-be-standardized-if-ever MP2T transports.

> you could combine these two due to the different framing needed.

Can't comment... I am afraid the current state of ICE-TCP is such that it is 
premature to set the relevant technical details at this point (?). Still, I 
assume that, for the sake of SIP, it is going to support RTP/AVP, with or 
without RTCP-MUX.

> connectivity checks from client to server can be done.

That's a good point. I understand this means the server needs to assume ICE is 
going to work if it offers it. I don't know if this is acceptable or not.

In any case though, the default transport in SIP ICE solves backward 
compatibility, not ICE failures between two ICE-capable endpoints. In that 
later case, I would lean toward advising client implementations to re-SETUP 
without ICE. Looks like an unavoidable complication here, without departing 
significantly from the current RTSP SETUP model.

> frozen algorithm. I am not comfortable to remove this protection of the

Understood. On the other hand, I am not confortable with involving the server 
with the frozen algorithm. Only the client should have to take care of this.

> has found a candidate. So from that perspective the frozen algorithm

Indeed.

> > In any case, default ICE is not a big complication. From my experience as
> > an ICE implementor, restart, frozen algo, multiple components and
> > multiple streams are where most problems lie.
>
> > By the way, keeping this will make the protocol even more chatty, should
> > you consider chattiness an issue.
>

I don't know. It might well be that initial media buffering, taking congestion 
control constraints into account, will take a lot more time that connectivity 
checks. SIP endpoints try hard to minimize media performance delay, but RTSP 
clients?

(...)
> cases some sort of restart would be needed.

Sounds like re-SETUP. I thought RTSP had this already?

> > RTSP already has re-SETUP for this, whereas SIP needs re-INVITE. Each
> > SETUP can simply use a brand-new ICE session (with a different ICE
> > username). I don't see the need for extra ICE-specifics. But...?
>

If I am not mistaken, it would be using something that RTSP already has, 
rather than something which must be added for NAT support.

(...)
> > And it should really really mandate rtprtcp-mux when ICE is used (thus
> > killing the need for multiple components as far as ICE is concerned).
>
> streams except one would reduce this issue.

Fine with me.

By the way, is there any RTSP ad-hoc?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 16:48:36 -0800

Remi wrote:

> Now that I think about it more... There is one thing is, 
> "plain" ICE would be clearly be overkill whenever the server 
> is in the unencumbered public Internet.  On the other hand, if 
> I understand ICE-Lite is not sufficient (no return routability 
> checks/DoS protection).

Right.  RTSP needs something between today's ICE-Lite and ICE-Full.

> As for when the server is behind a NAT, "plain" ICE will NOT 
> be sufficient:  UPnP, NAT-PMP or static port forwarding will be 
> needed for the RTSP control connections in the first place.  That 
> is yet another (unavoidable) extra intricacy and limitation that 
> is not dealt with in RTSP-NAT, as far as I remember (the I-D has 
> expired). 

(FYI, all expired Internet Drafts are available from
http://tools.ietf.org/internet-drafts/DRAFTNAME or, if you prefer pretty
formatting, http://tools.ietf.org/html/DRAFTNAME).

You are right, RTSP-NAT didn't worry about the RTSP signaling
path itself.

> As much as I don't like to rely on any of these 3, it would seem we 
> have to :-( 

We have to provide a way to contact the RTSP server over TCP, yes.
I had asked for a BoF to discuss some approaches for home server access
<http://www.employees.org/~dwing/bof-home-access.txt>, but it was
denied.  Perhaps we can gather more requirements and information and
ask for a BoF in Dublin. See a discussion of some approaches for home
server access (using UPnP, TURN, and SIP) in
draft-saito-sip-rendezvous-00.txt.

> I wonder why not use these same port forwarding scheme for the 
> media flows.  Now, this essentially turns the NATted RTSP server 
> into a public RTSP server, which is a HUGE simplification of 
> the problem.  Am I missing something?

UPnP and NAT-PMP do not work in a bunch of situations:  nested
NATs; enterprise NATs (which simply do not support UPnP or NAT-PMP);
NATs deployed by service providers (which happens today in Germany,
Africa, and S. America); some users disable UPnP because of
security concerns (most recently the Flash UPnP vulnerability
<http://www.gnucitizen.org/blog/hacking-the-interwebs>); some
NATs shipped with UPnP disabled by default (although NATs
shipping now are required to have UPnP enabled by default to 
earn the Microsoft Vista logo
<http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx>).

> > > vendors NOT to implement ICE, especially if they don't 
> > > care about the server-behind-NAT scenario...
> >
> I wonder if it would not be sufficient for these to discard 
> ICE transports, altogether, and force a downgrade to ??
> 

It is my understanding that Linksys has been shipping NATs with built-in 
RTSP ALGs for quite awhile.  These are not a lot of fun because they
are not feature- or bug- compatible with the RTSP client and RTSP
server (much like every other ALG for every other protocol, except
perhaps good old FTP).  I do know the goal is to not rely on such
ALGs.  As you might guess, the RTSP ALGs in such devices never
considered the RTSP server inside the home, so they may well do
really funky things with RTSP messages going 'backwards', 
especially if they are hairpinned through the NAT (that is, an
RTSP client in the home connects to the RTSP server on the NAT's
public IP Address, which is a reasonable thing for the RTSP client
to do if the in-home RTSP server published its public IP address
and TCP port in a rendezvous service like DNS (e.g., dyndns.org).

> > But I think we can ignore that consideration as long as 
> > they do not damage the necessary signalling.
> 
> ALG "should" leave it unmodified it, so it "should" work out 
> of the box. That might be a bit optimistic though :(
> 
> > request. Okay, lets do a thought experiment with what you 
> > propose and what limitations it will enforce.
> >
> I assume we can also get rid of the ICE role negotiation. I 
> would expect the RTSP client should always be the ICE-controlling 
> side.  This also removes an unlikely ICE error case.
> 
> Right. That should be sufficient for all variants of RTP/AVP 
> as well as the yet-to-be-standardized-if-ever MP2T transports.
> 
> Can't comment... I am afraid the current state of ICE-TCP is 
> such that it is premature to set the relevant technical details 
> at this point (?). Still, I assume that, for the sake of SIP, it 
> is going to support RTP/AVP, with or without RTCP-MUX.

RFC4571 has really simple framing (from Section 2 of RFC4571):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    ---------------------------------------------------------------
   |             LENGTH            |  RTP or RTCP packet ...       |
    ---------------------------------------------------------------

A STUN packet can be placed after the length just fine.  The receiver
pulls the length and performs normal demultiplexing to decide if
the framed payload is RTP or STUN (by examining the first two bits).

> That's a good point. I understand this means the server needs 
> to assume ICE is going to work if it offers it.  I don't know if 
> this is acceptable or not.

For the DoS protection feature, the client needs to support ICE.  
Without that, I don't see how to build DoS protection.

> without ICE. Looks like an unavoidable complication here, 
> without departing significantly from the current RTSP SETUP 
> model.
> 
> > frozen algorithm. I am not comfortable to remove this 
> > protection of the network.
> 
> Understood. On the other hand, I am not confortable with 
> involving the server with the frozen algorithm.  Only the client 
> should have to take care of this.
> 
> checks. SIP endpoints try hard to minimize media performance 
> delay, but RTSP clients?

I don't believe it is significant.

Even going across the United States, a connectivity check is
only going to cost 40ms.  I expect if that delay is too much,
the content provider can deploy content servers topologically
closer to the content consumers to reduce that value.

> If I am not mistaken, it would be using something that RTSP 
> already has, rather than something which must be added for 
> NAT support.
> 
> (...)

Gosh, I hope so.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Feb 2008 14:02:11 +0100

Rémi Denis-Courmont skrev:
> * PGP Signed by an unknown key: 02/19/2008 at 06:38:27 PM

I don't think you are missing something. However, we are splitting up 
the problem where it can be done. It is clear that the return 
routability check and support for clients behind NATs are priority one. 
Priority two is to support servers behind NATs. ICE will allow NAT 
traversal for the media using datagram (primarily UDP) also for servers 
behind NATs. Then the second problem for RTSP servers behind NATs is how 
the clients will reach them. This is clearly a unresolved problem, but 
it is separate from the media traversal. Thus we take one problem at a 
time. If someone likes to suggest something on how the resolve them I 
really would appreciate it.

[SNIP]

Lets discuss this in the context of the draft that will come out today. 
I think we considered most of the issues. The Froozen algorithm is still 
an open issue that will need discussion.

> By the way, is there any RTSP ad-hoc?

I think there will be one. At least one on RTSP NAT. However, I need to 
see what wholes there are in my IETF week to have it.

Cheers

Magnus Westerlund

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 25 Feb 2008 15:00:25 -0800

(I have changed the title)

The fragmentation of NAT traversal for various countless applications such as CS SIP, P2P SIP, RTSP and other application protocols, PIv4/IPv6, etc., plus each for UDP and TCP separately (as in new I-Ds) is no doubt quite unfortunate and more effort is called for.

Why not work on solutions for all application protocols?

Maybe HIP or the openVPN as a tunnel solution of last resort (is understood by most NAT) should be looked at with new energy, instead of busily building a Tower of Babel http://en.wikipedia.org/wiki/Tower_of_babel 

HIP needs some more work, but maybe it is worthwhile for all the good reasons. 

What do you all think? Do we have better options? 
Open flaming on this...

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, February 25, 2008 7:02 AM
To: Rémi Denis-Courmont
Cc: [email-masked]; Jeff Goldberg (jgoldber)
Subject: Re: [MMUSIC] RTSP ICE (was Re: New I-D on ICE for non-SIP protocols: NICE)

[SNIP]

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 26 Feb 2008 09:54:32 +0200

Le Tuesday 26 February 2008 01:00:25 ext Henry Sinnreich, vous avez écrit :
> The fragmentation of NAT traversal for various countless applications such
> as CS SIP, P2P SIP, RTSP and other application protocols, PIv4/IPv6, etc.,
> plus each for UDP and TCP separately (as in new I-Ds) is no doubt quite
> unfortunate and more effort is called for.
>
> Maybe HIP or the openVPN as a tunnel solution of last resort (is understood
> by most NAT) should be looked at with new energy, instead of busily
> building a Tower of Babel http://en.wikipedia.org/wiki/Tower_of_babel

To repeat the exact same thing that I pointed out last week:

First, OpenVPN is largely unsuited for various reasons:
 - implies encryption all the time -> waste,
 - client-server protocol -> unsuited for NAT-to-NAT scenarios,
 - not standardized.

> HIP needs some more work, but maybe it is worthwhile for all the good

How many years will elapse till it's available in Microsoft Windows? Vista+1 
is not coming any time soon. ICE (draft) is already deployed...

If what you want is a peer-to-peer IP overlay, use RFC4380. It's been 
supported by Microsoft for years, it's an IETF standard-track document, it 
does not force encryption in the tunneling protocol, it does not require 
adding a new address family to your whole network stack, and you don't even 
need to modify the standard IP-based applications to use it.

> What do you all think? Do we have better options?

Of course, there are some reasons why many people don't like these solutions:
- more difficult to report failures up to the application protocol because 
they are hidden below the IP layer,
- not middlebox-friendly, because everything is hidden inside a single UDP 
flow.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 26 Feb 2008 12:35:52 -0800

It is interesting to see doubting the support from Microsoft and that openVPN has the disadvantage of encryption :-)

But what about having this balkanization of NAT traversal solutions for each application protocol separately?

Maybe NAT traversal does not belong in MMUSIC as Lars Eggert has mentioned?
I also tend to see it as transport issue that has to work transparently for all application layer protocols. HIP could do it, unless there are better solutions.

Thanks, Henry

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 27 Feb 2008 10:15:39 +0200

Le Tuesday 26 February 2008 22:35:52 ext Henry Sinnreich, vous avez écrit :
> It is interesting to see doubting the support from Microsoft and that
> openVPN has the disadvantage of encryption :-)
>

I agree with you that re-inventing NAT traversal for "one's own" protocol 
seems to be a trend in IETF, not a very great one.

I would however point out that HIP is not *fundamentally* a NAT traversal 
mechanism, rather a new addressing architecture for the Internet, and OpenVPN 
is well, a VPN protocol, not a NAT traversal protocol. Because of this, their 
NAT traversal schemas simply cannot re-used.

That's why I like Teredo/RFC4380 and non-SIP ICE a lot better. These are 
*only* NAT traversal layers, and both of them are already widely deployed: 
RFC4380 is in all recent Windows boxes, and non-SIP ICE is basically the same 
as Jingle in GoogleTalk.

RFC4380 provides the "transport-agnostic" always-on tunneling schema which you 
keep asking for: you can run TCP unencumbered or any fancier transport on it. 
Non-SIP ICE is a simpler solution that can be used when you only need 
an "on-demand" "datagram" carrier through NATs.

Of course, you could also port OpenVPN on top of non-SIP ICE or so, but that 
only keeps the balkanization going.

> Maybe NAT traversal does not belong in MMUSIC as Lars Eggert has mentioned?

Quite possibly. It sounds very much like a transport issue, rather than a RAI 
(neither INT) one to me.

> I also tend to see it as transport issue that has to work transparently for
> all application layer protocols. HIP could do it, unless there are better
> solutions.

In my humble opinion, a better idea is to not reinvent NAT traversal specially 
for HIP, but use an existing schema instead.

-- 
Rémi Denis-Courmont
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Feb 2008 11:24:50 +0100

Hi Henry,

I think we are working towards the general goal of reducing issues with 
NAT and FW traversal. And we are not re-inventing NAT traversal. In this 
case we are mapping it onto the application protocol. I think this 
always will be necessary. The hurdle to do that mapping may be reduced 
as we refine everything. However, for the moment some local adaptation 
of ICE is necessary to have it work in RTSP.

How this is done, is in fact open for discussion.

Cheers

Magnus Westerlund

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 27 Feb 2008 06:54:52 -0800

Rémi,

I agree with the sentiment in your comments and hope other folks on the list would provide their comments as well.

> what about having this balkanization of NAT traversal solutions for
> each application protocol separately?

Thanks, Henry

---

From: Philip Matthews <[email-masked]>
Date: Wed, 27 Feb 2008 15:45:18 -0500

I am also worried about an approach that re-does NAT traversal for  
each protocol.

This is one of the motivations behind the ID-LOC proposal. Unlike  
HIP, ID-LOC does not include encryption. However, ID-LOC is a peer-to- 
peer solution and perhaps not appropriate in all cases.

- Philip

On Wed, 27-Feb-08, at 09:54 , Henry Sinnreich wrote:

> Rémi,
>
> I agree with the sentiment in your comments and hope other folks on  
> the list would provide their comments as well.
>
> Cc: Magnus Westerlund; Cullen Jennings; Peterson, Jon; Gonzalo  
> Camarillo; Jeff Goldberg (jgoldber); Philip Matthews; Lars Eggert;  
> [email-masked]
>> But what about having this balkanization of NAT traversal  
>> solutions for