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

[Zaheduzzaman Sarker <[e-mail]>]

On Mon, Aug 14, 2023 at 8:39 PM [e-mail] <[e-mail]>
wrote:

> 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]>
> wrote:
>
> Here's the thread in y your discuss on the SCIP draft. Thanks!
>
> ---------- Forwarded message ---------
> From: *[e-mail] <[e-mail]>* <[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]>, The IESG <
> [e-mail]>
> Cc: [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [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.
>
>
>
> 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.
>

Yes the security consideration refers to different RTP profiles but that is
on a different context. i was expecting this specification says this RTP
format can be used with any RTP profile or list some RTP profiles.  Also
now that you want to remove "RTP profile" from introduction section, what
does that supposed to mean?


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

Thanks for the section 3.1. But then section 4 now has "highly variable"
and "as describe above" is not that helpful there if you are referring to
the job of the packetizer.

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

I don't think removing text here is the appropriate. Rather I would suggest
to actually make is clear that there is no requirement to have jitter
buffer. Also network SHOULD NOT repackatize the SCIP packets seems like a
good recommendation to have.


>
>
>
>
>
> -  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].
> 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 was referring to Lars's discuss on not publishing this doc as standard
track as if cannot normatively refer to the SCIP spec.


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

Looks good. However, section 4 might have this repeated.


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

that's a good suggestion. I will then wait for the -06 version.

//Zahed


>
>
>
>
>