[rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Sun, 17 February 2019 22:33 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37864124D68; Sun, 17 Feb 2019 14:33:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rtcweb-fec@ietf.org, Ted Hardie <ted.ietf@gmail.com>, rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com>
Date: Sun, 17 Feb 2019 14:33:05 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/wDnDbSAgSmUs6-q8W2dMK3aAm1I>
Subject: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 22:33:05 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-fec-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 nit: The subsequent discussion seems to indicate that at least some of these mechanisms are already specified and not new in this document; (if so) it would be nice to have the exposition reflect that. Section 3.3 For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery Is "added" supposed to be something other than "appended" (which strongly resembles the "redundant encoding" of the previous section)? Section 4.1 Does it make sense to give subsection backreferences when talking about (e.g.) redundant encoding? Section 5.2 Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an nit: Since this Section 5 is solely for video, is it more appropriate to refer to Section 5.1.2 ("Registration of video/flexfec") of draft-ietf-payload-flexible-fec-scheme? Section 7 To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED. Just to double-check: this is explicitly only mandating FEC for audio and ignoring video entirely? Section 8 Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. This seems to imply that "FEC" is a specific usage and that flexfec is not a subset of generic FEC. If so, this could probably be reworded to be less confusing to the reader (though my suspicion is that the "always causes redundant data to be transmitted" is only intended to apply to specific mechanisms from Section 3). Section 9 This document seems to be agnostic on the question of RTP vs. SRTP; I would consider referencing their respective security considerations as well as what is already covered here. As described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as described in [RFC5764], Section 4.1.2. I was going to comment about the lack of clarity here, but I see that Ekr has already gotten the core points, and that the secdir review has already resulted in some chanegs in the editor's copy. It would be nice to have the result of the (merged) edits available to look at, though.
- [rtcweb] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk
- Re: [rtcweb] Benjamin Kaduk's No Objection on dra… Justin Uberti
- Re: [rtcweb] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk
- Re: [rtcweb] Benjamin Kaduk's No Objection on dra… Justin Uberti
- Re: [rtcweb] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk