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

"Ali C. Begen" <acbegen@gmail.com> Mon, 05 October 2015 15:15 UTC

Return-Path: <acbegen@gmail.com>
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 B95CA1ACF08 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 08:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=ham
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 pqEPShdX4Igr for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 08:15:23 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F092E1ACF09 for <mmusic@ietf.org>; Mon, 5 Oct 2015 08:15:22 -0700 (PDT)
Received: by obcgx8 with SMTP id gx8so130793855obc.3 for <mmusic@ietf.org>; Mon, 05 Oct 2015 08:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M+hytprOXjGHtUxnRQExTqRu7TcQRY8aTx/NQ/6U9P4=; b=ze98nxdRJQ5Ixuw7KNy94zQimr647k5naYtOWq6+rma3Cw1GVIxIHzUQaONc/SV7pq hjrVSeFOEVRHZZR4MecxWwIKyHIA0bhlbKjNS3ecywJo9iAlSru9ehmEEK/SLFp0csZS ABlJwfUDhov3maBSb2HxnTcPSXO7xzfq6BMaYKCKXt3FRpQmj8PtcP3sQpHcqVzo+l15 1rKg005my3hhO5sWTq7KIZV6Hjt/Z79qWQAqL5tBay65Tv841d5Hl+9O2OmvphOz0Ku0 PKntbyNK1ccKC99Uh4eTNPsUf9s7VKc/0LnbUJ0sDvDVAgCtHy3DIOFUjQq4PwWzVWZd V0bg==
MIME-Version: 1.0
X-Received: by 10.60.23.73 with SMTP id k9mr17016089oef.25.1444058122361; Mon, 05 Oct 2015 08:15:22 -0700 (PDT)
Received: by 10.202.213.83 with HTTP; Mon, 5 Oct 2015 08:15:22 -0700 (PDT)
In-Reply-To: <56095160.3040709@alum.mit.edu>
References: <55F15276.4030308@ericsson.com> <CAG371noODCX7Y7Thiyy9HK4XeOxJ4iqp89GsSkBV7oWspmeEmw@mail.gmail.com> <56095160.3040709@alum.mit.edu>
Date: Mon, 5 Oct 2015 18:15:22 +0300
Message-ID: <CAG371noDJDbR_=KeAD=ZVmNRn1i_Ps9-T092eBGB0g0xdAFzQw@mail.gmail.com>
From: "Ali C. Begen" <acbegen@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/QZ3WLEPw2R4N3n9KLLK3xNAkgxQ>
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 15:15:30 -0000

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?



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