Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Pete Heist <peteheist@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>, Aaron Wood <woody77@gmail.com>
Cc: cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available
Date: Thu, 16 Feb 2017 17:51:30 +0100	[thread overview]
Message-ID: <DE778D95-F8F5-4A97-A94D-7D3D90AA062B@gmail.com> (raw)
In-Reply-To: <CAACCB41-BB81-4D92-BD7B-2EBA96E9725C@gmx.de>


> On Feb 16, 2017, at 5:21 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> 
>> On Feb 16, 2017, at 17:15, Aaron Wood <woody77@gmail.com> wrote:
>> 
>> The approach that's in all of the Cisco documentation (FWIW) about such things for wired networks is that the higher-priority traffic classes for VoIP and video are also bandwidth limited to a fraction of the total (and less than a majority, at that).  But that's in an environment where you _can_guarantee a minimum level of service.  With the changing throughput rates of wifi, that's a bit harder.
>> 
>> But I can certainly see the case being made that the VO and VI queues are never allowed to be over X% of traffic.
> 
> 	I guess the problem is that any station can just decide by itself to just send AC_VO and in a typical home steup the AP will not get a say in that. This is why I propose the AP to escalate its own priority marking to get its packets distributed… In a sense if there are thresholds for permissible VO/VI traffic fractions below which the AP will not escalate its own priority this will come close to throttling the high priority senders, no? 

I thought Aaron’s suggestion sounds both sensible and not difficult to implement. That way we wouldn’t even have to regularly monitor it, and anyone who is marking all their packets thinking they’re doing themselves a favor is just limiting their max throughput.

Could there be another keyword in Cake to do this automatically, say “fairdiffserv", or would this just be feature bloat for what is already a sophisticated shaper? I don’t know if there are sensible mappings from dscp value to max percentage throughput that would work most of the time, or if there could also be an adjustable curve parameter that controls the percentage backoff as you go up dscp levels.

Sebastian, I wasn’t sure what you meant by the AP’s “own packets”, ones that originate from the AP? One thing with might happen if you raise some priorities is there may be an arms race, and also once packets are forwarded to an upstream router with an already elevated priority they might unfairly compete there, but maybe you meant only to treat some packets differently in the AP, not to actually change the value in the DSCP field...

Pete


  reply	other threads:[~2017-02-16 16:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-30 21:21 [Make-wifi-fast] " Pete Heist
2017-01-30 21:44 ` Toke Høiland-Jørgensen
2017-01-30 22:48   ` Aaron Wood
2017-02-01 14:53     ` Toke Høiland-Jørgensen
2017-01-30 23:21   ` Dave Taht
2017-01-31 16:40     ` Pete Heist
2017-02-14  8:56     ` Pete Heist
2017-02-15 23:03       ` Dave Täht
2017-02-16  7:57         ` Pete Heist
2017-02-16  8:42           ` [Make-wifi-fast] [Cake] " Sebastian Moeller
2017-02-16  9:17             ` Pete Heist
2017-02-16 16:15               ` Aaron Wood
2017-02-16 16:21                 ` Sebastian Moeller
2017-02-16 16:51                   ` Pete Heist [this message]
2017-02-16 17:19                     ` Jonathan Morton
2017-02-16 19:05                       ` Pete Heist
2017-02-16 20:54                         ` Pete Heist
2017-02-16 21:03                       ` Sebastian Moeller
2017-02-17  7:53                         ` Pete Heist
2017-02-17  9:52                           ` Toke Høiland-Jørgensen
2017-02-19 15:25       ` [Make-wifi-fast] " Dave Taht
2017-01-31 15:52   ` Pete Heist
2017-02-01 14:48     ` Toke Høiland-Jørgensen
2017-02-02  8:25       ` Pete Heist
2017-02-07 11:57         ` Toke Høiland-Jørgensen
2017-02-08 15:26           ` Pete Heist
2017-02-08 16:11             ` Toke Høiland-Jørgensen
2017-02-08 16:35               ` Dave Taht
2017-02-08 17:10                 ` Dave Taht
2017-02-08 17:11                   ` Dave Taht
2017-02-09  8:35                 ` Pete Heist
2017-02-09  7:45               ` Pete Heist
2017-02-09 13:51                 ` Toke Høiland-Jørgensen
2017-02-09 14:20                   ` Pete Heist
2017-02-09 14:44                     ` Toke Høiland-Jørgensen
2017-02-10  7:51                       ` Pete Heist
2017-02-08 18:29             ` [Make-wifi-fast] [Cake] " John Yates
2017-01-30 23:55 ` [Make-wifi-fast] " Dave Taht
2017-01-31 16:58   ` Pete Heist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DE778D95-F8F5-4A97-A94D-7D3D90AA062B@gmail.com \
    --to=peteheist@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    --cc=woody77@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox