[Cerowrt-devel] [Bloat] fq_codel is two years old

dpreed at reed.com dpreed at reed.com
Thu May 15 18:01:45 PDT 2014 

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 at 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 at 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" <dave.taht at gmail.com>
> said:
> >
> >
> >
> >> On Wed, May 14, 2014 at 3:32 PM, Kathleen Nichols
> <nichols at 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 at 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 at 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 at 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
> >> > 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 at lists.bufferbloat.net
> >> >> https://lists.bufferbloat.net/listinfo/bloat
> >> >>
> >> >
> >> > _______________________________________________
> >> > Bloat mailing list
> >> > Bloat at 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 at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>_______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140515/a2ecdf00/attachment.html>

More information about the Cerowrt-devel mailing list