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

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

Christer,

Responses inline below with [DH].


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: Christer Holmberg <christer.holmberg=[e-mail]>
Sent: Friday, August 25, 2023 2:57 AM
To: Hanson, Daniel C <[e-mail]>; Zaheduzzaman Sarker <[e-mail]>
Cc: [e-mail]; Jonathan Lennox <[e-mail]>; [e-mail]; The IESG <[e-mail]>; [e-mail]
Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

Hi,

>SCIP is an application layer protocol transported via RTP.  Multiplexing schemes such as
>BUNDLE (RFC 8843/9143) should be beyond the scope of SCIP.  As long as the RTP payload
>is not altered, it should be transparent.  Doesn't BUNDLE itself have mechanisms for
>mux/demux audio and video streams?

So, the SCIP control message RTP packets will use the same payload type number as the encrypted codec RTP packets they are associated with?

Example:

     m=audio 50000 RTP/AVP 96
     a=rtpmap:96 scip/8000

In this case, both the audio packets and the associated SCIP control messages will be sent using payload type 96, and the payload type number will be used to associated the SCIP control messages with the audio stream?

[DH] Yes, SCIP control messages (some encrypted) and the encrypted audio payload are both transported on PT 96.


I also have a couple of other questions:

Q1:

I wonder what the following sentence in Section 5.3 means:

   "The application negotiation between endpoints will determine whether
   the audio and video streams are transported as separate streams over
   the audio and video payload types or as a single media stream on the
   video payload type."

Does this mean that the application could choose to transport both the audio and video packets as a video stream, using the video payload type and video stream 5-tuple? Is that some kind of application layer multiplexing mechanism, where the RTP layer will think everything is video?

And, how exactly does such "application negotiation" look like?

[DH] That sentence is supposed to mean that when both audio and video media types are used in a session, the SCIP control messages may be transported over the audio PT and/or video PT.  However, in re-reading it, we may just delete that text.


Q2:

Is there some text somewhere how/if scip works with transcoders, mixers, conference servers etc?

[DH] When used with conference servers, SCIP is point-to-multipoint.  Each endpoint establishes a security association with the "red" conference server.  Audio streams are decrypted from each endpoint, mixed, then sent back to all endpoints encrypted.  It might be possible to transcode the decrypted audio stream tunneled through SCIP at the conference server before sending to a specific client that does not support the preferred audio codec in the SCIP control messages.

Regards,

Christer


From: Christer Holmberg <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>
Sent: Thursday, August 24, 2023 7:54 AM
To: Hanson, Daniel C <[e-mail]<mailto:[e-mail]>>; Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jonathan Lennox <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

Hi,

I have one question regarding this draft: does it work with BUNDLE (RFC 8843)? If I e.g., send an "audio scip stream" and a "video scip stream" on a single 5-tuple, will the receiver be able to detect which scip messages belong to the audio stream and which belongs to the video stream?

Or, if I send multiple audio scip streams on a single 5-tuple, will the receiver be able to detect which scip message belong to which audio stream?

OR, would you use a single scip control for the whole BUNDLE (i.e., all audio and video streams using the same 5-tuple)?

Regards,

Christer


From: avt <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, 16 August 2023 17.12
To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jonathan Lennox <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

Zahed,

Please refer to Revision 05 since the discussion points below keep referring to 04.

Responses inline below with [DH3].


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]<mailto:[e-mail]>>
Sent: Tuesday, August 15, 2023 10:10 AM
To: Hanson, Daniel C <[e-mail]<mailto:[e-mail]>>
Cc: Jonathan Lennox <[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]>; The IESG <[e-mail]<mailto:[e-mail]>>; Faller, Michael F <[e-mail]<mailto:[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.



On Mon, Aug 14, 2023 at 8:39?PM [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, August 11, 2023 6:44 AM
To: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>; Hanson, Daniel C <[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]>; The IESG <[e-mail]<mailto:[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.

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?

[DH3] The first sentence in the section states "... in any applicable RTP profile..." so we are unclear what you are asking.  The entire paragraph was copied from approved RFCs written in 2017 and 2020.  I don't understand why the text was acceptable then but not now.  The "RTP profile" in the Introduction in Revision 05 was in the context of network devices implementing packet filtering:
      Also,  as the SCIP protocol continues to evolve independently of this
      document, any network device that attempts to filter traffic (e.g.,
      deep packet inspection) based on current SCIP traffic profiles may
      cause unintended consequences in the future when changes to the SCIP
      traffic may not be recognized by the network device.




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

[DH3] The text was not intended to describe the job of the packetizer, rather emphasizing that the SCIP RTP payload contains so many different control messages sent at differing intervals as well as various encrypted codecs that it is not possible to define a concise format like G.711 or G.729.  Perhaps the paragraph could be moved above the diagram to avoid confusion.




  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.

[DH3] Rev 05 section 4 last sentence has the text "Network devices MUST NOT modify SCIP RTP packets.".




-  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/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a9217e55267b84de&q=1&e=20586ccc-a0e1-4677-a0e6-9203418b61e7&u=https%3A%2F%2Fwww.iad.gov%2FSecurePhone%2F>.

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.

[DH3] There is precedence: RFC 8817 (TSVCIS) published in August 2020 refers to the TSVCIS specification as an Informative Reference.




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

[DH3] We were hoping to resolve all issues before posting version 06.


//Zahed