Subject: [MMUSIC] RID Open Issue 2: Definition of Bitrate

From: Adam Roach <[email-masked]>
Date: Mon, 2 Nov 2015 13:36:12 +0900

[I'm explicitly CC'ing Magnus on this mail because I expect him to have 
useful input here]

One of the issues we didn't have time to cover in MMUSIC today was the 
definition we use for "bitrate" in the RID document.
> mmusic-rid.pptx 
Currently, we have our own definition, which we believe is compatible 
with (but more complete than) TIAS:

    max-br, for bit rate in bits per second. The restriction applies to
    the media payload only, and does not include overhead introduced by
    other layers (e.g., RTP, UDP, IP, or Ethernet). The exact means of
    keeping within this limit are left up to the implementation, and
    instantaneous excursions outside the limit are permissible. For any
    given one-second sliding window, however, the total number of bits
    in the payload portion of RTP SHOULD NOT exceed the value specified
    in "max-br.”

That said, I know that there's been a lot of discussion in the past 
around formal bandwidth definitions, and I'd be just as happy to point 
to some external document for the definition, as long as there is one 
that is sufficiently complete.

As a related matter -- and I recognize that this isn't, strictly 
speaking, an MMUSIC issue -- we need a definition of "bandwidth" to use 
in the WebRTC statistics API (which allows JavaScript applications to 
retrieve information about sessions). It would be quite messy if we used 
a different definition for these two uses. Whatever we select for RID 
should be identical to what we use for WebRTC statistics. I don't think 
this should be constraining, but we should sanity-check that whatever we 
use makes sense in both places.

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Nov 2015 14:40:52 +0900

> definition we use for "bitrate" in the RID document.

Are you asking that someone create a very small document that has a
very precise definition of the bitrate definition you want to use here
(and elsewhere)?

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Nov 2015 14:45:09 +0900

> very precise definition of the bitrate definition you want to use here

That would be a potential solution. If there's a formal definition 
somewhere that could serve the purpose, that would be another.

Or we could conclude that the definition in the current document is 
sufficient -- although that seems like a rather remote possibility.

/a

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Nov 2015 16:17:41 +0200

Hi,

I agree that the definition is consistent with the TIAS from RFC3890.

I think it is the right value to use here and OK with specifying it here in the document since we have multiple places where bit rate parameter name is defined and specified and we should keep it this way. (BTW; it is close enough to the max-br in RFC6184 (H.264 RTP payload).

I have a question about the one second window. In H.323 systems where it was addressed the window was 3 second for averaging the max bit rate. Note that the major problem is when you have a full frame (typically source switch). For the rest of the time the actual average bit rate may be lower than the max-br value anyhow.

Roni

From: mmusic [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday, November 02, 2015 6:36 AM
To: [email-masked]
Cc: Magnus Westerlund
Subject: [MMUSIC] RID Open Issue 2: Definition of Bitrate

[I'm explicitly CC'ing Magnus on this mail because I expect him to have useful input here]

One of the issues we didn't have time to cover in MMUSIC today was the definition we use for "bitrate" in the RID document.

Currently, we have our own definition, which we believe is compatible with (but more complete than) TIAS:

max-br, for bit rate in bits per second. The restriction applies to the media payload only, and does not include overhead introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this limit are left up to the implementation, and instantaneous excursions outside the limit are permissible. For any given one-second sliding window, however, the total number of bits in the payload portion of RTP SHOULD NOT exceed the value specified in "max-br.”

That said, I know that there's been a lot of discussion in the past around formal bandwidth definitions, and I'd be just as happy to point to some external document for the definition, as long as there is one that is sufficiently complete.

As a related matter -- and I recognize that this isn't, strictly speaking, an MMUSIC issue -- we need a definition of "bandwidth" to use in the WebRTC statistics API (which allows JavaScript applications to retrieve information about sessions). It would be quite messy if we used a different definition for these two uses. Whatever we select for RID should be identical to what we use for WebRTC statistics. I don't think this should be constraining, but we should sanity-check that whatever we use makes sense in both places.

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Nov 2015 10:41:31 +0900

On 2 November 2015 at 14:45, Adam Roach <[email-masked]> wrote:
>> someone create a very small document that has a
> That would be a potential solution.

I think that's the solution I prefer, if it is the case that there is
no existing definition.  That document could note that this is a
tighter definition of TIAS.  The risk there is that we might be
tempted to redefine TIAS in the process.