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

Thu, 15 May 2014 18:40:17 -0700 

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, dpr...@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" <da...@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, dpr...@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.t...@gmail.com>
said:
>
>
>
>> On Wed, May 14, 2014 at 3:32 PM, Kathleen Nichols
<nich...@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 <eduma...@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 <eduma...@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 <therb...@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@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-de...@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>_______________________________________________
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























					Reply via email to