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

["[e-mail]" <[e-mail]>]

Zaheduzzaman,

Responses are inline below with [DH].


Dan Hanson
General Dynamics Mission Systems

-----Original Message-----
From: Zaheduzzaman Sarker via Datatracker <[e-mail]> 
Sent: Thursday, January 05, 2023 6:29 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

----
External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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?

[DH] Highly variable is meant to cover all of the control messages exchanged that establish a secure session, similar to an IKEv2 exchange.  Additionally, the encrypted audio stream may also employ DTX.

  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?

[DH] SDP defines scip/8000 (audio) and scip/90000 (video), the sampling rates.  It does not refer to the SDP 'b' parameter.
 

- 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?

[DH] We did not want to impose a requirement for a jitter buffer in the Endpoint. Implementors can choose whether or not to implement.

-  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.

[DH] We are planning a few minor updates based on the TSV-ART review.  However, we are waiting to resolving the comments before posting an update to the draft.

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

Some further comments -

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

[DH] The current SCIP-210 specification is not a public document.  For the current specification, please request a copy from [e-mail].  There is a much older version that was posted on https://www.iad.gov/SecurePhone/.  

- 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.

[DH] SCIP-210 defines many of the design considerations.  The primary purpose of this RFC is to define SCIP for the internetworking functions (SIP Call Managers, SBCs, etc.) so that these devices will allow SCIP to traverse their networks as an opaque blob.  The devices do not need to attempt to parse the SCIP RTP packets, hence the lack of specificity on the exact RTP packet format.  Many of the internetworking devices are deny-all and do not provide the capability to permit the SCIP payload.  It would be next to impossible to attempt to list all of the possible RTP packet formats given the numerous SCIP call control messages.

[DH] We are attempting to follow in the path of RFC 8817 TSVCIS which is also based on the non-public TSVCIS specification.