Re: [tsvwg] [Ecn-sane] per-flow scheduling

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 27 June 2019 08:49 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 C1E4612012C for <tsvwg@ietfa.amsl.com>; Thu, 27 Jun 2019 01:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 uDyKE5ebaGwy for <tsvwg@ietfa.amsl.com>; Thu, 27 Jun 2019 01:49:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 721CE12000F for <tsvwg@ietf.org>; Thu, 27 Jun 2019 01:49:04 -0700 (PDT)
Received: from MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 701EF1B001BF; Thu, 27 Jun 2019 09:48:57 +0100 (BST)
Message-ID: <5D1482F9.4050204@erg.abdn.ac.uk>
Date: Thu, 27 Jun 2019 09:48:57 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
CC: "David P. Reed" <dpreed@deepplum.com>, Sebastian Moeller <moeller0@gmx.de>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de> <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com> <835b1fb3-e8d5-c58c-e2f8-03d2b886af38@gmail.com> <1561233009.95886420@apps.rackspace.com> <71EF351D-AFBF-4C92-B6B9-7FD695B68815@gmail.com> <1561241377.4026977@apps.rackspace.com> <4E863FC5-D30E-4F76-BDF7-6A787958C628@gmx.de> <1561566706.778820831@apps.rackspace.com> <a52d0a9f-9652-705a-babe-441f93532845@kit.edu>
In-Reply-To: <a52d0a9f-9652-705a-babe-441f93532845@kit.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bFPLcetKPGX1YnY9PgUZWWeGMKI>
Subject: Re: [tsvwg] [Ecn-sane] per-flow scheduling
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Jun 2019 08:49:07 -0000

On 27/06/2019, 08:53, Bless, Roland (TM) wrote:
> Hi,
>
> Am 26.06.19 um 18:31 schrieb David P. Reed:
>
>> The idea that "link utilization" of 100% must be achieved is why we got
>> bufferbloat designed into routers. It's a worm's eye perspective. To
> You are right, but IMHO it is even worse, because it is an
> artefact of the particular loss-based TCP congestion control
> as it was designed and the correspondingly derived "BDP buffer size"
> rule. The loss-based AIMD congestion control is able to keep up the
> utilization then, because it uses the systematically built standing
> queue during its back-off after a packet loss. That essentially keeps
> the sending rate at the same level. However, now we know that avoiding
> queuing delay is important, we can also design better congestion
> controls that do not fill the available buffer capacity up to exhaustion
> and that do not require standing queues to keep up link utilization.
>
> However, as you also wrote, the positive and negative effects of
> existing buffers depend a lot on the particular traffic pattern and this
> has also changed much during the last decades. So I think that revising
> the "buffer size" discussion could be useful...
>
> Aside from that I find the SCE proposal very useful, because it allows
> to provide an additional level of congestion signalling that could
> be used by various congestion control schemes.
>
> Regards,
>   Roland
I know from the work on using ECT(0) with RFC8511, that you can already 
get a lot of benefit from treating ECN as a first indication of 
congestion and loss as a much more serious signal. I may have missed 
something recently. I recall attempts to do 3-level marking of ECNin the 
past,but  when I last looked through the litterature I did not find any 
lasting deployment resulted or modern research  (please send pointers if 
I overlooked something).

I am therefore  rather skeptical that research on SCE is ready  I'd be 
curious to see what extra value is gained from the SCE approach.

Gorry