[AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-avtcore-rtp-scip-04: 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-rtp-scip/



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

Thanks for working on this specification. My understanding is that SCIP is not
a typical audio/video codec and intention here is to defice  a payload format
used along with other audio/video codecs. Thanks to Olivier Bonaventure for an
excellent TSVART review.

I would like to discuss the followings -

- It is not clear to me what RTP profile should be used with this payload
format. The RTP profiles are mentioned only in the security considerations. I
think this specification would not be sufficient to be implemented without
specifying the profile usage. I am getting that all the control messages are
sent as SCIP messages, hence it needs to be clear on the RTP/RTCP usage.

- This statement needs to be clarified more -

    "SCIP traffic is highly variable and the bit rate specified in the SDP
    [RFC8866] is OPTIONAL since discontinuous transmission (DTX) or other
    mechanisms may be used."

  What does this "highly variable" traffic mean? In what sense it is variable,
  variable bitrate? if this is highly variable how this would react to
  congestion and rate control?

  what bitrate is specified in the SDP? are you talking about the "b" parameter
  and interpretation of that? how is that to be interpreted in the session
  level and media level due to DTX?

- it says -

    "a jitter buffer MAY be implemented in endpoint devices only"

  Given that "both discontinuous and continuous traffic are highly probable", a
  jitter buffer is a MAY? How to handle late loss or reordering? is it expected
  that no transmission error possible in the environment where SCIP operates?

-  what is the plan to include the changes agreed to with the TSVART reviewer?
I mostly agreed with the resolution agreed with the reviewer and would like to
see those changes in the document before we approve this document. That is the
reason I am not bringing those topics back in this discuss. Please consider
them as my discuss points as well.


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

Some further comments -

- Please add a link to SCIP specification, I had hard time finding public
description or documentation of SCIP codecs.

- I think it would be great to provide the design principles behind SCIP with
some details. This will be helpful for understanding the motivation and rtp
format specified in the document.