[AVTCORE] Benjamin Kaduk's Yes on draft-ietf-avtcore-cc-feedback-message-08: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 23 September 2020 23:25 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F973A15C1; Wed, 23 Sep 2020 16:25:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-avtcore-cc-feedback-message@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, Bernard Aboba <bernard.aboba@gmail.com>, bernard.aboba@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160090353165.31814.11488206076041378547@ietfa.amsl.com>
Date: Wed, 23 Sep 2020 16:25:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/If2pIiZMzzFVnBBQC0D9J2DWzLg>
Subject: [AVTCORE] Benjamin Kaduk's Yes on draft-ietf-avtcore-cc-feedback-message-08: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 23:25:32 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-avtcore-cc-feedback-message-08: Yes 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-avtcore-cc-feedback-message/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 control designs are not interoperable. To enable algorithm evolution as well as interoperability across designs (e.g., different rate adaptation algorithms), it is highly desirable to have generic congestion control feedback format. nit: singular/plural mismatch "format"/"to have generic". To help achieve interoperability for unicast RTP congestion control, this memo proposes a common RTCP feedback packet format that can be (side note) is there work underway for non-unicast RTP congestion control? Section 2 In addition the terminology defined in [RFC3550], [RFC3551], [RFC3611], [RFC4585], and [RFC5506] applies. [3551 and 3611 don't seem to have prominent dedicated "definitions" sections.] Section 3.1 o L (1 bit): is a boolean to indicate if the packet was received. 0 represents that the packet was not yet received and all the subsequent bits (ECN and ATO) are also set to 0. 1 represents that the packet was received and the subsequent bits in the block need to be parsed. (side note) it's tempting to parse this as the "loss bit", but then a value of true means not-lost and false means lost, which feels somewhat unnatural. That said, preserving all-bits-zero as "no data" is probably worth the tradeoff... sent previous reports for RTP packets included in both reports. If an RTP packet was reported as received in one report, that packet MUST also be reported as received in any overlapping reports sent later that cover its sequence number range. What should a recipient do if this invariant is violated? Tear down the RTP session as a protocol violation? Section 4 feedback, using a feedback interval range of 50-200ms. Applications need to negotiate an appropriate congestion control feedback interval at session setup time, based on the choice of congestion control algorithm, the expected media bit rate, and the acceptable feedback overhead. Are there protocol mechanisms standardized that can perform this negotiation? (I note that though we provide SDP signalling for the use of CCFB overall, we do not define SDP signalling for the feedback interval.) Section 7 provides duplicate information. Accordingly, when congestion control feedback is to be used with RTP and ECN, the SDP offer generated MUST include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate that the RTP Congestion Control Feedback Packet is to be used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be used. Am I reading this correctly that a "mixed" deployment with Offerer that supports both mechanisms and an Answerer that only supports RFC 6679 will result in ECN not being used for the RTP session at all, even though 6679 is supported by both parties? Why does it not suffice to only constrain the Answer behavior? Section 8 control. TMMBR could, however, be viewed a complementary mechanism that can inform the sender of the receiver's current view of acceptable maximum bit rate. The Received Estimated Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] provides similar feedback. The REMB I-D expired in 2014; is it still useful to reference it by name (as opposed to a representative of a class)? Contrast to draft-holmer-rmcat-transport-wide-cc-extensions, which expired in 2016, but we reference only as an example of the class of schemes that adds a transport-wide sequence number to each RTP packet. RTCP Extended Reports (XR): Numerous RTCP extended report (XR) blocks have been defined to report details of packet loss, arrival times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It is possible to combine several such XR blocks into a compound RTCP packet, to report the detailed loss, arrival time, and ECN marking marking information needed for effective sender-based congestion control. However, the result has high overhead both in terms of bandwidth and complexity, due to the need to stack multiple reports. If I am reading correctly, RFC 6679 only provides ECN counters, not necessarily at packet granularity, so it may not actually provide as much information as this mechanism. Section 9 Are the named individuals the members of the design team? If not, where can the membership of the design team be determined? Section 11 I look forward to the clarification regarding off-path attacks produced in response to the tsv-art review. In theory the exposure of (somewhat) fine-grained timing information at per-packet granularity could open up new attacks that look for side channels in processing of other protocols operating between the same endpoints, but I am not really convinced that millisecond-scale information presents enough exposure to merit mentioning here. congestion on the path. This will negatively impact the quality of experience of that receiver. Since RTP is an unreliable transport, a And potentially other entities using the bottleneck segment of that path? Also could potentially cause excessive resource consumption on the sender? sender can intentionally leave a gap in the RTP sequence number space without causing harm, to check that the receiver is correctly reporting losses. [I assume that recommended remediation measures in the face of such a lying peer are covered in the referenced documents already.] An on-path attacker that can modify RTCP congestion control feedback packets can change the reports to trick the sender into sending at either an excessively high or excessively low rate, leading to denial of service. The secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. I guess to try to do this off-path you'd need to guess the SSRCs and sequence-numbers (mod 2**16) in addition to transport ports, which quickly becomes infeasible if there's more than one stream, so it really is just an off-path threat. Section 12.1 It seems that we only list 3611 as normative for the terminology reference, but I didn't see any terminology usage that we clearly needed 3611 for.
- [AVTCORE] Benjamin Kaduk's Yes on draft-ietf-avtc… Benjamin Kaduk via Datatracker
- Re: [AVTCORE] Benjamin Kaduk's Yes on draft-ietf-… Colin Perkins