Re: [MMUSIC] RTSP ICE (was Re: New I-D on ICE for non-SIPprotocols: NICE)

Remi wrote:

> Le Tuesday 19 February 2008 14:35:26 Magnus Westerlund, vous 
> avez écrit :
> > 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.
> 
> 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).

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>).

> > > 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...
> >
> > This is clearly a valid concern.
> 
> 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?
> >
> > 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.
> 
> 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.

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.
> 
> 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.
> >
> > 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"
> 
> 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.
> 
> > 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].
> 
> Right. That should be sufficient for all variants of RTP/AVP 
> as well as the yet-to-be-standardized-if-ever MP2T transports.
> 
> > 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.
> 
> 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).

> > 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.
> 
> 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.

> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> Indeed.
> 
> > 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.
> 
> > > 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.
> >
> > Understood, but hard for me to quantify.
> >
> > > By the way, keeping this will make the protocol even more 
> > > chatty, should
> > > you 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.
> 
> 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?

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.

> (...)
> > > 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.
> 
> Sounds like re-SETUP. I thought RTSP had this already?
> 
> > > By the way, keeping this will also make the protocol yet 
> > more chatty.
> > >
> > >>>    o  Simllarly, ICE restarts are not supported in 
> > >>> NICE.  Restarts are
> > >>>       an artifact of sending updated offers and answers.
> > >>
> > >> 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...?
> >
> > 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.
> 
> If I am not mistaken, it would be using something that RTSP 
> already has, rather than something which must be added for 
> NAT support.
> 
> (...)
> > > 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).
> >
> > 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.
> 
> Fine with me.
> 
> 
> By the way, is there any RTSP ad-hoc?

Gosh, I hope so.

-d

_______________________________________________
mmusic mailing list
mmusic@ietf.org
http://www.ietf.org/mailman/listinfo/mmusic