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 <da...@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 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
>>>
-- Sent from my Android device with K-@ Mail. Please excuse my brevity.
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
