<font face="times new roman" size="2"><p style="margin:0;padding:0;">I was suggesting that there is no reason to be intimidated.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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*.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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".</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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!</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;"><br /><br />On Sunday, July 7, 2013 8:24pm, "Mikael Abrahamsson" <swmike@swm.pp.se> said:<br /><br /></p>
<div id="SafeStyles1373315275">
<p style="margin:0;padding:0;">> On Sun, 7 Jul 2013, dpreed@reed.com wrote:<br />> <br />> > So when somebody "throws that in your face", just confidently use the<br />> > words "Bullshit, show me evidence", and ignore the ignorant person who<br />> <br />> Oh, the people that have told me this are definitely not ignorant. Quite<br />> the contrary.<br />> <br />> ... and by the way, they're optimising for the case where a single TCP<br />> flow from a 10GE connected host is traversing a 10G based backbone, and<br />> they want this single TCP session to use every spare capacity the network<br />> has to give. Not 90% of available capcity, but 100%.<br />> <br />> This is the kind of people that have a lot of influence and causes core<br />> routers to get designed with 600 ms of buffering (well, latest generation<br />> ones are down to 50ms buffering). We're talking billion dollar investments<br />> by hardware manufacturers. We're talking core routers of latest generation<br />> that are still being put into production as we speak.<br />> <br />> Calling them ignorant and trying to wave them off by that kind of<br />> reasonsing isn't productive. Why not just implement the high RTT testing<br />> part and prove that you're right instead of just saying you're right?<br />> <br />> THe bufferbloat initiative is trying to change how things are done. Burden<br />> of proof is here. When I participate in IETF TCP WG, they talk goodput.<br />> They're not talking latency and interacting well with UDP based<br />> interactive streams. They're optimising goodput. If we want buffers to be<br />> lower, we need to convince people that this doesn't hugely affect goodput.<br />> <br />> I have not so far seen tests with FQ_CODEL with a simulated 100ms extra<br />> latency one-way (200ms RTT). They might be out there, but I have not seen<br />> them. I encourage these tests to be done.<br />> <br />> --<br />> Mikael Abrahamsson    email: swmike@swm.pp.se<br />></p>
</div></font>