[AVTCORE] Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtcp-green-metadata-10: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-avtcore-rtcp-green-metadata-10: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtcp-green-metadata/



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

Hi Yong, Christian, and Edouard,

Thank you for the effort put into this specification. Interestingly, this
reminds proposals made in the past to send feedback information for battery
optimization, etc. [1]

# Generic Comment

I don’t have access to the base ISO/IEC spec. I trust the WG and Gorry that the
content is aligned. Likewise, I trust that no changes in the two amendments in
https://www.iso.org/standard/83674.html#amendment impact the IETF spec. Right?

Please fine below some few points for DISCUSSion:

# Invalid values

CURRENT:
   The value of Frame Rate equal to 0 is invalid.
   …
   The value of Picture Width equal to 0 is invalid.
   …
   The value of Picture Height equal to 0 is invalid.

For all for these, I think we need to have "MUST NOT be sent".

# Receiver reaction

CURRENT:
   If the encoder is capable of adjusting its
   temporal-spatial resolution, it SHOULD take into account the received
   TSRR message for future coding of pictures.

## A encoder may be servicing several receivers. Adjusting may depend on
contexts not specific to a given session. Shouldn’t the behavior be governed by
a policy rather than a normative language? The signal received is no more than
a hint. Whether it is honored or not is local to the sender.

## Some text saying that requesters should be prepared for their adjustment
requests to be discarded. Likewise, say that no need to request a same
adjustment that was discarded.

## Shouldn’t guards be there against frequent change requests?

# Please indicate the unit for Frame rate for messages.

# Illegal values

CURRENT:
   Picture Width (14 bits): The coding picture width in the units of
   luma samples the media sender is using henceforth.

   Picture Height (14 bits): The coding picture height in the units of
   luma samples the media sender is using henceforth.

Should this discard 0?

# ABNF

CURRENT:
  rtcp-fb-ccm-param =/ SP "tsrr" ; Temporal-Spatial Resolution

I think we need to cite a normative ABNF reference?

# Operational considerations

Thanks for Section 7. I think that some ops warnings are needed for the actual
use of this feature. I suggest to add a discussion about the following:

The quality of experience may be impacted by honoring inadequate suggestions
from a receiver (e.g., default values). Users may complain about the quality of
service that was lowered because of such adjustment queries. Operators
deploying media senders should be aware of that risk and may calibrate hints
that they can accommodate (acceptable ranges). Tools and procedures for SLA
fulfillment and assurance should take this into account.


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

# Applicability Scope

CURRENT:
   This specification describes an RTCP feedback message format for the
   ISO/IEC International Standard 23001-11, known as Energy Efficient
   Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC
   29/ WG 3 MPEG System.  The RTCP payload format specified in this
   specification enables receivers to provide feedback to the senders
   and thus allows for short-term adaptation and feedback-based energy
   efficient mechanisms to be implemented.  The payload format has broad
   applicability in real-time video communication services.

I would insist on the general applicability of the feedback approach by making
this change:

NEW:
   The RTCP payload format specified in this document
   enables receivers to provide feedback to the senders
   and thus allows for short-term adaptation and feedback-based energy
   efficient mechanisms to be implemented.  The payload format has broad
   applicability in real-time video communication services.
   Specifically, it can be used for the
   ISO/IEC International Standard 23001-11, known as Energy Efficient
   Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC
   29/ WG 3 MPEG System.

# Energy optimization, Reduction Quality of Experience

CURRENT:
   ISO/IEC 23001-11 specification, Energy Efficient Media Consumption
   (green metadata) [GreenMetadata], specifies metadata that facilitates
   reduction of energy usage in the encoding, decoding, and display
   processes while preserving the user’s quality of experience.

Unless we have data that reflect that claim, I would avoid including such
claims in an IETF Standard Track document.

What about?

NEW:
   ISO/IEC 23001-11 specification, Energy Efficient Media Consumption
   (green metadata) [GreenMetadata], specifies metadata that may help
   reduction of energy usage in the encoding, decoding, and display
   processes.

# Ambiguity

CURRENT:
  Two main types of metadata are defined in the specification.

Which specification? Please make that clear in the draft.

# Internal APIs

CURRENT:
   A receiver
   operating on battery power can estimate its power consumption rate
   and, if necessary, request a reduction in pixel rate to ensure
   completion of the scheduled session.  Furthermore, when multiple
   tasks share a processing unit and a software decoder is allocated a
   limited portion of the available resources, the receiver can monitor
   real-time throughput and request a lower resolution or frame rate
   that aligns with the decoder’s processing capability.

These assumes that local APIs/Primitives are made available at the receiver
side to retrieve the state data. Can we say so in the text? Of course, the
details of these are internal and out of scope.

# Can we please remind the format in rfc4585#section-6.1 in the preamble of
Section 4?

# nit

OLD:
   The content of the FCI entry for the Temporal-Spatial Resolution
   Request …

NEW:
   The content of the FCI entry for the Temporal-Spatial Resolution
   Request (TSRR) …

# Formatting

OLD:
            Syntax of an FCI Entry in the TSRR Message

                                  Figure 1
NEW:

          Figure 1: Syntax of an FCI Entry in the TSRR Message

## Idem for Figure 2

# Various SSRCs

I spent some time checking the various SSRCs defined here and
rfc4585#section-6.1.

I found the answer deeper in the doc. Can we please move the following text to
be part of the SSRC description in 4.1.1?

CURRENT:
   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the request, and the "SSRC of media source"
   is not used and SHALL be set to 0.  The SSRCs of the media senders to
   which the TSRR applies are in the corresponding FCI entries.

# Scope

CURRENT:
   The reaction to the reception of more than one TSRR message by a
   media sender from different media receivers is left open to the
   implementation.

I thought the context is point-to-point sessions. I have no issue with this
behavior but which issue are we concerned here with?

# User interface or user?

CURRENT:
   Only if it is known that the user interface
   requires quick feedback, the message MAY be sent with early or
   immediate feedback timing.

I don’t parse the first part. Isn’t this about user experience? Of course, some
configuration can be provided to captured that as par of an user interface)

# Reword

OLD: The FCI field SHALL contain one or more TSRN FCI entries.

NEW: The FCI field SHALL contain at least one TSRN FCI entry.

Cheers,
Med

[1]
https://datatracker.ietf.org/doc/html/draft-mou-pcp-application-network-feedback-02#section-3.3