General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Hal Murray <hmurray@megapathdsl.net>, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] ipspace.net: "QUEUING MECHANISMS IN MODERN SWITCHES"
Date: Wed, 28 May 2014 11:56:26 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1405281146090.32611@nftneq.ynat.uz> (raw)
In-Reply-To: <5AB607A3-A4EA-4B6E-A0F6-7FA0ED9B36E7@gmail.com>

On Wed, 28 May 2014, Jonathan Morton wrote:

> On 28 May, 2014, at 12:39 pm, Hal Murray wrote:
>
>>> in non discarding scheduling total delay is conserved,
>>> irrespective of the scheduling discipline
>>
>> Is that true for all backplane/switching topologies?
>
> It's a mathematical truth for any topology that you can reduce to a black box 
> with one or more inputs and one output, which you call a "queue" and which 
> *does not discard* packets.  Non-discarding queues don't exist in the real 
> world, of course.
>
> The intuitive proof is that every time you promote a packet to be transmitted 
> earlier, you must demote one to be transmitted later.  A non-FIFO queue tends 
> to increase the maximum delay and decrease the minimum delay, but the average 
> delay will remain constant.

True, but not all traffic is equal. delays in DNS and short TCP connections are 
far more noticable than the same total delay in long TCP connections (because 
the users tend to be serialized on the short connections while doing the long 
ones in parallel)

so queueing that favors short duration flows over long duration ones still 
averages the same latency delay overall, but the latency/connection_length will 
remain very small in all cases instead lf letting this ratio become very large 
for short connections.

David Lang

>>> 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.
>>
>> The simplest interesting case is where you have two input lines feeding the
>> same output line.
>>
>> AQM may not be the best solution, but you have to do something.  Dropping any
>> packet that won't fit into the buffer is probably simplest.
>
> The relative bandwidths of the input(s) and output(s) is also relevant.  You *can* have a saturated 5-port switch with no dropped packets, even if one of them is a common uplink, provided the uplink port has four times the bandwidth and the traffic coming in on it is evenly distributed to the other four.
>
> Which yields you the classic tail-drop FIFO, whose faults are by now well documented.  If you have the opportunity to do something better than that, you probably should.  The simplest improvement I can think of is a *head*-drop FIFO, which gets the congestion signal back to the source quicker.  It *should* I think be possible to do Codel at 10G (if not 40G) by now; whether or not it is *easy* probably depends on your transistor budget.
>
> - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

  reply	other threads:[~2014-05-28 18:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28  9:39 Hal Murray
2014-05-28 11:00 ` Jonathan Morton
2014-05-28 18:56   ` David Lang [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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
2014-05-28 18:44     ` David Lang

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=alpine.DEB.2.02.1405281146090.32611@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=hmurray@megapathdsl.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