[AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS)
"Spencer Dawkins" <spencer.dawkins@huawei.com> Wed, 20 April 2016 01:20 UTC
Return-Path: <spencer.dawkins@huawei.com>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8102612D6DA; Tue, 19 Apr 2016 18:20:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencer.dawkins@huawei.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160420012041.31613.87215.idtracker@ietfa.amsl.com>
Date: Tue, 19 Apr 2016 18:20:41 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/P-X6Q6QcI1jyz5qFdTTp03C0aWM>
Cc: avtcore-chairs@ietf.org, magnus.westerlund@ericsson.com, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org
Subject: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Apr 2016 01:20:41 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-avtcore-rtp-circuit-breakers-14: 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 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I really like this specification, and have two questions I'd like to understand before balloting YES ... I'm looking at this text: 4.5. Ceasing Transmission What it means to cease transmission depends on the application. The intention is that the application will stop sending RTP data packets to a particular destination 3-tuple (transport protocol, destination port, IP address), until the user makes an explicit attempt to restart the call. It is important that a human user is involved in the decision to try to restart the call, since that user will eventually give up if the calls repeatedly trigger the circuit breaker. This will help avoid problems with automatic redial systems from congesting the network. Accordingly, RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the ^^^^^^^^^^ sender has received information that the congestion has dissipated, or can reasonably be expected to have dissipated. and trying to understand why this is not MUST NOT. I'm trying to reconcile this with the RFC 2119 definition of SHOULD NOT, which is 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Could you help me understand when automatic restarts might be "acceptable or even useful"? Reading on, I'm wondering if this text is anticipating It is recognised that the RTP implementation in some systems might not be able to determine if a call set-up request was initiated by a human user, or automatically by some scripted higher-level component of the system. but definitely want to understand what you're thinking here. I have a similar question about this text ECN-CE marked packets SHOULD be treated as if it were lost for the purposes of congestion control, when determining the optimal media sending rate for an RTP flow. If an RTP sender has negotiated ECN support for an RTP session, and has successfully initiated ECN use on the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD ^^^^^^ be treated as if they were lost when calculating if the congestion- based RTP circuit breaker (Section 4.3) has been met. Could you help me understand why an implementation wouldn't do this?
- [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-… Spencer Dawkins
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Colin Perkins
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Spencer Dawkins at IETF
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Spencer Dawkins at IETF
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Colin Perkins
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Colin Perkins
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Spencer Dawkins at IETF
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Ben Campbell
- Re: [AVTCORE] Spencer Dawkins' Discuss on draft-i… Colin Perkins