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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 05 October 2015 17:01 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A71AD362 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 10:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level:
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_INVITATION=-2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_62=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUW0QM6RAbN5 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 10:01:51 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AC41AD35D for <mmusic@ietf.org>; Mon, 5 Oct 2015 10:01:50 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with comcast id RUzD1r00427uzMh01V1qjt; Mon, 05 Oct 2015 17:01:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id RV1n1r00U3Ge9ey01V1pr6; Mon, 05 Oct 2015 17:01:50 +0000
To: "Ali C. Begen" <acbegen@gmail.com>
References: <55F15276.4030308@ericsson.com> <CAG371noODCX7Y7Thiyy9HK4XeOxJ4iqp89GsSkBV7oWspmeEmw@mail.gmail.com> <56095160.3040709@alum.mit.edu> <CAG371noDJDbR_=KeAD=ZVmNRn1i_Ps9-T092eBGB0g0xdAFzQw@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5612ACFA.9060400@alum.mit.edu>
Date: Mon, 5 Oct 2015 13:01:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAG371noDJDbR_=KeAD=ZVmNRn1i_Ps9-T092eBGB0g0xdAFzQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444064510; bh=z7+b5AReu7Z8CW8X3AiFtvEIphFYpzxJBKwebMW6+ao=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WvhOusn12ij6Ss2WwR3Ec0tBHFejFdzwk34CTfLlNVQVocsW3fmjkgPFEFLNjGmx0 kMOEaXpPWcEQMUEQnyyAmTcfqTnFc4dH0kiVOQELmnhbln9wEZ39Qc/2QvwQORF3nq R5lmDXQiyeSYYMEvXN//FpX19zVCDyioSZZu2pWEDqb8jDyQ/QM3PBR8XCZftmhw77 MYpBtYNEv5hzJw4ZPZSkEwMj/aoTyeBb/pIGy0LoJBfuBbW1dAZsXtOhUTXoHFFZDD YpbOLWGgVPpDfE7a/wmAASwuywfsUdLn2TkCParNwtOhXqyQvf73hmOKUN2/JMQ81R HM4zjKAHN3mHQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/NxII9GJRZPgIrFg66OIBGbt6ZQs>
Cc: "mmusic \(E-mail\)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Making b=CT session level only - draft-ietf-mmusic-rfc4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 17:01:53 -0000

On 10/5/15 11:15 AM, Ali C. Begen wrote:
> Hi Paul
>
> Yes the phrase is used twice but they are for different levels
> (session and media). I think explicit text is the most straightforward
> approach.
> Or is the part that says "from the scope" not clear to you?

I didn't mean to imply that there is anything wrong with using it twice.

My problem is that I don't know what "bandwidth implicit from the scope" 
means, or even what "scope" refers to here.

I *guess* that scope means "session" or "media" level scope? If so, what 
bandwidth is implicit for each scope?

	Thanks,
	Paul

> On Mon, Sep 28, 2015 at 5:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> 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
>>> <magnus.westerlund@ericsson.com> 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  +46 10 7148287
>>>> Färögatan 6                 | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>>>> ----------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>