Subject: [MMUSIC] I-D ACTION:draft-gentric-mmusic-stream-switching-00.txt

From: [email-masked]
Date: Mon, 10 Mar 2003 10:09:35 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RTSP Stream Switching
	Author(s)	: P. Gentric
	Filename	: draft-gentric-mmusic-stream-switching-00.txt
	Pages		: 26
	Date		: 2003-3-10
	
Stream switching is a technique used to change the data rate of a 
media being streamed, typically for the purpose of adaptation to 
the effectively available bandwidth of the network. A backward 
compatible and independent RTSP 'SWITCH' command is proposed in 
order to enable RTSP-based stream switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-gentric-mmusic-stream-switching-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-gentric-mmusic-stream-switching-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Mar 2003 16:32:32 +0100

Hi,

I have some comments on this proposal. My general comment is that the need for such a solution as outline in the proposal is not very present.

The draft includes two different mechanisms. 
1. A way of selecting streams to switch between, i.e. SWITCHSETUP and SWITCHCLOSE. 
2. A way of signaling requests and notifications on happening or soon to happen switches, i.e. SWITCH and SWITCHSIGNAL. 

Functionality one. The basic problem here is actually one of capability exchange. A streaming server needs to now what capabilities a client has so the offered streams does not go outside what the client can handle. However this problem is much larger than simple selecting what streams to switch between. It also includes media codecs, signaling extensions that are supported, etc. If one has a general mechanism for capability exchange one can ensure before setting up the session that one's client can handle what the server will send. That way a server can perform switching without having to worry if the client can handle it. 

I think mechanisms to handle this general problem are starting to come into being. The first component is a more capable session description protocol which supports capability negotiation, i.e. SDP-NG. Then we will need to look at how we can use SDP-NG in the context of RTSP. I think it will be necessary to provide some extensions in functionality, perhaps as simple as providing a back channel for the SDP-NG response in SETUP. 

My conclusion is that making a narrow solution that only solves a little piece of the problem is no good. Lets fix this properly. Until then I think the current mechanisms work sufficiently well. What the draft misses to point out is that a client already today are very capable of handling adaptation of bit-rates for streams. As pointed out by the draft what it calls client transparent switches works very well. These changes that are within the defined payload format and codec configuration can in certain cases be very large and in other none. 

For the non-transparent cases, i.e. needs to use multiple RTP payload types to signal which configuration to use, is not a major problem from standards point. If one accepts to start a session that contains a SDP with multiple PTs one needs to handle this. I can understand that it puts some pressure on the client implementations to handle multiple codecs. However in most case I think this is simple a question of different configurations, for example AAC and MPEG4 Visual streams. I don't think as a general case that one may not perform announced and potential a codec change / reconfiguration without explicit approval from the client. The client accepted to handle this by setting up the session. 

Looking at functionality 2: The signaling of switching commands. Lets start with the service SWITCHSIGNAL provides. This is used to notify that a switch will take place. I don't see how signaling this in advance can help. First, in most case you can't determine that you are going to switch any significant time in advance. The reason of course being that switching is done to react to changes in the network. When changes happens you need to switch quickly, there is no time to wait two seconds after a RTSP command has gone out. So therefore its better to switch directly. A transparent switch does not effect client in any way. A non-transparent may effect the client if its built on dynamic loading of codecs, etc. In this case you will still receive some heads up notice. This due to the clients buffer. When the packets start arriving with a different RTP PT the client can detect this directly and start preparing. The time in advance will depend on the amount of buffering left at !
that time. Another aspect of SWITCHSIGNAL is that it may not arrive before the actual media packets that represent the switch. 

One argument that might be used for the usefulness of SWITCHSIGNAL is the synchronization information carried in it. However I don't see any need. As long as media playout are continuos the existing timeline will continue to exist and provide synchronization. 

Lets continue with SWITCH. This being a client to server command to change to another stream. In my work with the 3GPP PSS adaptation work I have come to the conclusion that server controlled adaptation is the best thing. Reasons are:

1. In a best effort network the sending side are responsible for what it sends out on the network. This is as pointed out the model used by all IETF congestion control mechanisms. Server controls allows for halting transmission if feedback stops. 

2. Server has the knowledge where it is suitable to switch. It simply has the media and all its meta data available and can therefore best determine when and how to switch.

3. There are fewer servers in both implementations and actual numbers. This makes bug fixes updates of algorithms etc. much easier. 

4. Server has knowledge when packets where sent. This allows it to take client feedback into that context. Doing it the other way seems to require more signaling. 

5. It can be deployed in a backwards compatible way. As soon as a server support adaptation it can start performing it. The basic feedback will be RTCP which hopefully most support and sends. However a adaptation solution based on client side requires both client and server to be updated. 

Of course in some cases it would be simpler if the client took the decision but from my point of view it is in favor for the server controlled solution. 

Another point is that it already exist RTSP ways to influence the server on what to send. The Bandwidth header can be included in PLAY, or SET_PARAMETER requests to tell the server what available bit-rate it sees. The server can then adapt its transmission to what the client claims and then verify it by looking at RTCP feedback. 

Further the adaptation is not as simple as switching between different encodings. The server can actually perform other actions that change the sent bit-rate. One good example is stream thinning. I could for example reduce a video sequence with 5% by simply removing some frames. Done in an optimal way it would not degrade the quality very much. Perhaps simply a little lower frame rate.

Finally I would like to make some explicit remarks about a few thing written in the draft.

1. Section 1.5 bullet 1: Assumed that bit-rate will be constant. I have not made that assumption in a long time. However given a certain bit-rate it is best to utilize it to the maximum, and that means producing constant bit-rate streams for that bit-rate. 

2. Section 2.1.2 The MUST NOT in first bullet: In some sense I would have to agree with you that the client must agree on the codecs/configuratins to use. However that is done by any client setting up a session which SDP file specify this. 

My point with this rather long mail is that I don't think the proposal is appropriate and better ways of handling the problems exist or are under development. Not all pieces may be in place and work may be needed. However I think that it should be performed in areas that have more general application and helps fix larger problems. 

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic