Re: [MMUSIC] Making b=CT session level only - draft-ietf-mmusic-rfc4566bis

[Paul Kyzivat <[e-mail]>]

On 9/28/15 9:19 AM, Ali C. Begen wrote:
> Hi Magnus
>
> Here is my suggested text based on your input. Changes are in the CT
> and AS definitions. Let me know if you are happy with this text.

The following phrase is used twice: "... is different from the implicit 
value from the scope ...".

I don't understand what this is trying to tell me. Can it be clarified? 
(I realize this is also used in the old text, but still it is a problem 
to me.)

	Thanks,
	Paul

> -acbegen
>
> 5.8.  Bandwidth ("b=")
>
>        b=<bwtype>:<bandwidth>
>
>     This OPTIONAL line denotes the proposed bandwidth to be used by the
>     session or media.  The <bwtype> is an alphanumeric modifier giving
>     the meaning of the <bandwidth> figure.  Two values are defined in
>     this specification, but other values MAY be registered in the future
>     (see Section 8 and [RFC3556], [RFC3890]):
>
>     CT If the bandwidth of a session is different
>        from the bandwidth implicit from the scope, a "b=CT:..." line
>        SHOULD be supplied for the session giving the proposed upper limit
>        to the bandwidth used (the "conference total" bandwidth).  Similarly, if
>        the bandwidth of bundled media streams in an m line is different from
>        the implicit value from the scope, a "b=CT:..." line SHOULD be supplied
>        in the media level. The primary purpose of this is to give an
> approximate idea as to
>        whether two or more sessions (or bundled media streams) can
> coexist simultaneously.
>     Note that CT gives a total bandwidth figure for all the media at all
>     endpoints.
>
>     AS The bandwidth is interpreted to be application specific (it will
>        be the application's concept of maximum bandwidth).  Normally,
>        this will coincide with what is set on the application's "maximum
>        bandwidth" control if applicable.  For RTP-based applications, AS
>        gives the RTP "session bandwidth" as defined in Section 6.2 of
>        [RFC3550]. Note that AS gives a bandwidth figure for a single
> media at a single
>     endpoint, although there may be many endpoints sending simultaneously.
>
>     A prefix "X-" is defined for <bwtype> names.  This is intended for
>     experimental purposes only.  For example:
>
>        b=X-YZ:128
>
>     Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
>     SHOULD be registered with IANA in the standard namespace.  SDP
>     parsers MUST ignore bandwidth fields with unknown modifiers.
>     Modifiers MUST be alphanumeric and, although no length limit is
>     given, it is recommended that they be short.
>
>     The <bandwidth> is interpreted as kilobits per second by default.
>     The definition of a new <bwtype> modifier MAY specify that the
>     bandwidth is to be interpreted in some alternative unit (the "CT" and
>     "AS" modifiers defined in this memo use the default units).
>
> On Thu, Sep 10, 2015 at 12:50 PM, Magnus Westerlund
> <[e-mail]> wrote:
>> Hi,
>>
>> The chairs have been nagging me about some action points that I got assigned
>> in my absence at the IETF92 MMUSIC session. So lets try to settle them.
>>
>> The main question for one of them is if SDPbis should make the b=CT
>> bandwidth modifier into a session level only parameter?
>>
>> So, it is clear that session level CT value is the total upper limit for
>> bandwidth consumption, independent on direction incoming or outgoing from an
>> endpoint for this Multimedia session.
>>
>> Note that I believe it to be Multi-media session rather than communication
>> session. This is due to that SDP is used to describe a multi-media session.
>>
>> I would also note that for Offer/Answer it is not clear if the offer applies
>> to the offerer or the answerer. This is due to the non-directionality
>> declaration of CT. My personal interpretation is that the offer applies to
>> the answerer and the answer applies to the offerer. But, this is one thing
>> that should be clarified if anyone dares revise RFC 3264.
>>
>> Regarding CT on media level (m=) I think the interpretation of it also here
>> is not that unclear. It is just that it has no meaning in the pre-bundle
>> Offer/Answer context, where one had only one Media source in that RTP
>> session the m= created. But if one looks at SDP/SAP usage then CT do make
>> much more sense. In multi-party usages like multicast, defining an AS for
>> one media source a CT value for the aggregate across all session endpoints
>> do make sense.
>>
>> Which leads me to want to clarify that CT on media level is possible and has
>> meaning but only in contexts where one m= line (or a bundle group of m=
>> lines) may contain multiple media sources and thus media streams and
>> therefore an aggregate limitation makes sense.
>>
>> If people agree with this I think we need to make some amendment both to
>> SDPbis and to Mux-attributes to make this clear.
>>
>> SDPbis (-15) says:
>>
>> 5.8.  Bandwidth ("b=")
>>
>>        b=<bwtype>:<bandwidth>
>>
>>     This OPTIONAL line denotes the proposed bandwidth to be used by the
>>     session or media.  The <bwtype> is an alphanumeric modifier giving
>>     the meaning of the <bandwidth> figure.  Two values are defined in
>>     this specification, but other values MAY be registered in the future
>>     (see Section 8 and [RFC3556], [RFC3890]):
>>
>>     CT If the bandwidth of a session or media in a session is different
>>        from the bandwidth implicit from the scope, a "b=CT:..." line
>>        SHOULD be supplied for the session giving the proposed upper limit
>>        to the bandwidth used (the "conference total" bandwidth).  The
>>        primary purpose of this is to give an approximate idea as to
>>        whether two or more sessions can coexist simultaneously.
>>
>>     AS The bandwidth is interpreted to be application specific (it will
>>        be the application's concept of maximum bandwidth).  Normally,
>>        this will coincide with what is set on the application's "maximum
>>        bandwidth" control if applicable.  For RTP-based applications, AS
>>        gives the RTP "session bandwidth" as defined in Section 6.2 of
>>        [RFC3550].
>>
>>     Note that CT gives a total bandwidth figure for all the media at all
>>     sites.  AS gives a bandwidth figure for a single media at a single
>>     site, although there may be many sites sending simultaneously.
>>
>>     A prefix "X-" is defined for <bwtype> names.  This is intended for
>>     experimental purposes only.  For example:
>>
>>        b=X-YZ:128
>>
>>     Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers
>>     SHOULD be registered with IANA in the standard namespace.  SDP
>>     parsers MUST ignore bandwidth fields with unknown modifiers.
>>     Modifiers MUST be alphanumeric and, although no length limit is
>>     given, it is recommended that they be short.
>>
>>     The <bandwidth> is interpreted as kilobits per second by default.
>>     The definition of a new <bwtype> modifier MAY specify that the
>>     bandwidth is to be interpreted in some alternative unit (the "CT" and
>>     "AS" modifiers defined in this memo use the default units).
>>
>>
>> I think this needs to be modified in a couple of different places.
>>
>> First I think the CT explanation text should be expanded to discuss this
>> context of possible multiple streams in the context of one m= line, and that
>> in that and only that case does media level make sense.
>>
>> Then I would like to move up the text in the note about CT into the main
>> definition and change "sites" to "endpoints".
>>
>>
>> And Mux-attributes (-10) says:
>>
>> 6.1.  RFC4566 - SDP: Session Description Protocol
>>
>>     [RFC4566] defines the Session Description Protocol (SDP) that is
>>     intended for describing multimedia sessions for the purposes of
>>     session announcement, session invitation, and other forms of
>>     multimedia session initiation.
>>
>>     +------------+-----------------------------------+-------+----------+
>>     | Name       | Notes                             | Level | Mux      |
>>     |            |                                   |       | Category |
>>     +------------+-----------------------------------+-------+----------+
>>     | bwtype:CT  | Not Impacted                      | S     | NORMAL   |
>>     |            |                                   |       |          |
>>     | bwtype:AS  | For the media level usage, the    | B     | SUM      |
>>     |            | aggregate of individual bandwidth |       |          |
>>     |            | values is considered              |       |          |
>>     |            |                                   |       |          |
>>     +------------+-----------------------------------+-------+----------+
>>
>>                            RFC4566 bwtype Analysis
>>
>>
>> So here Level needs to be changed to B (Both). Then I would state that the
>> Category should be IDENTICAL. I don't know what it would mean to have
>> different CT values for different media sources in a bundle group.
>>
>> It might be worth adding a Note about CT, and why CT is much more useful in
>> a bundle-group than on a non-bundled m= line.
>>
>> Comments on this?
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> Färögatan 6                 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>