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

Colin Perkins <csp@csperkins.org> Tue, 22 September 2020 16:19 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4863A0907; Tue, 22 Sep 2020 09:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOd5Jg0q8dZG; Tue, 22 Sep 2020 09:19:31 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [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 ietfa.amsl.com (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; d=csperkins.org; 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 [81.187.2.149] (port=37461 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) 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 <csp@csperkins.org>
In-Reply-To: <160078165368.7234.14368794515227742740@ietfa.amsl.com>
Date: Tue, 22 Sep 2020 17:19:21 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-avtcore-cc-feedback-message@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, Bernard Aboba <bernard.aboba@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <45C72EF0-393B-4DCC-B840-C5B7BC8661FB@csperkins.org>
References: <160078165368.7234.14368794515227742740@ietfa.amsl.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-BlackCat-Spam-Score: 19
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/4XXTq1lPKCBXNbtuMnopOtflkmE>
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-avtcore-cc-feedback-message-08: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: 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.

Colin



> On 22 Sep 2020, at 14:34, Magnus Westerlund via Datatracker <noreply@ietf.org> 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 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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
https://csperkins.org/