Skip to main content

Last Call Review of draft-ietf-avtcore-rtp-scip-04

Request Review of draft-ietf-avtcore-rtp-scip
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2022-12-19
Requested 2022-12-05
Authors Dan Hanson , MikeFaller , Keith Maver
I-D last updated 2022-12-19
Completed reviews Secdir Early review of -02 by Magnus Nyström (diff)
Genart Early review of -01 by Stewart Bryant (diff)
Artart Early review of -01 by Jim Fenton (diff)
Artart Early review of -02 by Jim Fenton (diff)
Tsvart Last Call review of -04 by Olivier Bonaventure (diff)
Opsdir Last Call review of -04 by Dan Romascanu (diff)
Assignment Reviewer Olivier Bonaventure
State Completed
Request Last Call review on draft-ietf-avtcore-rtp-scip by Transport Area Review Team Assigned
Posted at
Reviewed revision 04 (document currently at 09)
Result Ready w/issues
Completed 2022-12-19
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 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

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.