Subject: Re : RTSP

From: Anup Rao <[email-masked]>
Date: Tue, 15 Oct 1996 16:42:47 -0700

Mark Handley  wrote:
 
>  - in the RTSP-Audio family, reserving a codec ID range for Microsoft
> Audio Compression Manager but not referencing RTP AV profile payload
> types or ITU standards seems odd, particularly as there are likely to
> be overlaps.
>
         The only reason we used it is the fact that it is a  fairly
comprehensive  codec name space,  and convenient from an implementation
point of view. We will definitely review this in order to address your
concerns.
 
> - I can't figure out where the stuff in Appendix D fits in, but
> perhaps I just haven't read the spec through closely enough.
>
        We really look at RTSP as a being a protocol to access media
streams
and control their delivery.  In doing so, we have found need for some
things not related to control as such - I think a good example is
Copyright. The question is - does this really belong in the protocol ?
We do believe that there is a strong case for it, and it adds to the
completeness of the protocol.

> In general, my main reservation about this is the use of TCP (which
> provides arbitrary delays to achieve reliability) to control real-time
> UDP based streams where timing is all important.  I'd prefer to see a
> mapping of this protocol over UDP...

Rob Lanphier has answered this. I have a few things to add to what was
said earlier:-

What TCP buys us is :-

1) Reliability with  performance optimized by collective net experience
of  many years.

2) Ability to provide security relatively easily, for example, by using
SSL(that needs to be on top of a reliable layer). If we wanted to do
anything similar with underlying UDP, we would have to reinvent TCP.
RTSP is a means to access and control media streams, and risks being
incomplete if this need is not addressed.  TCP itself does not provide
much security, as you have pointed out. But having its reliability means
that security can be addressed via existing means.
 
3) It enjoys enormous, enormous  support by existing infrastructure.
Validation/association of UDP streams with TCP connections is possible
and fairly well accepted(example firewalls,  SOCKS v5) due to its
connection oriented nature.

Potentially, we could drop the requirement of TCP and have it run over
any reliable protocol - this would make it more general.

The question about controlling time sensitive data via something that
trades off delay for reliability is very  valid, and we had given
thought  to it earlier. It is  important to note that control messages
are a) uni-directional for the most part b) discontinuous(not related
significantly to the rate of the stream) and occasional(less than one
req/rep per RTT)by their very nature, and therefore do not result in any
significant delay. Also, these are by nature small in size, and
unfragmented. Henning Schulzrinne has already pointed out most of this.
Our experience indicates  that TCP is a good choice for these messages
and response to control messages does not suffer. In view of this and
the belief that having a reliable connection around  is important, doing
a lightweight reliable transport solely for the control just does not
seem right.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.  -  LiveMedia                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 16 Oct 1996 09:05:16 +0100

>unfragmented. Henning Schulzrinne has already pointed out most of this.

henning should try some real experiments o nthis

we find that runnign a TCP along side a UDP over real Internet paths, you 
can quite often measure 4 or more SECONDS difference i nthe delivery
times....of occasional TCP fragments of a few bytes, compared with a
UDP packet....

 >a lightweight reliable transport solely for the control just does not
 
I recommend you try this over some long haul paths.....

the rest of your reasonaing for TCP seems very sound, though (the
deployed infrastructure for SSL and trust in this.....however ill or
well founded, is there....)

of course, just because you trust a TCP that controls a UDP in one
context, doesn't mean yo udo i nanother - htere are some veyr nasty
d3enial of service attacks that a modest TCP controlling a massive
media on demand stream could perpertrate.....especially if the latter
is multicast inside a firewall...

 jon