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

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

Instead of just lobbing ITU and ALP into the debate, maybe we should
consider this issue in a bit more detail.

It was suggested that UDP might be a better choice than TCP for the
control channel.

Clearly, we can implement a TCP-like retransmission and RTT algorithm
for UDP. This may even turn out to be a good idea (or maybe not). Some
considerations:

There are two cases:

- If the control protocol has low rates (less than one request/response
per RTT), delay performance of UDP and TCP will be virtually identical
(except possibly due to different timer granularities) unless you
"cheat" by making the UDP version retransmit more aggressively. Until we
have some form of traffic policing, not everybody will appreciate this
"application-level priority".

- If the control protocol has significant data rates (more than one
packet un'acked per RTT):

Adding a non-rate-controlled protocol that is much more aggressive than
TCP for applications that have potentially a large rate doesn't seem
like a really great idea. Having the control rate increase with the rate
of congestion packet drop is already more of a positive feedback loop
than I feel comfortable with. If TCP backs off too aggressively, we
should fix TCP, not unleash a protocol where vendors will have every
incentive to not back off to get better performance than the
competition.

If the control protocol is to have more than one packet outstanding
unacknowledged, we pretty quickly come back to re-implementing a
windowed reliable transport protocol. Seems like we have one of those
already. Given that it took many years to get all the bugs worked out of
TCP implementations, I'm not quite sure whether having every application
programmer develop their own version, with every incentive to be a bit
more pushy than the competition, is such a great idea.

Mark (in private email) mentioned that TCP's stream nature means you
can't take something back once you put it into the pipe. Good point. Are
there examples for this particular application where this is likely to
occur?

Henning
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Mark Handley <[email-masked]>
Date: Fri, 11 Oct 1996 18:23:25 +0100

>than I feel comfortable with. 

I agree with you on this point.  However, we should consider the
context in which control protocols operate.  RTCP for instance is a
non-rate controlled protocol, but it operates in the context of an RTP
stream, and so should be almost negligable bandwidth.  

The sort of control protocols we're discussing here also operate in
the context of RTP data streams - we can link the data rate of the
control protocol to that of the data stream so that any positive
feedback effect in the control protocol is insignificant compared to
the data traffic.

>If TCP backs off too aggressively, we

TCP is the nearest thing we have to a generic reliable protocol - it
does not back off too aggressively because it is designed primarily
for applications that are able to trade off delay for reliability.

When we're controlling a significant rate UDP data stream, we want a
reliable control protocol that can get through rapidly, but we don't
need to pretend it's a generic data transfer protocol.  We may not
be prepared to accept the same tradeoff that TCP makes.  In this
context, having something a little more aggressive is probably
required.

If you modify TCP, people will use your more aggressive TCP for things
you didn't intend, such as Web data transfers.  

What I can't quite decide is whether we need something completely
different from a stream protocol like TCP, so that later commands can
simply supercede earlier ones if they haven't been acked yet.  A
trivial example is where a user clicks on stop, play, stop then
rewind-to-start and play again in quick succession.  Users do these
sorts of things.  Simply sending what you expect the server to be
doing (like "play-from-time:0") means all the previous commands (of
this type) can be superceded if they're still outstanding without
worrying about still trying to get them there.  In general, this seems
like a good idea, but whether it's necessary or not, I don't know.

TCP would tend to bundle up consecutive commands into a single packet
anyway (at least until we have an MTU of data waiting, at which point
we start to lose...).  If the control protocol has any messages which
don't require absolute reliability (such as the RTSP udp-resend
message I suspect) then using a protocol that provides per-message
ACKs to the application and out-of-order delivery seems a sensible
design choice.

Presumably the reason we're still discussing this is that the design
tradeoffs aren't completely obvious.  

So, let's add another possibility to muddy the waters further :-) When
we're doing playback into a multicast session, we could multicast all
the control messages to the media-server.  This would have the
advantages of keeping everyone informed as to what they should be
expecting to see/hear, plus also possibly allow people to take turns
controlling the server so that the "video-object" could be a real 
shared-object like other shared objects.  This seems like it might
sometimes be useful to do.  

Mark