[Cerowrt-devel] happy 4th!

[Jim Gettys]

On Mon, Jul 8, 2013 at 4:50 PM, <dpreed at reed.com> 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" <swmike at swm.pp.se>
> said:
>
>  > On Sun, 7 Jul 2013, dpreed at 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 at swm.pp.se
> >
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130708/ff03bcba/attachment-0002.html>