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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Sep 2015 11:50:46 +0200

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 28 Sep 2015 16:19:58 +0300

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.

-acbegen

5.8.  Bandwidth ("b=")

      b=<bwtype>:<bandwidth>

   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.

      b=X-YZ:128

On Thu, Sep 10, 2015 at 12:50 PM, Magnus Westerlund
<[email-masked]> 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.
>
> 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
> 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.
>
> 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
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Sep 2015 10:40:32 -0400

> 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