Subject: Re: Re : RTSP

From: [email-masked] (Tim Dorcey)
Date: Wed, 16 Oct 1996 10:11:32 -0700

At 7:31 AM 10/16/96, Henning Schulzrinne wrote:
>
>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

Except that TCP will (should) err on the conservative side with respect to
retransmit.  I don't know what the exact parameterization is, but it's not
going to retransmit unless it is p% likely that loss has occurred.  The p
you want for generic transport is not the p you want in this case.

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

Yes, if the STOP scenario is really a practical concern, then it could be
addressed by having a UDP control channel available for repetition of
urgent messages.  This is probably an easier patch than rewriting the rest
of the protocol to deal with unreliable transport.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Oct 1996 09:20:57 +0100

>of the protocol to deal with unreliable transport.

yes.....

if the application tries to send new data
 at less than 1 rtt, with a modest loss rate (e.g 5% or 10%:-)
you have a good chance you get repeated loss and are not only
retranmistting, but retransmit subsequent data packets which means the
rtx timer stays high (goes on getting higher), and it takes a long
time to get a packet through first time, and get a good  RTT estiamte
again....and reset the backoff on the RTX timer.....

with UDP, this problem goes away

if you want to incoproate "playback and record" features from a
distributed HTTPngng web site, in a multiway conference, you need 
multicast for your control protocol as well as your data....

i suggest RTSP has two mappings for control messages, one for TCP for
"media on demand" model usage, and one for UDP, for paricipation of a
storage/replay system in a multiway interactive scenario....

 jon

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Oct 1996 11:39:30 +0100

>storage/replay system in a multiway interactive scenario....

I was starting to think along similar lines.  For most control
functionality, you require application level acknowledgements anyway -
you can't just assume that because you put a message into a TCP
connection that it has been acted upon yet.

Defining an RTSP so that it can work over UDP should be perfectly
feasible.  It should allow better control responses and the ability to
not care if some mesages get through or not (eg. UDP-resend if you
really need that functionality).  But there are also pragmatic reasons
why working over TCP is desirable (mostly to do with firewalls).

So it seems to me like we should design an RTS(control)P so that it
works over UDP (ie, has appropriate application-level acknowledgements
and each message is sufficiently idempotent), but is unambiguously
framed so it can also work over TCP too.

#include <wg-chair-hat>
Right now we're arguing in circles, and this isn't helping solve the
problem.  We've been in this situation before with SIP/SCIP and didn't
reach concensus.  It's beginning to look like the solution there is to
do the same thing.

Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Oct 1996 12:55:35 +0100

#include <iab-hat>
char *greeting = ":-)"

 >framed so it can also work over TCP too.

yes.....exactly

 >reach concensus.  It's beginning to look like the solution there is to

yes.....
i think you can easily define a retrieval/playback application level
protocol which can have a TCP mapping for one to one, and a UDP
mapping for one to many or participatory playback, and an 
IPv6onATM+UDP+RSVP one for ng fanatics

and there's no reason RTSP couldn't be the start....

 jon

---

From: Jeff Smith <[email-masked]>
Date: Thu, 17 Oct 1996 07:24:41 -0700

If those here in the Bay Area are interested I would like to arrange a
meeting between Netscape, Progressive, Steve Casner, myself and other
in the area and maybe we can work out details of a TCP and UDP
RTS(control)P before IETF.

My biggest stumbling block regarding the protocol I'm working on is
that while I understand our application I admit I don't think much
about other applications such as the video/audio-on-demand class of
apps.

I'm at NANOG next week (and I'm sure a number of important others are
in France for the WEB/Multimedia thing) so how does the week of 10/28
look for any who might be interested?

We (NTT) has a very useful collaboration room for about 5-8 people
(which is about the number I envision coming) and it is available.

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]

 |>#include <iab-hat>
 |>char *greeting = ":-)"
 |>
 |> >So it seems to me like we should design an RTS(control)P so that it
 |> >works over UDP (ie, has appropriate application-level acknowledgements
 |> >and each message is sufficiently idempotent), but is unambiguously
 |> >framed so it can also work over TCP too.
 |>
 |>yes.....exactly
 |>
 |> >#include <wg-chair-hat>
 |> >Right now we're arguing in circles, and this isn't helping solve the
 |> >problem.  We've been in this situation before with SIP/SCIP and didn't
 |> >reach concensus.  It's beginning to look like the solution there is to
 |> >do the same thing.
 |>
 |>yes.....
 |>i think you can easily define a retrieval/playback application level
 |>protocol which can have a TCP mapping for one to one, and a UDP
 |>mapping for one to many or participatory playback, and an 
 |>IPv6onATM+UDP+RSVP one for ng fanatics
 |>
 |>and there's no reason RTSP couldn't be the start....
 |>
 |>
 |> jon
 |>
 |>