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

Suhas Nandakumar <suhasietf@gmail.com> Mon, 05 October 2015 18:23 UTC

Return-Path: <suhasietf@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 035DD1B32D5 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 11:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, HTML_MESSAGE=0.001, 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 EDZbhWfylQ1L for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 11:23:04 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 2BDC21B32C2 for <mmusic@ietf.org>; Mon, 5 Oct 2015 11:23:04 -0700 (PDT)
Received: by vkfp126 with SMTP id p126so102191284vkf.3 for <mmusic@ietf.org>; Mon, 05 Oct 2015 11:23:03 -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; bh=mS/kqkV+r5duCbkvkNiOrdb9abDnQ4gVu+2C3T5J3mw=; b=FLSa+EYNZbx0P2tx1zPwt0wyzQo4joQAImPjglfntG6ykM+iAUXIa72NrUfORdnq5z 5a/XvaZlAhuzKejIoFbuUIJMarc+PjCHre+iX/f5VncCIYF8+HTEkvwe24xem86LVV0j WhLLFd25CZPgVKuDCb3+pYreCDOzXVci4ytpKWZTOuVnI7/qZcIUY3YTCL+Zniuuwk/J T5VfUeOBGqGsHqdLg85YXpszIK9GyqpuDm+EvPnTO4o/rn5kmU74shqVUbegfT6do9cC eIzUAGc/lu6cQvH396XQALKPemA6aD/rF3KseLVx851gmXBxxjRbesAi4FZlSIRgPnKm U7Fg==
MIME-Version: 1.0
X-Received: by 10.31.16.11 with SMTP id g11mr20785017vki.152.1444069383191; Mon, 05 Oct 2015 11:23:03 -0700 (PDT)
Received: by 10.31.172.151 with HTTP; Mon, 5 Oct 2015 11:23:03 -0700 (PDT)
In-Reply-To: <55F15276.4030308@ericsson.com>
References: <55F15276.4030308@ericsson.com>
Date: Mon, 05 Oct 2015 11:23:03 -0700
Message-ID: <CAMRcRGTW8OW9vkFcXoHx2YnZipVf_MicpPh7jGKWoy5W=imD8g@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114363ac9dc40a05215f9a84"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/nAIKfRLzbgaxLjU_S6-iNSbbppY>
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 18:23:08 -0000

>From Magnus  on Mux Attributes usage of b=CT:

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.


[Suhas] : I am fine with changing the level to B and category to IDENTICAL
as suggested ,

I do think need to update the SDP IANA registry to make that change. I am
assuming that RFC4566bis will be doing that change.

On the note about usage of CT, does the below text sounds good

Note:
 Specifying the SDP b=CT attribute at the media level represents
approximate aggregate bandwidth for all the media streams multiplexed and
the value must be identical across all the media streams multiplexed.
However in non-bundled scenarios, a b=CT media level attribute's
interpretation is not clearly identified and MUST NOT be specified.



Please let me know if the text suggestion looks fine and I can submit a new
version to match the same.


Thanks
Suhas


On Thu, Sep 10, 2015 at 2:50 AM, 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
>