Re: [art] Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10
"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Mon, 10 October 2022 08:05 UTC
Return-Path: <pengshuping@huawei.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821D6C14F72C; Mon, 10 Oct 2022 01:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFyc0HAys563; Mon, 10 Oct 2022 01:05:50 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D89C14F740; Mon, 10 Oct 2022 01:05:49 -0700 (PDT)
Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MmBJb613Dz67xwN; Mon, 10 Oct 2022 16:04:15 +0800 (CST)
Received: from canpemm500007.china.huawei.com (7.192.104.62) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 10 Oct 2022 10:05:46 +0200
Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm500007.china.huawei.com (7.192.104.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 10 Oct 2022 16:05:45 +0800
Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2375.031; Mon, 10 Oct 2022 16:05:44 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Colin Perkins <csp@csperkins.org>
CC: "art@ietf.org" <art@ietf.org>, "draft-ietf-rmcat-rtp-cc-feedback.all@ietf.org" <draft-ietf-rmcat-rtp-cc-feedback.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>
Thread-Topic: Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10
Thread-Index: AQHY2kPvzaZNVBxwwEyviKyDPVXCaK4HSSlQ
Date: Mon, 10 Oct 2022 08:05:44 +0000
Message-ID: <40433c3df02546478227b15c2e735788@huawei.com>
References: <166003222046.58655.11877444893849918494@ietfa.amsl.com> <F93AB42F-0E12-4D0D-983A-380DBC265069@csperkins.org>
In-Reply-To: <F93AB42F-0E12-4D0D-983A-380DBC265069@csperkins.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.153.176.106]
Content-Type: multipart/alternative; boundary="_000_40433c3df02546478227b15c2e735788huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/lrh4dtv-cEDyByXR37B8eW3Om-o>
Subject: Re: [art] Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2022 08:05:55 -0000
Hi Colin, No worries. I have gone through your responses, which are fine with me. Thank you! Best Regards, Shuping From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, October 7, 2022 7:57 PM To: Pengshuping (Peng Shuping) <pengshuping@huawei.com> Cc: art@ietf.org; draft-ietf-rmcat-rtp-cc-feedback.all@ietf.org; last-call@ietf.org; rmcat@ietf.org Subject: Re: Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10 Hi Shuping, Thank you for your review, and apologies for my slow follow-up. On 9 Aug 2022, at 9:03, Shuping Peng via Datatracker wrote: Reviewer: Shuping Peng Review result: Ready with Issues Reviewer: Shuping Peng Review Result: Ready with Issues I am the assigned ART-ART reviewer for this draft (draft-ietf-rmcat-rtp-cc-feedback-10). Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: "No major issues found." Thanks. Minor Issues: Abstract: "This memo discusses the types of congestion control feedback that it is possible to send using the RTP Control Protocol (RTCP), and their suitability of use in implementing congestion control for unicast multimedia applications." It is not clear what are the types of congestion control feedback considered in this draft. In Section 2, the "RTCP reception quality feedback" is mentioned but only once, while in the rest of this draft, "RTCP congestion control feedback" is considered [8888]. It seems that the "RTCP reception quality feedback" is directly taken as the "RTCP congestion control feedback". RTCP provides several types of reception quality feedback. Congestion control feedback is one such type. I’ve changed the start of Section 2, to now say “when providing RTCP feedback for congestion control purpose” to clarify. A proposal for the abstract of this draft, just for the author's reference: "This memo discusses the types of RTCP feedback that it is possible to send for the congestion control purposes, and their suitability of use in implementing congestion control for unicast multimedia applications." That change would work, but re-reading the abstract I think a more important change would be to highlight the rate of which congestion control feedback is sent, not the type of feedback. I’ve changed it to: This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and its suitability for implementing congestion control for unicast multimedia applications. It would be better to provide a reference for "RTCP reception quality feedback", e.g. [RFC7201]? No, that’s discussing a different topic. The references for RTCP reception quality feedback are RFCs 3550, 3611, and 4585, which are already cited by this draft. Section 2: "The RTP standards have long said that a 5% overhead for RTCP traffic is generally acceptable, while providing the ability to change this fraction. Is this still the case for congestion control feedback? " Is the congestion control feedback part of the overhead for RTCP traffic? If yes, then this sentence seems to be redundant. Congestion control feedback is part of the overhead for RTCP traffic. The draft is discussing how that overhead changes when different amounts of congestion control feedback are sent, and what rates of congestion control feedback are possible while keeping the overhead within that 5% bound. Or considering the context, maybe change it to something like, "The RTP standards have long said that a 5% overhead for RTCP traffic, including congestion feedback, is generally acceptable, while providing the ability to change this fraction." That’s an accurate statement of fact, but the draft is asking a question about whether the congestion control can fit within the 5% overhead often considered acceptable. Section 3.1: Just wonder whether the descriptions regarding the classification of the RTCP feedback packets (i.e. full, compound, RTCP feedback packets, or reduced-size RTCP packets in the 3rd/4th/... paragraph) could be listed out at the beginning of the Section 3, since this information is referred in both following scenarios. It could be, but I think the document flows better with this information inline where it’s first used, rather than separated out at the start of the section. Section 4: What are the "other media topologies"? It would be good to give some examples and references. I added a reference to RFC 7667, which describes RTP topologies. Nits: * Section 2: s/The key question is how often does the receiver need to send feedback on the reception quality... of the network? /The key question is how often the receiver needs to send feedback on the reception quality ... of the network. I think the original is correct. s/Approaches like in-network filtering of acknowledgements have been proposed to reduce acknowledgement overheads ... can also /Approaches like in-network filtering of acknowledgements that have been proposed to reduce acknowledgement overheads ... can also Fixed, thanks. s/it might make sense to give the option of sending congestion feedback less often than does TCP /it might make sense to give the option of sending congestion feedback less often than TCP does Fixed, thanks. Section 3: s/comprise a 2 octet header/comprise a 2-octet header Fixed. s/The RTCP congestion control feedback (CCFB) report comprises an 8 octet RTCP header and SSRC, a 4 octet report timestamp, and for each of the remote audio and video SSRCs, an 8 octet report header, and 2 octets per packet reported upon, and padding to a 4 octet boundary if needed /The RTCP congestion control feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a 4-octet report timestamp, and for each of the remote audio and video SSRCs, an 8-octet report header, and 2 octets per packet reported upon, and padding to a 4-octet boundary if needed Fixed. s/How many RTP packets does the RTCP XR congestion control feedback packet included in these compound RTCP packets report on? /How many RTP packets does the RTCP XR congestion control feedback packet include in these compound RTCP packets report on? I think the original was correct, but I added some punctuation to clarify. s/alternating compound and reduced-size reports gives results as shown in Table 4. /alternating compound and reduced-size reports give results as shown in Table 4. The original is correct. s/The use of reduced-size RTCP gives a noticeable reduction /The use of reduced-size RTCP reports gives a noticeable reduction Both are correct. * Section 4 s/close to it's current form/close to its current form Fixed. The apostrophe is hard :-) Cheers, Colin
- [art] Artart last call review of draft-ietf-rmcat… Shuping Peng via Datatracker
- Re: [art] Artart last call review of draft-ietf-r… Colin Perkins
- Re: [art] Artart last call review of draft-ietf-r… Pengshuping (Peng Shuping)