From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5EA673B29E for ; Sat, 11 Apr 2020 22:05:20 -0400 (EDT) Received: by mail-il1-x132.google.com with SMTP id t11so5655480ils.1 for ; Sat, 11 Apr 2020 19:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Se3Xpzh+sYHzoB7Rhfdia3iGZPwkgQJ3oo0hJtPWxSM=; b=S7E6ucFL5bEjFsu29rl7DdCDjvpWebQ1Rf8GOb2pR+Odde51ZzGzBUiZVsLR3bbFHw zEt/CMIb/R/y0MMCTqCFCqvxx5lGdqN2QVjHKQgVDVg9u1KQd0Csvewd4TcB7UDSZdKP hfmsjXwVGG8sJuJWRRm8I5v+ur/YgeUosMhNm9laqnU323M5e2x6Nvp6lcccLR1RnBMy 0yhQZsrVyE/G1fXqjWTYEBelXvZ+ZZFLYV4akmdPTtC61mtzWVITmiaq2kBBxC3lJT/x hjsOljpHRZ0QTTII1NCX2+VTi/xRhVyAv2QfxV5QXSeiqJB2m15T71pFijWz5wK9KX8i 4hHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Se3Xpzh+sYHzoB7Rhfdia3iGZPwkgQJ3oo0hJtPWxSM=; b=cwxywCayDVuI4mcSYkKzjON/gwTSnKOknMjvyWuAlTfSJv3pYtimCOrnVTkYYLUpfw 3cu5cH6JwCLA5bk0myqoovVxg0Tzgkvdw4N14dpwiIDaiF+20vrLzunVDsq9ZWY1PzZk erICzvU10JGncjb6mLrFLpboI507hHb4lOvmZdLNatFcvDldngbfxA+4AtdCPHl+B2mR s5J1WpFQLkCY/gX2oIELIfskf6+KEvxIn7XKlZGxxcapmYobyYMdTnXwp+WYOah85QJG Vj9g7c3+xyAE7yheOZa8yjnWwQFn/6ZaD0JrIJmOcOQgocWlWnrtd8MK14hiwguAwwji gFGg== X-Gm-Message-State: AGi0PuadNWva1K1JMo3Lu+m9a5TG1UsKPdmZ0UGOQnd6NhEkUHiKEHvb /U9/z9VaEshceK7uDu1Mj0+ks2Ucv7FuF8gTpAgnS4n2Pi0= X-Google-Smtp-Source: APiQypKbv1QfMt+To10Sn5H5aOnJtoOhH36cZVD4DnBBFQZSI5W1rUBcY7snGtuN2BsguwyQi/nW8PSRZz0nd8pVafw= X-Received: by 2002:a92:8e50:: with SMTP id k16mr12261250ilh.45.1586657119659; Sat, 11 Apr 2020 19:05:19 -0700 (PDT) MIME-Version: 1.0 References: <1586653525.57076088@apps.rackspace.com> In-Reply-To: <1586653525.57076088@apps.rackspace.com> From: Dave Taht Date: Sat, 11 Apr 2020 19:05:07 -0700 Message-ID: To: "David P. Reed" Cc: Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Anyone got a view on this? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 02:05:20 -0000 On Sat, Apr 11, 2020 at 6:05 PM David P. Reed 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, trac= es... 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=E2=80=99s target rate calculation (Equation(1))used=CE=B7=3D0.98and=CE=B4=3D133ms. Ou= r Wi-Fi implementationuses the link rate estimator from =C2=A75, while our emulated cel-lular network setup assumes the realistic scenario that ABC=E2=80=99srouter 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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729