From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp201.iad.emailsrvr.com (smtp201.iad.emailsrvr.com [207.97.245.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BE8BF21F18C for ; Mon, 8 Jul 2013 13:50:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp30.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2D2D620119; Mon, 8 Jul 2013 16:50:22 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy7.wa-web.iad1a (legacy7.wa-web.iad1a.rsapps.net [192.168.2.216]) by smtp30.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 066F4200BA; Mon, 8 Jul 2013 16:50:22 -0400 (EDT) Received: from reed.com (localhost [127.0.0.1]) by legacy7.wa-web.iad1a (Postfix) with ESMTP id D761A3200B4; Mon, 8 Jul 2013 16:50:21 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 8 Jul 2013 16:50:21 -0400 (EDT) Date: Mon, 8 Jul 2013 16:50:21 -0400 (EDT) From: dpreed@reed.com To: "Mikael Abrahamsson" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130708165021000000_30245" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1373223178.486913695@apps.rackspace.com> Message-ID: <1373316621.879922633@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] happy 4th! X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:50:24 -0000 ------=_20130708165021000000_30245 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI was suggesting that there is no reason to be intimidated.=0A =0AAnd ye= s, according to the dictionary definition, they are ignorant - as in they d= on't know what they are talking about, and don't care to.=0A =0AThey may be= influential, and they may have a great opinion of themselves. And others = may view them as "knowledgeable". The folks who told Galileo that he was = wrong were all of that. But they remained ignorant.=0A =0AAs to being cons= tructive, I'm not convinced that these people can be convinced that their d= ismissal of bufferbloat and their idea that "goodput" is a useful Internet = concept are incorrect.=0A =0AIf they are curious, experimental evidence mig= ht be useful. But have they done their own experiments to validate what th= ey "accept as true"? I've been told by more than 50% of professional EE's= practicing that "Shannon's Law" places a limit on all radio communications= capacity. But none of these EE's can even explain the Shannon-Hartley AWG= N channel capacity theorem, its derivation, and its premises and range of a= pplicability. They just "think they know" what it means. And they are inc= redibly arrogant and dismissive, while being totally *incurious*.=0A =0AThe= same is true about most "networking professionals". Few understand queuei= ng theory, its range of applicability, etc. *or even exactly how TCP works*= . But that doesn't stop them from ignoring evidence, evidence that is righ= t in front of their eyes - every day. It took Jim Gettys' curiosity of why= his home network performance *sucked* to get him to actually dig into the = problem. And yet much of IETF still tries to claim that the problem doesn'= t exist! They dismiss evidence - out of hand.=0A =0AThat's not science, it= 's not curiosity. It's *dogmatism* - the opposite of science. And those p= eople are rarely going to change their minds. After 45 years in advanced c= omputing and communications, I can tell you they will probably go to their = graves spouting their "old-wives-tales".=0A =0ASpend your time on people wh= o don't "throw things in your face". On the people who are actually curiou= s enough to test your claims themselves (which is quite easy for anyone who= can do simple measurements). RRUL is a nice simple test. Let them try it= !=0A =0A =0A=0A=0AOn Sunday, July 7, 2013 8:24pm, "Mikael Abrahamsson" said:=0A=0A=0A=0A> On Sun, 7 Jul 2013, dpreed@reed.com wrote= :=0A> =0A> > So when somebody "throws that in your face", just confidently = use the=0A> > words "Bullshit, show me evidence", and ignore the ignorant p= erson who=0A> =0A> Oh, the people that have told me this are definitely not= ignorant. Quite=0A> the contrary.=0A> =0A> ... and by the way, they're opt= imising for the case where a single TCP=0A> flow from a 10GE connected host= is traversing a 10G based backbone, and=0A> they want this single TCP sess= ion to use every spare capacity the network=0A> has to give. Not 90% of ava= ilable capcity, but 100%.=0A> =0A> This is the kind of people that have a l= ot of influence and causes core=0A> routers to get designed with 600 ms of = buffering (well, latest generation=0A> ones are down to 50ms buffering). We= 're talking billion dollar investments=0A> by hardware manufacturers. We're= talking core routers of latest generation=0A> that are still being put int= o production as we speak.=0A> =0A> Calling them ignorant and trying to wave= them off by that kind of=0A> reasonsing isn't productive. Why not just imp= lement the high RTT testing=0A> part and prove that you're right instead of= just saying you're right?=0A> =0A> THe bufferbloat initiative is trying to= change how things are done. Burden=0A> of proof is here. When I participat= e in IETF TCP WG, they talk goodput.=0A> They're not talking latency and in= teracting well with UDP based=0A> interactive streams. They're optimising g= oodput. If we want buffers to be=0A> lower, we need to convince people that= this doesn't hugely affect goodput.=0A> =0A> I have not so far seen tests = with FQ_CODEL with a simulated 100ms extra=0A> latency one-way (200ms RTT).= They might be out there, but I have not seen=0A> them. I encourage these t= ests to be done.=0A> =0A> --=0A> Mikael Abrahamsson email: swmike@swm.pp= .se=0A> ------=_20130708165021000000_30245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= I was suggesting that there is no reason to be intimidated.

=0A

 

=0A

And = yes, according to the dictionary definition, they are ignorant - as in they= don't know what they are talking about, and don't care to.

=0A

 

=0A

They= may be influential, and they may have a great opinion of themselves.  = ;And others may view them as "knowledgeable".   The folks who told Gal= ileo that he was wrong were all of that.  But they remained ignorant.<= /p>=0A

 

=0A

As to being constructive, I'm not convinced that these people can= be convinced that their dismissal of bufferbloat and their idea that "good= put" is a useful Internet concept are incorrect.

=0A

 

=0A

If they are curi= ous, experimental evidence might be useful.  But have they done their = own experiments to validate what they "accept as true"?   I've been to= ld by more than 50% of professional EE's practicing that "Shannon's Law" pl= aces a limit on all radio communications capacity.  But none of these = EE's can even explain the Shannon-Hartley AWGN channel capacity theorem, it= s derivation, and its premises and range of applicability.  They just = "think they know" what it means.  And they are incredibly arrogant and= dismissive, while being totally *incurious*.

=0A

 

=0A

The same is true ab= out most "networking professionals".  Few understand queueing theory, = its range of applicability, etc. *or even exactly how TCP works*.  But= that doesn't stop them from ignoring evidence, evidence that is right in f= ront of their eyes - every day.  It took Jim Gettys' curiosity of why = his home network performance *sucked* to get him to actually dig into the p= roblem.  And yet much of IETF still tries to claim that the problem do= esn't exist!  They dismiss evidence - out of hand.

=0A

 

=0A

That's no= t science, it's not curiosity.  It's *dogmatism* - the opposite of sci= ence.  And those people are rarely going to change their minds.  = After 45 years in advanced computing and communications, I can tell you the= y will probably go to their graves spouting their "old-wives-tales".

=0A=

 

=0A

Spend your time on people who don't "throw things in your face".  = On the people who are actually curious enough to test your claims themselve= s (which is quite easy for anyone who can do simple measurements).  RR= UL is a nice simple test.  Let them try it!

=0A

 

=0A

 

=0A=0A



On Sunday, July 7, 2013 8:24pm, "Mikael A= brahamsson" <swmike@swm.pp.se> said:

=0A
=0A

> On Sun, 7 Jul 2= 013, dpreed@reed.com wrote:
>
> > So when somebody "thr= ows that in your face", just confidently use the
> > words "Bull= shit, show me evidence", and ignore the ignorant person who
>
> Oh, the people that have told me this are definitely not ignorant. Qu= ite
> the contrary.
>
> ... and by the way, they'r= e optimising for the case where a single TCP
> flow from a 10GE con= nected host is traversing a 10G based backbone, and
> they want thi= s single TCP session to use every spare capacity the network
> has = to give. Not 90% of available capcity, but 100%.
>
> This = is the kind of people that have a lot of influence and causes core
>= ; routers to get designed with 600 ms of buffering (well, latest generation=
> ones are down to 50ms buffering). We're talking billion dollar i= nvestments
> by hardware manufacturers. We're talking core routers = of latest generation
> that are still being put into production as = we speak.
>
> Calling them ignorant and trying to wave the= m off by that kind of
> reasonsing isn't productive. Why not just i= mplement the high RTT testing
> part and prove that you're right in= stead of just saying you're right?
>
> THe bufferbloat ini= tiative is trying to change how things are done. Burden
> of proof = is here. When I participate in IETF TCP WG, they talk goodput.
> Th= ey're not talking latency and interacting well with UDP based
> int= eractive streams. They're optimising goodput. If we want buffers to be
> lower, we need to convince people that this doesn't hugely affect goo= dput.
>
> I have not so far seen tests with FQ_CODEL with = a simulated 100ms extra
> latency one-way (200ms RTT). They might b= e out there, but I have not seen
> them. I encourage these tests to= be done.
>
> --
> Mikael Abrahamsson email: sw= mike@swm.pp.se
>

=0A
 ------=_20130708165021000000_30245--