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

"Ben Campbell" <> Wed, 04 May 2016 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5E6412D0B6; Wed, 4 May 2016 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lsGDR9eckal; Wed, 4 May 2016 08:00:35 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82D8112D6CE; Wed, 4 May 2016 08:00:27 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be []
From: "Ben Campbell" <>
To: "Colin Perkins" <>
Date: Wed, 04 May 2016 10:00:12 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <>
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: <>
Cc:, Magnus Westerlund <>,,, The IESG <>, Stephen Farrell <>
Subject: Re: [AVTCORE] Stephen Farrell's No Objection on draft-ietf-avtcore-rtp-circuit-breakers-15: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 May 2016 15:00:37 -0000

On 4 May 2016, at 5:39, Colin Perkins wrote:


>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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?