Last Call Review of draft-ietf-avtcore-rtp-scip-04
review-ietf-avtcore-rtp-scip-04-tsvart-lc-bonaventure-2022-12-19-00

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

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.

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

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.