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

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

Zaheduzzaman,

Thank you for your continued discussion of SCIP.  Note that some of points relating to Revision 04 below no longer apply because of changes made in Revision 05.  We encourage you to download SCIP-210 then review Revision 05.  Comments are inline below with [DH2].


Regards,
Dan Hanson
General Dynamics Mission Systems

This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

From: Zaheduzzaman Sarker <[e-mail]>
Sent: Friday, August 11, 2023 6:44 AM
To: Jonathan Lennox <[e-mail]>; Hanson, Daniel C <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; The IESG <[e-mail]>
Subject: Re: 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.

Thanks Jonathan for forwarding this email. I lost the thread while changing my email address. My responses inline -

On Wed, Aug 9, 2023 at 12:41?AM Jonathan Lennox <[e-mail]<mailto:[e-mail]>> wrote:
Here's the thread in y your discuss on the SCIP draft. Thanks!
---------- Forwarded message ---------
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tue, Feb 7, 2023, 2:15 PM
Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)
To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>


Zaheduzzaman,

Responses are inline below with [DH].


Dan Hanson
General Dynamics Mission Systems

-----Original Message-----
From: Zaheduzzaman Sarker via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, January 05, 2023 6:29 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.

Didn't see any response to this discuss point.

[DH2] In the Security Consideration section "RTP profile" refers to "Profile" AVP, AVPF, SAVP, SAVPF, ...
This text was copied from existing RFCs 8130 and 8817.  We will be removing "RTP Profile" from the
Introduction section added in Rev 05 and an upcoming Rev 06.



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

Please make is clear in the document. I guess by highly variable you are referring both size variation and sending rate variation.

[DH2] The text referring to "Highly variable" was removed in Rev 05.



  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.

would be great to clarify this.

[DH2] The text referring to "bitrate" was removed in Rev 05.




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

Ok, then this reasoning need to be described. Also there should guidance on how to handle late loss or reordering. Also the consequences of having jitter buffer or not having jitter buffer should be discussed so that the implementers made an educated choice. If there is not impact on the SCIP application then that should also be mentioned.

[DH2] The text referring to "jitter buffer" was removed in Rev 05.



-  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.
Thanks. Please let me know if this done I will check the diff.

[DH2] Revision 05 was posted on March 29.



----------------------------------------------------------------------
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]<mailto:[e-mail]>.  There is a much older version that was posted on https://www.iad.gov/SecurePhone/.

Ok, we are already having bigger discussion on this so let that be discussion there.

[DH2] Please download the SCIP-210 specification.  It should answer many of your questions.



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

This I don't believe was very clear to me. May be it is better that this explicitly mentioned in the Introduction of this document. Let me know if I have missed it somehow. This would have set my mind set differently while reviewing this specification.

[DH2] Revision 05 updated the Abstract, Introduction, and Background to reflect this.


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.

However, I was not asking for a comprehensive list of design principles here. As short summery of what are the basic design principles of this SCIP would have helped me a lot to understand the potential application usage of SCIP message, specially when SCIP specification is not publicly available.

[DH2] Please download the SCIP-210 specification.  It should answer many of your questions.  Bernard suggested thinking of SCIP as a tunneling protocol, where other codecs transported in an encrypted channel.  We will be adding words to this effect in Rev 06.