From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A76A63CB3A for ; Wed, 11 Dec 2019 16:18:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1576099132; bh=X0d3IrJES4PRjXR7rEWkaTJLmSlb/a6MdvbrfB2m7Wk=; h=Date:Subject:From:To:From; b=nAHCF3ylSDt+qFTLyTvO67VWtdbrGD4KnreRq5IEhjeMhJt1tf1/9WKqBP94/gOsg BB42Ls52+mI+LubZtcRJmEsDzaZaLgOmjNZs/R2MtvUSemOmkqWZTMAsWBoY4LBc0G HKraJMNDqmIbddODN7XG2chSz6WotVMmWqPj9HbY= Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 47193558C; Wed, 11 Dec 2019 16:18:52 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 11 Dec 2019 16:18:52 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id 326DA61463; Wed, 11 Dec 2019 16:18:52 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 11 Dec 2019 16:18:52 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Wed, 11 Dec 2019 16:18:52 -0500 (EST) From: "David P. Reed" To: "Dave Taht" Cc: "Prateesh Goyal" , "Hari Balakrishnan" , "ECN-Sane" , "Mohammad Alizadeh" , "bloat" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: Message-ID: <1576099132.20373478@apps.rackspace.com> X-Mailer: webmail/17.2.0-RC Subject: Re: [Bloat] [Ecn-sane] abc congestion control on time varying wireless links X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 21:18:52 -0000 I will not be gentle here. THe authors deserve my typical peer-review feedb= ack as an expert in the field of wireless protocols and congestion. (Many o= f you on the list are as well, I know, and may have different reviews. But = I'm very troubled by this paper's claims. It's interesting technically, but= flawed seriously, enough that I would send it back for more work before pu= blication. (not that my opinion matters these days)=0A=0AA separate perspec= tive from me on the paper.=0A=0A1) There is a problem in the very title wor= ding of the paper. WiFi is not at all a "time varying wireless link" Nor is= it obvious that a time varying link is even a good approximate model of Wi= Fi LANs. What do I mean here?=0A=0A a. WiFi is not a link. In its typical= deployment (non-peer-to-peer) it is a hub that is multiplexed by many wire= less links that share the same spatial channel, but follow different paths.= =0A b. WiFi's spatial shared wireless channel's temporal behavior is not m= odeled by a single scalar variable called "speed" or "error rate" that is v= arying over a range over time.=0A c. congestion is typically queueing dela= y on a shared FIFO queue. In the AP-STA operation described, when delays ha= ppen they are not at all characterized by a shared single FIFO queue. In fa= ct each packet travels twice through the air, each time in a highly correla= ted temporal distribution, and each packet travels through two FIFO cuques,= plus a strange CSMA exponential backoff queue. This is NOT congestion in a= ny real sense.=0A=0A2) the paper doesn't present any data whatever regardin= g actual observed channel behaviors, or even actual observed effects.=0A = a. Indoor propagation of OFDM signals is complicated. I've done actual meas= urements, and continue to carry them out. But many others have as well. The= sources of variability over time and the time constants of that variabilit= y are not well characterized in the literature at all. My dear friend Ted R= apaport is an expert on *outdoor* microwave and mmwave propagation, and has= done lots of measurements there. But not indoor, where such things as rota= ting fans, moving people, floorand ceiling elements, etc. all affect the pr= opagation of OFDM signals in ways that do vary, but not according to any mo= del that has been characterized sufficiently to build, say, an ns2 simulati= on.=0A b. the indoor behavior at the MAC layer of signals is highly varia= ble due to many effects, not all physical (for example, microwave noise tha= t affects the time waiting for a "clear" channel before a station can trans= mit. This can vary a lot. Also, in a Multi-User Dwelling or an enterprise o= ffice/campus, other WiFi traffic causes delay at the MAC layer that is non = trivial. What's the problem here is that this "interference" (not radio int= erference at all, but MAC layer variability) is not slowly varying in any s= ense. The idea that this is modelable by a congestion control mechanism of = any sort is not clear.=0A c. driving all of this is the mix of applicatio= n traffic in a "local area" (the physical region around the access point, a= nd the upstream network to which the access point connects. Not all of this= traffic is anything like a simple distribution. In fact, it's time varying= across many time scales. For example, Netflix video is typically TCP with = controlled bursts (buffer filling) separated by long relatively quiet perio= ds. These bursts can use up all available airtime. In contrast, web traffic= for one "page" often involves many independent HTTP streams (or soon HTTP3= /UDP streams being rolled out at scale by Google on all its services) invol= ving 10's or even hundreds of remote distinct sites, where response time is= critical (lag under load is unacceptable).=0A=0A3. the paper alludes to, b= ut doesn't really characterize, the issue of "fairness" very well. Fairness= isn't Harrison Bergeron style exact matching of bits delivered among all p= airs. Instead, it really amounts to allocation of latency degradation (due = to excess queueing) among independent applications sharing the medium. In o= ther words, it is more like "non-starvation", except where the applications= themselves may actually back off their load when resources are reduced, to= be "friendly".=0AI am afraid that this pragmatic issue, the real goal of c= ongestion control, is poorly discussed in the paper, yet it is the crucial = measure of a good congestion control scheme. Throughput is entirely seconda= ry to avoiding starvation unless the starvation can be proved to be inheren= t in the load presented.=0A=0A=0ANow I will say the mechanism presented may= well be quite useful, but I think such mechanisms should not just be prese= ented in the technical literature *as if it were obvious that they are usef= ul* at least in some typical real world situations.=0A=0AIn other words, be= fore launching into solving a problem, one needs to research and characteri= ze the problem being solved. Preferably this research will produce good exp= erimentally valid models.=0A=0AWe saw back in the early 1970's a huge volum= e of theoretical work from some famous people (Bob Gallegher of MIT is a go= od example) where packet networks were evaluated under Poisson arrival load= s, and asserted to be good. It turns out that there are NO real world netwo= rks that have anything like Poisson arrival processes. The only reason Pois= son arrival processas are interesting is because they are mathematically tr= ivial to analyze in closed form without simulation.=0A=0ABut work on time-s= hared operating system schedulers in the 1960's (at MIT, in the Multics pro= ject, but also at Berkeley and other places) had already demonstrated that = user requests are not at all Poisson. In fact, so far from Poisson that any= scheduler that assumed Poisson arrivals was dreadful in practice. Adding e= picycles to Poisson arrivals fixed nothing, but produced even richer "close= d form" solutions, and a vast literature of research results in departments= focused on scheduling theory around the US.=0A=0AThe same has been true of= Gallegher and his theory students. Poisson random arrivals infest the lite= rature, and measurement driven, practical research in networking has been d= espised. =0A=0AIt's time to focus on the Science of actual real networks, w= ireless ones in the real world, and simulations validated against real worl= d situations (as scientists do when they have to model the real world).=0A= =0AI'm very, very sad to see this kind of publication, which is not science= , but just a mathematical game played based on a hunch about wireless behav= ior that is not based on measurements or characteristic applicaitons. IN co= ntrast, the reality centered work being done by people like the bloat proje= ct, while not so academically abstract, is the state of the art=0A=0AA prop= er title would be "a random congestion control mmethod on ann imaginary art= ificial network that might, if we are lucky, be somewhat like a wifi networ= k, but honestly we never actually looked at one in the wild"