Subject: RTSP

From: "Scott Petrack" <[email-masked]>
Date: Fri, 11 Oct 96 10:00:52 IST

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

I am not expressing a personal opinion here about whether this is a good
idea or not. I am suggesting that this part of the I-D has already been
discussed.

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.

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.

I'll try hard to read carefully the draft today to make my remarks
worth more than $0.02.

Scott

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 11 Oct 1996 08:16:31 -0400

> idea or not. I am suggesting that this part of the I-D has already been

I also question the gain this provides. The RTP header is 12 bytes, the
"compressed" version 5 bytes, for a saving of 7 bytes. RealAudio 28.8
(14.4 doesn't seem to work on Solaris) seems to send 247 bytes per UDP
packet. This amounts to a saving of an amazing 2.83 % of bandwidth (or
2.6% if you figure in the IP header). 

> Scott

Henning