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

Colin Perkins <csp@csperkins.org> Tue, 10 May 2016 23:26 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 90E0912D803; Tue, 10 May 2016 16:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Kh27R0IfDVec; Tue, 10 May 2016 16:26:06 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1290E12B027; Tue, 10 May 2016 16:26:06 -0700 (PDT)
Received: from [81.187.2.149] (port=40545 helo=[192.168.0.90]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1b0H2Q-0007zn-Ra; Wed, 11 May 2016 00:26:03 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Colin Perkins <csp@csperkins.org>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <ED6AA3E6-0345-4D02-B76B-99CE822A5420@kuehlewind.net>
Date: Wed, 11 May 2016 00:26:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <44A9243A-9429-45C4-A0EE-DBFD67A4148E@csperkins.org>
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> <ED6AA3E6-0345-4D02-B76B-99CE822A5420@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/z1jsCaCCMWbyCfT67VkFqpgn5o4>
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:26:07 -0000

> On 10 May 2016, at 23:58, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> 
> 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...

I'm sorry, but I'm still not seeing the justification for this. The ABE work you cited earlier is TCP specific, and I don't recall any other discussion in TSV or RMCAT around alternative back-off for non-TCP flows. What am I missing?

Colin