Re: [tsvwg] thoughts on operational queue settings (Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04)

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 12 April 2018 08:14 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F642124235 for <tsvwg@ietfa.amsl.com>; Thu, 12 Apr 2018 01:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 nViSZm8rxPYB for <tsvwg@ietfa.amsl.com>; Thu, 12 Apr 2018 01:14:03 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E811205F0 for <tsvwg@ietf.org>; Thu, 12 Apr 2018 01:14:03 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7C0E5AF; Thu, 12 Apr 2018 10:14:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1523520840; bh=gzAzWe7CPj3/0fpiZAUJuGYTEGFnvXrLEjN4WvfRUDI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=N3iBnDLwW2Z33SnCpYFC0Bo+PaaGZqY2NWkpacWJzU4CYaTKAOAJsJ9yM6tZz+xhS F5W2xKJQxxFRIhvo8tpjXP8P+D8IlmgVJ1f40Nsi2YGTKrZX+8/N/MU79Qu44KwOyS vhgm6nFGPcFORaFUxW1f/QaUFpHI6SPBBUsjKef0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 785619F; Thu, 12 Apr 2018 10:14:00 +0200 (CEST)
Date: Thu, 12 Apr 2018 10:14:00 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Toerless Eckert <tte@cs.fau.de>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, tsvwg@ietf.org
In-Reply-To: <20180412080515.g5qkjqmluru26nib@faui48f.informatik.uni-erlangen.de>
Message-ID: <alpine.DEB.2.20.1804121007560.18650@uplift.swm.pp.se>
References: <20180406160344.xwfqgzhzfto56jhq@faui48f.informatik.uni-erlangen.de> <5252b232-13df-fb19-227f-95694572b86c@kit.edu> <20180412012544.tmnzec3zddlyrmlb@faui48f.informatik.uni-erlangen.de> <39fb9195-b46f-945f-d414-936f97a59d87@gmail.com> <alpine.DEB.2.20.1804120818210.18650@uplift.swm.pp.se> <20180412080515.g5qkjqmluru26nib@faui48f.informatik.uni-erlangen.de>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mREDkrg5CKzoRkI4HXOkLYq-zo0>
Subject: Re: [tsvwg] thoughts on operational queue settings (Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 08:14:05 -0000

On Thu, 12 Apr 2018, Toerless Eckert wrote:

> I would hope today we could get a separate WFQ for LE on all
> platforms which looks to me like the much easier and easier to
> predict solution. If you tell me thats not the case, my
> interest to delve again into RED profiles will raise again *sigh*

There are too many platforms and they're all different as you already 
said. Common platforms will give you the possibility of having a few 
queues, so I will also investigate what the result would be of having 
three queues, one for LE, one for BE and one for rest, where LE gets 5% 
and the two other queues share the rest (getting half the bw each if both 
are congested).

This kind of setup would result in no congestion seen by rest of traffic 
even if BE and LE are fully congested.

If I set the LE drop profile to 1ms/2ms then it stopped working when there 
was BE congestion. I think this is not what one wants to happenn for 
normal customers, instead LE traffic should get some bandwidth even if 
it's a smallish single digit percentage of the total.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se