[Make-wifi-fast] Anyone got a view on this?

[David P. Reed]

Thanks, Dave. In explanation, rather than defense of MIT research in this case, I'd like to say one thing.

The pressure to hype ones results today is astronomical for professors, especially pre-tenure, but even post-tenure. Compared to my time at MIT's Project MAC that became the Laboratory for Computer Science, and then much later, CSAIL, you could get tenure and respect merely by publishing one really good paper a year at SOSP, ASPLOS, ... Today, you have to have your name on 5-10 student-produced papers per year, get grants or contracts to support all your students renewed every year, ... and hopefully find grad students to teach all your classes for you.

The NIT News Office is huge today. It's people maintain their jobs by finding and promoting any little timely idea. (a few years ago, MIT publicized "wireless power" as  a breakthrough, without any technical details of the limitations imposed by physical reality on the idea of transmitting power using a 1 MHz RF radiator and pickup in a room. But hey, a lot of reporters picked it up and put MIT's name in the papers.

This is because there is no funding for academic research, basically. Neither industry nor government thinks they need to pay for this stuff. So instead, a travesty has been made of much research in academia by the need to self-promote. And "everyone does it".

The result is that zillions of results are published under the good name of MIT or other institutions, but the reader has to evaluate for themselves whether the results are useful.

I hate this. But I have a lot of sympathy, a great deal of sympathy, for those trapped in that system.

I'm lucky. I can do my own research in my own home lab. If I want, I can publish on the Internet, for free. But I only feel a need to do that if the result is worth publishing. I don't have to prematurely publish a half-baked idea and get it through skeptical referees. Instead, I can just polish and give a finish to the ideas so it is worth reading about.

That was what publishing a computer science paper used to be about. There was about one conference that mattered in one's field - in my case SIGOPS. And only really good papers got published. If you couldn't publish there, you didn't. And you could still get tenure.

On Saturday, April 11, 2020 10:05pm, "Dave Taht" <dave.taht at gmail.com> said:

> On Sat, Apr 11, 2020 at 6:05 PM David P. Reed <dpreed at deepplum.com> wrote:
>>
>> https://techxplore.com/news/2020-04-wireless-networks.html
> 
> MIT still is good at PR, unlike us.
> 
> Yer the one that handed them their ass on your prior paper review.
> (and me, privately, I handed 'em their ass on the quality of their
> result vs a vs modern fq_codel on wifi (post "ending the anomaly"),
> since they didn't compare against the real deal, seemingly
> specifically picking a kernel that pre-dated our work - and I view the
> trace results they use as entirely useless). the actual paper
> presented is probably this one:
> https://www.usenix.org/system/files/nsdi20-paper-goyal.pdf
> 
> I only skimmed it briefly. no running code, non-reproduceable results, traces...
> 
> Rather than compare against fq_codel, they ripped out a real wifi
> emulation entirely, and did codel with cubic rather than fq_codel.
> They got a glow on from getting published after multiple tries. And
> then there's the totally artificial test setup...
> 
> "Our emulated cellular network experiments used a mini-mum RTT of 100
> ms and a buffer size of 250 MTU-sized pack-ets. Additionally, ABC’s
> target rate calculation (Equation(1))usedη=0.98andδ=133ms. Our Wi-Fi
> implementationuses the link rate estimator from §5, while our emulated
> cel-lular network setup assumes the realistic scenario that
> ABC’srouter has knowledge of the underlying link capacity [1"
> 
> Uh, huh.
> 
> PLEASE NOTE: That said, I like the simplifying conceptualization of
> ECT(1) equals accellerate in abc, *with* a transport that thinks that
> way. it's sort of inbetween the SCE concept and the L4S DCTCP concept
> and may well have a bit of promise. But lacking code...
> 
> One of these days having the war with real results with real tech vs
> academia might seem worthwhile, but, me, I'm still got a glow on from
> actually seeing the ath10k finally behave.
> 
> https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002
> 
> only cost us 4 years of life, that.... so many other chips to fix...
> 
> I really, really, really used to have way more respect for MIT and
> academia than I do today. I really wish they'd produced results
> against our more modern openwrt implementation and published source
> code. As it is it feels like they are not advancing or being true to
> the goals of real science. For all I know, by us knocking it so far
> out of the park with "ending the anomaly", no academic will cite it or
> compare against it because they can't do better. Just ignore it. Am I
> grumpy about this? you betcha... do I feel like writing a paper or
> letter to the editor? I don't really know the right way to fight an
> academic battle. Never learned. What's the right response? "Dear
> USENIX, you do your readers a disservice by allowing a paper that made
> claims about wifi to not do any coherent comparison with "ending the
> anomaly", published a few years prior, containing code that seems to
> outperform it by a large margin, and the current default in the linux
> kernel"?
> 
> Prefer just to ship code....
> 
> I kind of feel that way also when stanford keeps insisting on still
> teaching CS244 with a ludicrously small buffersize relative to what's
> being observed in the field, also. And then people clone that course
> thinking it represents some reality. And the recent buffersizing
> workshop... oh, don't get me started. It's makework. Keeping a problem
> alive to keep the grant money coming.
> 
> 
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> 
> 
> 
> --
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
>