CoDel AQM discussions
 help / color / mirror / Atom feed
From: David Collier-Brown <davec-b@rogers.com>
To: Richard Scheffenegger <rscheff@gmx.at>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] About Packet Drop in Codel
Date: Fri, 27 Feb 2015 20:57:40 -0500	[thread overview]
Message-ID: <54F12094.5040200@rogers.com> (raw)
In-Reply-To: <mailman.153549.1425025588.1815.codel@lists.bufferbloat.net>

On 02/27/2015 03:26 AM, From: Stephen Hemminger <stephen@networkplumber.org>
"Richard Scheffenegger" <rscheff@gmx.at> wrote:
>> Hi Members,
>> i am doing M.tech and my research topic is AQM.
>> i tried to run codel with ns-2.35.
>> And i found packet loss is more in codel as compared to RED.
> More packet loss is no necessarily a bad thing.
> You need to measure throughput and latency together.

TCP isn't a normal queuing system: when it gets close to it's capacity, 
it throttles the sender, so that the system isn't driven into the load 
range where latency goes up and (effective[1]) throughput plummets.

Instead, it does congestion *avoidance*, rather like deadlock avoidance, 
and levels off total bandwidth to something very close but just below to 
the link's capacity. Dropping a packet forces the sender to reduce their 
offered load and then try to increase it slowly until they exceed the 
maximum and it drops another packet.

This is cool: instead of the latency vs load curve looking like "_/", it 
looks like "_", at something close to 99% bandwidth. Lovely low latency, 
near-maximum bandwidth.

--dave
--
[1. Effective throughput is what humans care about: x Mb/S.  If your 
data is delayed 30 seconds, theoretical throughput doesn't change, but 
frames from a movie are horribly delayed, and in effect, throughput is 
horrid. This too is something that TCP does well, and people like Van 
Jacobsen and Neil Gunther understand, but simplistic users of queuing 
theory don't]

I'm an ex-York University nerd and author, so if I can help in your 
efforts, drop me a line.

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain


       reply	other threads:[~2015-02-28  1:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.153549.1425025588.1815.codel@lists.bufferbloat.net>
2015-02-28  1:57 ` David Collier-Brown [this message]
2015-02-26 17:12 divya singla
2015-02-26 18:32 ` Richard Scheffenegger
2015-02-26 23:14   ` Stephen Hemminger
2015-03-02 17:43     ` divya singla
2015-03-02 18:10       ` Rick Jones
2015-03-02 18:22       ` Jonathan Morton
2015-03-02 18:43         ` divya singla
2015-03-02 19:07           ` Jonathan Morton
2015-03-03 18:12             ` divya singla
2015-03-03 18:27               ` Rick Jones
2015-03-02 18:35       ` Jonathan Morton

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

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

  git send-email \
    --in-reply-to=54F12094.5040200@rogers.com \
    --to=davec-b@rogers.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=davecb@spamcop.net \
    --cc=rscheff@gmx.at \
    /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