Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] ieee vs ietf stds for dscp mappings
Date: Sun, 15 Nov 2015 13:20:23 -0800	[thread overview]
Message-ID: <20151115132023.317a0478@xeon-e3> (raw)
In-Reply-To: <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk>

On Sun, 15 Nov 2015 15:52:40 +0100
Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
> > 	On the wifi-side my limited understanding of the access rules tell me,
> > that allowing clients to pick their qos marking can and will starve the AP of
> > TxOps, so unless the AP can enforce a unified tier for all clients the AP
> > should, in my humble opinion, actually pick its own marking (and medium access
> > probability) adaptively, depending on what the clients use, in a nice BE
> > environment stick to BE but if the clients start sending too many packets in the
> > two higher classes (dynamically measured threshold might be required) the AP
> > should up its game and switch its own packets to the same class. My rationale is
> > that the AP is going to have a better vantage point of the competing clients and
> > hence should be in a better position to guarantee some sort of fairness, than
> > any one client. Since this seems so simple, there probably is a very good
> > technical reason why this can not work, that I am just unable to see.  
> 
> The problem with WiFi is that there are actually two effects of QoS:
> There's the priority queueing (i.e. the four 802.11e queues work as
> strict priority queues), and there's the retransmission and back-off
> behaviour associated with each of the tiers.
> 
> The latter is what can cause starvation for other clients: Because
> the transmission and back-off settings for the "latency-sensitive"
> queues (VO and VI) are more aggressive, they will tend to starve out
> other things. However, it's not guaranteed that the AP can detect that
> this is happening (it would just see a lot of collisions). You could try
> to infer it by looking at the markings of the packets, but in principle
> there's no reason why a client can't use more aggressive transmission
> settings for packets that are not diffserv marked at the IP layer.

In my experience with customers, they tend to put in hard
policing limits for any of the latency sensitive queues. I.e if the network
is 100mbit, they put in a policer to drop traffic over some limit (typically 25%
of the bandwidth). That way they are guaranteed to not stave regular classes.

  parent reply	other threads:[~2015-11-15 21:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-14 12:42 Dave Taht
2015-11-14 12:43 ` Dave Taht
2015-11-14 13:55   ` Jonathan Morton
2015-11-14 14:09     ` Dave Taht
2015-11-14 15:53     ` Sebastian Moeller
2015-11-14 16:46       ` Jonathan Morton
2015-11-14 19:17         ` Sebastian Moeller
2015-11-15 14:52       ` Toke Høiland-Jørgensen
2015-11-15 15:35         ` Sebastian Moeller
2015-11-15 21:20         ` Stephen Hemminger [this message]
2015-11-15 21:39           ` Jonathan Morton
2015-11-15 21:40           ` Sebastian Moeller

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/cake.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=20151115132023.317a0478@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=cake@lists.bufferbloat.net \
    --cc=toke@toke.dk \
    /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