Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@vt.edu wrote: > > Do we have a good cookbook on how to determine the set-rate? On DSL, the sync rates in each direction should usually be readable from the modem; they are typically reported on the router's status page. The advertised rate is less reliable, to say the least. On wireless links, all bets are off - even with stationary endpoints, link capacity varies wildly over time. This needs to be solved in the radio-modems. If it's wifi, however, a link-rate-independent solution now exists for certain hardware, and there's nothing theoretically stopping something similar being put into future HardMAC implementations. If we get the choice of hardware, naturally we choose wisely. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
Well, On June 19, 2018 10:34:07 PM GMT+02:00, valdis.kletni...@vt.edu wrote: >On Mon, 18 Jun 2018 18:46:18 -0700, Dave Taht said: > >> One of cake's "minor" features is the *perfect* defeat of the htb >> based shaper in cable modems. If you know the set-rate on the modem, >> you just set it to the same thing and get vastly superior performance >to >> docsis 3.1, pie, or the sqm-scripts. > >Do we have a good cookbook on how to determine the set-rate? With cable ___ >Cerowrt-devel mailing list >Cerowrt-devel@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
On Mon, 18 Jun 2018 18:46:18 -0700, Dave Taht said: > One of cake's "minor" features is the *perfect* defeat of the htb > based shaper in cable modems. If you know the set-rate on the modem, > you just set it to the same thing and get vastly superior performance to > docsis 3.1, pie, or the sqm-scripts. Do we have a good cookbook on how to determine the set-rate? ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
good rant! -Original Message- From: "Dave Taht" Sent: Tuesday, June 19, 2018 3:33pm To: "dpr...@deepplum.com" Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" Subject: Re: Invisibility of bufferbloat and its remedies Well, I ranted: http://blog.cerowrt.org/post/net_neutrality_isps/ I am thinking a string of shorter pieces aimed directly at customers, reviewers, politicians, etc might do a bit more good than the gargantuan things jim tends to do. On Mon, Jun 18, 2018 at 6:46 PM, Dave Taht wrote: > I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next week. > > If there are people to see, asses to kick or kiss, I'm up for it, let > me know. Presently I just plan to give my talk and get the heck out of > dodge. > > One of cake's "minor" features is the *perfect* defeat of the htb > based shaper in cable modems. If you know the set-rate on the modem, > you > just set it to the same thing and get vastly superior performance to > docsis 3.1, pie, or the sqm-scripts. > > On Mon, Jun 18, 2018 at 3:43 PM, dpr...@deepplum.com > wrote: >> I have been one of the most prominent advocates of network neutrality. I'm >> constantly informing my friends and the press about "buffering" not being >> related to neutrality at all. >> >> >> >> I think that's the best we can do. >> >> >> >> Packet neutrality is actually a key part of the Internet's design, pushing >> control mechanisms to the edge, with a minimum of "intelligence" in the >> routers/switches/gateways. In particular, "content-based" and >> "endpoint-address-based" targeted throttling was never how the Internet >> Protocol layer was supposed to work. That's a fundamental result of the >> "end-to-end argument" applied to congestion management. I've spent a lot of >> time on that issue technically. The original discussions going back before >> Van Jacobson's early work, up to RED and ECN, all are based on providing >> congestion signalling sufficient to cause endpoints competing for resources >> to adapt their behavior cooperatively in real time, while maintaining >> minimal latency under load. >> >> >> >> Latency under load is the crucial metric across the entire IP layer, >> endpoints and routers. It's clear that minimizing latency under load has to >> be achieved by avoiding buffering insite the network, moving it to the >> source (and destination). >> >> >> >> I've given this lecture to policy people a lot. In fact, deliberate creation >> of "bloat" is a technical strategy that has been used in the past to destroy >> VoIP and other real-time communicaitons. Microsoft was caught doing it >> decades ago, as were some other conflicted communicaitons providers. They >> could selectively delay small packets using DPI, while letting FTPs get full >> speed. That's one of the reasons we coined the idea of Network Neutrality. >> >> >> >> But radical right wingers of the sort that blossom in the paranoid world of >> the dark net started arguing that the routers should have political freedom >> to do whatever they damn well pleased with packets, because routers are >> people just like corporations, and a "free market" is the solution to >> everything. >> >> >> >> Well, technically, the Internet doesn't work if their is not some mechanism >> for eliminiating lag under load by eliminating queueing delay in bottleneck >> nodes. >> >> >> >> That's ultimately what Network Neutrality is about. There's a lot of other >> crap being pushed by folks who pile on to the Network Neutrality discussion. >> People want to "fix prices" for example, arguing that profits are bad. Those >> guys are not the problem. >> >> >> >> The problem is that the vertically integrated monopolists want to claim that >> the Internet should be subject to Deep Packet Inspection at every router, >> designed to charge rents based on content of the packets and who is the >> original sender or destination of the packet - that is, charging Netflix or >> NBC Universal packets nothing, and charging IPFS packets 100x as much. >> >> >> >> So, no, the Network Neutrality people are NOT the problem with Bufferbloat. >> >> >> >> Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their >> customers on DOCSIS 2.0 are just ordering faster service tiers to overcome >> the Bufferbloat in their DOCSIS 2 CMTS's. >> >> -Original Message- >> From: "Dave Taht" >> Sent: Monday, June 18, 2018 3:07pm >> To: "dpr...@deepplum.com" >> Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" >> >> Subject: Re: Invisibility of bufferbloat and its remedies >> >> On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com >> wrote: >>> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/ >>> >>> It's distressing how little the tech press understands the real problem. >> >> Yea, that one is pretty sad. >> >> It still remains a field of active academic research: >> >> https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5 >> >>> >>> Of course, cable
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
Well, I ranted: http://blog.cerowrt.org/post/net_neutrality_isps/ I am thinking a string of shorter pieces aimed directly at customers, reviewers, politicians, etc might do a bit more good than the gargantuan things jim tends to do. On Mon, Jun 18, 2018 at 6:46 PM, Dave Taht wrote: > I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next week. > > If there are people to see, asses to kick or kiss, I'm up for it, let > me know. Presently I just plan to give my talk and get the heck out of > dodge. > > One of cake's "minor" features is the *perfect* defeat of the htb > based shaper in cable modems. If you know the set-rate on the modem, > you > just set it to the same thing and get vastly superior performance to > docsis 3.1, pie, or the sqm-scripts. > > On Mon, Jun 18, 2018 at 3:43 PM, dpr...@deepplum.com > wrote: >> I have been one of the most prominent advocates of network neutrality. I'm >> constantly informing my friends and the press about "buffering" not being >> related to neutrality at all. >> >> >> >> I think that's the best we can do. >> >> >> >> Packet neutrality is actually a key part of the Internet's design, pushing >> control mechanisms to the edge, with a minimum of "intelligence" in the >> routers/switches/gateways. In particular, "content-based" and >> "endpoint-address-based" targeted throttling was never how the Internet >> Protocol layer was supposed to work. That's a fundamental result of the >> "end-to-end argument" applied to congestion management. I've spent a lot of >> time on that issue technically. The original discussions going back before >> Van Jacobson's early work, up to RED and ECN, all are based on providing >> congestion signalling sufficient to cause endpoints competing for resources >> to adapt their behavior cooperatively in real time, while maintaining >> minimal latency under load. >> >> >> >> Latency under load is the crucial metric across the entire IP layer, >> endpoints and routers. It's clear that minimizing latency under load has to >> be achieved by avoiding buffering insite the network, moving it to the >> source (and destination). >> >> >> >> I've given this lecture to policy people a lot. In fact, deliberate creation >> of "bloat" is a technical strategy that has been used in the past to destroy >> VoIP and other real-time communicaitons. Microsoft was caught doing it >> decades ago, as were some other conflicted communicaitons providers. They >> could selectively delay small packets using DPI, while letting FTPs get full >> speed. That's one of the reasons we coined the idea of Network Neutrality. >> >> >> >> But radical right wingers of the sort that blossom in the paranoid world of >> the dark net started arguing that the routers should have political freedom >> to do whatever they damn well pleased with packets, because routers are >> people just like corporations, and a "free market" is the solution to >> everything. >> >> >> >> Well, technically, the Internet doesn't work if their is not some mechanism >> for eliminiating lag under load by eliminating queueing delay in bottleneck >> nodes. >> >> >> >> That's ultimately what Network Neutrality is about. There's a lot of other >> crap being pushed by folks who pile on to the Network Neutrality discussion. >> People want to "fix prices" for example, arguing that profits are bad. Those >> guys are not the problem. >> >> >> >> The problem is that the vertically integrated monopolists want to claim that >> the Internet should be subject to Deep Packet Inspection at every router, >> designed to charge rents based on content of the packets and who is the >> original sender or destination of the packet - that is, charging Netflix or >> NBC Universal packets nothing, and charging IPFS packets 100x as much. >> >> >> >> So, no, the Network Neutrality people are NOT the problem with Bufferbloat. >> >> >> >> Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their >> customers on DOCSIS 2.0 are just ordering faster service tiers to overcome >> the Bufferbloat in their DOCSIS 2 CMTS's. >> >> -Original Message- >> From: "Dave Taht" >> Sent: Monday, June 18, 2018 3:07pm >> To: "dpr...@deepplum.com" >> Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" >> >> Subject: Re: Invisibility of bufferbloat and its remedies >> >> On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com >> wrote: >>> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/ >>> >>> It's distressing how little the tech press understands the real problem. >> >> Yea, that one is pretty sad. >> >> It still remains a field of active academic research: >> >> https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5 >> >>> >>> Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 >>> gear deployed can't admit to their plant being bloat-causing. >>> >>> In fact it protects their cable business against cord cutters. >> >> Lacking competition in general, doesn't
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
I will be in D.C., presenting https://www.cs.kau.se/tohojo/cake/ - next week. If there are people to see, asses to kick or kiss, I'm up for it, let me know. Presently I just plan to give my talk and get the heck out of dodge. One of cake's "minor" features is the *perfect* defeat of the htb based shaper in cable modems. If you know the set-rate on the modem, you just set it to the same thing and get vastly superior performance to docsis 3.1, pie, or the sqm-scripts. On Mon, Jun 18, 2018 at 3:43 PM, dpr...@deepplum.com wrote: > I have been one of the most prominent advocates of network neutrality. I'm > constantly informing my friends and the press about "buffering" not being > related to neutrality at all. > > > > I think that's the best we can do. > > > > Packet neutrality is actually a key part of the Internet's design, pushing > control mechanisms to the edge, with a minimum of "intelligence" in the > routers/switches/gateways. In particular, "content-based" and > "endpoint-address-based" targeted throttling was never how the Internet > Protocol layer was supposed to work. That's a fundamental result of the > "end-to-end argument" applied to congestion management. I've spent a lot of > time on that issue technically. The original discussions going back before > Van Jacobson's early work, up to RED and ECN, all are based on providing > congestion signalling sufficient to cause endpoints competing for resources > to adapt their behavior cooperatively in real time, while maintaining > minimal latency under load. > > > > Latency under load is the crucial metric across the entire IP layer, > endpoints and routers. It's clear that minimizing latency under load has to > be achieved by avoiding buffering insite the network, moving it to the > source (and destination). > > > > I've given this lecture to policy people a lot. In fact, deliberate creation > of "bloat" is a technical strategy that has been used in the past to destroy > VoIP and other real-time communicaitons. Microsoft was caught doing it > decades ago, as were some other conflicted communicaitons providers. They > could selectively delay small packets using DPI, while letting FTPs get full > speed. That's one of the reasons we coined the idea of Network Neutrality. > > > > But radical right wingers of the sort that blossom in the paranoid world of > the dark net started arguing that the routers should have political freedom > to do whatever they damn well pleased with packets, because routers are > people just like corporations, and a "free market" is the solution to > everything. > > > > Well, technically, the Internet doesn't work if their is not some mechanism > for eliminiating lag under load by eliminating queueing delay in bottleneck > nodes. > > > > That's ultimately what Network Neutrality is about. There's a lot of other > crap being pushed by folks who pile on to the Network Neutrality discussion. > People want to "fix prices" for example, arguing that profits are bad. Those > guys are not the problem. > > > > The problem is that the vertically integrated monopolists want to claim that > the Internet should be subject to Deep Packet Inspection at every router, > designed to charge rents based on content of the packets and who is the > original sender or destination of the packet - that is, charging Netflix or > NBC Universal packets nothing, and charging IPFS packets 100x as much. > > > > So, no, the Network Neutrality people are NOT the problem with Bufferbloat. > > > > Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their > customers on DOCSIS 2.0 are just ordering faster service tiers to overcome > the Bufferbloat in their DOCSIS 2 CMTS's. > > -Original Message- > From: "Dave Taht" > Sent: Monday, June 18, 2018 3:07pm > To: "dpr...@deepplum.com" > Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" > > Subject: Re: Invisibility of bufferbloat and its remedies > > On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com > wrote: >> https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/ >> >> It's distressing how little the tech press understands the real problem. > > Yea, that one is pretty sad. > > It still remains a field of active academic research: > > https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5 > >> >> Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 >> gear deployed can't admit to their plant being bloat-causing. >> >> In fact it protects their cable business against cord cutters. > > Lacking competition in general, doesn't help. > > What I am actually more frustrated about is the network neutrality > advocates A) conflating "buffering" with malfeasance, rather than a > technical problem > and B) Using politics rather than technology to attempt to achieve > their goals. If *only* a few prominent members of that side of affairs > "got" that some better technology, deployed, might solve some of their > problems and make the internet
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
I have been one of the most prominent advocates of network neutrality. I'm constantly informing my friends and the press about "buffering" not being related to neutrality at all. I think that's the best we can do. Packet neutrality is actually a key part of the Internet's design, pushing control mechanisms to the edge, with a minimum of "intelligence" in the routers/switches/gateways. In particular, "content-based" and "endpoint-address-based" targeted throttling was never how the Internet Protocol layer was supposed to work. That's a fundamental result of the "end-to-end argument" applied to congestion management. I've spent a lot of time on that issue technically. The original discussions going back before Van Jacobson's early work, up to RED and ECN, all are based on providing congestion signalling sufficient to cause endpoints competing for resources to adapt their behavior cooperatively in real time, while maintaining minimal latency under load. Latency under load is the crucial metric across the entire IP layer, endpoints and routers. It's clear that minimizing latency under load has to be achieved by avoiding buffering insite the network, moving it to the source (and destination). I've given this lecture to policy people a lot. In fact, deliberate creation of "bloat" is a technical strategy that has been used in the past to destroy VoIP and other real-time communicaitons. Microsoft was caught doing it decades ago, as were some other conflicted communicaitons providers. They could selectively delay small packets using DPI, while letting FTPs get full speed. That's one of the reasons we coined the idea of Network Neutrality. But radical right wingers of the sort that blossom in the paranoid world of the dark net started arguing that the routers should have political freedom to do whatever they damn well pleased with packets, because routers are people just like corporations, and a "free market" is the solution to everything. Well, technically, the Internet doesn't work if their is not some mechanism for eliminiating lag under load by eliminating queueing delay in bottleneck nodes. That's ultimately what Network Neutrality is about. There's a lot of other crap being pushed by folks who pile on to the Network Neutrality discussion. People want to "fix prices" for example, arguing that profits are bad. Those guys are not the problem. The problem is that the vertically integrated monopolists want to claim that the Internet should be subject to Deep Packet Inspection at every router, designed to charge rents based on content of the packets and who is the original sender or destination of the packet - that is, charging Netflix or NBC Universal packets nothing, and charging IPFS packets 100x as much. So, no, the Network Neutrality people are NOT the problem with Bufferbloat. Comcast, on the other hand, has been slow-rolling DOCSIS 3.0, because their customers on DOCSIS 2.0 are just ordering faster service tiers to overcome the Bufferbloat in their DOCSIS 2 CMTS's. -Original Message- From: "Dave Taht" Sent: Monday, June 18, 2018 3:07pm To: "dpr...@deepplum.com" Cc: cerowrt-devel@lists.bufferbloat.net, "bloat" Subject: Re: Invisibility of bufferbloat and its remedies On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com wrote: > https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/ > > It's distressing how little the tech press understands the real problem. Yea, that one is pretty sad. It still remains a field of active academic research: https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5 > > Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 gear > deployed can't admit to their plant being bloat-causing. > > In fact it protects their cable business against cord cutters. Lacking competition in general, doesn't help. What I am actually more frustrated about is the network neutrality advocates A) conflating "buffering" with malfeasance, rather than a technical problem and B) Using politics rather than technology to attempt to achieve their goals. If *only* a few prominent members of that side of affairs "got" that some better technology, deployed, might solve some of their problems and make the internet better for everyone, we'd make more progress. fq_codel is a uniquely "american" algorithm, in that it gives the "little guy" a little boost until it achieves parity with everyone else. > > And the solution is needed in the CMTS once neighbors all start becoming > heavier users, because it is a shared buffering pool with no fairness or > bloat protection. My principle observation is that with the changes in traffic patterns in the last decade, and the predominance of application-rate limited streaming, that most folk are merely forced into a bandwidth tier that is less rarely annoying. This does not of course solve the corporate gateway problems very well, nor does it truly
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
From a ton of memes at: https://me.me/t/buffering
"Dear youtube:
I can deal with ads
I can deal with buffer
But when ads buffer, I suffer"
and innumerable others, some NSFW
https://me.me/i/16133421
On Mon, Jun 18, 2018 at 1:59 PM, Michael Richardson wrote:
>
> dpr...@deepplum.com wrote:
> > I blame IETF members, individually and collectively. If ietf exists for
> > any reason other than as a boondoggle for world travel, it's for
> > resolving issues like this one.
>
> Slightly fair.
>
> A thing that I tried to get ISOC's "deploy360" to do was to create a wall of
> shame on bufferbloat five or eight years ago. It was before the AQM WG did
> any work, I think. I wanted ISOC to collect the data, because I wanted it
> visible at the CTO level.
>
> At the very very least, I wanted a series of curated links to statements from
> various equipment vendors about the problem.
> I.e. www.example.com/bufferbloat.html for example in
> {cisco,juniper,huawei,calix,...}
>
> I asked many of my IETF contacts at these places if they knew who at their
> company was dealing with it. I also asked salespeople that I dealt with,
> hoping to put pressure the other way. I got nowhere.
>
> I wanted, at the very least, to get them to acknowledge that there was a
> problem, even if they didn't have an estimate on a solution, at least I could
> point the salesperson at the page on their site, and say, "I'll buy when you
> get me a delivery date".
> A major client of mine lost three large (VoIP) customers because of hidden
> bufferbloat in Bell Canada's LAN extension service... which "never lost any
> packets", the sales people explained. It was at a time when we
> weren't quite using the term bufferbloat, and we didn't quite know how to
> measure it in convincing ways.
>
> I still think that this is a good idea.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works| network architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
>
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
dpr...@deepplum.com wrote:
> I blame IETF members, individually and collectively. If ietf exists for
> any reason other than as a boondoggle for world travel, it's for
> resolving issues like this one.
Slightly fair.
A thing that I tried to get ISOC's "deploy360" to do was to create a wall of
shame on bufferbloat five or eight years ago. It was before the AQM WG did
any work, I think. I wanted ISOC to collect the data, because I wanted it
visible at the CTO level.
At the very very least, I wanted a series of curated links to statements from
various equipment vendors about the problem.
I.e. www.example.com/bufferbloat.html for example in
{cisco,juniper,huawei,calix,...}
I asked many of my IETF contacts at these places if they knew who at their
company was dealing with it. I also asked salespeople that I dealt with,
hoping to put pressure the other way. I got nowhere.
I wanted, at the very least, to get them to acknowledge that there was a
problem, even if they didn't have an estimate on a solution, at least I could
point the salesperson at the page on their site, and say, "I'll buy when you
get me a delivery date".
A major client of mine lost three large (VoIP) customers because of hidden
bufferbloat in Bell Canada's LAN extension service... which "never lost any
packets", the sales people explained. It was at a time when we
weren't quite using the term bufferbloat, and we didn't quite know how to
measure it in convincing ways.
I still think that this is a good idea.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Invisibility of bufferbloat and its remedies
On Mon, Jun 18, 2018 at 9:26 AM, dpr...@deepplum.com wrote: > https://www.cordcuttersnews.com/3-easy-tips-to-fix-constant-buffering/ > > It's distressing how little the tech press understands the real problem. Yea, that one is pretty sad. It still remains a field of active academic research: https://scholar.google.com/scholar?as_ylo=2018=bufferbloat=en_sdt=0,5 > > Of course, cable companies like Charter and ATT who have mostly DOCSIS 2 gear > deployed can't admit to their plant being bloat-causing. > > In fact it protects their cable business against cord cutters. Lacking competition in general, doesn't help. What I am actually more frustrated about is the network neutrality advocates A) conflating "buffering" with malfeasance, rather than a technical problem and B) Using politics rather than technology to attempt to achieve their goals. If *only* a few prominent members of that side of affairs "got" that some better technology, deployed, might solve some of their problems and make the internet better for everyone, we'd make more progress. fq_codel is a uniquely "american" algorithm, in that it gives the "little guy" a little boost until it achieves parity with everyone else. > > And the solution is needed in the CMTS once neighbors all start becoming > heavier users, because it is a shared buffering pool with no fairness or > bloat protection. My principle observation is that with the changes in traffic patterns in the last decade, and the predominance of application-rate limited streaming, that most folk are merely forced into a bandwidth tier that is less rarely annoying. This does not of course solve the corporate gateway problems very well, nor does it truly kill it dead, but until that day when "the right stuff" is readily available, and more informed demand exists. I was sad to see recently a cisco white paper that even ignored their own work on pie. > Still, routers with queue management that reduce bloat would help a lot, if > "buffering" is seen frequently under load. > > So why isn't anyone talking about this problem after at least a decade of > knowing it, and knowing how to fix it? > > I blame IETF members, individually and collectively. If ietf exists for any > reason other than as a boondoggle for world travel, it's for resolving issues > like this one. Heh. I have essentially abandoned the IETF as the inmates are running the asylum, and trying to continue to make our points there was seemingly fruitless - and out of my budget. I'd rather stay home and get better code out the door. Or come up with some other set of orgs to annoy into paying attention. I would not mind going to another IETF meeting to give a preso (on, say, cake), but I'm unwilling to front the funds or time anymore. > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
