Re: [AVTCORE] Alissa Cooper's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

Alissa Cooper <> Mon, 02 May 2016 23:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 757A412D642 for <>; Mon, 2 May 2016 16:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=qk8WrK0t; dkim=pass (1024-bit key) header.b=eGOuPFYT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NA9IlQrrUVzS for <>; Mon, 2 May 2016 16:11:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 480EE12D680 for <>; Mon, 2 May 2016 16:11:45 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C949E20C6C for <>; Mon, 2 May 2016 19:05:17 -0400 (EDT)
Received: from frontend1 ([]) by compute1.internal (MEProxy); Mon, 02 May 2016 19:05:17 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=PgAxgY6ph/tNS11uHXdTQHQcBls=; b=qk8WrK 0t3DGEYDylAWZOvYHxor4NYbSbJsMqQ/g7SGP/iCHms4hhJvTxraXsgX8b53mTP7 5FEuknNPz8Klda/70LvQ5u5EU2CBuxa3vAzKFTVnvS++iRRDp3T7FaFephWiMQ91 soIAo1DiOHxYyQrC38zvmN9p2LrMBbtweZi10=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PgAxgY6ph/tNS11 uHXdTQHQcBls=; b=eGOuPFYTndyxvofE5F3VfBzZGaYoW8r806NwPS+CD2Pitd4 rOWP6ixZ+qCHAPcXE76q7ZkzPzhODkYQSdftUpUSu9xnSd/2I4wBZ//gz/KeEhXu 4Vct37Dwnm0Redk+vuKZwtxohcKivjrU2d4y0wYgIoSpSiDl6jN3wb43mSu4=
X-Sasl-enc: jK3vjveChEctp9VBp8/uMPMdr6a8FLOdy6RppR35rjH7 1462230317
Received: from ( []) by (Postfix) with ESMTPA id EB9FFC00014; Mon, 2 May 2016 19:05:16 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Mon, 2 May 2016 16:05:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:, Magnus Westerlund <>,, IESG <>,
Subject: Re: [AVTCORE] Alissa Cooper's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and 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: Mon, 02 May 2016 23:11:47 -0000

> On May 2, 2016, at 3:28 PM, Colin Perkins <> wrote:
> Hi,
>> On 2 May 2016, at 22:49, Alissa Cooper <> wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-avtcore-rtp-circuit-breakers-15: Discuss
>> 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
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> Many thanks for this work. I expect to ballot YES once we discuss and
>> resolve the issue below.
>> In Section 4.5, I understand the need to base the re-start of the media
>> flow on a human user intervention, but I find it puzzling that this is
>> framed in terms of "restarting the call" rather than "restarting the
>> flow." The recommendation in Section 8 is that senders MUST treat each
>> session independently, but ending/restarting "the call" seems to assume
>> that multiple flows will be treated together.
>> One situation I'm thinking of is one where my audio and video traffic are
>> in separate RTP flows and are routed along different paths for whatever
>> reason. Some network problem is encountered in the video path, triggering
>> a circuit breaker. The "call" doesn't necessarily need to be terminated
>> and re-started, because my audio can continue just fine. This is another
>> case where the application may not want to rely on a human user re-start
>> (if you leave it up to me whether to re-start my video, I'll certainly
>> try to re-start it right away).
> It’s fine if the human user tries to restart the media straight-away: if it keeps failing, they’ll eventually give up. The goal is to avoid an automatic restart that never gives up if it keep failing.

Fair enough, although in this particular case it doesn’t seem to make a lot of sense to leave it up to the user.

>> I think the text in this section needs to
>> be re-phrased to separate the case where a circuit breaker triggering on
>> a single 3-tuple causes a whole call to end (either because the call
>> consisted of a single flow or because all of the flows were encountering
>> congestion and it takes just one circuit breaker to trigger the end of
>> it) from cases where it causes only that flow to be suspended, and
>> reference Section 8 to make it clear that the unit of operation for
>> "ceasing" and "re-starting" is a single flow unless the sender chooses to
>> group flows.
> Right - if the flows are bundled together, then the circuit breaker applies to the entire bundle. If they’re sent on separate paths, then it applies to each flow individually. If that’s not clear, I agree that we should fix the text to make it so.
>> Furthermore (and this is not a DISCUSS point but I leave it here since it
>> follows from the points above), the normative recommendation in the first
>> paragraph here doesn't really follow from the discussion of restarting
>> the call. The recommendation is not to automatically re-start until
>> indications are received that congestion has improved, which is different
>> from waiting until a human user re-starts. I think this would be clearer
>> if the normative recommendation came first and the human user case was
>> discussed afterward.
> This is in §4.5? I can rephrase, if it’s clearer.

Yes, this is all in 4.5

>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> (1) Did the WG discuss BCP status for this rather than PS?
> Not that I recall. Standards track seems more appropriate to me, but BCP would be fine also.

I could see arguments either way. I asked since draft-ietf-tsvwg-circuit-breaker is approved for BCP.

>> (2) Section 4.3:
>>  "If such a reduction in
>>  sending rate resolves the congestion problem, the sender MAY
>>  gradually increase the rate at which it sends data after a reasonable
>>  amount of time has passed, provided it takes care not to cause the
>>  problem to recur ("reasonable" is intentionally not defined here)."
>> In later sections you explain that thresholds are not specified because
>> they are application-dependent. I think that would be useful to note here
>> too as the reason for not defining "reasonable," assuming that is the
>> reason.
> Sure.
> -- 
> Colin Perkins