Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>
Date: Tue, 29 Nov 2016 03:20:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Bob Briscoe <ietf@bobbriscoe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/FTszK_nm_rqIY0qnkftHw97KjiM>
Cc: tcpm IETF list <tcpm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "Bless, 
 Roland \(TM\)" <roland.bless@kit.edu>, TCP Prague List <tcpPrague@ietf.org>,
 AQM IETF list <aqm@ietf.org>
Subject: Re: [tcpPrague] [aqm] L4S status update
Precedence: list


> On 29 Nov, 2016, at 02:45, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>=20
> 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=E2=80=99t 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 =E2=80=9Ccompletely overriding =
the hosts=E2=80=99s choice=E2=80=9D 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=E2=80=99t =
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=E2=80=99d =
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=E2=80=99m 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