Subject: RTSP and TCP control

From: Scott Petrack <[email-masked]>
Date: Thu, 17 Oct 1996 09:03:47 +0200

My experience shows that control messages over TCP can indeed
be delayed or worse because of flow control. This happens
typically when trying to get service from Israel to some
server in the US in the heavily loaded hours of the internet.
(There are often 14 hops between me and some server in the US).
By "worse" I mean that the delay is so bad that the connection
times out. This is because all the UDP stream traffic just
totally overwhelms TCP traffic. This is one of those things
that of course will be solved when the Messiah comes and
RED is deployed, but until then my very "real-world" 
experience suggests that using TCP will result in significantly
worse control function.

The problem is not so much a STOP message, since I can just stop
the playout locally. The problem occurs with things like 
fast forward or even worse, slow motion. Within the true hard
constraints of RTT, I would like to be able to play with
the control buttons (like pause, slow down, fast forward, etc.),
just like I could do at home. The constraint of RTT and jitter
are very limiting, but my experience shows that using TCP
in the control channel significantly reduces the amount of 
function I can get.

As Tim said, all I really want to do is synchronize the states 
of the two machines. I don't really need a reliable bytestream.

ABout the bandwidth of RTCP: I agree that every byte matters.
I tried to make this point in Montreal and got laughed at.
But the point here should be this: many applications want 
to get feedback between clients and servers about the statistics
of the transmission. RTCP should be viewed as the "Correct"
and "standard" way to do this. I personally have not yet
seen the C/RTCP spec, but I think that for compression it might
be reasonable to to allow applications to define wehich fields
in the sender reports and receiver reports are going to be
transmitted. This could be done in a RTCP packet which desscribes
and tailors the SR and RR, sort of a dynamic profile. The intent
would be that the current RR and SR are the "full" versions,
but that an app could announce at the beginning of a session 
that it is going to send a "partial" version.  Of course
this announcement would have to be acknowledged, but it would 
happen only once at the beginning of the session. If we can
agree upon some minimal version, then perhaps a static profile tpo
to tailor RR and SRs would be useful. I agree too that we
might want to be more flexible about how often to send RTCP.

But the basic fact, that RTCP is "the" way to  transmit 
packet statistics, I think should be maintained. I will try to
write up my experiments with tailoring RTCP for low bandwidth
soon.