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

Colin Perkins <csp@csperkins.org> Tue, 10 May 2016 15:41 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 30B4912B048; Tue, 10 May 2016 08:41:49 -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 8YoaukYjyhlx; Tue, 10 May 2016 08:41:47 -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 8F61012D1E9; Tue, 10 May 2016 08:41:46 -0700 (PDT)
Received: from [130.209.247.112] (port=59241 helo=mangole.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 1b09n4-0002K9-HU; Tue, 10 May 2016 16:41:43 +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: <4D284CCC-C343-42DA-A47F-DD7931A05C6D@nostrum.com>
Date: Tue, 10 May 2016 16:41:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <91AD984C-C2FD-4666-ADC0-71A3F0767BDF@csperkins.org>
References: <20160503222644.8260.58780.idtracker@ietfa.amsl.com> <4C3D57C2-DDCA-4F2A-BF42-B69E03195B67@csperkins.org> <4D284CCC-C343-42DA-A47F-DD7931A05C6D@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
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/aICOVEmk-D4im9xMt8mF2jTtU_A>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org, The IESG <iesg@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: Tue, 10 May 2016 15:41:49 -0000

> On 4 May 2016, at 16:00, Ben Campbell <ben@nostrum.com> wrote:
> 
> On 4 May 2016, at 5:39, Colin Perkins wrote:
> 
> [...]
> 
>>> ----------------------------------------------------------------------
>>> 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.
> 
> How about restating it to describe the consequences if a parallel congestion control allows packet loss rates to exceed the threshold?

“To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by the RTP circuit breaker algorithms”? 

Or “…will need to keep packet loss rates within the envelope permitted by the RTP circuit breaker algorithm”?

Colin



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