[Bloat] the cisco pie patent and IETF IPR filing

[Bloat] the cisco pie patent and IETF IPR filing

[Dave Taht]

Two items:

A) The IETF IPR filing   http://datatracker.ietf.org/ipr/2187/ points
to the wrong patent: 13/874,500. A google search for that patent
number brings up http://www.google.com/patents/US20130239255"

 It is ironically relevant to the discussions at hand, as that one concerns:

Abstract:

"Provided are methods of increasing the tolerance of a plant to
abiotic stresses and/or increasing the biomass and/or increasing the
yield of a plant by expressing within the plant an exogenous
polynucleotide homologous to SEQ ID NO:13."

... As I consider myself a near-vegetable, and am 40 pounds heavier,
and not responding particularly well to antibiotics, after
participating for the past several years on all the ietf mailing lists
I just got off of. I am sure that upon acceptance of pie in the ietf,
that making that particular patent more generally available for all to
use would probably have similar effects on others.

The correct patent number for PIE, 13/874,600, is here:

http://www.google.com/patents/US20140328175

I would appreciate that the IPR filing be corrected.

In the meantime, here's some more great NSFW george carlin routines!

https://www.youtube.com/watch?v=tVlkxrNlp10

B) Vishal Misra (author of PI) gave me pointers to his PI papers
recently (and he had NO idea at all his work was used for pie! - he
got his marketing department to issue a press release about it:
http://engineering.umass.edu/news/got-bufferbloat-umass-amherst-research-behind-fix
)

I usually have a pretty strict policy about never reading patents, but
I read all those papers [1], and both! patents above. I had not fully
realized that the PI-AQM work went as far back as 2001. The PI update
equation and the PIE update equation, look pretty darn similar, just
the meanings of two variables, changed.

C) I am kind of curious if any working code for the original PI
algorithm exists for linux?

D) oh, never mind, I will blog about the rest one day.

[1] still prefer fq_codel.

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Wed, Mar 4, 2015 at 2:08 PM, Rong Pan (ropan) <ropan@cisco.com> wrote:
> The correct Cisco IPR is http://datatracker.ietf.org/ipr/2540/.

Thank you very much for the pointer to the correct IPR filing.

I apologize for being grumpy.


-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[David Lang]

On Wed, 4 Mar 2015, KK wrote:

> Date: Wed, 04 Mar 2015 01:01:19 -0800
> From: KK <kk@cs.ucr.edu>
> To: Vishal Misra <misra@cs.columbia.edu>, Dave Taht <dave.taht@gmail.com>
> Cc: "aqm@ietf.org" <aqm@ietf.org>, bloat <bloat@lists.bufferbloat.net>
> Subject: Re: [aqm] the cisco pie patent and IETF IPR filing
> 
> I think a combination of PI/PIE/fq_codel with ECN would enable us
> a) be less dependent of the physical amount of buffering that is
> implemented on the intermediate devices
> b) allow us to use buffering for what it is meant to do - ride out
> transient variations in traffic, at points where there is a mismatch in
> available capacity

The question is how much of a burst should the buffer be able to handle? Right 
now buffers routinely hold 10+ seconds worth of traffic (and Dave T showed the 
airline system buffering 10+ MINUTES of traffic)

The problem is that if you buffer too much, you break the TCP link speed 
probing, and if you buffer even more you end up with the sender genrating a new 
packet to deliver while you still are buffering the old one.

Buffers need to hold less than one second worth of traffic, and emperical 
testing is showing that much less is desirable (Others can post more exact 
numbers, but I belive that somewhere between 1/100 of a second and 1/10 of a 
second is a reasonable range)


> c) allow us to support different types of links, including wireless lossy
> links

If a retry is fast and has a very high probability of succeding, then it may be 
worth holding it and doing a link-level retry. But the existing mess that is 
wifi is hardly a good example of this being the right thing to do in a congested 
environment.

David Lang

> d) as we wrote in the ECN RFC, allow even short-lived transfers to not
> suffer
> Thanks,
>

Re: [Bloat] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Wed, Mar 4, 2015 at 12:17 AM, Vishal Misra <misra@cs.columbia.edu> wrote:
> Hi Dave,
>
> Thanks for your email. A few quick points:
>
> - I have actually sent a note already to someone on the Cisco PIE team
> about the error in the IETF IPR filing and am sure they will get it
> corrected. You have helpfully dug out the actual patent application
> and it appears that one digit got inadvertently changed in the Cisco
> IETF IPR declaration of the patent application.
>
> - I wish I had a "marketing department" that would do stories for me
> :-). I work at Columbia University and that story that you point out
> was done by a writer at the UMass-Amherst engineering school as an
> example of academic research having practical impact. There is an
> urgent need to support more academic research and I think stories like
> this one support the cause.

Well, yes and no. One thing I have tried really hard to do throughout
this project is give credit where credit is due, at every talk for
example, always mentioning pie, even before I actually had any data on
it's performance.- I try to give every individual that has contributed
something to this "stone soup" project, as here at uknof -

https://plus.google.com/u/0/107942175615993706558/posts/immF8Pkj19C

praise - for what they did to help out. There have been an amazing
level of details to sort out along the way here at every level in the
OS stack, and in the hardware and there is simply no one individual or
company I would single out as truly key, except maybe George P.
Burdell!

A lesson I have learned is that folk in marketing are not particularly
good at correctly distributing credit, and I assume that is how they
are taught to write, to not look at any facts outside of their
immediate objectives. [1]

http://newsroom.cisco.com/feature-content?type=webcontent&articleId=1414442

and 'course nobody in the press has shown up with a photographer to
write puff pieces about the overall effort except, well, cringely's
work is not puffy enough by marketing standards:  (
http://www.cringely.com/tag/bufferbloat/ )

I admit to a great deal of frustration when nick weaver writes an
otherwise *excellent* piece in forbes,
http://www.forbes.com/sites/valleyvoices/2015/02/27/this-one-clause-in-the-new-net-neutrality-regs-would-be-a-fiasco-for-the-internet/

 and expends 3+ paragraphs explaining bufferbloat, but never gives the
reader a link back *to the word* so that maybe, some CTO or CEO that
reads that rag would have some context and clue when an engineer comes
up to him asking for permission to go implement a fix that is now,
basically, off the shelf.

*I* am going to keep giving credit to everyone I can, in every talk
and presentation I do, and there are quite a few core contributors
that I wish I had called out by name more - for example, I would have
mentioned felix feitkau's contribution towards fixing wifi at the
nznog talk if I could correctly pronounce his name! I struggled for
years to be able to pronounce juliusz's!

At the very least, I hope we can do more from a SEO perspective - and
all *pull together* to get the message out - that bufferbloat is
fixed, that solutions are being standardized in the ietf, and the code
is widely available on a ton of platforms already - and move to
somehow get to where ISPs are announcing settings for things like
openwrt + sqm-scripts, and more importantly - schedules for rolling
out fixes (like docsis 3.1 and better CPE) to their customers.

everyone:

What else more can we do here to cross the chasm?

> - Indeed neither me nor any of the other PI authors had any idea of
> the PIE work. I discovered it accidentally when I was at MIT giving a
> talk on Network Neutrality and Dave Clark mentioned Cisco's PIE and
> DOCSIS 3.1 to me. I later read up on PIE and was pleasantly surprised
> that our PI work from more than a decade back evolved into it.
>
> - I had contributed the PI code to Sally Floyd back in 2001 and it has
> been part of ns2 for the longest time (pi.cc). It shouldn't be
> difficult to adapt that for a Linux implementation and I am happy to
> help anyone who wishes to try it. Maybe that might affect your loyalty
> to fq_codel.

I let the data take me where it may. I (not) always have, but reformed
about 15 years ago. [1] I hope that you and your students also,  do
some experiments on the successors to PI and RED and DRR - and also
follow the data where-ever it leads you.

I was fiercely proud of sfqred - until fq_codel blew it away on every
benchmark I could devise. I have long longed to find another
independent expert in the field to create new experiments and/or
recreate/reproduce/disprove our results.

[1] "For a successful technology, reality must take precedence over
public relations, for Nature cannot be fooled. " - Richard P. Feyman,
Challenger Disaster report:
https://www.youtube.com/watch?v=6Rwcbsn19c0


> -Vishal
> --
> http://www.cs.columbia.edu/~misra/
>
>> On Mar 4, 2015, at 1:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Two items:
>>
>> A) The IETF IPR filing   http://datatracker.ietf.org/ipr/2187/ points
>> to the wrong patent: 13/874,500. A google search for that patent
>> number brings up http://www.google.com/patents/US20130239255"
>>
>> It is ironically relevant to the discussions at hand, as that one concerns:
>>
>> Abstract:
>>
>> "Provided are methods of increasing the tolerance of a plant to
>> abiotic stresses and/or increasing the biomass and/or increasing the
>> yield of a plant by expressing within the plant an exogenous
>> polynucleotide homologous to SEQ ID NO:13."
>>
>> ... As I consider myself a near-vegetable, and am 40 pounds heavier,
>> and not responding particularly well to antibiotics, after
>> participating for the past several years on all the ietf mailing lists
>> I just got off of. I am sure that upon acceptance of pie in the ietf,
>> that making that particular patent more generally available for all to
>> use would probably have similar effects on others.
>>
>> The correct patent number for PIE, 13/874,600, is here:
>>
>> http://www.google.com/patents/US20140328175
>>
>> I would appreciate that the IPR filing be corrected.
>>
>> In the meantime, here's some more great NSFW george carlin routines!
>>
>> https://www.youtube.com/watch?v=tVlkxrNlp10
>>
>> B) Vishal Misra (author of PI) gave me pointers to his PI papers
>> recently (and he had NO idea at all his work was used for pie! - he
>> got his marketing department to issue a press release about it:
>> http://engineering.umass.edu/news/got-bufferbloat-umass-amherst-research-behind-fix
>> )
>>
>> I usually have a pretty strict policy about never reading patents, but
>> I read all those papers [1], and both! patents above. I had not fully
>> realized that the PI-AQM work went as far back as 2001. The PI update
>> equation and the PIE update equation, look pretty darn similar, just
>> the meanings of two variables, changed.
>>
>> C) I am kind of curious if any working code for the original PI
>> algorithm exists for linux?
>>
>> D) oh, never mind, I will blog about the rest one day.
>>
>> [1] still prefer fq_codel.
>>
>> --
>> Dave Täht
>> Let's make wifi fast, less jittery and reliable again!
>>
>> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Bloat] the cisco pie patent and IETF IPR filing

[Vishal Misra]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

Hi Dave,

> On Mar 5, 2015, at 8:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I let the data take me where it may. I (not) always have, but reformed
> about 15 years ago. [1] I hope that you and your students also,  do
> some experiments on the successors to PI and RED and DRR - and also
> follow the data where-ever it leads you.



In 2003 we had published a paper on STPI (Self-Tuning PI). The self-tuning design accounted for variations in link capacity, presence of cross traffic (i.e. unregulated UDP flows) and variations in the number of flows being controlled. We also proved the (local, exponential) stability of our self-tuning mechanism.

The paper is available at http://dna-pubs.cs.columbia.edu/citation/paperfile/79/GLOBECOM_2003_STAQM.pdf

This was an evolution over our first PI design where we introduced the concept of linear controllers for AQM.

BTW STPI is not PIE, the differences as I see them are

(1) STPI explicitly accounts for cross traffic.
(2) STPI tunes the parameters continuously, over the entire range of loss (marking) rates unlike PIE which seems to be doing it for 3 specific values chosen ahead of time.
(3) The stability of the adaptive mechanism of STPI was rigorously proven in a linearized setting. 
(4) The tradeoff between stability and responsiveness for the time constant of adaptation was made explicit.
(5) STPI does not, as the author of PIE stated recently "control the offset to the reference level and second moment of the latency independently”. STPI simply controls the latency, I don’t know of any way to control the second moment of any reference signal by a linear controller like PI(E), but then I do not know the details of PIE. It was a very deliberate design choice by us to introduce a linear controller like PI for AQM because of ease of implementation. We could’ve gone the route of optimal and/or non-linear controllers but we didn’t.

As a side note, we also designed a self-tuning version of RED that we called STRED (different from ARED) but RED suffers from some fundamental limitations so exploring that won’t be of interest.

So I am getting STPI and PI implemented as part of cerowrt and will release the code for anyone to play with/evaluate.

More than anything, it is the increased deployment of ECN that has revived an interest in AQM for me.

-Vishal
--
http://www.cs.columbia.edu/~misra/




[-- Attachment #2: Type: text/html, Size: 7203 bytes --]

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Wed, Apr 8, 2015 at 11:51 PM, Greg Skinner <gregskinner0@icloud.com> wrote:
> Sorry I haven’t had a chance to comment on this until now.  Also, I’m not on the bloat list, but you may copy any responses to me there, if you wish.
>
> I was thinking perhaps another approach to spreading the word could be presenting talks at conferences aimed at CIOs and CTOs.  They are generally interested in saving money and getting better performance from equipment that’s already in use.  The algorithms and techniques discussed here do that.

I agree that we are more ready to talk to those sorts of folk now.
However I personally am tired of travelling and talking and would
prefer someone else(es) be "Speaker-to-CTOs", and get all the airline
miles, fame and fortune for a while, maybe getting in some golf time
as well.

I would really LOVE it if more people here gave talks and attended
conferences, user group meetings, etc.

A problem here is a lot of people take our bufferbloat-beating
algorithms as someone selling yet another form of snake oil - and it
is worse - here, we are not making snake oil - we are *giving it away*
- and if it doesn't work, you can have your money back! I have had to
go to sceptic´s houses and install the software, after doing a
measurement, and forcing our tools on to j.random persons laptops, in
order to make the points we make. That does not scale, although it
usually turns a skeptic into an enthusiastic supporter.

I expended the majority of my budget on travel in the first few years,
primarily to find and talk to experts in the field, to make sure we
were not going to break the internet. I am pretty sure the Internet
will be less broken with more of our stuff in play, than not, now.

A concern to me, in finding a "Speaker-to-CTOs" is to find someone who
can present the solutions in a way even more neutrally than I do, and
yet convince people to actually go deploy them. I make no bones (these
days!) about how I feel that fq + aqm + ecn (fq_codel´s default mode)
is safe to deploy, for example, and there are many people here that
disagree with me, thinking that aqm + ecn alone is safe to deploy, and
obviously I promote fq_codel derived stuff on routers (and sch_fq on
well protected servers), far more than pie, although I am careful to
maintain that I can´t wait to see pie (without ecn) on cablemodems one
day RSN.

I have NO idea to what extent a product having or not having a given
shaping/fq/aqm algorithm could be used as a sales tool for people
selling it, and actually selling something that worked would be a big
motivator for some future speaker to chase after the CTO/CIO/CEOs at
their conferences. Certainly ubnt´s customers are digging it...

>Getting sysadmins or netadmins to make config changes to enable the sysctl settings and/or upgrade kernels (in production) might be more difficult, because they don’t always have the authority to make these types of changes, even though they have the privileges.

In the good ole days sysadmins were eager to do anything they could to
improve network behavior and connectivity, and did not have to filter
every decision through management, a lawyer, and an accountant.

Recently at the NZNOG conference there was a whole session where
provider after provider announced their AS number and willingness to
peer with anybody. I nearly had to wipe away tears of remembered joy
for the good ole days where we cared more about connectivity and good
service rather than anything else.

In the general case, strategically, I have preferred to work bottom up
rather than top down, and to accumulate enough operational experience
to then be able to approach top management with a fait accompli (it is
easier to ask for forgiveness than permission) and permission to go
full scale on a rollout with results in hand.

This strategy is sort of working in multiple places, notably google
uses this approach effectively (and distros like openwrt, free.fr,
etc, fedora 22 and anything running systemd without patches, like
arch, all defaulting to fq_codel rather than pfifo_fast now!).

There are several target audiences:

A) hardware makers: I would like it if more firewall makers like
barracuda were paying attention, and we had something that worked on
pfsense. As happy as I am about ubnt´s enthusiastic support for
fq_codel, there has not been a peep from multiple other places.
B) Chip designers: Here, aside from whatever is going on with
streamboost at qca, I am not sure if anyone is paying attention.
C) China: Folk making gear there, notably EEs, would benefit from more
awareness. I long for a good bufferbloat talk or article written in
multiple other languages, including the main ones there, japanese, and
spanish.
D) Big web service providers and CDN folk - where sch_fq is
potentially a big deal (being as it is so popular already)
E) IT staffs in general - nanog has an upcoming conference that would
be good to have a talk at.
F) VOIP and webrtc service providers - here we made a huge dent
already in the asterisk and freeswitch communities. I was asked to do
a followup at the next cluecon, but as I will be out of the country -
if anyone would like to give a talk there please contact me offlist.
G) Load balancer makers. There is some sign that F5 is paying
attention, at least, but what others are doing here is unknown.
F) ISPs

And way too many conferences to attend.

> But a CIO or CTO has the authority to request that these types of changes be made permanent, especially if it improves the bottom line.

I agree that we need to start talking to more of these folk, at a
level they can understand, with arguments that involve saving money
with better, faster, less latent networks.

> —gregbo
>
>> On Mar 5, 2015, at 5:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Wed, Mar 4, 2015 at 12:17 AM, Vishal Misra <misra@cs.columbia.edu> wrote:
>>> Hi Dave,
>>>
>>> Thanks for your email. A few quick points:
>>>
>>> - I have actually sent a note already to someone on the Cisco PIE team
>>> about the error in the IETF IPR filing and am sure they will get it
>>> corrected. You have helpfully dug out the actual patent application
>>> and it appears that one digit got inadvertently changed in the Cisco
>>> IETF IPR declaration of the patent application.
>>>
>>> - I wish I had a "marketing department" that would do stories for me
>>> :-). I work at Columbia University and that story that you point out
>>> was done by a writer at the UMass-Amherst engineering school as an
>>> example of academic research having practical impact. There is an
>>> urgent need to support more academic research and I think stories like
>>> this one support the cause.
>>
>> Well, yes and no. One thing I have tried really hard to do throughout
>> this project is give credit where credit is due, at every talk for
>> example, always mentioning pie, even before I actually had any data on
>> it's performance.- I try to give every individual that has contributed
>> something to this "stone soup" project, as here at uknof -
>>
>> https://plus.google.com/u/0/107942175615993706558/posts/immF8Pkj19C
>>
>> praise - for what they did to help out. There have been an amazing
>> level of details to sort out along the way here at every level in the
>> OS stack, and in the hardware and there is simply no one individual or
>> company I would single out as truly key, except maybe George P.
>> Burdell!
>>
>> A lesson I have learned is that folk in marketing are not particularly
>> good at correctly distributing credit, and I assume that is how they
>> are taught to write, to not look at any facts outside of their
>> immediate objectives. [1]
>>
>> http://newsroom.cisco.com/feature-content?type=webcontent&articleId=1414442
>>
>> and 'course nobody in the press has shown up with a photographer to
>> write puff pieces about the overall effort except, well, cringely's
>> work is not puffy enough by marketing standards:  (
>> http://www.cringely.com/tag/bufferbloat/ )
>>
>> I admit to a great deal of frustration when nick weaver writes an
>> otherwise *excellent* piece in forbes,
>> http://www.forbes.com/sites/valleyvoices/2015/02/27/this-one-clause-in-the-new-net-neutrality-regs-would-be-a-fiasco-for-the-internet/
>>
>> and expends 3+ paragraphs explaining bufferbloat, but never gives the
>> reader a link back *to the word* so that maybe, some CTO or CEO that
>> reads that rag would have some context and clue when an engineer comes
>> up to him asking for permission to go implement a fix that is now,
>> basically, off the shelf.
>>
>> *I* am going to keep giving credit to everyone I can, in every talk
>> and presentation I do, and there are quite a few core contributors
>> that I wish I had called out by name more - for example, I would have
>> mentioned felix feitkau's contribution towards fixing wifi at the
>> nznog talk if I could correctly pronounce his name! I struggled for
>> years to be able to pronounce juliusz's!
>>
>> At the very least, I hope we can do more from a SEO perspective - and
>> all *pull together* to get the message out - that bufferbloat is
>> fixed, that solutions are being standardized in the ietf, and the code
>> is widely available on a ton of platforms already - and move to
>> somehow get to where ISPs are announcing settings for things like
>> openwrt + sqm-scripts, and more importantly - schedules for rolling
>> out fixes (like docsis 3.1 and better CPE) to their customers.
>>
>> everyone:
>>
>> What else more can we do here to cross the chasm?
>>
>>> - Indeed neither me nor any of the other PI authors had any idea of
>>> the PIE work. I discovered it accidentally when I was at MIT giving a
>>> talk on Network Neutrality and Dave Clark mentioned Cisco's PIE and
>>> DOCSIS 3.1 to me. I later read up on PIE and was pleasantly surprised
>>> that our PI work from more than a decade back evolved into it.
>>>
>>> - I had contributed the PI code to Sally Floyd back in 2001 and it has
>>> been part of ns2 for the longest time (pi.cc). It shouldn't be
>>> difficult to adapt that for a Linux implementation and I am happy to
>>> help anyone who wishes to try it. Maybe that might affect your loyalty
>>> to fq_codel.
>>
>> I let the data take me where it may. I (not) always have, but reformed
>> about 15 years ago. [1] I hope that you and your students also,  do
>> some experiments on the successors to PI and RED and DRR - and also
>> follow the data where-ever it leads you.
>>
>> I was fiercely proud of sfqred - until fq_codel blew it away on every
>> benchmark I could devise. I have long longed to find another
>> independent expert in the field to create new experiments and/or
>> recreate/reproduce/disprove our results.
>>
>> [1] "For a successful technology, reality must take precedence over
>> public relations, for Nature cannot be fooled. " - Richard P. Feyman,
>> Challenger Disaster report:
>> https://www.youtube.com/watch?v=6Rwcbsn19c0
>>
>>
>>> -Vishal
>>> --
>>> http://www.cs.columbia.edu/~misra/
>>>
>>>> On Mar 4, 2015, at 1:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> Two items:
>>>>
>>>> A) The IETF IPR filing   http://datatracker.ietf.org/ipr/2187/ points
>>>> to the wrong patent: 13/874,500. A google search for that patent
>>>> number brings up http://www.google.com/patents/US20130239255"
>>>>
>>>> It is ironically relevant to the discussions at hand, as that one concerns:
>>>>
>>>> Abstract:
>>>>
>>>> "Provided are methods of increasing the tolerance of a plant to
>>>> abiotic stresses and/or increasing the biomass and/or increasing the
>>>> yield of a plant by expressing within the plant an exogenous
>>>> polynucleotide homologous to SEQ ID NO:13."
>>>>
>>>> ... As I consider myself a near-vegetable, and am 40 pounds heavier,
>>>> and not responding particularly well to antibiotics, after
>>>> participating for the past several years on all the ietf mailing lists
>>>> I just got off of. I am sure that upon acceptance of pie in the ietf,
>>>> that making that particular patent more generally available for all to
>>>> use would probably have similar effects on others.
>>>>
>>>> The correct patent number for PIE, 13/874,600, is here:
>>>>
>>>> http://www.google.com/patents/US20140328175
>>>>
>>>> I would appreciate that the IPR filing be corrected.
>>>>
>>>> In the meantime, here's some more great NSFW george carlin routines!
>>>>
>>>> https://www.youtube.com/watch?v=tVlkxrNlp10
>>>>
>>>> B) Vishal Misra (author of PI) gave me pointers to his PI papers
>>>> recently (and he had NO idea at all his work was used for pie! - he
>>>> got his marketing department to issue a press release about it:
>>>> http://engineering.umass.edu/news/got-bufferbloat-umass-amherst-research-behind-fix
>>>> )
>>>>
>>>> I usually have a pretty strict policy about never reading patents, but
>>>> I read all those papers [1], and both! patents above. I had not fully
>>>> realized that the PI-AQM work went as far back as 2001. The PI update
>>>> equation and the PIE update equation, look pretty darn similar, just
>>>> the meanings of two variables, changed.
>>>>
>>>> C) I am kind of curious if any working code for the original PI
>>>> algorithm exists for linux?
>>>>
>>>> D) oh, never mind, I will blog about the rest one day.
>>>>
>>>> [1] still prefer fq_codel.
>>>>
>>>> --
>>>> Dave Täht
>>>> Let's make wifi fast, less jittery and reliable again!
>>>>
>>>> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
>>>
>>
>>
>>
>> --
>> Dave Täht
>> Let's make wifi fast, less jittery and reliable again!
>>
>> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
>>
>>
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Steinar H. Gunderson]

On Thu, Apr 09, 2015 at 12:24:03PM -0700, Dave Taht wrote:
> disagree with me, thinking that aqm + ecn alone is safe to deploy, and
> obviously I promote fq_codel derived stuff on routers (and sch_fq on
> well protected servers), far more than pie, although I am careful to
> maintain that I can´t wait to see pie (without ecn) on cablemodems one
> day RSN.

Can you elaborate on what you mean by “well protected”? I usually recommend
sch_fq for end hosts pretty much uncritically, so if there's a snag, I'd love
to hear about it.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Thu, Apr 9, 2015 at 12:27 PM, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Thu, Apr 09, 2015 at 12:24:03PM -0700, Dave Taht wrote:
>> disagree with me, thinking that aqm + ecn alone is safe to deploy, and
>> obviously I promote fq_codel derived stuff on routers (and sch_fq on
>> well protected servers), far more than pie, although I am careful to
>> maintain that I can´t wait to see pie (without ecn) on cablemodems one
>> day RSN.
>
> Can you elaborate on what you mean by “well protected”? I usually recommend
> sch_fq for end hosts pretty much uncritically, so if there's a snag, I'd love
> to hear about it.

I am very impressed with sch_fq overall. However it optimizes overmuch
for new connections, with a default quantum of a full IW10, which
leaves it vulnerable to DDOS attacks, thus these days I say "well
protected" in the expectation that the servers serving data are behind
boxes doing better firewall and DDOS management.

Recently some mods to sch_fq landed to make it a bit safer to more
widely deploy on more kinds of traffic than just web servers, the
relevant patch by eric dumazet is:

https://www.marc.info/?l=git-commits-head&m=142362949328825&w=3

He is also doing some work to make syn flood handling more robust
elsewhere in the kernel but I do not think that has landed yet.

In it´s present form, sch_fq is for some kinds of servers, not
routers, nor stuff that is generating tons of udp traffic (I think)

A VM is a server, but the bare metal underneath is a router.

fq_codel is a much safer default for general use, and sch_fq more of a
(really nice) specialized option, at this point. Some of this is just
my opinion, based on observations of several attacks I made against it
with some attack tools - but you know who to ask internally for their
opinion and data. I would welcome coherent guidance about how when and
where to use sch_fq, AND to deal with DDOSes. I learned more about
DDOS stuff from a recent cloudflare preso than I ever wanted to know.

I look forward to seeing someone try to add, say "pie", to sch_fq, to
make it safer to use in that case, and also to handle the case where
sch_fq is turned on in a router when it shouldn´t be. I finally got
around to benchmarking sch_fq vs fq_codel vs cake  and some other
stuff recently in a 115/12Mbit cable emulation, and you can clearly
see sch_fq misbehaving as it lets routed queue lengths get out of
hand.

That latest netperf-wrapper data set is here:

http://snapon.lab.bufferbloat.net/~d/cake3-fixed-tests.tgz

While I expect cake to fill a very needed niche, we still have not
arrived at the one true, all singing, all dancing, queue managment
system - but BOY! have we come a long way in a few years.

Still, I think better ethernet devices and switch chips are going to
be needed in the long term to make our networks faster and loss free,
and hope to sink more time into prototyping those every time I get a
break from the make-wifi-fast project. (see .sig. :) )

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU

Re: [Bloat] [aqm] the cisco pie patent and IETF IPR filing

[Dave Taht]

On Wed, Apr 8, 2015 at 11:51 PM, Greg Skinner <gregskinner0@icloud.com> wrote:
> Sorry I haven’t had a chance to comment on this until now.  Also, I’m not on the bloat list, but you may copy any responses to me there, if you wish.
>
> I was thinking perhaps another approach to spreading the word could be presenting talks at conferences aimed at CIOs and CTOs.  They are generally interested in saving money and getting better performance from equipment that’s already in use.  The algorithms and techniques discussed here do that.

Well, more directly to this point - they can do it on Linux, on modern
distros, on all cpus supported. Those using with other OSes or older
embedded gear or top brand switchs/routers like cisco, juniper, or
arista are all still in a hole, as are most of the users of head end
BRASes, CMTSes, etc. It would be nice to have the big folk announcing
solutions and plans and so on before nagging the CTOS and CIOS with
stuff they can´t just buy. Telling someone that they have to switch
their entire edge network over to Linux is often a hard sell.

I do keep hoping for a tilera or a cavium to pour this stuff into
their chips and firmware, but so far no such luck.

Blatant plug: see my .sig

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU