Subject: RTSP: 3. Speed field

From: Rob Lanphier <[email-masked]>
Date: Thu, 17 Apr 1997 13:41:34 -0700

"Speed" pertains to the sending of data faster than
its "natural" rate (i.e. the rate necessary for
just-in-time delivery). It is particularly useful
when subsampling of the data to implement features
like visual fast-forward or rewind will not work.

The authors recommend that this field remain intact
with the following cautionary note:

     Use of this field changes the bandwidth used for
     data delivery. It is meant for use in specific
     circumstances where preview of the presentation
     at a higher or lower rate is necessary.
     Implementors should keep in mind that bandwidth
     for the session may be negotiated beforehand (by
     means other than RTSP), and therefore
     re-negotiation may be necessary. When data is
     delivered over UDP, it is highly recommended
     that means (such as RTCP) be applied to
     ascertain the amount of data being received
     against that sent.

The rough consensus is to leave the speed field in
with cautionary notes about misuse. A few of the
observations from around the room:
   o Eric Fleishman from Microsoft noted that there
     should be a pre-negotiated maximum bandwidth for
     this.
   o Generally agreed that sending 28k stream at 56k
     is the same as choosing 56k stream over 28k, so
     the danger introduced by the speed parameter is
     minimal.
   o Negotiated duration of speed is a bad idea,
     according to Steve Casner of Precept.
   o Mark Handley and Steve Casner noted that
     congestion control should be handled by the
     underlying transport.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: David Oran <[email-masked]>
Date: Fri, 18 Apr 1997 10:38:02 -0400

>     should be a pre-negotiated maximum bandwidth for
I don't remember Eric's comment, but I think I disagree with this. Since
you have to both ask the server to increase the speed *and* change your
bandwidth reservation to match, I see no reason the client and server have
to agree beforehand on a maximum range for the speed parameter. Except for
the possibility of a upper bound the server knows quasi-statically based on
its current hardware (e.g. data can come off the disk only so fast) it is
dynamic conditions which determine what is the upper bound on speed the
server can do - conditions can change (possibly for the better!) during a
session. It might make sense during SETUP or OPTIONs to have the server
tell the client an absolute upper bound of what it might ask in SPEED, this
doesn't strike me as terribly important.

>     according to Steve Casner of Precept.
I agree wholeheartedly with this.
>     congestion control should be handled by the
Ditto.
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]