From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 F0F853B260 for ; Wed, 11 May 2016 12:33:15 -0400 (EDT) Received: by mail-yw0-x236.google.com with SMTP id g133so47864282ywb.2 for ; Wed, 11 May 2016 09:33:15 -0700 (PDT) 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; bh=dSMNkNaN5YkCkXkf0sLb6MqLT5ZP3mkWXF5YQ+uUxBA=; b=cuBqk21uJQxoHJqSnrd6XeyEdydoWku2TbIfSD10HLfQj1jmpXanhy+Qe8kW3ZV1z9 5HEQw9kOgJVKeNbJ79FTdHiH1c8+ZCfOJ9UmWTyPEo8CDvAJ5VjG16Khd5gMp8L7RHFF EjMIKkgyOC9ahHM/ssoX8XTKUmeFNwRqFdxlhP+MMppS7thUiLjIPLJ0gQSEQzFt7d51 3BIV5DUpSHpQN1yb6xYiyFq6qf6AR3G3g6I9h3n8oxlcgkBRxidd5bsNKD5XqqNV5v/S LsTQWD0ztfayjIwrGcUZVnLtVl3JinYexoCgNlkfvhL2E/oZQezgAwgdQGNLh/4HkAll uXiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dSMNkNaN5YkCkXkf0sLb6MqLT5ZP3mkWXF5YQ+uUxBA=; b=aGEdHSf+pR+x8J30giSRRmu6qYfFYSJUnJJrNVKFUCcQdR5pcE7Fby8S5uiE9YM9BI symPCfpLQ4JlecIMc4R4YrE6GeriBvp7X+xMvK0iOWK8HZr69+0V+Y94YacIeSaxh26R SVrkuBJ8c1eDvYQc4K29ius44iCejTe8yzkXmQbRuzXdaJW4ZWRQcqH2XX0U5XLDYxNy T2v+AZP4Lm2bYGDFru1V+w/uxtmXTodJHyOnWuHLdbUZG3OEUTEMAfOPXLBy8h0Ez4kh LA9/lISr3AeWlk/L3EEkd8KnQFIs14ViBVrVO8DJzPe/jua7g0wTT3X73scidmUNY36Z J14w== X-Gm-Message-State: AOPr4FV1vxdkIKO+vR3W21m06pa/Uw+yy5x5xTrD4H106WgZ3DfTY+mouM6AV50+Ld9hmNaBNgoQ2GYr4I+75w== MIME-Version: 1.0 X-Received: by 10.37.57.195 with SMTP id g186mr2124510yba.38.1462984395548; Wed, 11 May 2016 09:33:15 -0700 (PDT) Received: by 10.37.74.134 with HTTP; Wed, 11 May 2016 09:33:15 -0700 (PDT) In-Reply-To: References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> <874ma4ljfz.fsf@toke.dk> Date: Wed, 11 May 2016 18:33:15 +0200 Message-ID: From: Luca Muscariello To: Dave Taht Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , "make-wifi-fast@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=94eb2c08e18a357332053293997b 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 16:33:16 -0000 --94eb2c08e18a357332053293997b Content-Type: text/plain; charset=UTF-8 What is worse is that I agree entirely. Short time fairness is important and more important is a fairness criterion that enables expedited forwarding for RTC. And for RTC what you say is key. However, EDCF is not going to help when you have many stations and low PHY rates should be disabled to get something that approaches to what you have in mind. On Wednesday, 11 May 2016, Dave Taht wrote: > My own foci are going to be around trying to rip every source of > potential latency out of the current system: be it deferred > interrupts, bad rate control information, overlong txops, excessive > retries, insufficient packet loss, busting the block ack window, and > quashing stations grabbing too much airtime... > > and then adding back in "bandwidth" from there. We have enough > bandwidth in wifi nowadays, just now narrow enough time slices to feed > many stations sanely. > > a somewhat subtle distinction is that aiming for airtime fairness > independently of the behaviors of real traffic is not a goal (for me). > A system handing out 8 stations 8ms each of airtime is "fair", but > handing out 1ms each - or just enough, for example, for my > videoconferencing flow to handle each frame with a single txop - or > getting a new station started faster on some web traffic - is better. > > Certainly there is a ton of low hanging fruit to excise, and achieving > something closer to but we ignore multicast, channel scans, and other > oddities to our peril. > > I don't, for example, think that aiming for airtime fairness over 1sec > intervals is good, 20-50ms would be way more desirable. And so on. > Getting a good rate control estimate by the second txop used by a > previously idle station would be good. And so on. > > ... > > this message brought to you from the association for more coffee in the > morning. > --94eb2c08e18a357332053293997b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What is worse is that I agree entirely.

Short time fairness is= important and more important is a fairness criterion that enables expedite= d forwarding for RTC.
=C2=A0And for RTC=C2=A0
<= div>what you say is key.

However, EDCF is not goin= g to help when you have many stations and low PHY rates should be disabled= =C2=A0
to get something that approaches to what you have in mind.=

On Wednesday, 11 May 2016, Dave Taht <dave.taht@gmail.com> wrote:
My own foci are going to be around trying to rip every source of
potential latency out of the current system: be it deferred
interrupts, bad rate control information, overlong txops, excessive
retries, insufficient packet loss, busting the block ack window, and
quashing stations grabbing too much airtime...

and then adding back in "bandwidth" from there. We have enough bandwidth in wifi nowadays, just now narrow enough time slices to feed
many stations sanely.

a somewhat subtle distinction is that aiming for airtime fairness
independently of the behaviors of real traffic is not a goal (for me).
A system handing out 8 stations 8ms each of airtime is "fair", bu= t
handing out 1ms each - or just enough, for example, for my
videoconferencing flow to handle each frame with a single txop - or
getting a new station started faster on some web traffic - is better.

Certainly there is a ton of low hanging fruit to excise, and achieving
something closer to but we ignore multicast, channel scans, and other
oddities to our peril.

I don't, for example, think that aiming for airtime fairness over 1sec<= br> intervals is good, 20-50ms would be way more desirable. And so on.
Getting a good rate control estimate by the second txop used by a
previously idle station would be good. And so on.

...

this message brought to you from the association for more coffee in the mor= ning.
--94eb2c08e18a357332053293997b--