Subject: [MMUSIC] Comments on draft-wei-mmusic-rtsp-bitrate-header-01

From: Magnus Westerlund <[email-masked]>
Date: Sun, 02 Jul 2006 12:08:56 +0200

Hi Wei,

I have reviewed your draft and do have some comments on it. I think the 
biggest short coming is the lack of reviewing the current state of the 
art and available mechanisms. I think one needs to consider the problem 
from what is currently used to cope with the issues you consider.

First of all the usage of multi-rate files are common. First of all it 
doesn't require advanced codec features to make it work. With a well 
coded H.263 or basically any other video codec you can create a file 
where the sender can switch between different codec rates. However it 
can primarily only be done at certain points. But file formats like the 
ISO base media file format and its childs (.3gp, .mp4) do support 
markings of such points.

Secondly the adaptation in for example 3GPP, and I think in some other 
system are not based on client requests, they are based on feedback from 
the client and the server makes the decision on how to change the 
transmission bit-rate. The interesting problem in streaming is the 
interactions between transmission bit-rate, media bit-rate and the 
receiver buffer. Due to the receiver buffer, the transmission bit-rate 
can be different from the media bit-rate. This makes is possible to 
adapt the transmission bit-rate on a finer scale then the media 
bit-rate. Thus the media bit-rate only needs to be changed when there is 
a clear trend that the available transmission bit-rate is insufficient 
for the used media bit-rate.

One should also be aware of the common usage of transmission scheduling, 
where a variable media bit-rate is changed to a constant bit-rate 
through the usage of the receiver buffer. One shuffles the transmission 
times to achieve an almost constant transmission bit-rate. However when 
combined with adaptation that transmission schedule may be slowed down 
or speed up depending on the available bit-rate. There are quite complex 
interactions between the media stream and transmission scheduler of an 
adaptive system.

You also review the differences between your proposal and the 3GPP a=alt 
  SDP attribute. However I think it is quite clear that you do not fully 
understand the purpose of that attribute. The attribute was defined as 
part of the larger effort to define adaptive streaming in 3GPP. Please 
be aware that the approach of that work was a toolbox one. This part of 
the solution was to allow relative dumb clients to select initially a 
bit-rate that they though suited them. That selection does not rule out 
the usage of server based stream adaptation as a reaction to the 
feedback the client sends about the reception. So the intention was 
never that there would be a exhaustive description of rates the server 
could produce. Also in 3GPP the bit-rate span available helps to keep 
the number of alternatives down. However I do expect in many cases they 
will describe the media + transport bit-rates that it would send without 
any of the adaptation tricks being applied.

An overview of the 3GPP solution and example of what an implementation 
can achieve is present in the following article:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=33765&arnumber=1607894&count=10&index=6

So be aware that the possible transmission rates and also media 
bit-rates are quite diverse and difficult to exhaustively list. An 
interesting issue is however that some rates will be more easy to 
produce with good media quality than others depending on how one combine 
methods like stream switching and thinning.

I would also like to object against having the user perform congestion 
control. An streaming system needs congestion control unless it is used 
in a environment where there is dedicated transport resources. The 
congestion control needs to be automatic and not user based. However it 
might be valid to have controls that allows the user to get better 
quality than currently available by reserving resources.

I would also consider the impact of delivering the bit-rates after 
session establishment has on the possibility to use QoS, determine if a 
session is possible to support or not. You should also not forget the 
"Bandwidth" header that already is available in RTSP.

I think there is a possibility to improve the bandwidth and general 
session characterization in the description phase. The 3GPP solution was 
never intended to be super generic and primarily considered the world it 
has, with session bandwidths in the range of 10-384 kbps. Even if there 
is faster links than that today, the 3GPP streaming clients do not have 
specification to follow that support any codec and profile that can 
utilize that bandwidth, yet.

I would primarily like some clearer description of what problems you are 
trying to solve. Because to me neither of the problems you describe in 
the introduction are unsolved problems.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/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

---

From: Kylin Wei <[email-masked]>
Date: Mon, 03 Jul 2006 19:07:49 +0800

Hi, Westerlund,

Thank you very much for your comments on my draft. Your comments are very
important to me.
I'm very interested in RTSP. I think whether we can reduce verbose media
description of multi-rate files. Perhaps a client doesn't want to change
transport bitrate at all, so we only offer the default bitrate. If it wants
to change bitrate, it must send a request to inquire bitrate range of media
source. When receives the inquiring request, server will respond bitrate
range in a simple form.
When server receives a PLAY request with the Bitrate header, it should
append the necessary configure information of this specified bitrate such as
the size of pre-decoder buffer into the PLAY response. This is why I don't
use the Bandwidth header. The server made different operation to them.
My solution can support not only advance codec, but also common codec. I
mean that if a media file has a large number of bitrates of the same codec,
my solution is more advantageous.
I don't think that the congestion control needs to be automatic and not user
based. If we combine them to use, we will get a better congestion control
effect. Firstly, if an ADSL subscriber has 1.5M access bandwidth, how to
determine this value by the feedback from the client. This operation will be
very easy if a user is permitted to select suitable bitrate. Secondly, if a
media source has two bitrates, 520K and 530K, transport bitrate may be
changed frequently between them according to the feedback from the client,
because the feedback is not always very accurate
.
As you had said, I do not fully understand the purpose of "a=alt" attribute.
Thank you.

Kylin Wei 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Sunday, July 02, 2006 6:09 PM
> To: mmusic (E-mail); Kylin Wei
> Subject: Comments on draft-wei-mmusic-rtsp-bitrate-header-01
> 
> Hi Wei,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Jul 2006 13:52:18 +0200

Hi,

See inline.

> my solution is more advantageous.

It is not clear to me why the media descriptions with this information 
is becoming to verbose. I don't see how this becomes simpler and also it 
prevents the client from determining its possibilities in regards to the 
content prior to actually setting things up. This actually makes QoS 
reservations more difficult.

I also think you should consider capability descriptions and how they 
can impact what the server presents for the client. In 3GPP one uses 
UAProf to describe the clients capability. A URI for that capability 
description is included in for example the DESCRIBE request, thus 
allowing the server to respond with a tailored description. Similar 
solutions is present in a number of proprietary solutions also.

> because the feedback is not always very accurate.

Congestion control is something that is required in all cases where one 
doesn't have dedicated resources on the whole end to end path. This is 
need for two main reasons, prevent you from using more than your fair 
share, and secondly ensure that what you receive is useful at all. The 
reason I write the second one is that if you don't have congestion 
control and for example tries to make a 500 kbps content go down a 300 
kbps link then you will have consistent drop rates of way over 20% that 
makes the received content unusable. In this case the user is likely to 
terminate the session. With correctly implemented congestion control you 
clearly should avoid this issue. The first reason is also a really 
important thing for the long term stability of the Internet. This is not 
something you can leave to the user. Because the user, may not even be 
present and watching the content being delivered. And even if, the users 
reaction is way to slow for being good for the network. Be also aware 
that you may end up with a network which predominately consist of badly 
behaving clients, then they will also suffer themselves instead of only 
letting other suffer.

Congestion control is not simple and do require some knowledge to get it 
right when it comes to media applications. However in the case of 
streaming the problem has been made simpler buy the possibility to use a 
fairly large receiver buffer to dampen the fluctuations of the available 
bit-rate. If the problem is bad feedback, lets focus on how to provide 
good feedback. Have you tried using DCCP or RTP/UDP with TFRC (AVPCC) 
and found that they are not usable? If you have such data both AVT and 
the DCCP WG would be interested in that.

So I am still interested in a good explanation of what problem you try 
to resolve.

Cheers

Magnus Westerlund

---

From: Kylin Wei <[email-masked]>
Date: Tue, 04 Jul 2006 11:05:53 +0800

Hi Westerlund,

> So I am still interested in a good explanation of what problem you try
It's my fault that I hadn't expressed my viewpoint clearly. The problem
which I try to resolve is that to avoid a large SDP body of multi-rate media
source, if some bitrates are provide by the same codec, we should offer the
default bitrate.

>In 3GPP one uses
> allowing the server to respond with a tailored description.
Can you give me an example about how to tailor a description according to
UAProf?  It will give a tailor description, but my solution can give full
description.

> reservations more difficult.
1.
   m=video 0 RTP/AVP 98
   b=AS:44
   a=rtpmap:98 MP4V-ES/90000
   a=control:trackID=4
   a=fmtp:98 profile-level-id=8; config=01010000012000884006682C2090A21F
   a=range:npt=0-150.2
   a=X-initpredecbufperiod:98000
   a=alt-default-id:4
   a=alt:3:b=AS:16
   a=alt:3:a=control:trackID=3
   a=alt:3:a=X-initpredecbufperiod:48000
   a=alt:5:b=AS:104
   a=alt:5:a=control:trackID=5
   a=alt:5:a=X-initpredecbufperiod:150000
2.
   m=video 0 RTP/AVP 98
   b=AS:44
   a=rtpmap:98 MP4V-ES/90000
   a=control:trackID=4   
   a=fmtp:98 profile-level-id=8; config=01010000012000884006682C2090A21F
   a=range:npt=0-150.2
   a=X-initpredecbufperiod:98000   

Do you think which is the simpler between two forms? I don't understand why
it will prevent the client from determining its possibilities. Do you think
we should reserve resources before the SETUP or before the PLAY? 

> terminate the session.
If some bitrates are showed on client interface, I think the user would like
to select a lower transport bitrate before terminating the session. 

>prevent you from using more than your fair share.......
>The first reason is also a really
> something you can leave to the user.
Yes, we shouldn't leave this to the user. But I don't understand why we
leave this to the congestion control. It's very convenient to implement that
on the access device.

> And even if, the users
Do you mean that a bad client will change transport bitrate frequently and
it will affect network condition? We can adopt a policy to prevent that.

> good feedback.
I don't mean that the manual changing transport bitrate is better than the
automatic. I think that we will get a better congestion control effect if we
combine them to use. As you had said, the automatic congestion control will
waste network bandwidth and hardware capability and be more complex.

Thank you. 

Kylin Wei

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Jul 2006 09:57:59 +0200

> source, if some bitrates are provide by the same codec, we should offer the

I think we have quite different views on what a large SDP body is. Also 
I fail to see the problem with having a slightly larger SDP is. In 
streaming and RTSP we transmit the SDP over TCP and do not have SIP's 
UDP MTU problem. For me the trade off between providing this information 
in the most suitable mechanism and having slightly larger messages is 
easy at very little cost. The SDP is so insignificant in bits compared 
to the media streams that even it might become up to 2 magnitudes larger 
without being a serious issue.

I don't think providing multiple bit-rates using the same payload types 
is an problem. In fact if you review the a=alt proposal would will find 
that it prevents the declaration of payload type configurations on a=alt 
lines. That is for two reasons; 1. To enable an a=alt unaware client to 
  use the SDP, including server side adaptation based on what ever 
feedback it provides. 2. To avoid tying payload formats to closely to 
specific bit-rate alternatives due to the fact that many configurations 
have quite a large bit-rate span.

> UAProf?  It will give a tailor description, but my solution can give full

I would recommend that you read TS 26.234 and TS 26.244. The later is 
the 3GP file format and contains a section about generating SDPs based 
on the hint in the file format. It maps out which attributes that is 
simply copied, which may be modified and which needs to be generated by 
the server. However please be aware that that tailoring do require an 
understanding of what aspects to filter on and how that affect the 
session one presents to the client.

> we should reserve resources before the SETUP or before the PLAY? 

If you ask the question as which is simpler, of course that is 2. 
However the question one should ask on self is: Does the extra 
information and its usability warrant the extra complexity?

When it comes to resource reservation. It can happen at any stage from 
after receiving the SDP to PLAY request. However for certain aspects it 
might be better to do that early and minimize or avoid any delay in 
waiting for the reservation to complete.

> leave this to the congestion control. It's very convenient to implement that

What do you mean with the access device? The end-point terminal 
equipment or something in the access network? The reason the congestion 
control in the end-points needs to do this, is that they are the only 
one that can currently do end-to-end congestion control. One needs to 
remember that in a best-effort network the congestion can happen at any 
point in the network between the transmitter and the receiver.

> waste network bandwidth and hardware capability and be more complex.

Can you please elaborate how congestion control is wasteful? If you 
don't have more bits to transmit then you don't transmit them. If that 
upper limit is due to the adaptation mechanism in the sender that don't 
want to increase the media bit-rate, the lack of higher bit-rate 
alternatives or a user introduced upper boundary does not really matter.

Once more I think this debate needs to consider what things we try to 
control. Is it the transmission bit-rate and the handling of that or the 
policy regarding media bit-rates and other aspects of the session?

Cheers

Magnus Westerlund

---

From: Kylin Wei <[email-masked]>
Date: Wed, 05 Jul 2006 11:36:31 +0800

> have quite a large bit-rate span.

My draft is only to discuss an improvement. There is no doubt that a large
SDP body will consume network and decrease efficiency. Of course, you can
think that it's so insignificant. But if there are large numbers of bitrates
within one media file, such as hundreds or thousands of bitrates, I think
that it's worth to optimize that. If we can improve that, why don't we do
that? 
Furthermore, if a user or a client doesn't want to change transport bitrate,
is it necessary to offer full description of all alternative bitrates to
client?
Besides, if the bitrate range of media source was changed, a GET_PARAMETER
request with bitrate parameter is more flexible than a DESCRIBE request,
because it need only to get updated bitrate parameter value instead of a
full description of media source.
Of course, I may neglect some problems. Your comments are very helpful for
me.
Thank you. 

Kylin Wei

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Jul 2006 10:36:36 +0200

> Of course, I may neglect some problems. Your comments are very helpful for

Some observations, so far I at least has not seen files with enormous 
amounts of alternative encodings. Usually there are some reasonably 
large bit-rate steps between them. Somewhere around 20-50% seems quite 
common. Also in targeted deployment when the access technology has known 
capabilities it is possible to make smart choices here that allow good 
usage. In case the full access link is not available one backs down one 
step.

So if the number of alternatives gets beyond 50 we are way of and should 
definitely find some better alternative. However I don't think we are 
going there. This is for two reasons, tailoring of the content to the 
receiver client. The way adaptation is implemented that in most cases 
allows transmission at almost any rate. However the information in the 
SDP is practical for two reasons, provide guidance on the available span 
and to provide certain configuration at the different bit-rates. The 
second one can be problematic currently as the used media bit-rate may 
not always be obvious by the client.

I would like to state some objections against doing optimization, simple 
because one can. Normally one does optimization because the gain 
outweighs the cost of doing the optimization. And the cost can be 
reduced interoperability, cost of implementation, computational 
complexity, loss of generality, consumption of extension space etc. Thus 
as usual the impact of a change must be well considered.

One reason I am reluctant of doing anything in this space is that I 
would like to receive a bit more feedback on for example how well the 
3GPP REL6 adaptive streaming standard really work in the field. It would 
be good if IETF could manage to publish something general in this space 
that would help all users of streaming.

I am also concerned that despite the large deployment of RTSP there is 
quite little interest in doing RTSP work within IETF. I understand that 
the long time the update has taken contributes to this. I hope for more 
interest in actually fixing the foundation before rushing into 
extensions. RFC 2326 is not much of a foundation. I am still looking for 
both reviewers and help with editing of the rfc2326bis draft.

Cheers

Magnus Westerlund