General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Neil Davies <neil.davies@pnsol.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] ipspace.net: "QUEUING MECHANISMS IN MODERN SWITCHES"
Date: Tue, 27 May 2014 13:34:16 +0100	[thread overview]
Message-ID: <346A4866-BEF9-4371-91AF-D4FEF4CE4A36@pnsol.com> (raw)
In-Reply-To: <CAPh34md=TBwWUKugZTvipXhAGmjcCxe-X8dcDw9PxvqeLVh_4A@mail.gmail.com>

Hagen

It comes down to the portion of the end-to-end quality attenuation (quality attenuation - ∆Q - incorporates both loss and delay) budget  you want to assign to device and how you want it distributed amongst the competing flows (given that is all you can do - you can’t “destroy” loss or “destroy” delay, just differentially distribute it). 

As for ingress/egress capacity being almost the same, that *REALLY* depends on the deployment scenario….

You can’t do traffic performance engineering in a vacuum - you need to have objectives for the application outcomes - that makes the problem context dependent. 

When we do this for people we often find that there are several locations in the architecture where FIFO is the best solution (where you can prove that the natural relaxation times of the queues, given the offered load pattern, is sufficiently small so as not to induce to much quality attenuation). In other places you need to do more analysis.\x10

Neil

On 27 May 2014, at 13:20, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

> The question is if (codel/pie/whatever) AQM makes sense at all for
> 10G/40G hardware and higher performance irons? Igress/egress bandwidth
> is nearly identical, a larger/longer buffering should not happen. Line
> card memory is limited, a larger buffering is defacto excluded.
> 
> Are there any documents/papers about high bandwidth equipment and
> bufferbloat effects?
> 
> Hagen


  reply	other threads:[~2014-05-27 12:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27  8:21 Hagen Paul Pfeifer
2014-05-27 10:45 ` Neil Davies
2014-05-27 12:20   ` Hagen Paul Pfeifer
2014-05-27 12:34     ` Neil Davies [this message]
2014-05-28 18:44     ` David Lang
2014-05-28  9:39 Hal Murray
2014-05-28 11:00 ` Jonathan Morton
2014-05-28 18:56   ` David Lang
2014-05-28 22:15     ` Bill Ver Steeg (versteb)
2014-05-29  7:20   ` Neil Davies
2014-05-29 14:06     ` Jonathan Morton
2014-05-29 16:58     ` Dave Taht

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=346A4866-BEF9-4371-91AF-D4FEF4CE4A36@pnsol.com \
    --to=neil.davies@pnsol.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=hagen@jauu.net \
    /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