Olivier, Regarding congestion control, SCIP currently only uses constant bitrate codecs such as MELPe 2400 bps, and G.729D 6400 bps. There is little that can be done with these codecs short of changing number of audio frames per packet should congestion occur. Other variable bitrate codecs are being considered for future use that could be adjusted based on network conditions. Regards, Dan Hanson General Dynamics Mission Systems -----Original Message----- From: Olivier Bonaventure <Olivier.Bonaventure@xxxxxxxxxxxx> Sent: Thursday, December 22, 2022 1:37 AM To: Hanson, Daniel C <Dan.Hanson@xxxxxxxxx>; tsv-art@xxxxxxxx Cc: avt@xxxxxxxx; draft-ietf-avtcore-rtp-scip.all@xxxxxxxx; last-call@xxxxxxxx Subject: Re: Tsvart last call review of draft-ietf-avtcore-rtp-scip-04 ---- 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. Dear Dan, Thanks for your reply. > This document has been reviewed as part of the transport area review > team's ongoing effort to review key IETF documents. These comments > were written primarily for the transport area directors, but are > copied to the document's authors and WG to allow them to address any > issues raised and also to the IETF discussion list for information. > When done at the time of IETF Last Call, the authors should consider > this review as part of the last-call comments they receive. Please > always CC _tsv-art@ietf.org_ <mailto:tsv-art@xxxxxxxx> if you reply to > or forward this review. > I received this document from the viewpoint of the transport and have > identified several parts that are unclear in the document. > In section 4, you note " The SCIP payload size will vary considerably, > especially during SCIP secure session establishment." Vary > "considerably" is a vague statement. Given problems with PathMTU, it > could be useful to discuss how MTU issues should be handled by SCIP > implementations and whether you rely on fragmentation. > [DH] /Add to end of first paragraph in Section 4:/ SCIP > implementations SHOULD employ mechanisms to limit payload sizes so as > not to exceed the network MTU. You might add a reference to PathMTU discovery such as RFC4821. > You define an audio payload format and a video payload format. When > the two formats are used together, are there RTP synchronization > issues as described in section 3.3.4 or RFC8088 that need to be taken > into account ? You only mention that clock rates of 8000Hz and 90000Hz > SHALL be used for voice and video. > [DH] /Add to end of second paragraph in Section 4:/ SCIP > implementations MAY employ mechanisms, such as Inter-media RTP > Synchronization as described in RFC 8088 Section 3.3.4, to synchronize > audio/scip and video/scip streams. This is not very specific, but fine for me. > The most important point is that the document should describe how > applications will react in case of congestion. If there is a > persistent congestion, does the application reduces its transmission rate or not ? > Please refer to the following section of RFC8088 [DH] /Add Section 3.1 > Congestion Control Considerations:/ The bitrate of SCIP may be > adjusted depending on the capability of the underlying codec (MELPe, > G.729D, etc.). The number of encoded audio frames per packet may also > be adjusted to control congestion. Other congestion control mechanisms > as described in RFC 3550, RFC 8083, and RFC 8085 may also be employed. > Further congestion control techniques are being researched in the > RMCAT Working Group. This paragraph is a bit weak. SCIP applications should sense the network conditions, implement RFC8083 and adjust their bitrate or number of audio frames per packet based on the network conditions. RFC3550 does define any congestion control scheme. RFC8083 defines techniques to detect when there is excessive congestion. It would make sense to recommend the utilization of RFC8083 in SCIP with a MUST or perhaps a SHOULD. RFC8085 defines generic guidelines for applications that do not implement congestion control. Best regards, Olivier PS: I'll be offline until January -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
