General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Thomas Graf <tgraf@suug.ch>,
	jdb@comx.dk, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Notes about hacking on AQMs
Date: Wed, 8 Jun 2011 10:50:44 -0700	[thread overview]
Message-ID: <20110608105044.62a912af@nehalam.ftrdhcpuser.net> (raw)
In-Reply-To: <BANLkTinGxR5zSBa1tWAZ3F6_VLwAtt1urA@mail.gmail.com>

On Wed, 8 Jun 2011 10:52:07 -0600
Dave Taht <dave.taht@gmail.com> wrote:

> On Wed, Jun 8, 2011 at 10:41 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le mercredi 08 juin 2011 à 09:51 -0600, Dave Taht a écrit :
> >
> >>
> >> And they are *all* wrong to varying extents, which is why I like the
> >> 'mondo classifier' idea for DSCP+firewalling mentioned earlier on this
> >> thread. Converging on several standards for packet marking vs the
> >> adhoc-ness of thousands of different partial solutions that now exist
> >> really makes sense to me.
> >
> > I can tell you there are hundred of different *valid* setups, especially
> > in server farms, when you want some control of network trafic, now
> > machines have Gb or 10Gb links...
> 
> Well, there are hundreds of thousands of completely ad-hoc solutions
> of varying degrees of effacy.
> 
> Getting it down to mere hundreds would be be a good start.
> 
> > Really, there is no "one big thing that solves all problems,
> > automatically".
> 
> Oh, I agree.

It isn't just a Linux problem. Cisco and Juniper have been doing
QoS solutions for years. Like Linux there is the "billions of knobs
version" and the KISS version. The KISS versions are fair queueing
based. The problem is that the more complex QoS variants can't be
done in ASIC's and go down the software path.  Linux has the same
problem, the more complex QoS ends up requiring locks that embed
performance.

  reply	other threads:[~2011-06-08 17:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-08 12:12 Dave Taht
2011-06-08 12:56 ` Eric Dumazet
2011-06-08 13:32   ` Dave Taht
2011-06-08 14:04     ` Dave Taht
2011-06-08 14:57       ` Eric Dumazet
2011-06-08 15:20         ` Dave Taht
2011-06-08 15:21           ` Dave Taht
2011-06-23 22:38           ` Juliusz Chroboczek
2011-06-23 22:47             ` Dave Taht
2011-06-08 15:27         ` Jesper Dangaard Brouer
2011-06-08 15:45           ` Eric Dumazet
2011-06-08 15:51             ` Dave Taht
2011-06-08 16:41               ` Eric Dumazet
2011-06-08 16:52                 ` Dave Taht
2011-06-08 17:50                   ` Stephen Hemminger [this message]
2011-06-08 23:06           ` Thomas Graf
2011-06-09 17:18             ` Jesper Dangaard Brouer
2011-06-09 16:04   ` Jesper Dangaard Brouer
2011-06-09 16:14     ` Eric Dumazet
2011-06-09 17:20       ` Jesper Dangaard Brouer

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

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

  git send-email \
    --in-reply-to=20110608105044.62a912af@nehalam.ftrdhcpuser.net \
    --to=shemminger@vyatta.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=jdb@comx.dk \
    --cc=tgraf@suug.ch \
    /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