Re: [AVTCORE] Stephen Farrell's No Objection on draft-ietf-avtcore-rtp-circuit-breakers-15: (with COMMENT)

Colin Perkins <csp@csperkins.org> Wed, 04 May 2016 10:59 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 E204812D193; Wed, 4 May 2016 03:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 texYVKd4khQ0; Wed, 4 May 2016 03:59:57 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BC812D0A1; Wed, 4 May 2016 03:59:57 -0700 (PDT)
Received: from [130.209.254.12] (port=57809 helo=vpn12.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1axuDE-0008Jh-VB; Wed, 04 May 2016 11:39:26 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <20160503222644.8260.58780.idtracker@ietfa.amsl.com>
Date: Wed, 4 May 2016 11:39:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C3D57C2-DDCA-4F2A-BF42-B69E03195B67@csperkins.org>
References: <20160503222644.8260.58780.idtracker@ietfa.amsl.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/YUMVfyF1iRN-kZXIl3XSF22tQH8>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG <iesg@ietf.org>, avt@ietf.org
Subject: Re: [AVTCORE] Stephen Farrell's No Objection on draft-ietf-avtcore-rtp-circuit-breakers-15: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 04 May 2016 10:59:59 -0000

> On 3 May 2016, at 23:26, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-avtcore-rtp-circuit-breakers-15: No Objection
> 
> 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-rtp-circuit-breakers/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> I just have a nit and a random query...
> 
> - nit: The abstract says "It is expected that future
> standards-track congestion control algorithms for RTP will
> operate within the envelope defined by this memo." That
> seems both unwise and unlikely to work to me. Unwise in
> that you're trying to control the future which seems like
> it'll just generate heat and not light, and unlikely to
> work since it's not clear to me that any CC scheme can
> take into account circuit breaker constants configured on
> a node that may not be known anywhere else. I'd say better
> would be to say that we hope that future CC algorithms
> will be consistent with this and leave it at that.
> However, if that sentence is the product of a bunch of
> haggling then it's probably better to leave it as-is and
> I'll just hold my nose a bit;-) (Same sentence is in the
> intro - same comment.)

In some sense, it’s stating the obvious. If an endpoint implements the RTP circuit breaker, which will stop the flow if packet loss exceeds a certain threshold, then any congestion control running in parallel had better make sure the packet loss rate staying below that threshold if it wants the flow to continue. I’m open to suggestions to improve the text.

> - query: Assuming people have implemented some or all of
> this, I wondered if it'd be a good idea to document some
> of the ways in which those implementations went wrong,
> i.e. bugs already fixed, especially if there were any
> that'd result in the circuit not being broken when it
> ought be. But that's probably too late or better done in
> some other document for now, so feel free to ignore me.

There’s been some list discussion, and implementers have found bugs in RTCP handling in other implementations as a result of implementing the circuit breaker. This might be better handled in a -bis draft in a few years, once we’ve got more experience with the combination of this and the RMCAT congestion control algorithms. 

Cheers,
Colin





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