IETF Logo Mail Archive

Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 10 May 2016 23:00 UTC

Return-Path: <ietf@kuehlewind.net>
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 0AD8B12D136 for <avt@ietfa.amsl.com>; Tue, 10 May 2016 16:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0Z0fLpVDLwaW for <avt@ietfa.amsl.com>; Tue, 10 May 2016 16:00:05 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C36012B00A for <avt@ietf.org>; Tue, 10 May 2016 16:00:04 -0700 (PDT)
Received: (qmail 16271 invoked from network); 11 May 2016 01:00:00 +0200
Received: from softdnserror (HELO ?10.189.73.149?) (192.54.222.20) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 00:59:59 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <96261ECE-C99A-442F-BA22-7EF1CF200164@csperkins.org>
Date: Tue, 10 May 2016 18:58:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED6AA3E6-0345-4D02-B76B-99CE822A5420@kuehlewind.net>
References: <20160503120321.7534.26562.idtracker@ietfa.amsl.com> <32C2F93E-9CB9-4645-9C42-320AA8B24ED5@csperkins.org> <2EC09917-2E05-407D-AA7F-38C73B179C4B@kuehlewind.net> <219AC00D-9E2E-4AF7-85F0-924EAE5F6164@kuehlewind.net> <BD5D6E34-3C35-4221-86A1-AB3150EBFFE1@csperkins.org> <8D786065-7DCD-43A2-BB69-5D7B1D44546B@kuehlewind.net> <953AB9F5-6220-4C9E-80B6-FE72BF80B648@csperkins.org> <762DC4EA-F5E8-49EB-BFEC-5DFA569B9444@kuehlewind.net> <12182E39-A26B-431F-9CCA-7E602EBFAB7E@csperkins.org> <30E6734A-0595-404E-8823-F27603B6CFC1@kuehlewind.net> <F3648EEF-5BBD-4F2F-BE9E-552D27EE3C2F@csperkins.org> <8CF47513-8E62-4EA0-B938-E9829EC4B774@kuehlewind.net> <9824AE79-0C56-4087-8C3C-E36812909B0E@csperkins.org> <1B501087-267A-4DBF-A08C-40245EC1200D@kuehlewind.net> <96261ECE-C99A-442F-BA22-7EF1CF200164@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/XJYgY0iAhesozckrq2mw2CI3Hus>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG <iesg@ietf.org>, avt@ietf.org
Subject: Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and 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: Tue, 10 May 2016 23:00:07 -0000

Hi Colin,

> Am 10.05.2016 um 18:49 schrieb Colin Perkins <csp@csperkins.org>:
> 
>> And further for ECN the persistent congestion level can be quite high, even without causing the queue to fill up but maintaining a low queuing delay level. Therefore ECN needs clearly to be treated differently than loss.
> 
> If you require the circuit breaker to only trigger on loss, not on ECN marks, this forces the queue to overflow before the problematic flow is stopped. That disrupts other traffic sharing the queue. The point of using ECN is to be able to stop flows causing persistent excessive congestion without the latency penalty of the queue overflow.

I’m not objecting to use ECN as input signal (I personally still think it might not be needed, but, yes can be used). However, it must be treated differently than loss. You are free to propose a mechanism how to take CE into account (differently than counting it as loss), e.g. counting it separately and using a even higher threshold...

Mirja

v2.23.0 | Report a Bug | By Email