Re: [rmcat] review of draft-ietf-avtcore-cc-feedback-message-04

Colin Perkins <csp@csperkins.org> Thu, 25 July 2019 15:13 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 C4CAD1202E4 for <rmcat@ietfa.amsl.com>; Thu, 25 Jul 2019 08:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 iYa3YzIVyOHG for <rmcat@ietfa.amsl.com>; Thu, 25 Jul 2019 08:13:17 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82: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 9433F120302 for <rmcat@ietf.org>; Thu, 25 Jul 2019 08:12:44 -0700 (PDT)
Received: from [2001:67c:1232:144:b553:8542:b41d:796d] (port=55131) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <csp@csperkins.org>) id 1hqfQ7-0006wG-2J; Thu, 25 Jul 2019 16:12:43 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAOLMUdBCtnsDgJbrx91tFN++B3=ibvRepn4tyMShNhoHNx4MDQ@mail.gmail.com>
Date: Thu, 25 Jul 2019 11:12:36 -0400
Cc: "rmcat@ietf.org WG" <rmcat@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E143FC4-3889-435E-8CDE-20215A27F75E@csperkins.org>
References: <CAOLMUdBCtnsDgJbrx91tFN++B3=ibvRepn4tyMShNhoHNx4MDQ@mail.gmail.com>
To: Steffen Schulze <steschu77@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/POimqolN5Dz62JRnJRN5sW-IwX0>
Subject: Re: [rmcat] review of draft-ietf-avtcore-cc-feedback-message-04
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Jul 2019 15:13:21 -0000

Hi,

> On 23 Jul 2019, at 12:00, Steffen Schulze <steschu77@gmail.com> wrote:
> 
> Hi,
> 
> while reviewing draft-ietf-avtcore-cc-feedback-message-04 I found a
> minor typo you might want to fix on page 7:
> 
> then an ECN-CE mark MUST be reported that for packet;
> 
> to
> 
> then an ECN-CE mark MUST be reported for that packet;

Thanks, will fix.

> In addition I have some questions:
> 
> If a duplicate packet arrives which would update the ECN-CE field for
> the previously reported packet, as stated on page 7, how far back the
> receiver must report that?

That’s intentionally not specified, since the amount of state receivers keep, and the length of time they hold it for, varies significantly. Keeping track of duplicates for a small number of reporting intervals is likely sufficient.

> Can a CCFB packet include multiple reports for the same SSRC? (Which
> would be interesting for updating a duplicate.)

It can contain multiple reports for a single SSRC, and there can be multiple CCFB packets in a compound RTCP packet.

> The current proposal includes information about packet reception back
> to the sender for all kinds of QoS parameters, including jitter,
> packet-loss, round-trip time, etc. Therefore would it be worth
> considering to report duplicate packets to the sender as well?


I tend to think the overhead of reporting duplicates in CCFB feedback packets outweighs the utility, and we have other mechanisms to report them. It could be added if there were WG consensus to do so, of course.

Colin