From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B467521F1B5 for ; Mon, 8 Jul 2013 14:04:40 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so6918602oag.37 for ; Mon, 08 Jul 2013 14:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uJaXX1wZmL9NQ8w2xRdinEQYDKhu6shoUzRu/WUoLf4=; b=JpbdtRwMv948+GSkP/0veqkIPe2U7P2Xkta9giTeemiN1Y/L1AfzllCMjQ5zrspc7n Fujk89gKEVPmfXM3hvt3JHgca0b39v4sk7nExejZ1g0Wwc81UlE9gb4azmLfZRtaWaQR ipuj/Dq/naP1t57kTb8HvbHmesJnbM6EcRQbkfw9p4Qijd7OmUnq9nF17FhXdUORfhF0 YCp4+eC9glLUGEJH9asRLaI6C0FNU/TMaHGDzV8TJTV9/PI94rAVhttClZ6w4fku1RGF c1oXEa8o+uJOLHIeQaFVKRZwALrFEQLHRTz2KF+SWS/7YDEIjNq+3BO+amZTT+4rWbwL 8WXw== MIME-Version: 1.0 X-Received: by 10.60.98.233 with SMTP id el9mr22052777oeb.46.1373317479559; Mon, 08 Jul 2013 14:04:39 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Mon, 8 Jul 2013 14:04:39 -0700 (PDT) In-Reply-To: <1373316621.879922633@apps.rackspace.com> References: <1373223178.486913695@apps.rackspace.com> <1373316621.879922633@apps.rackspace.com> Date: Mon, 8 Jul 2013 17:04:39 -0400 X-Google-Sender-Auth: fG1bIwhimOyUtABCM-YPD5HRpno Message-ID: From: Jim Gettys To: David P Reed Content-Type: multipart/alternative; boundary=089e0118409e88793204e10664f3 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 21:04:41 -0000 --089e0118409e88793204e10664f3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 4:50 PM, wrote: > I was suggesting that there is no reason to be intimidated. > > > > 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. > > > > They 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. > > > > As to being constructive, I'm not convinced that these people can be > convinced that their dismissal of bufferbloat and their idea that "goodput" > is a useful Internet concept are incorrect. > > > > If they are curious, experimental evidence might be useful. But have they > done their own experiments to validate what they "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 AWGN channel capacity > theorem, its 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*. > > > > The same is true about 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 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. > Actually, I don't face much disbelief in the IETF these days, in recent memory. Remaining problems there are mostly around how common/severe the problem is, and that buffers hide everywhere, and people aren't yet paranoid enough to go find the problems. More common than IETF disbelief is among the network measurement research community, ironically, where (some of them) would like to dismiss the problem as not common, or severe enough to be worth bothering with. Net result are a number of papers with conclusions that are suspect at best, and bogus at worst. I suspect some of them are embarrassed that they overlooked the bufferbloat problem in the data they were talking... The other major problem I've seen (and am writing about as I compose this), is that networking people seem to worship the 100ms number as a "given" from "heaven", when in fact, human factors and the speed of light make it easy to demonstrate that *any* unnecessary latency hurts many/most applications. > > That's not science, it's not curiosity. It's *dogmatism* - the opposite > of science. And those people are rarely going to change their minds. > After 45 years in advanced computing and communications, I can tell you > they will probably go to their graves spouting their "old-wives-tales". > > > > 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 themselves > (which is quite easy for anyone who can do simple measurements). RRUL is a > nice simple test. Let them try it! > Yup. Simple tests, and simple results. Which is why I started reporting bufferbloat in my blog with extremely simple tests any networking person should be able to perform themselves. RRUL is one step above that (though still pretty simple). - Jim > > > > > > On Sunday, July 7, 2013 8:24pm, "Mikael Abrahamsson" > said: > > > On Sun, 7 Jul 2013, dpreed@reed.com wrote: > > > > > So when somebody "throws that in your face", just confidently use the > > > words "Bullshit, show me evidence", and ignore the ignorant person who > > > > Oh, the people that have told me this are definitely not ignorant. Quite > > the contrary. > > > > ... and by the way, they're optimising for the case where a single TCP > > flow from a 10GE connected host is traversing a 10G based backbone, and > > they want this 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 > investments > > 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 them off by that kind of > > reasonsing isn't productive. Why not just implement the high RTT testing > > part and prove that you're right instead of just saying you're right? > > > > THe bufferbloat initiative is trying to change how things are done. > Burden > > of proof is here. When I participate in IETF TCP WG, they talk goodput. > > They're not talking latency and interacting well with UDP based > > interactive streams. They're optimising goodput. If we want buffers to be > > lower, we need to convince people that this doesn't hugely affect > goodput. > > > > I have not so far seen tests with FQ_CODEL with a simulated 100ms extra > > latency one-way (200ms RTT). They might be out there, but I have not seen > > them. I encourage these tests to be done. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > --089e0118409e88793204e10664f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Jul 8, 2013 at 4:50 PM, <dpreed@reed.com> wrote:

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

=A0

And yes, according to the dictionary defini= tion, they are ignorant - as in they don't know what they are talking a= bout, and don't care to.

=A0

They may be influential, and they may have = a great opinion of themselves. =A0And others may view them as "knowled= geable". =A0 The folks who told Galileo that he was wrong were all of = that. =A0But they remained ignorant.

=A0

As to being constructive, I'm not convi= nced that these people can be convinced that their dismissal of bufferbloat= and their idea that "goodput" is a useful Internet concept are i= ncorrect.

=A0

If they are curious, experimental evidence = might be useful. =A0But have they done their own experiments to validate wh= at they "accept as true"? =A0 I've been told by more than 50%= of professional EE's practicing that "Shannon's Law" pla= ces a limit on all radio communications capacity. =A0But none of these EE&#= 39;s can even explain the Shannon-Hartley AWGN channel capacity theorem, it= s derivation, and its premises and range of applicability. =A0They just &qu= ot;think they know" what it means. =A0And they are incredibly arrogant= and dismissive, while being totally *incurious*.

=A0

The same is true about most "networkin= g professionals". =A0Few understand queueing theory, its range of appl= icability, etc. *or even exactly how TCP works*. =A0But that doesn't st= op them from ignoring evidence, evidence that is right in front of their ey= es - every day. =A0It took Jim Gettys' curiosity of why his home networ= k performance *sucked* to get him to actually dig into the problem. =A0And = yet much of IETF still tries to claim that the problem doesn't exist! = =A0They dismiss evidence - out of hand.


Actually, I don't face much disbelief in the IETF these = days, in recent memory. =A0Remaining problems there are mostly around how c= ommon/severe the problem is, and that buffers hide everywhere, and people a= ren't yet paranoid enough to go find the problems.

More common than IETF disbelie= f is among the network measurement research community, ironically, where (s= ome of them) would like to dismiss the problem as not common, or severe eno= ugh to be worth bothering with. =A0Net result are a number of papers with c= onclusions that are suspect at best, and bogus at worst. I suspect some of = them are embarrassed that they overlooked the bufferbloat problem in the da= ta they were talking...

The other major problem I'= ve seen (and am writing about as I compose this), is that networking people= seem to worship the 100ms number as a "given" from "heaven&= quot;, when in fact, human factors and the speed of light make it easy to d= emonstrate that *any* unnecessary latency hurts many/most applications.

=A0

That's not science, it's not curios= ity. =A0It's *dogmatism* - the opposite of science. =A0And those people= are rarely going to change their minds. =A0After 45 years in advanced comp= uting and communications, I can tell you they will probably go to their gra= ves spouting their "old-wives-tales".

=A0

Spend your time on people who don't &qu= ot;throw things in your face". =A0On the people who are actually curio= us enough to test your claims themselves (which is quite easy for anyone wh= o can do simple measurements). =A0RRUL is a nice simple test. =A0Let them t= ry it!


Yup. =A0Simple tests, and simple results. =A0Which is why I = started reporting bufferbloat in my blog with extremely simple tests any ne= tworking person should be able to perform themselves. =A0RRUL is one step a= bove that (though still pretty simple).
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim

=A0

=A0



On Sunday, July 7, 2013 8:24pm, &qu= ot;Mikael Abrahamsson" <swmike@swm.pp.se> said:

> On Sun, 7 Jul 2013, dpreed@reed.com wrote:
>
&= gt; > So when somebody "throws that in your face", just confid= ently use the
> > words "Bullshit, show me evidence", and ignore the igno= rant person who
>
> Oh, the people that have told me this are = definitely not ignorant. Quite
> the contrary.
>
> ... a= nd by the way, they're optimising for the case where a single TCP
> flow from a 10GE connected host is traversing a 10G based backbone, an= d
> they want this 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 c= auses core
> routers to get designed with 600 ms of buffering (well, = latest generation
> ones are down to 50ms buffering). We're talki= ng billion dollar investments
> by hardware manufacturers. We're talking core routers of latest ge= neration
> that are still being put into production as we speak.
&= gt;
> Calling them ignorant and trying to wave them off by that kind= of
> reasonsing isn't productive. Why not just implement the high RTT t= esting
> part and prove that you're right instead of just saying = you're right?
>
> THe bufferbloat initiative is trying to = change how things are done. Burden
> of proof is here. When I participate in IETF TCP WG, they talk goodput= .
> They're not talking latency and interacting well with UDP bas= ed
> interactive streams. They're optimising goodput. If we want = buffers to be
> lower, we need to convince people that this doesn't hugely affect = goodput.
>
> I have not so far seen tests with FQ_CODEL with a= simulated 100ms extra
> latency one-way (200ms RTT). They might be o= ut there, but I have not seen
> them. I encourage these tests to be done.
>
> --
> = Mikael Abrahamsson email: swmike@swm.pp.se
>


______________________________________________= _
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


--089e0118409e88793204e10664f3--