Subject: Re : RTSP

From: [email-masked] (Tim Dorcey)
Date: Tue, 15 Oct 1996 21:05:47 -0700

This may be too philosophical for this stage of the game, but another
argument against using TCP in this context is the same "end-to-end"
argument that goes against using hop-by-hop error recovery to achieve
end-to-end reliability.  I.e., what you really need is reliability at the
application level, some synchronization of state between client and server.
By the time you account for all the disruptions that could occur even with
reliable transport (e.g., dropped connections, crashed machines,
insufficient system resources, improper protocol implementations on the
other end) it may not be much additional work to deal with lost messages at
the application level, skipping the need for reliable transport all
together, and, I think, yielding a more robust system.

Of course, TCP can save the application a lot of work, if many errors can
be detected/corrected under the surface, on the way toward producing a
correct *end* result (or an *end* error condition).  This is clearly the
case with bulk file transfer.  It is much less true for a message passing
control protocol, where the *end* result is of a timely nature.  E.g.,
suppose a client wants to abort an incoming UDP stream and sends a STOP
message via TCP.  The packet containing the STOP message is lost, TCP
detects this after a while, backs off to avoid congestion, and tries again.
Meanwhile, it is obvious at the application level that STOP has not
occurred.  If the application were not assuming a reliable transport layer,
it would just keep saying STOP until the data stopped.  Evidence of correct
state is the ack.

Unless you are taking advantage of TCP's ability to reassemble a byte
stream (at the expense of delay) or its carefully tuned flow control
algorithms, I can't see that it adds much value.  But, then again, I can't
speak to the pragmatic concerns regarding current firewall/security
practices, and if this stuff is up and running now, let's not have
hypothetical/philosophical objections get in the way of some real world
experience.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Oct 1996 07:31:52 -0400

> it would just keep saying STOP until the data stopped.  Evidence of correct

As was pointed out before, the flow control issue is a red herring in
this case. Your STOP message will not get delayed by flow control.

Once the RTT measurement has adjusted right, TCP will discover a loss
within the shortest time possible - a RTT (modulo timer resolution). The
only way to cut down that delay statistically is by repeating the STOP
command a number of times within the RTT and hope that one of the
packets makes it. That may be a worthwhile design for this application.

Given that we have experience with TCP, current users (RealAudio) seem
to think it works well enough, proponents of alternatives haven't had a
chance to demonstrate the superiority of their proposals and that TCP
avoids having to build another protocol, it may be best to simply allow
later use of a different protocol. A client that supports it would
simply send a request to the well-known control port using its
super-fast-reliability mechanism and discover whether there's anybody
home at the port. If not, use TCP.

-- 
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: Jon Crowcroft <[email-masked]>
Date: Wed, 16 Oct 1996 14:28:10 +0100

>packets makes it. That may be a worthwhile design for this application.

the receiver will not know, and if there is subsequent loss of the
reteanmissted packet, TCP backs off the timer (i.e. there are two
backoffs, one of the window, which is not relevant here) - i.e. we are
not fussed about congestion or flow control here - we are concerned
howeer that as multiple losses DO happen i na real net, you will get a
binary exponential backoff of the _retransmit timer, which is
mean+variance of RTT - 

as a network gets congested, RTT gets higher (and variance also gets
higher), and loss goes up - but your STOP message then takes 
exponentially longer to get through....on average

a UDP based scheme could make the RTCP style assumption in the
knowledge that the APPLICATION dsamps RTCP to only be a fixed fraction
of the RTP traffic, and send with a constant RTX timer set to 1 mean +
variance of the measured RTT

 >home at the port. If not, use TCP.

and what if i want to control multiple soruces simulataneously with a
single STOP message? then UDP would let me use multicast...........

someone shoyuld build a UDP (conf control bus) style VCR
controller protocol to show proof of concept....

cheers
 jon

---

From: Jeff Smith <[email-masked]>
Date: Wed, 16 Oct 1996 09:28:41 -0700

|>
 |>and what if i want to control multiple soruces simulataneously with a
 |>single STOP message? then UDP would let me use multicast...........
 |>
 |>
 |>someone shoyuld build a UDP (conf control bus) style VCR
 |>controller protocol to show proof of concept....
 |>
 |>cheers
 |> jon
 |>
 |>

I was planning to finish my putting my thoughts together on this, but
couldn't resist this one...

This is what we are trying to do at NTT (though within RTCP for the
time being).  We actually need multicast for control to provide
awareness in a collaborative session.

Please see the BOF notes and my work in progress at
http://ecolabor.nttlabs.com/~sumisu/streams-bof/
http://ecolabor.nttlabs.com/docs/

I will explain/discuss more later (was planning on joining this
conversation sometime this afternoon) but the idea is to describe a
session using SDP (including information of the control channel),
invite entities (sinks and sources) via SIP, actually start recording
or playback on the control channel, etc.

What is "special" about our case is that we want to provide awareness
to all participants of what controls are being applied to a stream or
streams (actually to a sink or source).  Our model is of a
"relatively" loosely coupled conference and floor control may be
managed (via SCCP?), but we want other participants to have indication
that a given participant has pressed pause, stop, rewind, etc.

We also want to control cameras.  We have collaboration rooms that
have multiple cameras and other devices and remote control would
assist in the seamless use of these rooms (between Japan and the US
for example).

Well, like I said, more later.  Our goals are a "generic" solution for
peer-to-peer collaborative environments not the "broadcast"
client-server models that Netscape and Progressive are most likely
aiming for.

js

--
 Jeffrey D. Smith     【ジェフリー・スミス】
 Nippon Telegraph and Telephone Corporation   
 Software Laboratories Palo Alto	              
 250 Cambridge Ave., Suite 205			TEL  +1 415 833 3605
 Palo Alto, CA 94306				FAX  +1 415 326 1878
					 	ISDN +1 415 843 0667

 pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A  03 CF 6B E1 CF C4 D0 0D
 e-mail: [email-masked]