Subject: [MMUSIC] Spencer Dawkins' Discuss on draft-ietf-mmusic-rid-14: (with DISCUSS and COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 16 Apr 2018 08:54:40 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-mmusic-rid-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please consider this to be an opportunity to explain something to an AD who
doesn't understand codecs super well ... so I doubt it will be hard to clear my
Discuss.

I'm not entirely comfortable that Section 8 isn't normative. Is the theory that
if (for example) I decide that my H.264 format parameter maps onto a
codec-independent parameter that you don't think it maps to, then you and I
probably would probably end up ignoring the rid and doing what we would do, if
one of us didn't support rids? If not, what's supposed to happen (normatively)?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

If "rid" actually means something, it might be nice to expand it in the
Abstract and Introduction. After the first couple of pages, I was guessing that
it means something like "RTP Stream Identifier", based on a quick scan of
https://tools.ietf.org/html/draft-ietf-avtext-rid-09, but that draft doesn't
ever expand "rid" or use "rid" in the text, so then I think I'm wrong, because
this draft also uses "rid-id", and I'm guessing that's probably not "RTP Stream
Identifier Identifier". By the time I get down to Section 5, I decide it means
"Restriction Identifier", but then I'm not any happier that I'm guessing
"rid-id" means "Restriction Identifier Identifier" :-)

I'm confused by the SHOULD NOT in

  o  max-fps, for frame rate in frames per second.  For encoders that
      do not use a fixed framerate for encoding, this value should
      restrict the minimum amount of time between frames: the time
      between any two consecutive frames SHOULD NOT be less than 1/max-
      fps seconds.

The related description of max-pps, also uses a SHOULD, but explains why
excursions outside this value are permissible.

(I'm also confused by "this value should restrict the minimum amount of time
between frames" - I saw that you're using RFC 8174 for keywords, but is this
just saying "this value restricts the minimum amount of time between frames",
or something else?)

I note that 8.1 and 8.2 both include something like

   Both
   correspond to restrictions on receiver capabilities, and never
   indicate sending restrictions.

Is that true for all format parameters, for all codecs? If so, perhaps that
should be explicit, in one of the normative sections (in which case, it
wouldn't be useful here). If not, are implementations supposed to know what to
do?

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Apr 2018 18:07:59 -0500

> one of us didn't support rids? If not, what's supposed to happen (normatively)?

I think what might have gotten lost here is that Section 8 is most 
emphatically *not* a mapping.

Section 8 is effectively an example section, serving to reinforce this 
statement from earlier in the document:

    The additional restrictions on individual streams are indicated with
    a new "a=rid" SDP attribute.  Note that the restrictions communicated
    via this attribute only serve to further restrict the parameters that
    are established on a PT format.  They do not relax any existing
    restrictions.

In terms of the possibility of varying interpretations, the guiding 
principle that this section is intended to drive home is: the RID 
restrictions, if understood, are honored independently of any other 
restrictions. So, if you came to the conclusion that (e.g.) the H.264 
parameter "MaxMBPS" didn't have the relationship with the RID "max-pps" 
parameter in this document, you're *still* signing up to keep your 
pixel-per-second count down below the value indicated in "max-pps."

Whether you do so is something that can be objectively evaluated. It's 
not really open for debate if you sign up to send no more than 10 
million pixels per second and yet send 100 million pixels per second 
whether you're honoring the constraint, and that evaluation occurs 
regardless of what you think about how many macroblocks you think you 
can send per second.

/a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Apr 2018 19:08:58 -0500

Hi, Adam,

On Mon, Apr 16, 2018 at 6:07 PM, Adam Roach <[email-masked]> wrote:

> Whether you do so is something that can be objectively evaluated. It's not
> really open for debate if you sign up to send no more than 10 million
> pixels per second and yet send 100 million pixels per second whether you're
> honoring the constraint, and that evaluation occurs regardless of what you
> think about how many macroblocks you think you can send per second.

That's roughly what I suspected, except smart.

I'll clear now, and thanks for the quick clue!

Spencer