Re: [MMUSIC] Simulcast worries: What bitrate? (from the WEBRTC list)

Adam Roach <adam@nostrum.com> Mon, 01 February 2016 21:22 UTC

Return-Path: <adam@nostrum.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 80E391B36E3 for <mmusic@ietfa.amsl.com>; Mon, 1 Feb 2016 13:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 1Br5bJFW7EC1 for <mmusic@ietfa.amsl.com>; Mon, 1 Feb 2016 13:22:25 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6F8AA1B2DDE for <mmusic@ietf.org>; Mon, 1 Feb 2016 13:22:25 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u11LME2h041009 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Feb 2016 15:22:15 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <56279638.9030007@alvestrand.no> <5628F926.7060304@nostrum.com> <562A37FC.1010805@ericsson.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <56AFCC86.7050809@nostrum.com>
Date: Mon, 1 Feb 2016 15:22:14 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <562A37FC.1010805@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Dxdl9t2nRp3jA1zaJzpmSngkjLc>
Subject: Re: [MMUSIC] Simulcast worries: What bitrate? (from the WEBRTC list)
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, 01 Feb 2016 21:22:27 -0000

On 10/23/15 08:37, Magnus Westerlund wrote:
> Den 2015-10-22 kl. 16:56, skrev Adam Roach:
>> On 10/21/15 08:42, Harald Alvestrand wrote:
>>> I'd be happier if we could say "this is the same bitrate as b=TEAS" or
>>> something like that - if an implementation has to stick to multiple
>>> definitions of bitrate for the same media flow, which will happen with
>>> a=rid .. max-br and b= in the same message, it would be nice to be able
>>> to use the same counters.
>>
>> I'm good either way. We can keep this as-is, or add a reference to
>> RFC3890. Anyone want to speak for or against moving over to the RFC3890
>> definition of bandwidth?
>
> Hi,
>
> I am of the opinion (having authored RFC 3890) that we should use a 
> more well defined bit-rate definition than what is in TIAS.
> In fact the current definition is well matching that of TIAS, with the 
> additional constraints of a measuring interval. I think this is the 
> minimal improvement we should do.

I read this to say that you think the text in draft-ietf-mmusic-rid is 
sufficient without any external reference. I'm happy with that as an 
answer. :)

> I can argue for an even more specific bandwidth definitions. My 
> personal position is that the stream specific ones (SMT and SLT) in 
> our SDP bandwidth proposal (now expired) actually makes sense to be 
> used with RID:
> https://www.ietf.org/archive/id/draft-westerlund-mmusic-sdp-bw-attribute-02.txt 
>

All of the definitions in that document are problematic for the vast 
majority of WebRTC's use cases, since they all include the phrase 
"including protocol overhead."   In general, web browsers operate high 
enough on the protocol stack that getting access to "protocol overhead" 
introduced by layers 1 through 4 is simply implausible.

/a