[AVTCORE] Magnus Westerlund's Discuss on draft-ietf-avtcore-cc-feedback-message-08: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-avtcore-cc-feedback-message-08: 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-avtcore-cc-feedback-message/



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

In Section 7.

there is discussion that CCFB will replace the ECN FB format. I find that
appropriate however there is one function in ECN FB format that is not
discussed here. Section 7.2.1 in RFC 6679 states

An immediate or
      early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
      be generated on receipt of the first ECT- or ECN-CE-marked packet
      from a sender that has not previously sent any ECT traffic.  Each
      regular RTCP report MUST also contain an ECN Summary Report
      (Section 5.2).  Reception of subsequent ECN-CE-marked packets MUST
      result in additional early or immediate ECN feedback packets being
      sent unless no timely feedback is required.

There are no specification in this document that says that on reception of
ECN-CE marks the feedback packet should be sent using early or immediate. That
might not be required given a correctly configured session, where reporting
occur on the time scale. However, I think some discussion of the usage of early
reporting for ECN-CE mark is needed if longer reporting intervals are used.

Where there any discussion in the WG of this subject?


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

A. Section 3.1:
The document in one paragraph states the below:

The value of num_reports MAY be zero, indicating that there are no
   packet metric blocks included for that SSRC.

When reading this I did wonder what value should be set. This is given almost
at the end of the section in the below sentence.

 If no packets are received from an SSRC in a reporting interval, a
   report block MAY be sent with begin_seq set to the highest sequence
   number previously received from that SSRC and num_reports set to zero
   (or, the report can simply to omitted).

I think it would be clearer if the recommendation for begin_seq when
num_reports = 0 to be stated in the context of the first one. Then a more
focused sentence for the second part can explain the context in that paragraph.

B. Section 11:

Since RTP is an unreliable transport, a
   sender can intentionally leave a gap in the RTP sequence number space
   without causing harm, to check that the receiver is correctly
   reporting losses.

I think "without causing harm" is overstating it. I think without serious harm
is more correct. Depending on jitter buffer and usage of NACK to report packet
loss a gap in the sequence number can have cause retransmission requests. Also
if the gap is in the wrong place in a packet sequence, for example in the
middle of sequence of packets for a single video frame it could trigger a
repair action despite all data have been received.

I would state it is possible to insert gap with some consideration for the
media so that minimal impact is had.