Subject: RE: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

From: [email-masked]
Date: Wed, 9 Oct 2002 18:23:24 +0300

Hi,

two comments on the draft:

- The computation of the h-size value in section 6.3 should be in Kbps. This is currently not specified.

- I think that it is also useful to have another "prate" parameter describing the average packet rate, in addition to the current (maximum) packet rate parameter. In real-time converational applications for example it is not possible to estimate in advance the max packet rate in the 1-second window, but the application could range packet rates between an average and a possible maximum. This could help resource reservation systems where it is possible to specify guaranteed and maximum bit rates separately.

Regards,

Igor

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 4:52 PM
To: Amir Wolf
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] Presenting
draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi Amir,

Comments below:

Amir Wolf wrote:

>
>Hi Magnus,
>I agree that a packet rate header may be more sufficient.
>Sending the blocksize header in the DESCRIBE request might be a good solution since the server will be able to set the a=prate according to the blocksize.
>However, one case is still uncovered  - if the client would like to get different blocksizes for audio and video - it can not be signaled in the DESCRIBE request.
>therefore I think that if a server supports the blocksize header - it should response about it in the setup request.
>

RFC 2326 is rather unclear on when the blocksize header can be used. In 
the draft to update RTSP blocksize is currently allowed in DESCRIBE, 
SETUP and PLAY. I agree in cases that you want to have different 
blocksizes to different media, you must use it in SETUP. Unless we 
specify a packet rate response header for RTSP the servers way of 
telling of a change in prate is to use ANNOUNCE. The right way forward 
here is probably to define a new header, but more comments are welcome 
on the issue.

>
>Regarding your question about the Average Bitrate - I think that the main use of the bitrate information is to set the client Buffers in a way that it will not overflow,
>However in some cases this can be insufficient especially when you have a constant bitrate and just one peak for a second, Therefore I think that we can add an optional header specifying the Average bitrate.
>

Thanks for your opinion. Another usage of the bitrate parameters is for 
reservation of resources. In that case the maximum makes sense. The 
maximum value can also be interpreted as with this bandwidth everything 
will work fine. More input please.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Oct 2002 14:06:49 +0200

Hi Igor,

Thanks for the comments, see my comments below:

>- The computation of the h-size value in section 6.3 should be in Kbps. This is currently not specified.

Yes, I can add such a clarification.

>- I think that it is also useful to have another "prate" parameter describing the average packet rate, in addition to the current (maximum) packet rate parameter. In real-time converational applicat…

Okay, I see that your motivation is that a maximum packet rate may be 
significantly higher than the most likely packet rate to use. Therefore 
if one would reserve resources based on maximum one would waste resource 
that would almost never be used. With an average packet rate one would 
be able to calculate, an bitrate most likely to work, and another 
guaranteed to work. However these calculated values does not directly 
correspond to the reserved bitrate terms guaranteed and maximum.

To summarize the added parameter suggestions:
- Add a average packet rate "pavgrate" so that application that most 
likely will be using a packet rate significantly different from the 
maximum it may ever require can do so. For clarity it would be good to 
rename "prate" to "pmaxrate".
- Add a new bandwidth modifier that specifies the average bitrate of the 
application. A problem is to define how an average should be defined. In 
cases when an application are not sending constantly an average becomes 
skewed downwards.

I think the definition on an "average" packet rate is easier than a 
bandwidth modifier with some type of average value. I would appreciate 
more input and also suggestions on how to specify these values.

Regards

Magnus Westerlund

---

From: [email-masked]
Date: Fri, 11 Oct 2002 10:27:19 +0300 (EEST)

Hello all,

I've read the draft and I need some clarification on the utility of the
SDP bandwidth field (b=...).
What is the purpose of this SDP field?
b=CT seems to be some kind of session admission control;
b=AS may have some usage on resource reservation;
b=rtcpbw is to control the bandwidth used by RTCP (this one is clear).

It is still unclear how an application would use this field (especially
CT&AS) in the session capabilities 'negotiation' (what is the meaning of
the field in an offer?, what is the meaning of the field in answer?).

My opinion is the CT&AS are irrelevant in a SIP SDP OFFER, because the
bandwidth that will be used on the network it is ultimately chosen
by answerer when selecting the audio/video codecs of the session.
And an CT/AS bandwidth constraint in an OFFER can be easily overrinden
by offering only certain codecs. The same irrelevance concerning
CT&AS happens in a SIP SDP ANSWER.

If the purpose of 'b' is network resource reservation for the session
a sender would want to use RSVP to reserve bw for EACH flow that it is
sending. And this makes the 'b' field REDUNDANT.

If the purpose of 'b' is just bandwidth signaling (the maximum bw that an
application would require) as for RTSP, this can be computed in a rough
way by computing, for each media description, the bw for the codec with
the highest bw using the worst (minimum) packetization interval and then
the sum of the computed bws. This also makes the 'b' field REDUNDANT.

The only modifier that makes sense is the one concerning RTCP bandwidth,
and I think can be rewritten as a media level attribute('a=') and may
appear only in those media descriptions that use RTP as transport protocol.

btw, are there any implementations that really use the 'b' field?

Best regards,
Dan Firac,
Software Engineer,
Redline Communications, Romania.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Oct 2002 13:14:27 +0200

Hi Dan,

I can't agree with you that the b=<bw-modifier>  are not needed. See 
comments to your reasoning below.

>CT&AS happens in a SIP SDP ANSWER.

You may be correct in that for some codecs the in a SIP/SDP with 
offer/answer the b=AS is not that useful. However for some codecs this 
parameter is very useful. If I offer you a H.263 video stream, how will 
you know within which limits I as a sender will keep the data stream. 
The codec has rather wide range of data rates it can produce. This can 
be solved by me including the b=AS. 

In the case of streaming using RTSP the b=AS is very useful. It is the 
primary way a server (sender) can inform the client (receiver) what data 
rates it will receive.  

To my understanding the use of CT is rather limited. However b=AS is 
wide spread and also required in for example 3GPP's Packet-based 
Streaming Service (PSS). As I point out in 
draft-westerlund-mmusic-sdp-bwparam-00.txt the AS is not without its 
problem and I propose a new modifier that will hopefully be even more 
useful.

>sending. And this makes the 'b' field REDUNDANT.

I have only rudimentary understanding on how the signaling with RSVP is 
done. But due to the information and responsibility division in a 
streaming application, the following should happen. The server inform 
the client about what bitrates it will send with b=AS. The client 
decides if it will reserve resources and do so (As it has to pay). When 
requesting the reservation it needs the b=AS values.

>the sum of the computed bws. This also makes the 'b' field REDUNDANT.

I don't agree that it can be derived with any precision at all. Some 
codec that has fixed rate, are of course easy, but many of the newer 
codecs use variable rate or allows selection of the encoding rate. A 
good example is the MPEG audio (AAC) and Video codecs. They can work in 
a wide range of bitrates. It is a big difference between explicitly 
saying that this AAC stream will not use more than 48 kbit/s and see 
that this stream is a AAC and can be any bitrate between 16-256 kbit/s. 
So the b=AS is not redundant.

>appear only in those media descriptions that use RTP as transport protocol.

See draft-ietf-avt-rtcp-bw-05.txt for the real RTCP bw modifiers. With 
the b= standardized since long, useful and extendable I don't see any 
advantage of switching to a=attribute. 

>btw, are there any implementations that really use the 'b' field?

Yes, any terminal supporting the 3GPP Packet-based Streaming Service 
standard. There is interoperability tests underway, in for example IMTC 
and products are starting to appear on the market.

The SIP people will have to speak for themselves, but I can be rather 
certain that need b=AS too.

Regards

Magnus Westerlund

---

From: [email-masked]
Date: Mon, 14 Oct 2002 14:53:09 +0300 (EEST)

Thank you for your comments.
I have only one suggestion about the next paragraph. See below.

Dan Firac,
Software Engineer,

> requesting the reservation it needs the b=AS values.

So, assuming that the client will request the reservation by himself,  the
client will have to use b=AS to request bandwidth from the network.
Right?

My suggestion is: the b=AS should contain the information very similar to
that a client would use in a reservation request. And when say that, I
have in mind the Token Bucket parameters:
- bucket size (bytes)
- rate (bps)
- peak-rate (bps)
- mtu, mpu
This are the parameters that the network understands (assuming the IntServ
model with RSVP). So b=AS parameters should be easily mapped into a RSVP
request. I guess they can be deducted, even for variable video codecs,
but, as a author of draft regarding bandwidth, you should figure out very
clearly how the client would USE the b=AS parameters!!

If I am right about the sender requesting reservation for its flows, then
b=AS is a redundant resource reservation signalling in an IntServ
enabled network. You agree on this?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Oct 2002 16:12:43 +0200

Hi Dan,

Comments below:

>enabled network. You agree on this?
Yes, b=AS is to my knowledge in most cases the only information it has 
before doing the reservation. The codec may in some cases give an 
indication on the streams shape. One must however ask, are there any 
need for any more elaborate parameters for resource reservation?

And I agree that for sender reserved flows b=AS is redundant for 
resource reservation. But it is also useful to other things, e.g. to 
know that the codec/host can handle the media bitrate.

The problem with the b=AS and my derived b=TIAS is that the parameter is an application specific maximum. So the exact meaning behind the maximum can't determine without a context. Also the usage of attribute is application dependent. But it may be used for:
- Resource reservation
- Determine media-bitrate to know that terminal capabilities can handle the decoding.
- Determine if the offered media is affordable from transport cost 
- Determine if ones connection can handle the offered media.
- Admission control for proxies, gateways, etc.

You may be correct that one should take the opportunity to present the use cases and interaction with different signaling protocols. However I don't believe that we today will cover all possible future use-cases. 

Regards

Magnus Westerlund

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Oct 2002 22:35:19 -0400

Comments inline

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Magnus Westerlund
> Sent: Monday, October 14, 2002 10:13 AM
[snip]
> You may be correct that one should take the opportunity to
> present the use cases and interaction with different signaling
> protocols. However I don't believe that we today will cover all
> possible future use-cases.

This is the most critical point.  "No use cases, no use" is a good motto.
I'm really not sure why we're doing this.  On the one hand, I fully agree
with the draft's assertion that AS is useless.  I also agree that TIAS
solves many of the problems.  However, a lot of the list discussion could be
better focused if we knew why we care about the parameter.

If the parameter is for the client for buffer allocation, then the data
stream bit rate is really all it needs to know about, as presumably most
operating systems or network interfaces make the appropriate allocations for
header overhead.  On the other hand, if the parameter is for network
resource reservation, then the parameters appropriate for network resource
reservation are what should be specified.

> >have in mind the Token Bucket parameters:

This makes sense to me, because...

> >This are the parameters that the network understands (assuming
[snip]

Note that with these parameters, the NAT-PT device can "do the right thing",
as only one of the parameters depends on transport (mtu), and even that
shouldn't be there.  The application really only cares about mpu, and can
calculate mtu.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Oct 2002 13:15:48 +0200

Hi Eric,

See comments below:

>better focused if we knew why we care about the parameter.

In the new version of the draft which I submitted today, I have included 
use cases. I so far have found 4 purposes of TIAS. From 
draft-westerlund-mmusic-sdp-bwparam-01.txt:

7.2.1. Usage

   A new bandwidth modifier is defined to at least be used for the
   following purposes:

   -  Resource reservation. A single bitrate can be enough to use for
      resource reservation. Some characteristics can be derived from the
      stream, codec type, etc. In some cases more information is needed,
      then another SDP parameter will be required.

   -  Maximum media codec rate. With the definition below of "TIAS" the
      given bitrate will mostly be from the media codec. Therefore it
      gives a good indication on the maximum codec bitrate required to
      be supported by the decoder.

   -  Communication bitrate required for the stream. The "TIAS" value
      together with "maxprate" can be used to determine the maximum
      communication bitrate the stream will require. By adding all
      maximum bitrates from the streams in a session together, a
      receiver can determine if its communication resources are
      sufficient to handle the stream. For example a modem user can
      determine if the session fits his modems capabilities and the
      established connection.

   -  Determine the RTP session bandwidth and derive the RTCP
      bandwidth. The derived transport dependent attribute will be the
      RTP session bandwidth in case of RTP based transport. The TIAS
      value can also be used to determine the RTCP bandwidth to use when
      using implicit allocation. RTP [6] defines that if not explicitly
      stated, additional bandwidth shall be used by RTCP equal to 5% of
      the RTP session bandwidth. The RTCP bandwidth can be explicitly
      allocated by using what is defined in [9].

I think you raises a valid question if one should be satisfied with a 
single bandwidth modifier or produce more tailored ones. For the last 
two I think TIAS is the right parameter. For maximum codec rate one 
could have think of more advanced parameters with several values giving 
max, min, distribution, etc. However such a parameter does not fit 
within the "b=" concept.

When it comes to resource reservation the maximum rate can certainty be 
enough. However more elaborate schemes can be used, for example the RSVP 
parameters. Well, RSVP is not the only way of doing reservations. There 
exist other systems that uses SDP information, e.g. the radio bearer 
allocation in UTRAN within the 3G system.

I would like to have further feedback on this. More use cases are 
welcome, especially with a proper explanation.

Regards

Magnus Westerlund