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.