Olivier,
Please see below our responses to your comments.
Regards,
Dan Hanson
General Dynamics Mission Systems
-----Original Message-----
From: Olivier Bonaventure via Datatracker <noreply@xxxxxxxx>
Sent: Monday, December 19, 2022 10:34 AM
To: tsv-art@xxxxxxxx
Cc: avt@xxxxxxxx; draft-ietf-avtcore-rtp-scip.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Tsvart last call review of draft-ietf-avtcore-rtp-scip-04
From: Olivier Bonaventure via Datatracker <noreply@xxxxxxxx>
Sent: Monday, December 19, 2022 10:34 AM
To: tsv-art@xxxxxxxx
Cc: avt@xxxxxxxx; draft-ietf-avtcore-rtp-scip.all@xxxxxxxx; last-call@xxxxxxxx
Subject: 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.
Reviewer: Olivier Bonaventure
Review result: Ready with Issues
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@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 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.
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.
7.3. Congestion Control
RTP and its profiles do discuss congestion control. There is ongoing
work in the IETF with both a basic circuit-breaker mechanism
[RFC8083] using basic RTCP messages intended to prevent persistent
congestion and also work on more capable congestion avoidance /
bitrate adaptation mechanism in the RMCAT WG.
Congestion control is an important issue in any usage in networks
that are not dedicated. For that reason, it is recommended that all
RTP payload format documents discuss the possibilities that exist to
regulate the bitrate of the transmissions using the described RTP
payload format. Some formats may have limited or step-wise
regulation of bitrate. Such limiting factors should be discussed.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
