Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-01.txt

Colin Perkins <csp@csperkins.org> Sat, 23 February 2013 18:57 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 1DAF621F86E8 for <avt@ietfa.amsl.com>; Sat, 23 Feb 2013 10:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2PaHNzT3tJ2 for <avt@ietfa.amsl.com>; Sat, 23 Feb 2013 10:57:50 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBB21F86C2 for <avt@ietf.org>; Sat, 23 Feb 2013 10:57:50 -0800 (PST)
Received: from [80.176.158.71] (port=40926 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1U9KHx-0007zg-EN; Sat, 23 Feb 2013 18:57:38 +0000
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5CC8F49-ED07-4C3B-9E36-0CA1D302D0F4"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CALw1_Q3+QeEi5H=JUAO=xRqDbkdE_jWGe-g7XtLgMvWp-HKcHQ@mail.gmail.com>
Date: Sat, 23 Feb 2013 18:57:35 +0000
Message-Id: <183330F1-1D37-4C48-BC15-FAF91DC8B34C@csperkins.org>
References: <20121022221624.7138.24306.idtracker@ietfa.amsl.com> <A1CB2B6E-E860-4BF5-AEE7-97C71DF10D9C@csperkins.org> <CALw1_Q12AJkaKomh3EHNSJKXWoFJW_G6NqsQxGnJaup9=Mg9Bw@mail.gmail.com> <2B95330E-6BF9-4F14-9F36-9E2CDF48A96D@csperkins.org> <CALw1_Q3+QeEi5H=JUAO=xRqDbkdE_jWGe-g7XtLgMvWp-HKcHQ@mail.gmail.com>
To: Kevin Gross <kevin.gross@avanw.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 23 Feb 2013 18:57:51 -0000

Kevin,

If the problem is congestion collapse, then a factor of ten reduction in sending rate may well help. However, I see your point, and will change the draft to only suggest ceasing transmission for this circuit breaker.

Colin



On 18 Feb 2013, at 16:48, Kevin Gross wrote:
> Because the circuit breaker is conservative, my assessment is that things are clearly badly busted when the breaker trips. In this case, over the duration of 3 RRs, not a single RTP packet has been delivered. If this is due to moderate congestion or flow control, you'd expect at least a few of the packets to get through. If none are getting through, there is either a connectivity problem or possibly congestive collapse. In neither case is reducing rate by a factor of 10 a useful response. Have I missed something? What sort of failure scenario are you thinking of where the reduced rate would be successful?
> 
> I am also concerned about scope. Circuit breakers are a safety net and should not interfere with congestion management techniques as they are developed. Circuit breakers should conservatively detect faults and trip. They should not half-trip or automatically reset themselves.
> 
> On Tue, Feb 12, 2013 at 5:18 PM, Colin Perkins <csp@csperkins.org> wrote:
>> Section 4.1: Delete second paragraph. As disused in the session today, if things are messed up enough to trigger circuit breaker #1, reducing offered load is not likely a useful response. Section 4.3 contains a copy of this recommendation and is probably an appropriate recommendation for circuit breaker #3 described there.
> 
> If this were a congestion control algorithm, I'd probably agree that we should be more aggressive in stopping transmission here, but the circuit breaker is supposed to be conservative when it fires, to encompass all reasonable congestion control behaviours. As such, I think it is better that the draft allow the option of reducing offered load as a response here, rather than mandate ceasing transmission immediately.



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