From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EDA373B260 for ; Wed, 11 May 2016 11:03:13 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u4BF3BEh024182; Wed, 11 May 2016 08:03:11 -0700 Date: Wed, 11 May 2016 08:03:11 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: <871t58n5wk.fsf@toke.dk> Message-ID: References: <871t58n5wk.fsf@toke.dk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1609643107-1462978991=:1548" Subject: Re: [Make-wifi-fast] Thoughts on tackling airtime fairness 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: Wed, 11 May 2016 15:03:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1609643107-1462978991=:1548 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 May 2016, Toke Høiland-Jørgensen wrote: > Improving the access point behaviour is definitely the straight-forward > way, and there are many obvious improvements that can result from that, > as we've already seen in e.g. Michal's patch set. So looking at airtime > fairness from the point of view of the access point makes sense. As a practical matter, we are not going to be able to change the code on the nodes. There are just too many closed source, and never-to-be-updated devices out there (IoT) So focusing on the AP is the right thing to do. > Basically, on a high level I think there are two things that we need to > achieve good airtime fairness: Building the right aggregates (like in > [3]), and scheduling (like in [4]) to compensate for when we get it > wrong or when we can't control the aggregation because the firmware > handles it. > > Getting closer to the practical level, what I plan to go poke at is: > > (1) The ath9k aggregation building logic, to try to achieve > constant-time aggregate size (for a suitable time quantum). Not sure > how much actually needs to change here; the standard already mandates > that an aggregate cannot be longer than 4ms, so the code already takes > time into account. And not sure how this interacts with rate > selection. I think the problem is that the aggregates are created too soon, and as a result the rate can change drastically between the time the aggreagate is formed and when it is sent. I don't believe that they are really limited to 4ms in practice. > (2) Adding a time-based scheduler to enforce airtime fairness. Building > this on FQ-CoDel seems like the sensible thing to do, to get the same > latency bonus for stations that only transmit occasionally. It would > be nice to be able to stick this in the mac80211 layer to make it > shared between drivers, but not sure the required timing information > is available at that layer. Right now, most of the stuff is still doing packet-count based queues. On wired networks where the rate was constant, moving to BQL was a huge win. When the rate can vary so drastically, we need to be factoring rate into the picture somehow. > A non-exhaustive list of issues that need to be resolved one way or > another: > > - What to account to each station's airtime? My thought would be > retransmissions, but not time spent waiting for other stations. Possibly, or possibly have retransmissions change the effective rate. > - What about management, control and multicast frames? I'd say just > ignore it (at least for now). I agree. > - How to measure the results? Can we dump the information from the > driver (and is it accurate)? Do we need to parse aircaps? Something > else? we need to be able to instrament the driver (I don't know if we can get enough data there or not currently) trying to work with aircaps has the problem that what you see in the aircap doesn't match what either the sender or receiver sees Take retransmissions as an example. They only happen because the receiver didn't see them. If you were to get an aircap off the same antenna as the receiver, you also wouldn't see them and therefor could not account for them. In the real world, you are doing the aircap from a different device, with a different antenna so what you see will be even more different. Now think about the normal case where you have two stations taking in two very different locations and one device to do the aircap. If we don't have anything else, aircaps are what we have to fall back on, but we need to realize how much we can't see at that point. David Lang --680960-1609643107-1462978991=:1548--