From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp81.ord1c.emailsrvr.com (smtp81.ord1c.emailsrvr.com [108.166.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6463721F350 for ; Fri, 16 May 2014 05:33:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6F6B3512F0; Fri, 16 May 2014 08:33:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 43DDE5131A; Fri, 16 May 2014 08:33:34 -0400 (EDT) User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: References: <3583FA43-EF5B-42D7-A79C-54C87AA514D5@gmail.com> <5373EEFF.5030407@pollere.com> <1400161663.82913275@apps.rackspace.com> <1400202105.4274862@apps.rackspace.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----FH4QZMQ3HAD3FU8ZN7QD7M59PNZHV3" Content-Transfer-Encoding: 8bit From: "David P. Reed" Date: Fri, 16 May 2014 08:33:32 -0400 To: David Lang Message-ID: Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] fq_codel is two years old X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 12:33:38 -0000 ------FH4QZMQ3HAD3FU8ZN7QD7M59PNZHV3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I'll answer this way... The endpoints can use information to slow down as early as possible. That's the whole point of control loop tuning. The fundamental resonance of a control loop depends on its speed of draining and filling the storage element. So you want to sample and deliver ASAP two things in a network that is trying to stay in a ballistic state. One is the aggregate instantaneous controlled (by TCP receiver windows and individual application demand) input rate affecting each switch and the other is the buffered amount on a path. The two factors are not the same, and buffered amount wants to be minimized. For max throughput you need only be in ballistic-maximum buffering. Which is the phase when the bottleneck buffers always have a packet to send but no more (analogous to double buffering). This is a phase in phase space. There can be waves of buffer expansion traveling in the medium at the critical phase boundary, but you don't want to allow a phase transition to backlogged because then the buffers begin to back up and the time to drain adds to the time to recover from sustained descent into colllapse. All flow receivers ideally would be receiving the two sampled measures. You are right that no action can be taken at a switch... but flow receivers can use earlier sampled measures to decide to take action more quickly to prevent incipient buffer growth. Though the situation is different in a highway network, the phase when a jam has developed at an intersection is similar. You want a highway system to operate at the point where no sustained jams exist. On May 15, 2014, David Lang wrote: >Well, if the link isn't congested, why do you need to do anything to >the traffic >other than forward it? You have no way of knowing what paths the >traffic is >going to follow once it hits the next router, so you don't know which >streams >are independent of each other. > >Now, if you are saying that fq_codel can be enhanced to gather stats >even when >there is no congestion so that it has a better idea of what to do once >congestion starts, then you may have a point. > >but fq_codel is very happy to run and do basically nothing if there is >no >congestion. It doesn't delay things to create a buffer. > >David Lang > > On Thu, 15 May 2014, David P. Reed wrote: > >> Both you and Dave Taft misunderstood my idea about standing queues >not being the right way to encode congestion in switches. I do not say >there would be no buffers for jitter. Nor do I call for admission >control. I just suggest that instead of deriving congestion from >backlog measures (requiring that there be backlogs created and >sustained) one can derive congestion measures without sustainng a >backlog... >> >> The result is ballistic flows, if you will. Analogous to ballistic >electrons in materials. >> >> On May 15, 2014, David Lang wrote: >>> We are talking about different things then. >>> >>> The "fast lane" I'm talking about is where ISPs want companies to >pay >>> them for >>> bandwidth (in addition to the companies paying their own ISP for >>> bandwidth and >>> in addition to their users paying them for bandwidth) >>> >>> As for your contention that an ideal Internet will have a buffer >size >>> of <1 >>> packet. That will work, but that will not fully utilize the network, >>> because >>> there will be jitter in the senders and some packet generation will >be >>> delayed, >>> leaving the network with nothing to send in that timeslot. >>> >>> If the network is not fully utilized, then fq_codel isn't needed, >just >>> send >>> packets as they arrive. It's only as a particular link approaches >full >>> utilization that queues will build up and deciding what to do >becomes >>> significant (and fq_codel and similar will matter) >>> >>> As for your thought of having an end-to-end feedback loop, the >problem >>> with that >>> is that it will only work if the path between them is stable and not >>> interfered >>> with by other flows. In the Internet as we have it today, neither >are >>> true. The >>> packets for your connection may travel over different paths, and >>> congestion >>> happens on a link-by-link basis with the combined packets of many >>> connections, >>> not end-to-end based on a single connection. >>> >>> David Lang >>> >>> On Thu, 15 May 2014, dpreed@reed.com wrote: >>> >>>> I don't think that at all. I suspect you know that. But if I >confused >>> you, let >>>> me assure you that my view of the proper operating point of the >>> Internet as a >>>> whole is that the expected buffer queue on any switch anywhere in >the >>> Internet >>>> is < 1 datagram. >>>> >>>> fq_codel is a good start, but it still requires letting buffer >>> queueing >>>> increase. However, mathematically, one need not have the queues >>> build up to >>>> sustain the control loop that fq_codel creates. >>>> >>>> I conjecture that one can create an equally effective congestion >>> control >>>> mechanism as fq_codel without any standing queues being allowed to >>> build up. >>>> (Someone should try the exercise of trying to prove that an optimal >>> end-to-end >>>> feedback control system requires queueing delay to be imposed. I've >>> tried and >>>> it's led me to the conjecture that one can always replace a >standing >>> queue >>>> with a finite memory of past activities - and if one does, the lack >>> of a >>>> standing queue means that the algorithm is better than any that end >>> up with a >>>> standing queue). >>>> >>>> fq_codel could be redesigned into a queue-free fq_codel. >>>> >>>> >>>> On Thursday, May 15, 2014 7:46pm, "David Lang" >said: >>>> >>>> >>>> >>>>> If you think "fast lanes" will actually increase performance for >any >>> traffic, >>>>> you are dreaming. >>>>> >>>>> the people looking for "fast lanes" are't trying to get traffic >>> through any >>>>> faster, they are looking to charge more for the traffic they are >>> already >>>>> passing. >>>>> >>>>> David Lang >>>>> >>>>> On Thu, 15 May 2014, dpreed@reed.com wrote: >>>>> >>>>>> Well done. I'm optimistic for deployment everywhere, except >>> CMTS's, the LTE >>>>> and HSPA+ access networks, and all corporate firewall and intranet >>> gear. >>>>>> >>>>>> The solution du jour is to leave bufferbloat in place, while >using >>> the real >>>>> fads: prioritization (diffserv once we have the "fast lanes" fully >>> legal) and >>>>> "software defined networking" appliances that use DPI for packet >>> routing and >>>>> traffic management. >>>>>> >>>>>> Fixing buffer bloat allows the edge- and enterprise- networks to >>> be more >>>>> efficient, whereas not fixing it lets the edge networks move users >>> up to more and >>>>> more expensive "plans" due to frustration and to sell much more >gear >>> into >>>>> Enterprises because they are easy marks for complex gadgets. >>>>>> >>>>>> But maybe a few engineers who operate and design gear for such >>> networks will >>>>> overcome the incredible business biases against fixing this. >>>>>> >>>>>> That's why all the efforts you guys have put forth are immensely >>> worth it. I >>>>> think this is one of the best innovations in recent years (Bram >>> Cohen's original >>>>> BitTorrent is another, for fully decentralizing data delivery for >>> the very first >>>>> time in a brilliant way.) I will certainly push everywhere I can >to >>> see fq_codel >>>>> deployed. >>>>>> >>>>>> If there were a prize for brilliant projects, this would be top >on >>> my list. >>>>>> >>>>>> >>>>>> >>>>>> On Wednesday, May 14, 2014 9:25pm, "Dave Taht" >>> >>>>> said: >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, May 14, 2014 at 3:32 PM, Kathleen Nichols >>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks, Rich. >>>>>>>> >>>>>>>> And to show you what an amazing bit of work that first fq_codel >>> was, >>>>> I have >>>>>>>> on my calendar that I first "exposed" CoDel to a small group in >>> a >>>>>>>> meeting room >>>>>>>> and on the phone at ISC on April 24. >>>>>>> >>>>>>> And we had all sorts of trouble with the phone, (eric didn't >hear >>>>>>> much) and we then spent hours and hours afterwards discussing >>> wifi >>>>>>> instead of codel... it was too much to take in... >>>>>>> >>>>>>> me, I'd started jumping up and down in excitement about 20 >>> minutes >>>>>>> into kathies preso... >>>>>>> >>>>>>> May 3rd, 2012 was the last 24 hr coding stint I think I'll ever >>> have. >>>>>>> >>>>>>> >>> https://lists.bufferbloat.net/pipermail/codel/2012-May/000023.html >>>>>>> >>>>>>> Ahh, the good ole days, when bufferbloat was first solved and we >>> all >>>>>>> thought the internet would speed up overnight, and we were going >>> to be >>>>>>> rock stars, invited to all the best parties, acquire fame and >>> fortune, >>>>>>> and be awarded medals and given awards. Re-reading all this >>> brought >>>>>>> back memories.... (heck, there's still a couple good ideas in >>> that >>>>>>> thread left unimplemented) >>>>>>> >>>>>>> >>> https://lists.bufferbloat.net/pipermail/codel/2012-May/thread.html >>>>>>> >>>>>>> It looks by may 5th we were getting in shape, and then there >were >>> a >>>>>>> few other issues along the way with the control law and so on... >>> and >>>>>>> eric rewrote the whole thing and made it oodles faster and then >>> as >>>>>>> best as I recall came up with fq_codel on saturday may 5th(?) - >>>>>>> >>>>>>> Ah, I haven't had so much fun in in years. My life since then >>> seems >>>>>>> like an endless string of meetings, politics, and bugfixing. >>>>>>> >>>>>>> The code went from sim/paper, to code, to testing, to mainline >>> linux >>>>>>> in another week. I wish more research went like that! >>>>>>> >>>>>>> commit 76e3cc126bb223013a6b9a0e2a51238d1ef2e409 >>>>>>> Author: Eric Dumazet >>>>>>> Date: Thu May 10 07:51:25 2012 +0000 >>>>>>> >>>>>>> codel: Controlled Delay AQM >>>>>>> >>>>>>> Now, as I recall the story, eric came up with fq_codel on a >>> saturday >>>>>>> afternoon, so I guess that was may 5th - cinco de mayo! >>>>>>> >>>>>>> And that too, landed in mainline... >>>>>>> >>>>>>> commit 4b549a2ef4bef9965d97cbd992ba67930cd3e0fe >>>>>>> Author: Eric Dumazet >>>>>>> Date: Fri May 11 09:30:50 2012 +0000 >>>>>>> >>>>>>> fq_codel: Fair Queue Codel AQM >>>>>>> >>>>>>> let's not forget tom herbert & BQL >>>>>>> >>>>>>> commit 75957ba36c05b979701e9ec64b37819adc12f830 >>>>>>> Author: Tom Herbert >>>>>>> Date: Mon Nov 28 16:32:35 2011 +0000 >>>>>>> >>>>>>> dql: Dynamic queue limits >>>>>>> >>>>>>> Implementation of dynamic queue limits (dql). This is a >>> libary >>>>> which >>>>>>> allows a queue limit to be dynamically managed. The goal of >>> dql is >>>>>>> to set the queue limit, number of objects to the queue, to >be >>>>> minimized >>>>>>> without allowing the queue to be starved. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It was really amazing to me to watch >>>>>>>> something Van and I had been discussing (okay, arguing) about >>>>> privately for >>>>>>>> 6 months and I'd been tinkering with be turned into real code >>> on >>>>> real >>>>>>>> networks. >>>>>>>> Jim Gettys is an incredible (and constructive) nagger, Eric >>> Dumazet >>>>> and >>>>>>>> amazing >>>>>>>> coder, and the entire open source community a really nifty >>> group of >>>>> folks. >>>>>>>> >>>>>>>> Maybe someday we will actually update the first article with >>> some of >>>>> the >>>>>>>> stuff >>>>>>>> we got into the last internet draft.... >>>>>>>> >>>>>>>> be the change, >>>>>>>> Kathie >>>>>>>> >>>>>>>> On 5/14/14 2:01 PM, Rich Brown wrote: >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> I just noticed that the announcement for the first testable >>>>>>>>> implementation of fq_codel was two days ago today - 14 May >>>>> 2012. >>>>>>>>> Build 3.3.6-2 was the first to include working fq_codel. >>>>>>>>> >>>>>>> >>>>> >>> >https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html >>>>>>>>> >>>>>>>>> Two years later, we see fq_codel being adopted lots of >>> places. >>>>> As >>>>>>>>> more and more people/organizations come to understand the >>>>> problem, >>>>>>>>> and how straightforward the solution can be, we're beginning >>> to >>>>> win >>>>>>>>> the battle to have a good Internet experience everywhere. >>>>>>>>> >>>>>>>>> Thanks to Dave, Eric, Kathie, Van, and all the members of this >>>>> list >>>>>>>>> for their perseverance, testing, comments, and patience. >>>>>>>>> Congratulations! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Rich _______________________________________________ Bloat >>>>> mailing >>>>>>>>> list Bloat@lists.bufferbloat.net >>>>>>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bloat mailing list >>>>>>>> Bloat@lists.bufferbloat.net >>>>>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dave Täht >>>>>>> >>>>>>> NSFW: >>>>>>> >>>>> >>> >https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >>>>>>> _______________________________________________ >>>>>>> Cerowrt-devel mailing list >>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>> _______________________________________________ >>>>> Bloat mailing list >>>>> Bloat@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/bloat >>>>> >> >> -- Sent from my Android device with K-@ Mail. Please excuse my >brevity. -- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------FH4QZMQ3HAD3FU8ZN7QD7M59PNZHV3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'll answer this way... The endpoints can use information to slow down as early as possible. That's the whole point of control loop tuning. The fundamental resonance of a control loop depends on its speed of draining and filling the storage element.

So you want to sample and deliver ASAP two things in a network that is trying to stay in a ballistic state. One is the aggregate instantaneous controlled (by TCP receiver windows and individual application demand) input rate affecting each switch and the other is the buffered amount on a path.

The two factors are not the same, and buffered amount wants to be minimized. For max throughput you need only be in ballistic-maximum buffering. Which is the phase when the bottleneck buffers always have a packet to send but no more (analogous to double buffering).

This is a phase in phase space. There can be waves of buffer expansion traveling in the medium at the critical phase boundary, but you don't want to allow a phase transition to backlogged because then the buffers begin to back up and the time to drain adds to the time to recover from sustained descent into colllapse.

All flow receivers ideally would be receiving the two sampled measures.

You are right that no action can be taken at a switch... but flow receivers can use earlier sampled measures to decide to take action more quickly to prevent incipient buffer growth.

Though the situation is different in a highway network, the phase when a jam has developed at an intersection is similar. You want a highway system to operate at the point where no sustained jams exist.

On May 15, 2014, David Lang <david@lang.hm> wrote:
Well, if the link isn't congested, why do you need to do anything to the traffic 
other than forward it? You have no way of knowing what paths the traffic is 
going to follow once it hits the next router, so you don't know which streams 
are independent of each other.

Now, if you are saying that fq_codel can be enhanced to gather stats even when 
there is no congestion so that it has a better idea of what to do once 
congestion starts, then you may have a point.

but fq_codel is very happy to run and do basically nothing if there is no 
congestion. It doesn't delay things to create a buffer.

David Lang

On Thu, 15 May 2014, David P. Reed wrote:

Both you and Dave Taft misunderstood my idea about standing queues not being the right way to encode congestion in
switches. I do not say there would be no buffers for jitter. Nor do I call for admission control. I just suggest that instead of deriving congestion from backlog measures (requiring that there be backlogs created and sustained) one can derive congestion measures without sustainng a backlog...

The result is ballistic flows, if you will. Analogous to ballistic electrons in materials.

On May 15, 2014, David Lang <david@lang.hm> wrote:
We are talking about different things then.

The "fast lane" I'm talking about is where ISPs want companies to pay
them for
bandwidth (in addition to the companies paying their own ISP for
bandwidth and
in addition to their users paying them for bandwidth)

As for your contention that an ideal Internet will have a buffer size
of <1
packet. That wil
 l work,
but that will not fully utilize the network,
because
there will be jitter in the senders and some packet generation will be
delayed,
leaving the network with nothing to send in that timeslot.

If the network is not fully utilized, then fq_codel isn't needed, just
send
packets as they arrive. It's only as a particular link approaches full
utilization that queues will build up and deciding what to do becomes
significant (and fq_codel and similar will matter)

As for your thought of having an end-to-end feedback loop, the problem
with that
is that it will only work if the path between them is stable and not
interfered
with by other flows. In the Internet as we have it today, neither are
true. The
packets for your connection may travel over different paths, and
congestion
happens on a link-by-link basis with the combined packets of many
connections,
not end-to-end based o
 n a
single connection.

David Lang

On Thu, 15 May 2014, dpreed@reed.com wrote:

I don't think that at all. I suspect you know that. But if I confused
you, let
me assure you that my view of the proper operating point of the
Internet as a
whole is that the expected buffer queue on any switch anywhere in the
Internet
is < 1 datagram.

fq_codel is a good start, but it still requires letting buffer
queueing
increase.  However, mathematically, one need not have the queues
build up to
sustain the control loop that fq_codel creates.

I conjecture that one can create an equally effective congestion
control
mechanism as fq_codel without any standing queues being allowed to
build up.
(Someone should try the exercise of trying to prove that an optimal
end-to-end
feedback control system requires queueing delay to be imposed. I've
tried and
it's led me to the conjecture that one can always replace a standing
queue
with a finite memory of past activities - and if one does, the lack
of a
standing queue means that the algorithm is better than any that end
up with a
standing queue).

fq_codel
  could
be redesigned into a queue-free fq_codel.


On Thursday, May 15, 2014 7:46pm, "David Lang" <david@lang.hm> said:



If you think "fast lanes" will actually increase performance for any
traffic,
you are dreaming.

the people looking for "fast lanes" are't trying to get traffic
through any
faster, they are looking to charge more for the traffic they are
already
passing.

David Lang

On Thu, 15 May 2014, dpreed@reed.com wrote:

Well done.  I'm optimistic for deployment everywhere, except
CMTS's, the LTE
and HSPA+ access networks, and all corporate firewall and intr
 anet
gear.

The solution du jour is to leave bufferbloat in place, while using
the real
fads: prioritization (diffserv once we have the "fast lanes" fully
legal) and
"software defined networking" appliances that use DPI for packet
routing and
traffic management.

Fixing buffer bloat allows the edge- and enterprise- networks to
be more
efficient,
whereas not fixing it lets the edge networks move users
up to more and
more expensive "plans" due to frustration and to sell much more gear
into
Enterprises because they are easy marks for complex gadgets.

But maybe a few engineers who operate and design gear for such
netw
 orks
will
overcome the incredible business biases against fixing this.

That's why all the efforts you guys have put forth are immensely
worth it.  I
think this is one of the best innovations in recent years (Bram
Cohen's original
BitTorrent is another, for fully decentralizing data delivery for
the very first
time in a brilliant way.) I will certainly push everywhere I can to
see fq_codel
deployed.

If there were a prize for brilliant projects, this would be top on
my list.



On Wednesday, May 14, 2014 9:25pm, "Dave Taht"
<
dave.taht@gmail.com>
said:



On Wed, May 14, 2014 at 3:32 PM, Kathleen Nichols
<
nichols@pollere.com>
wrote:

Thanks, Rich.

And to show you what an amazing bit of work that first fq_codel
was,
I have
on my calendar that I first "exposed" CoDel to a small group in
a
meeting room
and on the phone at ISC on April 24.

And we had all sorts of trouble with the phone, (eric didn't hear
much) and we then spent hours and hours afterwards discussing
wifi
instead of codel... it was too much to take in...

me, I'd started jumping up and down in excitement about 20
minutes
into kathies preso...

May 3rd, 2012 was the last 24 hr coding stint I think I'll ever
have.


https://lists.bufferbloat.net/pipermail/codel/2012-May/000023.html

Ahh, the good ole days, when bufferbloat was first solved and we
all
thought the internet would speed 
 up
overnight, and we were going
to be
rock stars, invited to all the best parties, acquire fame and
fortune,
and be awarded medals and given awards. Re-reading all this
brought
back memories.... (heck, there's still a couple good ideas in
that
thread left unimplemented)


https://lists.bufferbloat.net/pipermail/codel/2012-May/thread.html

It looks by may 5th we were getting in shape, and then there were
a
few other issues along the way with the control law and so on...
and
eric rewrote the whole thing and made it oodles faster and then
as
best as I recall came up with fq_codel on saturday may 5th(?) -

Ah, I haven't
  had so
much fun in in years. My life since then
seems
like an endless string of meetings, politics, and bugfixing.

The code went from sim/paper, to code, to testing, to mainline
linux
in another week. I wish more research went like that!

commit 76e3cc126bb223013a6b9a0e2a51238d1ef2e409
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 10 07:51:25 2012 +0000

codel: Controlled Delay AQM

Now, as I recall the story, eric came up with fq_codel on a
saturday
afternoon, so I guess that was may 5th - cinco de mayo!

And that too, landed in mainline...

commit 4b549a2ef4bef9965d97cbd992ba67930cd3e0fe
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 11 09:30:50 2012 +0000

fq_codel: Fair Queue Codel AQM

let's not forget tom herbert & BQL

commit 75957ba36c05b979701e9ec64b37819adc12f830
Author: Tom Herbert <therbert@google.com>
Date:   Mon Nov 28 16:32:35 2011 +0000

dql: Dynamic queue limits

Implementation of dynamic queue limits (dql).  This is a
libary
which
allows a queue limit to be dynamically managed.  The goal of
dql is
to set the queue limit, number of objects to the queue, to be
minimized
without allowing the queue to be starved.




It was really amazing to me to watch
something Van and I had been discussing (okay, arguing) about
privately for
6 months and 
 I'd
been tinkering with be turned into real code
on
real
networks.
Jim Gettys is an incredible (and constructive) nagger, Eric
Dumazet
and
amazing
coder, and the entire open source community a really nifty
group of
folks.

Maybe someday we will actually update the first article with
some of
the
stu
 ff
we got into the last internet draft....

be the change,
Kathie

On 5/14/14 2:01 PM, Rich Brown wrote:
Folks,

I just noticed that the announcement for the first testable
implementation of fq_codel was two days ago today - 14 May
2012.
Build 3.3.6-2 was the first to include working fq_codel.



https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html

Two years later, we see fq_codel bein
 g
adopted lots of
places.
As
more and more people/organizations come to understand the
problem,
and how straightforward the solution can be, we're beginning
to
win
the battle to have a good Internet experience everywhere.

Thanks to Dave, Eric, Kathie, Van, and all the members of this
list
for their perseverance, testing, comments, and
patience.
Congratulations!

Best regards,

Rich
Bloat
mailing
list Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat



Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat



--Dave Täht

NSFW:


https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat


-- Sent from my Android device with K-@ Mail. Please excuse my brevity.

-- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------FH4QZMQ3HAD3FU8ZN7QD7M59PNZHV3--