Re: [AVTCORE] Benjamin Kaduk's Yes on draft-ietf-avtcore-cc-feedback-message-08: (with COMMENT)

Colin Perkins <> Mon, 02 November 2020 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 055473A0810; Mon, 2 Nov 2020 05:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hH-PHR-VRh-L; Mon, 2 Nov 2020 05:26:37 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03F913A0FBD; Mon, 2 Nov 2020 05:26:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=2J/BKwPyjoUOWA7s7dqZVYVMyiKK9gDGYwFjlbrAikk=; b=sD3L6ifTU+oUPXC6ygFAFQ5gqR Mj/C8PnSmeQ/cnVHKufeExgarDetcpUInF6ThiSmSUe7MC+jLBq3ZihO/XdmZtpz782RbnVTf9ODd AdqyOBk8iyr1NnHNsO3CnlLYt78Cc233pq7tMS3eaByl2QMjzzWSdFS6u4TIbi+3QbxJafU+CFmjr yZc5hbQQNKZh/sjdtrMwZe63S42dwvrB7OeORPd2eNi7lpoYIhfwwLJrt+L2Pz4UiyXai3cNpW4f5 Z23Ql17cYKcdRsMQhH0eebviJWvspjfD9e6C+k1EGl1+dGERNv0eis687A6X9MUhly0sgESYlpJt2 7q4E5XWg==;
Received: from [] (port=37599 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kZZr1-0000HJ-1e; Mon, 02 Nov 2020 13:26:35 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 2 Nov 2020 13:26:31 +0000
Cc: The IESG <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [AVTCORE] Benjamin Kaduk's Yes on draft-ietf-avtcore-cc-feedback-message-08: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2020 13:26:40 -0000

> On 24 Sep 2020, at 00:25, Benjamin Kaduk via Datatracker <> wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?

Not that I know of.

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

Removed these references.

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

Renamed the bit to “R” to better match its use.

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

Treat the later report as an update, as in the previous sentence. I reordered the text to clarify. (It makes no sense for a packet to be reported as received then lost, but it’s not going to cause any great harm)

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

SDP has various mechanisms, such as b= lines amongst others, that allow this negotiation.

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

Good catch – I’ve changed this to allow the receiver to choose.

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

I think so…. it’s been a long time.

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

Yes, updated.

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

I’m not sure they are, but such guidance would relate to RTP implementations in general, not just to this feedback mechanism, so this isn’t the right place to add it.

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

Right – it’s not feasible as an off-path attack, because you need to also guess the SSRC, sequence number, and ports.

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

It should be informative, yes.

Colin Perkins