Subject: Re: RTSP

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

Hi Scott,

At 10:00 AM 10/11/96 IST, Scott Petrack wrote:
>My $0.02 before I read all the RTSP I-D carefully:
>
>1.I thought that there was actually a very large consensus in Montreal
>AGAINST blessing any kind of lightweight RTP, even in principle.
>This issue was already opened, decided, and closed.
> RTSP should rely on link-level RTP/UDP/IP
>compression if it wants a lightweight RTP. If it needs something over
>TCP, then one should do a link level RTP/TCP/IP. (This is of course
>particularly trivial to do over TCP.)

Compressed RTP is an optional feature, and the protocol has a mechanism to
bypass this compression.  However, we specify it so that there is an
interoperable modem-bandwidth solution.  This is something we rely on pretty
heavily.  The bandwidth saving may not seem dramatic, but every byte matters
on a modem.

Nonetheless, this is a fair claim.  I realize from one of your early drafts
that you'd originally proposed an interim solution, and I would agree with
your earlier assessments.  I'll discuss the compressed RTP issue a little
more thoroughly in another message.

>2. Using TCP for reliability of a control protocol is a really hideous
>thing to do. (Can you say ITU?). I would not like to see the IETF
>embrace such a monstrous practice. Of course, the issue of a reliable
>channel for RTP control is a very important one and must be addressed. I
>would think that adding a simple ACK scheme would be perfectly
>satisfactory. If you think (as I do) that the correct way to transport
>control for RTP streams is in some RTCP packets, then it's pretty
>obvious how to add an ACK packet type and how to piggyback it onto other
>RTCP packets in such a way as to add absolutely minimal overhead. This
>has the added advantage that if you don't need it you just don't do it,
>so it's totally "backward compatible" with existing RTP tools.

Please help me understand this a little better.  We've used a TCP control
stream in our product since the first release in 1994, primarily because it
has two advantages:

1.  It is reliable
2.  It is reasonably secure (especially when compared to UDP)

You've addressed how we may achieve reliability with RTCP, but not security.
Part of the reason that firewall administrators allow RealAudio through
their firewalls is because we use TCP for our control stream, and that they
can validate the source of a TCP stream with reasonable certainty, whereas
UDP is very easily spoofed.

The reason why I'm inclined to use TCP is because the design goals of TCP
and this reliable RTCP are virtually identical.  If I understood what design
objective is being achieved by avoiding TCP, I'd have a better understanding
of why we shouldn't use it.

>3. RTSP looks to me like a protocol for audio/video streaming playback.
>With just the tiniest effort, it could be made into a protocol for
>real-time control of RTP streams. This would include
>record, playback, translators, mixers, and perhaps other gateways. I
>don't want to do "everything." I want to restrict to and focus on
>"real-time control of RTP streams." I have no problem with starting with
>media types audio/video, and starting with playback/record. But I'd like
>to be sure *now* that the protocol will support more, just like I know now
>that RTP will support more later than its current rather simple usages.

Certainly this is going to be more than just playback of on-demand.  We see
this as being a control protocol layered on top of RTP to provide the
control elements necessary for widespread RTP use.  We currently are
focusing on the need to control playback in the near term, but we have
definitely set our sights on controling all aspects of transmission, because
we have a need to standardize all elements of media delivery.

Thanks for your comments on this.
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: Mark Handley <[email-masked]>
Date: Tue, 15 Oct 1996 20:32:33 +0100

>UDP is very easily spoofed.

Umm, perhaps I've missed something here.  TCP source spoofing is just
as easy as UDP source spoofing with the exception that the TCP initial
sequence number is supposed to be random.  Assuming you're designing a
protocol that does an exchange (and we are here), then this degree of
very limited security is trivially added to a UDP based protocol by
adding a random connection id field sent to the client by the server
in it's initial handshake.

Much better in either case though is to use IPSEC...

Mark