Re: [rmcat] Secdir last call review of draft-ietf-rmcat-rtp-cc-feedback-10

Colin Perkins <csp@csperkins.org> Fri, 07 October 2022 09:17 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38F9C14CF0B; Fri, 7 Oct 2022 02:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGdbNjUFLpJR; Fri, 7 Oct 2022 02:17:50 -0700 (PDT)
Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E9FC14CF02; Fri, 7 Oct 2022 02:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=krhRVb5HfXWZqUPVoOnxWzmMgiYSzy8x2EdWRxhf+Xo=; b=JheKCju4RWQI5R1NRYtXS1fb/q L64UYUSl3gb6vyooMwO26pMruLSAfOTU2eermgxj7F1wyFddfhk3yKxr0k4+QL+Ms+ZsdPE3qDe1N SpdfGI7oyJjV0VitFnshh5DlZk10Zm7hDxJu6TRf/djFJsN3JtD66g86rD89aY1tqIkCX9p5yftHq fsy43whg6rBUKDqohC0VjH3G0mshcDAk8vDC9izmojNwNT4f/hSXUS6WV/E5jjUIO+roKk79dwGkv GqY2k506taCSr42GS069JrmYGuc6Po9G4+u3XO8tuE8hdieIEXGz3/vfXApfdw8xqXdI5E++BecH+ 6WRAsaew==;
Received: from [81.187.2.149] (port=33042 helo=[192.168.0.72]) by mailhub-cam-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <csp@csperkins.org>) id 1ogjUK-0072wZ-96; Fri, 07 Oct 2022 10:17:48 +0100
From: Colin Perkins <csp@csperkins.org>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org, draft-ietf-rmcat-rtp-cc-feedback.all@ietf.org, last-call@ietf.org, rmcat@ietf.org
Date: Fri, 07 Oct 2022 10:17:39 +0100
X-Mailer: MailMate (1.14r5920)
Message-ID: <3A2981B5-E9ED-4CD0-AC59-4A66DB57425A@csperkins.org>
In-Reply-To: <166002236325.19592.1530282258442323000@ietfa.amsl.com>
References: <166002236325.19592.1530282258442323000@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/OKdgjo8EGxwP3-gCNxZ8nW_54Zo>
Subject: Re: [rmcat] Secdir last call review of draft-ietf-rmcat-rtp-cc-feedback-10
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 09:17:56 -0000

Hi Linda,

Thank you for the review, and apologies for my slow follow-up.

On 9 Aug 2022, at 6:19, Linda Dunbar via Datatracker wrote:

> Reviewer: Linda Dunbar
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any other
> last-call comments.
>
> This document discusses the types of congestion control feedback using the RTP
> Control Protocol. The document analyzes the feedback packet sizes and content
> for point-to-point Voice Telephony and point-to-point Conference call.
>
> Since most of today's conference bridges are multi-points to multi-points or at
> least multi-points (users) to multi-servers, I think multi-points analysis
> would be more useful. Will the author consider adding them?

Multipoint congestion control is a complex issue and would likely need a separate document to fully discuss. I also think the complexity would obscure the point this draft is trying to make. Accordingly, I don’t think it fits in this document.

> As for the Consideration of the RTCP feedback (Section 2), should you also
> consider how far away the endpoints are?  Will network congestion and distances
> impact the RTCP feedback?

Loss or delay of RTCP feedback packets due to congestion will affect the behaviour of the congestion control algorithm using that feedback. RFC 8888, Sections 4 and 5, discuss this, and highlight that it’s an issue that needs to be addressed in the congestion control algorithm specifications.

Changes to the RTT affect the responsiveness of congestion control algorithms that adapt to feedback sent every RTT. This draft makes the argument that video congestion control should rather send feedback every frame, or several frames, of video, since the sending rate can only change on a per frame basis. In this case, the distance (i.e., the RTT) doesn’t affect the RTCP feedback.

(RTCP timing, in general, is based on media rate and number of participants in a session, not on the RTT)

> Section 1 states, "It is also assumed that the congestion control feedback
> mechanism in RFC8888, .. are available." Question: Is the Congestion Control
> Feedback mechanism described in this document the same as in RRC 8888? What are
> the key differences?

This document is giving examples of how the feedback format described in RFC 8888 can be used, and what are the overheads of such use. I’ve changed this to “...are used” to clarify.

Colin


-- 
Colin Perkins
https://csperkins.org/