Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC Working Group of IETF

From: Rob Lanphier <[email-masked]>
Date: Tue, 15 Oct 1996 12:20:51 -0700

Hi Mark,

Thanks for taking the time to evaluate this, and sorry for not getting back
to you sooner.  This is the kind of input we were hoping to receive on
this.  Let me address some of the issues you bring up now, and Anup or I
will give you more background on the other issues shortly.

Mark Handley wrote:
> - the options mechanism is pretty complicated - as a general rule I
> (personally) prefer protocols without complicated option mechanisms.
> Telnet implementations (which you base the negotitation OK) often
> don't bother to implement any of the options these days.

Without discussing what telnet implementations usually do, I can say
with relative certainty that vendors and others who choose to
implement this protocol are almost certainly going to want to
embellish it in one way or another.

Perhaps the mechansism that we have can be simplified.  We should
discuss the ways in which we can do this.  However, I think we are
going to have to make sure that we have something sufficiently
sophisticated to allow additions to the protocol to come from
different sources, so that vendors can experiment with new options
prior to going through the standardization process without affecting
the robustness of the base protocol.

> - can a single fetch give multiple stream-header replies?  if not, how
> do you do *multi*media sessions?

A single TCP connection can support multiple stream-header replies
through the use of SCP.  Independent substreams are fetched by the
client, and then synchronized at the client to form a multimedia
presentation.  Communicating the assembly of a multimedia session is
something that still needs to be addressed, but can be addressed outside
of the control protocol (for instance, via a metafile that groups the 
streams or by an events stream that is no different from any other
stream).
 
> - in the stream-header flags, you can specify U, ie that the server
> can send UDP if required.  There's no equivalent T flag.  Does this
> mean that you assume the stream can alwasy be sent by "reliable
> means"?

We assume that there is a reliable way of sending the information.
Admittedly, this is based on our current model of having TCP and UDP
as the two modes of delivery.  However, there will always be
information that is going to have to be sent over at least a
reasonably reliable channel.

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

TCP seems to work reasonably well in our current line of products.  We
really do need the reliability of TCP (when people hit the "stop" button,
they do mean "stop").  The problem with using UDP is that, as Henning points
out, we would eventually be implementing our own version of TCP on top of UDP.

Another reason to use TCP is that TCP is very firewall friendly.  This is
also why we have a TCP-only option.  Many firewall administrators block all
UDP, and so having a way to access RTSP streams purely through TCP is a big win.

This is it for now.  Anup should be able to answer some of the questions
that I haven't, and I'll also elaborate more on many of these points and
others.  By all means, let's keep this conversation going.

Thanks,
Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com

---

From: [email-masked] (Christian Huitema)
Date: Mon, 21 Oct 1996 13:39:31 -0400

> out, we would eventually be implementing our own version of TCP on top
of UDP.

This is a very common and very false argument. When I say very common, I
speak by experience. This is exactly the reasoning that led to
implementing the border gateway protocol, BGP, on top of TCP. The same
design team, after a few years of experience, decided that the successor
to BGP, IDRP, would run on top of UDP.

Why? Precisely because `when people hit the "stop" button, they do mean
"stop"'. With TCP, when people push the stop button, the connection will
first wait for a complete transmission of the previous message, e.g. those
that say "please go on, I am still listening", then for a credit, before
actually carrying the "stop" message. In periods of congestions, that may
mean several seconds, when you would rather use your ressources to do
something else.

There are many other advantages to UDP, notably the avoidance of all the
restrictions based on connection counts. I don't mean just the kind of
limitations one finds in some versions of Windows NT, I also think of the
server architecture -- just have to listen to one or a few sockets, not
umpteen, means very different performances.

The firewall argument is very bogus. A firewall that does not let UDP
through would not only block multi-media signalling. It would block the
multi-media data as well...

-- 
Christian Huitema