Subject: Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Jun 2003 15:10:01 +0200

Hi Emre,

[email-masked] wrote:
> Simply, I propose to change the MUST statement in the session level TIAS value to a MAY statement and an explanation of the above case (sum of media level TIAS <= session level TIAS). An SDP generator can be clever enough to calculate the actual bandwidth needed by analysing the content, if available. Or it can just add up the media level TIAS values. The MUST statement omits the first possibility.
> 

I hope that you mean: (sum of media level TIAS >= session level TIAS)

Okay, I can agree to do that. There will be a paragraph or two to 
explain the implications of a session level TIAS smaller than the sum of 
them.

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

---

From: [email-masked]
Date: Mon, 16 Jun 2003 15:55:31 +0300

Hi Magnus,
Comment below:

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 13 June, 2003 11:32
> To: Aksu Emre (NMP/Tampere)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Questions/Comments on
> draft-ietf-mmusic-sdp-bwparam-03.txt
> 
> 
> Hi Emre,
> 
> Comments below.
> 
> > Hi Magnus,
> >>The session level value is bit redundant. It is simply the 
> sum of all 
> >>media streams and reflect the total amount of bandwidth needed to 
> >>accommodate this session. This can of course be calculated by 
> >>a receiver.
> >>
> > 
> > 
> > Also, in the <draft-ietf-mmusic-sdp-bwparam-03.txt>, in 
> section 6.2.3, Usage rules section, it is stated that:
> > "...The session level value, if present, MUST be the sum of 
> all media level values.".
> > 
> > I believe this is a true statement for constant bitrate 
> streams. But what about VBR cases? At least for RTP usage, 
> the definition of bandwidth is for max bandwidth consumption 
> over a 1 second sliding window, right? Hence, max bandwidth 
> consumption at session level may be smaller or equal to the 
> sum of these max bandwidths at media levels. And if the 
> client is making resource reservation for QoS purposes, then 
> there may possibly be a redundant amount of bandwidth 
> allocation if the session level bandwidth is simply the 
> absolute sum. Therefore, I believe that the session level 
> TIAS bandwidth value MAY be smaller than the sum of the media 
> level TIAS values. 
> 
> Yes, you are correct that if one has several VBR streams they can be 
> scheduled so that the sum of all the streams has a lower maximum.
> 
> The session level application of the TIAS value has been something I 
> have been had different views on, during the development of the this 
> draft. For a while I had TIAS only as media level attribute. 
> As I see it 
> there are three possible ways to go with this issue.
> 
> 1. Remove TIAS and maxprate at session level. This will remove the 
> redundancy compared to ver 03 definition. It will simplify 
> and prevent 
> any possibilities for contradictions between the values.
> 
> 2. Keep it as defined today as the sum of all media streams 
> values. Is 
> redundant, has the possibility to be contradicting between 
> session level 
> and media level.
> 
> 3. Define is at being the actual value when all media streams 
> are sent. 
>   Will allow for getting a whole session value that are less then the 
> sum of media level values. Will be more complex and will require more 
> implementation to consider if both values are present. A 
> given value on 
> session level will only be true if all media streams are 
> actually used. 
> Not known how often you can actually use this.
> 
> Looking at this list I now see that using 2 as current 
> proposed may be 
> the least good solution. I would like to get more input if 
> they believe 
> in 3.
> 

Best Regards,
Emre

Emre Baris Aksu
Nokia Mobile Phones