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

"Ben Campbell" <ben@nostrum.com> Wed, 04 May 2016 15:00 UTC

Return-Path: <ben@nostrum.com>
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 D5E6412D0B6; Wed, 4 May 2016 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable 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 3lsGDR9eckal; Wed, 4 May 2016 08:00:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D8112D6CE; Wed, 4 May 2016 08:00:27 -0700 (PDT)
Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u44F0Dlg002659 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 10:00:13 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18]
From: "Ben Campbell" <ben@nostrum.com>
To: "Colin Perkins" <csp@csperkins.org>
Date: Wed, 04 May 2016 10:00:12 -0500
Message-ID: <4D284CCC-C343-42DA-A47F-DD7931A05C6D@nostrum.com>
In-Reply-To: <4C3D57C2-DDCA-4F2A-BF42-B69E03195B67@csperkins.org>
References: <20160503222644.8260.58780.idtracker@ietfa.amsl.com> <4C3D57C2-DDCA-4F2A-BF42-B69E03195B67@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/uPTy59LC2wgjr49lVrZ-pBrVx9I>
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: Wed, 04 May 2016 15:00:37 -0000

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?

[...]

Thanks,

Ben.