Subject: Re: [MMUSIC] Comments on: draft-gentric-mmusic-stream-switching-00.txt

From: [email-masked]
Date: Thu, 13 Mar 2003 19:56:21 +0100

Magnus,

thanks a lot for your feedback!

a long reply to a long comment ...

**************************************************

you write:

>The draft includes two different mechanisms.
>1. A way of selecting streams to switch between, i.e. SWITCHSETUP and SWITCHCLOSE.
> [......]
>Functionality one. The basic problem here is actually one of capability exchange.

There is a misunderstanding here!

Indeed there is a capability exchange issue associated with stream switching  (And I agree that SDP-NG could help here )
...but not only the draft does not pretend to cover this at all
it is also intended to propose a solution independently from these issues!

specifically neither SWITCHSETUP nor SWITCHCLOSE are for capability exchange!

* SWITCHSETUP is actually exactly like SETUP, as mentionned in the draft,
the point of introducing SWITCHSETUP is only
a) to make it explicit for alternate streams
b) to improve backward compatibility

* SWITCHCLOSE is for ressource garbage collection only.
(BTW it is a well know problem of RTSP that you can SETUP dynamically but
that TEARDOWN kills the whole session)

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

I agree that for switching in *very* short notice SWITCHSIGNAL does not help...

this is in my view the difference between *rate* control and *congestion* control:
in an "emmergency" (congestion control) you want to switch down fast,
but when the network is stable you want to slowly explore "up" (TFRC, etc)
and you will have cases when the system is slowly drifting because the streaming rate
is only slitghtly too large for the network, and then you can have many seconds to react ...
(if you have a way to react!)

also remember that the target is *seamless* switching, in an emmergency (congestion control)
you want to preserve the network, seamless-ness is secondary, but outside of emmergencies
there are cases where you want to a really smooth playback and SWITCHSIGNAL is intended for that:

>One argument that might be used for the usefulness of
> SWITCHSIGNAL is the synchronization information carried in it.

YES!

> However I don't see any need. As long as media playout are
> continuos the existing timeline will continue to
>exist and provide synchronization.

Yes, true, but tricky and also with an fundamentaly important exception for audio
with multiple frames per packet, which makes SWITCHSIGNAL very useful:

In that case in order to synchronize the decoder needs to get *exact* RTP time stamp values
because 2 streams encoded from the same content at different bit rates will produce different
packetization, so that the decoder needs to discard a certain number of audio *frames* from
the first packet of the new streams in order to get perfect lip-sync ...

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

First I completely agree that in some cases server control is best.
as explained above SWITCHSIGNAL is actually provided solely
as an (optional) helper for that case !

The point however is that in *some* cases client control is  also nice.

******One key case is when RTCP feedback is blocked***********
(unfortunately I forgot to mention that one in the draft!!)

You will have to recognize it is also *very* natural
from the RTSP "philosophy" point of view!

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

I understand that, and for that reason
a) SWITCH is OPTIONAL
b) servers can deny SWITCH requests (especially up)
c) in all cases servers *can* stop sending when the RTCP feedback (or absence of) indicates congestion

the point is rather that in less dramatic cases you want to provide a smooth transition
(a seamless switch).

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

true, the server is also a mission critical device which economics are to be able
for a given hardware to support as many concurrent sessions as possible,
for that reason there are people (like us) who prefer to have the client make
the rate control computation and heuristics for target stream selection
(a bit like web servers use cookie to save the context at the client side)

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

Hum, maintenance and upgrades looks to me like a much more complicated issue than that...

anyway *everything* is optional in my proposal so ...
you can upgrade client first, or server first as you like;-)

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

again, maintaining a lot of context in the server may not be a good idea for everybody...

also I dont see the logic here since the first place where congestion is detected
is always the client (with one exception: TRIGTRAN, but that is yet another animal!)
plus the fact that the player buffer content is also an important parameter.

>5. It can be deployed in a backwards compatible way. As soon as a
> server support adaptation it can start performing it.

well again, same here !

> The basic feedback will be RTCP which hopefully most support and sends.

I am sorry hope is not enough for me:
actually THAT is a key motivation for client side command i.e. "SWITCH" command.

the possibility that RTCP feedback is blocked is a very real one.

> However a adaptation solution based on
>client side requires both client and server to be updated.

well, yes but by experience I am not so optimistic about a client which has not been designed
implemented and tested for it surviving a switch from a server!-)

Anyway one key point is that my proposal is 100% backward compatible:

* "old" servers that do not implement it will ignore SWITHSETUP and SWITCH ("501 not implemented")

* "old" clients that do not implement it will not send SWITHSETUP and therefore the server will *know*
that the client does not support Stream Switching

and *this* is in contrast with the solution you propose where a server would switch without even knowing if a client supports it!

****************************

you also write:

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

I am very surprised you can say that "it works very well"!
Can you point out interroperability test reports that would have escaped my attention?-)

The draft does not say it works well it says it works "in theory" and I am
of the kind who beleives there is a large gap between theory and practice ;-)

But OK, the point of the draft is also to aim for the more general solution because
the bit rate ranges reachable with the client-transparent modes are *just not good enough.*

The aim is definitively to be able to switch from a few Mb/s to a few kb/s,
and for that you will have drastic configuration changes (codecs,
screen sizes, number of audio channels, you name it)

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

sorry but I like to call a cat a cat ;-)

if it is a switch why not call it "SWITCH" ?????????

also there are 2 dozens of different such tricks being proposed/used by now!

the *point* would be that everybody uses the same one !

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

yes, it works but it is transparent only by removing B frames, which covers a very narrow bandwidth range ...

anyway this is something, as you point out, for which no standardization is needed anyway ...

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

AH But *that* is the point: to leverage on existing codec technology which has been
optimized for constant bit rate ! ... on networks with variable band width !

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

True,

however as explained I want to give some more flexibility here,
**just as SETUP can be performed at anytime**
I want to be able to SWITCHSETUP at anytime

By symmetry I also want to be able to SWITCHCLOSE at anytime
because the amount of ressources involved can be pretty large.

an example: a streaming service is nominal at 2 Mb/s, but
one client is apparently with a bad network, the session
has been rapidly switching down to 500 kb/s in the first
seconds of streaming and is now stable for several minutes:

I want to have the possibility that in the policy of the server
the server "decides" that this guy will not be able to get
2 Mb/s anymore (except maybe by restarting another session)
so my server garbage-collects the resources for streaming this
guy at 2 Mb/s (which involve a lot of saved space in cache etc)
plus it sends a SWITCHCLOSE to tell the client to do the same!
- which saves ressource on the client
- and if SWITCH is supported avoids it trying to switch up,
which would be denied anyway.

A probably more important example is a client running
low on ressources in a server-initiated-switch
scenario: the client sends a SWITCHCLOSE to the server to tell it
"dont switch to this bit rate,
not only would it waste BW
but playback would be interrupted,
because I had to garbage collect this codec."

> I don't think the proposal is appropriate and better ways of
> handling the problems exist or are under development.

I wish you could be more specific?

> Not all pieces may be in place and work may be needed.

oh yes !

> However I think that it should be performed in areas
> that have more general application and helps fix larger problems.

is this about SDP NG? (then I agree)
however again, my proposal is mostly orthogonal to session description/negociation...

Maybe I should have called it "stream switching control ?"

******************************************

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

                                                                                                                                              
                                                          To:   IETF MMUSIC WG <[email-masked]>                                              
                                                          cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                    
                                                          Subject:    [MMUSIC] Comments on: draft-gentric-mmusic-stream-switching-00.txt      
                                                                                                                                              
               Magnus Westerlund                          Classification:                                                                     
               <[email-masked]                                                                                                
               .se>                                                                                                                           
                                                                                                                                              
               Sent by:                                                                                                                       
               [email-masked]                                                                                                          
                                                                                                                                              
               13/03/2003 16:32                                                                                                               

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

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