[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