Subject: More Miscellanous RTSP comments

From: [email-masked]
Date: Thu, 14 Aug 1997 10:16:54 +0200 (MET DST)

Section 12.18 Expires.

	It's a nice cut & paste from the HTTP specification where
'the response' is substituted by 'the media stream'.

	It's ok if that's what you really meant, but this meaning
is not all that clear if the media stream is the cached object
we are talking about.

	First of all, it's no so easy to cache the media stream,
(It's possible, but it should be specified in what manner, and in
which cases, ... and not only how to cache it, but how to use it
when a new request come before it has expired) and, second,
it should be specified which responses will include this header
(those to SETUPs, or to PLAYs?) as they refer to a different entity
than the request they are part of. 

	If 'Expires' was not meant to refer the 'media stream', but
the response, then it should be aplicable only to the
DESCRIBE response (according to chapter 13).

-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
[email-masked]			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 15 Aug 1997 21:00:14 -0400

>         First of all, it's no so easy to cache the media stream,

Why, in particular, is it difficult to cache media streams? There are
some particular issues, such as dealing with 'holes' left by
random-access PLAY, but did you have anything else in mind?

> DESCRIBE response (according to chapter 13).

This is indeed fuzzy. I see several possibilities:

(1) Expiration of ANNOUNCE/DESCRIBE is the same as that of the stream.
I.e., the media stream is no longer valid after its description has
expired. This would seem to be sensible in most cases. Thus, the Expires
header would, as currently listed, only appear in an ANNOUNCE request or
a DESCRIBE response. However, not all streams require DESCRIBE.

(2) The two are kept separate. "Expires" in a SETUP response indicates
the expiration of the media stream. This is more flexible, I think, as
it allows media content to expire without the description having been
updated. (E.g., a news broadcast updated on the hour would likely
maintain the same description; there is no reason to refetch it hourly.)

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: [email-masked]
Date: Mon, 18 Aug 1997 10:45:26 +0200 (MET DST)

> random-access PLAY, but did you have anything else in mind?

	Actually I find a number of issues. Now that you say it's
not difficult, I'm a bit confused. Maybe you know something I don't.

	+ To start caching it the proxy will have to modify
directly the destination address/port in the transport header
(unless you want only cache Interleaved data), take active part
in the Resource Reservation Protocol in use (I'm assuming in
the future real-time delivery will in the rule make use of one),
and will add latency in the real-time contections.
	(I thought that the data carried out-of-band would not
go through proxies, but it does make sense in some cases)
	(Actually, now that I think about the implications of
having the other end of the TCP connection as default destination,
I realize that the proxy would have to modify the 'port' fields
in 'Transport:' and convey the RTP data anyway)

	+ The proxy will have to understand RTP (or other transport
protocols used) headers, at least time information and SSRC.
I suppose you don't want to restrict the use of the cached data
to request which have exactly the same Range:. This means that
it will have to understand at least partially RTP. (And
leaves still the problem of if it should reuse the same RTP
packets cached, or 'recode' them. What if the new Range requested
begins at the middle of an RTP packet? Does the proxy send the
whole of it? Does the proxy request the server a first packet
starting at the correct point and then starts delivering the
next packet cached? ...)

	+ The proxy will have to understand much more than
Transport: fields. Speed: and Scale: headers will be important,
'PAUSE' requests, ... It will have to mantain tables with
Session identifiers, URLs (according with your answer to
'Anders Klemets' about the need of Session:), SSRCs and
UDP ports at the proxy.
	Ex: Let's suppose a client want to receive a multiple
stream presentation. The proxy would have to modify all the
Transport: headers and redirect them to its own ports, it then
will have to remember all the streams part of the presentation
and be able to identify them. When getting a second play it
will have to identify which data is exactly being requested
(this involves Session-Id, URL, Ranges, RTP timing information, ...)

***
	+ As far as I know, proxies work in a best-effort delivery
manner, while I (and probably a client) expect a multimedia server
to deliver the data according to its time properties (one
reason is buffer space, ... but I think you know more than I do about
that). Should the proxy deal with this timing?

	+ There are a number of minor issues like:

	- If a cached stream is requested at a different rate, it
shouldn't be delivered by the proxy, because the server might have
different streams (maybe lower resolution for fast forward...)
for different scales. The use of 'Cache-Control:' is not trivial.
It should be the server, not the client who decides if it's
cacheable or not, but the 'normal rate' stream might be
cacheable, while the request for the 'fast forward rate' stream
(not cacheable) never reaches the server.
	This can also be seen as a Content Negotiation issue, but
its not addressed as such. (Maybe 'Accept:' & ... could
be used for this purpose)

	- How can a stream be invalidated? I'm not sure how it's
done in HTTP (or even if it's allways possible, including a
server-driven invalidation), but I suppose it's more difficult if
the data to be invalidated is carried out of band.

	- UDP losts are accumulated. (In the rtsp-00 version an
UDP_RESEND method was defined, but there is nothing similar
now, is it).

	- The number of ports in the proxy is proportional
to the *active* streams. (Unless SSRC demux. is used, sharing
UDP ports)

	TO SUMMARIZE, the more important considerations:
	- RTP has to be partially understood
	- Resource Reservation Protocols have to be taken into consideration
	- Best-effort delivery must be substituted by timely delivery

	People here used to be concerned about making life
easy for proxies and firewalls, but even the more simple ways of
caching streams became complex enough, in my opinion. (I think
that, at least, the proxy would have to partially understand
RTP, and to implement some kind of timely delivery instead of
the best-effort delivery system). The use of resource reservation
protocols becomes a bit more difficult as well, given that
(using RSVP as example) the client would have to make the
request involving the path between itself and the proxy, and
the proxy the path between itself and the server (I don't know
enough about RSVP to know if it considers directly the support
for proxies, but if not, as the routes may change dinamically
independently of RSVP, I don' see other solution), or even
more complex if there is a proxies herarchie.

	I don't mean that the use of proxies for RTSP & RTP/...
is a bad idea. Only that it is much more difficult than just
addapting existent proxies.

>> [...]
> [...]
> [...] 

	I like both, but specially the second. It makes it easier for
the proxies.

	P.S.: My knowledge about proxies is quite limited, I'm
sorry if I did address issues which are already solved or if I
didn't use the correct terminology.

-- 
Francisco Cortes (Paco)
		
[email-masked]

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Mon, 18 Aug 1997 08:44:45 -0400

The issues you identify are (mostly) real, except that these
difficulties describe the difficulties of building an RTSP server and
somehow assume that building caching proxies should be easier. I never
claimed that you can take an HTTP proxy, put it through some marketing
seminar and out comes an RTSP server.

Just like RTSP media servers have to "understand" more about the content
they are shipping than HTTP servers, in order to generate packets with
the right timing, this is also the case for RTSP proxy caches. This does
not have to be complicated: rtpplay does the type of timing and RTP
interpretation you describe (without trick modes) and is 330 lines long.

Just like HTTP caches are often built on top of some form of HTTP server
or at least share a large fraction of code, this will likely be true for
RTSP. Proxy caches are, architecturally speaking, both a client and a
server, so you'd expect them to be non-trivial.

Note that asking for delivery in the middle of a packet is not
fundamentally different from asking for a starting time between two
video frames. If you care about frame-level accuracy, you don't do that
(and use SMPTE to avoid the problem); you hope for a sensible server
otherwise and don't worry about an extra 20 ms of audio.

Caches have opportunities for loss reconstruction that are inappropriate
for end systems.