Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-avtcore-cc-feedback-message-08: (with DISCUSS and COMMENT)

Colin Perkins <> Tue, 22 September 2020 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A4863A0907; Tue, 22 Sep 2020 09:19:33 -0700 (PDT)
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 AOd5Jg0q8dZG; Tue, 22 Sep 2020 09:19:31 -0700 (PDT)
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 3BCB33A08C3; Tue, 22 Sep 2020 09:19:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=TDiFrhAM8m7lMs6lFF+ag0XhkLAElePnmhapWikvGXM=; b=HTxO5n1zIzShmyicmF7R9CHifT n9OC30c1yJ5UPVWT3cp3e6XNkNrJGIlw7ZBYvl2AmPsXOgedbs4qybKxpVG6Q3zOclW18npbBOp2a YEDRN2fLPuYlApzd5GYySoNF4b4vF89VDAhqlJb453/UHl2Izmtz/qL5aT6Gqc3FDB/W0bWPStH8g aIAAj1oMxxQhP2NPgeOfrWOWS2jSIAkL+0jUf1RbVJ33y3AM97CqK/0wo82BDsKSbZfKpt0d81cCO B5myRHpuGgBUW4wHd3ldqWEKM0pCLj88Y7l77Lyg+tNMu2F0TqGc+oW/TLY4HnVeJ6O/zbzBADLZm Qqft/kWQ==;
Received: from [] (port=37461 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kKl0o-000761-FW; Tue, 22 Sep 2020 17:19:26 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Tue, 22 Sep 2020 17:19:21 +0100
Cc: The IESG <>,,,, Bernard Aboba <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.3445.104.15)
X-BlackCat-Spam-Score: 19
Archived-At: <>
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-avtcore-cc-feedback-message-08: (with DISCUSS and 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: Tue, 22 Sep 2020 16:19:33 -0000

Good point – it’s probably worth adding some words to this draft to say that the guidance in Section 7 of RFC 6679 should be followed when using this feedback format to carry ECN marking information.


> On 22 Sep 2020, at 14:34, Magnus Westerlund via Datatracker <> wrote:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-avtcore-cc-feedback-message-08: Discuss
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> In Section 7.
> there is discussion that CCFB will replace the ECN FB format. I find that
> appropriate however there is one function in ECN FB format that is not
> discussed here. Section 7.2.1 in RFC 6679 states
> An immediate or
>      early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
>      be generated on receipt of the first ECT- or ECN-CE-marked packet
>      from a sender that has not previously sent any ECT traffic.  Each
>      regular RTCP report MUST also contain an ECN Summary Report
>      (Section 5.2).  Reception of subsequent ECN-CE-marked packets MUST
>      result in additional early or immediate ECN feedback packets being
>      sent unless no timely feedback is required.
> There are no specification in this document that says that on reception of
> ECN-CE marks the feedback packet should be sent using early or immediate. That
> might not be required given a correctly configured session, where reporting
> occur on the time scale. However, I think some discussion of the usage of early
> reporting for ECN-CE mark is needed if longer reporting intervals are used.
> Where there any discussion in the WG of this subject?
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> A. Section 3.1:
> The document in one paragraph states the below:
> The value of num_reports MAY be zero, indicating that there are no
>   packet metric blocks included for that SSRC.
> When reading this I did wonder what value should be set. This is given almost
> at the end of the section in the below sentence.
> If no packets are received from an SSRC in a reporting interval, a
>   report block MAY be sent with begin_seq set to the highest sequence
>   number previously received from that SSRC and num_reports set to zero
>   (or, the report can simply to omitted).
> I think it would be clearer if the recommendation for begin_seq when
> num_reports = 0 to be stated in the context of the first one. Then a more
> focused sentence for the second part can explain the context in that paragraph.
> B. Section 11:
> Since RTP is an unreliable transport, a
>   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 think "without causing harm" is overstating it. I think without serious harm
> is more correct. Depending on jitter buffer and usage of NACK to report packet
> loss a gap in the sequence number can have cause retransmission requests. Also
> if the gap is in the wrong place in a packet sequence, for example in the
> middle of sequence of packets for a single video frame it could trigger a
> repair action despite all data have been received.
> I would state it is possible to insert gap with some consideration for the
> media so that minimal impact is had.

Colin Perkins