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
