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/
- [AVTCORE] Magnus Westerlund's Discuss on draft-ie… Magnus Westerlund via Datatracker
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Colin Perkins