From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1D16B21F50E for ; Sun, 1 Feb 2015 02:47:24 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id hy4so13155073vcb.8 for ; Sun, 01 Feb 2015 02:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WumwuuuDHqLgucyFkYC33dv2Cs5r6jyaTc4t/N1+hTE=; b=pPRUA2siG/dKlHmkdZt6aqKALlneO8Yz6l6CbOfEhArQVcLMxhXU3C8EMCKmuFOn0Q tfPpzkzavUicC34i4bhPY5s7LLQGiSfgP6eM0JtKb/WR4DJepAWuMFmn74bcdo3vFyLD DZoknzxljOPx75JofgAX58J8qoUZzXL6y5wpYN13b20jWSzErFW9/IX0+iZ7aD1263mV 9wdWwmvYnqeOUPPV3okaNZXy441n7DRvOJ/74XKcmdlziAfWIv0lv8Jf4t9XOrrN5zbt ZmFwXhP68YAflILlfSRwuuw8VgLGnnqsjyCtHhjUmpIF86jnHxgH/gUS7VY8P/kxa160 iu1Q== MIME-Version: 1.0 X-Received: by 10.221.24.72 with SMTP id rd8mr8584913vcb.56.1422787643453; Sun, 01 Feb 2015 02:47:23 -0800 (PST) Received: by 10.52.178.134 with HTTP; Sun, 1 Feb 2015 02:47:23 -0800 (PST) Received: by 10.52.178.134 with HTTP; Sun, 1 Feb 2015 02:47:23 -0800 (PST) In-Reply-To: References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <54CB5D08.2070906@broadcom.com> <1422623975.21689.77.camel@edumazet-glaptop2.roam.corp.google.com> <54CB8B69.1070807@broadcom.com> <1422741065.199624134@apps.rackspace.com> Date: Sun, 1 Feb 2015 12:47:23 +0200 Message-ID: From: Jonathan Morton To: Dave Taht Content-Type: multipart/alternative; boundary=001a11335bfc143769050e049085 Cc: dstanley@arubanetworks.com, Andrew McGregor , Stig Thormodsrud , netdev@vger.kernel.org, linux-wireless , Jesper Dangaard Brouer , cerowrt-devel@lists.bufferbloat.net, Matt Mathis , Derrick Pallas , Mahesh Paolini-Subramanya , Kathy Giori , Tim Shepard , Avery Pennarun Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing` X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 10:47:53 -0000 --001a11335bfc143769050e049085 Content-Type: text/plain; charset=UTF-8 Since this is going to be a big job, it's worth prioritising parts of it appropriately. Minstrel is probably already the single best feature of the Linux Wi-Fi stack. AFAIK it still outperforms any other rate selector we know about. So I don't consider improving it further to be a high priority, although that trick of using it as a sneaky random packet loss inducer is intriguing. Much more important and urgent is getting some form of functioning SQM closer to the hardware, where the information is. I don't think we need to get super fancy here to do some real good, in the same way that PIE is a major improvement over drop-tail. I'd settle for a variant of fq_codel that gets and uses information about whether the current packet request might be aggregated with the previous packet provided, and adjusts its choice of packet accordingly. At the same time, models would undoubtedly be useful to help test and repeatably demonstrate the advantages of both simple and more sophisticated solutions. Ns3 allows laying out a reasonably complex radio environment, which is great for this. To counter the prevalence of one-station Faraday cage tests in the industry, the simulated environments should represent realistic, challenging use cases: 1) the family home, with half a dozen client devices competing with several interference sources (Bluetooth, RC toys, microwave oven, etc). This is a relatively easy environment, representing the expected environment for consumer equipment. 2) the apartment block, with fewer clients per AP but lots of APs distributed throughout a large building. Walls and floors may provide valuable attenuation here - unless you're in Japan, where they can be notoriously thin. 3) the railway carriage, consisting of eighty passengers in a 20x3 m space, and roughly the same number of client devices. The uplink is 3G based and has some inherent latency. Add some Bluetooth for flavour, stir gently. This one is rather challenging, but there is scope to optimise AP antenna placement, and to scale the test down slightly by reducing seat occupancy. 4) the jumbo jet, consisting of several hundred passengers crammed in like sardines. The uplink has satellite latencies built in. Good luck. 5) the business hotel. Multiple APs will be needed to provide adequate coverage for this environment, which should encompass the rooms as well as lounge, conference and dining areas. Some visitors may bring their own APs, and the system must be able to cope with this without seriously degrading performance. 6) the trade conference. A large arena filled with thousands of people. Multiple APs required. Good luck. I also feel that ultimately we're going to have to get industry on board. Not just passively letting us play around as with ath9k, but actively taking note of our findings and implementing at least a few of our ideas themselves. Of course, tools, models and real-world results are likely to make that easier. - Jonathan Morton --001a11335bfc143769050e049085 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Since this is going to be a big job, it's worth prioriti= sing parts of it appropriately.

Minstrel is probably already the single best feature of the = Linux Wi-Fi stack. AFAIK it still outperforms any other rate selector we kn= ow about. So I don't consider improving it further to be a high priorit= y, although that trick of using it as a sneaky random packet loss inducer i= s intriguing.

Much more important and urgent is getting some form of funct= ioning SQM closer to the hardware, where the information is. I don't th= ink we need to get super fancy here to do some real good, in the same way t= hat PIE is a major improvement over drop-tail. I'd settle for a variant= of fq_codel that gets and uses information about whether the current packe= t request might be aggregated with the previous packet provided, and adjust= s its choice of packet accordingly.

At the same time, models would undoubtedly be useful to help= test and repeatably demonstrate the advantages of both simple and more sop= histicated solutions. Ns3 allows laying out a reasonably complex radio envi= ronment, which is great for this. To counter the prevalence of one-station = Faraday cage tests in the industry, the simulated environments should repre= sent realistic, challenging use cases:

1) the family home, with half a dozen client devices competi= ng with several interference sources (Bluetooth, RC toys, microwave oven, e= tc). This is a relatively easy environment, representing the expected envir= onment for consumer equipment.

2) the apartment block, with fewer clients per AP but lots o= f APs distributed throughout a large building. Walls and floors may provide= valuable attenuation here - unless you're in Japan, where they can be = notoriously thin.

3) the railway carriage, consisting of eighty passengers in = a 20x3 m space, and roughly the same number of client devices. The uplink i= s 3G based and has some inherent latency. Add some Bluetooth for flavour, s= tir gently. This one is rather challenging, but there is scope to optimise = AP antenna placement, and to scale the test down slightly by reducing seat = occupancy.

4) the jumbo jet, consisting of several hundred passengers c= rammed in like sardines. The uplink has satellite latencies built in. Good = luck.

5) the business hotel. Multiple APs will be needed to provid= e adequate coverage for this environment, which should encompass the rooms = as well as lounge, conference and dining areas. Some visitors may bring the= ir own APs, and the system must be able to cope with this without seriously= degrading performance.

6) the trade conference. A large arena filled with thousands= of people. Multiple APs required. Good luck.

I also feel that ultimately we're going to have to get i= ndustry on board. Not just passively letting us play around as with ath9k, = but actively taking note of our findings and implementing at least a few of= our ideas themselves. Of course, tools, models and real-world results are = likely to make that easier.

- Jonathan Morton

--001a11335bfc143769050e049085--