From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 B8B9D3B260 for ; Wed, 11 May 2016 12:19:41 -0400 (EDT) Received: by mail-oi0-x235.google.com with SMTP id v145so75843387oie.0 for ; Wed, 11 May 2016 09:19:41 -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=nwuqZCW8J0GWKgJL91KYimSXXlbzaGICfX9KINOXKo4=; b=hCB1c+k/fBbemXZGmRJXnA+hghjb3v/TMsMrqMaH7tZ1OF8+ol+kj4/XVA2C3EB3Wm jwyrEsaYtYd+n9/fxnwd2FqtSGw5cdDoX/APQjf7St+z2BR8lFsITwZRJgFlKLreabL2 uopkc/gAiDfn1ctNF4koaFoQKQOP2+wBFLgcbzedBXs6vN1HhD9lyNZGvYs93rMBsmzL SKJNRZBP/gG1TNDXxn1SeiNJSN8mTEVUKcrXjxhVu9HypE6e/eFh38okkobLmnmNyvU6 qfUeXHkh47dvZivZaim8eYN//kU7GSl5TKBNn+jBQsN0SEEe0U9/g7pcHM4en3ZnW/rN Qa5A== 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=nwuqZCW8J0GWKgJL91KYimSXXlbzaGICfX9KINOXKo4=; b=NqZNyNmrIzHADU5dGAhYgpNeTwNEoQwThH2BanEYiKIHqV0il89yKPY83xwK3vBtBw tI9tkUxO5ojzDDNb7gfDwiO6WXytggBUnGK+AsYk5oO9SOBnsMOHC4TfvvnyTAwFtwTC UQAO1TuoVFWrXhOgu86DrwRq8uGaCGqs3EYlPwGRKvfE/wQDK1aRhsLZak2dd8FqcwEz DTH2fTZSvqrSrKVa1lLKWBt3LbDjehr6+AbbdeGOKsdYxByS4GAzKXwBvZqIGMjakSk6 dltFUUq4tHY4t81zKBZvyKudZXauWumPXegJLBlmpIybr1OWK7owkaVJAI1ZuN0SBuVw 2n4Q== X-Gm-Message-State: AOPr4FWVn06T6nle6H9MhLtAWWTkcgkRPwr2m6M0rQAIgZMSZev74B4QTuuMUmtXnja4Z2uQ6c6+FxJbaAbWXw== MIME-Version: 1.0 X-Received: by 10.202.178.135 with SMTP id b129mr2241166oif.139.1462983581215; Wed, 11 May 2016 09:19:41 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Wed, 11 May 2016 09:19:41 -0700 (PDT) In-Reply-To: References: <871t58n5wk.fsf@toke.dk> <87futolndh.fsf@toke.dk> <874ma4ljfz.fsf@toke.dk> Date: Wed, 11 May 2016 09:19:41 -0700 Message-ID: From: Dave Taht To: Luca Muscariello Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , "make-wifi-fast@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 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:19:41 -0000 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.