Re: [tcpPrague] [aqm] L4S status update

Matt Mathis <mattmathis@google.com> Tue, 29 November 2016 02:55 UTC

Return-Path: <mattmathis@google.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BDF12A26D for <tcpprague@ietfa.amsl.com>; Mon, 28 Nov 2016 18:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 5o3V6659v-pi for <tcpprague@ietfa.amsl.com>; Mon, 28 Nov 2016 18:55:53 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF76A12A26C for <tcpPrague@ietf.org>; Mon, 28 Nov 2016 18:55:49 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id c21so256174310ioj.1 for <tcpPrague@ietf.org>; Mon, 28 Nov 2016 18:55:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jkMOP/KHQzSi2auJF5ZhlJuZm6xyOw++BktHAv0Lkhs=; b=m9ZieNeEpGGS+q83lG7dnx8AD/BUbqQh7RahH63XjuRNxx2F7qoBfkDt6D/CogE5wH kiSgQpS3Yaj0tNew3QsTA7vQoiRZphFApXkPLNZbAxlKm79KWZ4V63wh8TGQPISKP5Dm y/IIVw9vz07lmL+NFXkeSoNZ8AXf6cFHOvGp+Zcclk+c/HfcczTERYK24kCGlmlLabiA mCZtQCLOi1okWITHR9C/KVBkeBDjtJHgVcyD4Gyo//JEfs20YVpaCkE3IwgIi7nucfx3 XPsnvQJ5ayHDmFhZ330H9gU8cWv5tRGe3MXD/smoKrfL6Sio8lC3F7PxE66ycKiG4Fxq oYUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jkMOP/KHQzSi2auJF5ZhlJuZm6xyOw++BktHAv0Lkhs=; b=gLwQlcIuqxs7GBcAsyZCXPu0kVpzCY9b22EctARrxzAsLnVc1XP8/e2hykfQgKhbMV SsdRZ3bXoiXoR9/WwdP+kT3ztOZ1ikPrDfIZb2abaW5U8gu++0l3SPnYysqWe/zMCGmr zAb2S4nxl1YeRNd5ldh9n2NB3VXgQSmVKfm7J24QJIU1YTNnwzuG6CS20Kv3XN6fADrd rM2tqpiJeEaRLACyyWkHrHdo86MF4ujA5tU9noXQLi285T7RmK8d3gyte/VwzQJmfp6X 7fqkhayV0HgB08YNbZ9RtrozG+4nM9AP9A+jcjcYsxC9PaLF0RTT2Te5jMgm4E1FkfEQ yi9A==
X-Gm-Message-State: AKaTC01DnFR8a9wVNlxRXEEzjLz+DmWhof5PuWxsINjPBZ6rABoRPbRYYV/dFYJpZ8JPJhDkRTjr7h0tp4wwO+4Y
X-Received: by 10.36.178.9 with SMTP id u9mr21501591ite.80.1480388148902; Mon, 28 Nov 2016 18:55:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.252.199 with HTTP; Mon, 28 Nov 2016 18:55:28 -0800 (PST)
In-Reply-To: <E615574E-2C76-4BAB-9481-E5FCF84659B3@gmail.com>
References: <be67928d-e1f7-2495-147d-1d42d6783cc8@bobbriscoe.net> <f6b89407-14d8-b532-b793-7490cb5a2117@kit.edu> <f16c9830-f97a-64e0-76e6-66f146576616@bobbriscoe.net> <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net> <E615574E-2C76-4BAB-9481-E5FCF84659B3@gmail.com>
From: Matt Mathis <mattmathis@google.com>
Date: Mon, 28 Nov 2016 18:55:28 -0800
Message-ID: <CAH56bmDoQ9OnjrrDD2XQ94AQ=G=y4U6KZh+q+q-sF6o1VvsdVQ@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Content-Type: multipart/alternative; boundary="f403045d9db6bf22fe054267b9bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/XHJb0ZSAaMfgfxOfyFtK_gI1zR0>
Cc: tcpm IETF list <tcpm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, TCP Prague List <tcpPrague@ietf.org>, "Bless, Roland (TM)" <roland.bless@kit.edu>, AQM IETF list <aqm@ietf.org>
Subject: Re: [tcpPrague] [aqm] L4S status update
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2016 02:55:55 -0000

Bob's point is that fq_anything forfeits any mechanism for an application
or user to imply the value of the traffic by how much congestion they are
willing to inflict on other traffic.

This concept is the foundation of ConEx and related technologies which
could move the capacity allocation problem into the economic domain.  This
actually makes a lot of sense.    However, after investing a lot of time in
it over the years (in collaboration with Bob etal), I have come to believe
that this only makes sense for enforcing financially equitable use of a
deliberately undersized network.    Building capacity is generally cheaper
than building the congestion instrumentation.....

That said, fq_anything does not work at core router scale.

Note that there are two views, each of which is self consistent:

1) You need fq_* to isolate flows; prioritization must be done with
IP/TOS/DSCP bits; aggressive flows can't hurt other flows; low delays
require that flows sharing a Q to be nice to each other and respond to AQM
2) Uniform AQM/drop/mark per packet permits shared economic view of the
value of the traffic (e.g. a price) ; traffic is prioritized by how
aggressive of CC you choose; low delay [is/should be] a design property of
the shared CC and AQM algorithms.

If you have a way to create proper incentives about congestion (e.g. price
and chargeback), #2 is probably a strong system; if that fails #1 is
probably stronger.

Note that half solutions or solutions split between the models don't work.
period.  Arguing about incomplete systems that are missing some of the
parts is pointless because they don't work at some level (often layer 8 or
9).

Drop tail counts as "neither", so even partial deployment of anything can
be an improvement.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Mon, Nov 28, 2016 at 5:20 PM, Jonathan Morton <chromatix99@gmail.com>
wrote:

>
> > On 29 Nov, 2016, at 02:45, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> >
> > I am particularly worried about embedding fq in the Internet. That is
> far worse than embedding a subtly different performance improvement for
> certain congestion controls. With fq, the network determines the precise
> departure time of each packet, completely overriding the host's choice,
> without any understanding of what the applications is trying to achieve.
>
> You don’t seem to be very fond of *either* component of fq_codel, then.  A
> shame, since it works very well in practice.
>
> What fq_codel does is identify latency-sensitive flows by the fact that
> they are not taking up their fair share of the bandwidth.  Packets
> belonging to these flows are typically delivered *immediately* and *without
> loss*.  This is a far cry from “completely overriding the hosts’s choice”
> of timing, as you claim.
>
> In fact, I would actually be grateful if you retracted that particular
> claim.
>
> It must be emphasised, though, that flow-isolating AQMs are not designed
> for the Internet core - there are just too many individual flows to
> manage.  Their place is at the edge, on either end of last-mile links,
> where the bottlenecks are most apparent.  For core, backhaul and peering
> links, plain AQM is sufficient and much easier to implement.
>
> > Even worse, in Jan 2017, I am told that fq_CoDel will become hard coded
> into the Linux WiFi drivers, without even a framework to dynamically load
> any alternative(s). Of course, we can add such a framework, but we are
> seeing Linux become the next major middlebox problem. It might be excusable
> if there were not sound alternatives available,... but there are.
>
> This tight integration is because it was necessary to solve some serious,
> long-standing problems with Linux wifi, which couldn’t be solved
> satisfactorily at the qdisc layer because information about wifi-specific
> things was needed - and there were *no* practical alternatives which
> actually solved the problem, otherwise we’d have used them.
>
> Wifi is also a last-mile technology, and it is often the bottleneck in
> several types of practical deployment.  Large conferences are a particular
> example.  I’m rather looking forward to seeing the first large conference
> to deploy the new Linux wifi stuff, and seeing whether it has made the
> typical load there easier to cope with.  It probably has.
>
>  - Jonathan Morton
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>