[Codel] About Packet Drop in Codel
David Collier-Brown
davec-b at rogers.com
Fri Feb 27 20:57:40 EST 2015
On 02/27/2015 03:26 AM, From: Stephen Hemminger <stephen at networkplumber.org>
"Richard Scheffenegger" <rscheff at 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 at spamcop.net | -- Mark Twain
More information about the Codel
mailing list