[Codel] About Packet Drop in Codel

[Codel] About Packet Drop in Codel

[divya singla]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

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.
is there anybody who also thinks the same or is it in my case only?
Am i doing something wrong?

[-- Attachment #2: Type: text/html, Size: 339 bytes --]

Re: [Codel] About Packet Drop in Codel

[Richard Scheffenegger]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

Hi Divya,

is this really the only metric that you are interested in?

What kind of topology and traffic pattern are you using? I would suggest to read the recent posts by Dave Taht around this topic (perhaps looking into ns-3, as the more modern simulator, featuring RRUL test), and also not focus too much on packet loss.


I would think, that the average and induced latency your RED TCP sessions are expiriencing were higher than those governed by CoDel?

What was the effective goodput, and the utilization of  your bottleneck link?

Qualitatively - I'd expect slightly sooner, and sometimes (within an RTT - so not much problem for TCP CC) more losses with Codel (depending where they happen) in order for it to get induced latency under control. But quantitatively, the losses shouldn't be orders of magnitude more, only so much to have a well running control loop there.

Best regards,
  Richard


  ----- Original Message ----- 
  From: divya singla 
  To: codel@lists.bufferbloat.net 
  Sent: Thursday, February 26, 2015 6:12 PM
  Subject: [Codel] About Packet Drop in Codel


  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.
  is there anybody who also thinks the same or is it in my case only?
  Am i doing something wrong?




------------------------------------------------------------------------------


  _______________________________________________
  Codel mailing list
  Codel@lists.bufferbloat.net
  https://lists.bufferbloat.net/listinfo/codel

[-- Attachment #2: Type: text/html, Size: 3413 bytes --]

Re: [Codel] About Packet Drop in Codel

[Stephen Hemminger]

On Thu, 26 Feb 2015 19:32:58 +0100
"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.

Re: [Codel] About Packet Drop in Codel

[divya singla]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

please explain me this also:

how codel controls the delay like it drops the packet when it spends more
time than target and after that it will be retransmitted.
So in case of retransmission and all, i think delay should be more. isn't
it?


Next , How  does UDP react like tcp adjusts its rate when there is packet
loss and UDP?

On Fri, Feb 27, 2015 at 4:44 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Thu, 26 Feb 2015 19:32:58 +0100
> "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.
>

[-- Attachment #2: Type: text/html, Size: 1294 bytes --]

Re: [Codel] About Packet Drop in Codel

[Rick Jones]

On 03/02/2015 09:43 AM, divya singla wrote:
> please explain me this also:
>
> how codel controls the delay like it drops the packet when it spends
> more time than target and after that it will be retransmitted.
> So in case of retransmission and all, i think delay should be more.
> isn't it?

At the risk of typing beyond my understanding...

CoDel is expected to be deployed in situations where the maximum 
possible queuing is rather large at a bottleneck link.  Probably several 
multiples of the RTT in time/size.  It is a response to a belief that 
throwing more and more memory at queues and holding that every packet is 
sacred is a good thing.  Consider what would/could happen with such 
queues without CoDel and what that would mean to delay.

> Next , How  does UDP react like tcp adjusts its rate when there is
> packet loss and UDP?

UDP doesn't.  The *application* using UDP is expected too, just as 
applications using UDP have been expected to do "the right things" from 
the beginning.

rick jones

>
> On Fri, Feb 27, 2015 at 4:44 AM, Stephen Hemminger
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>
>     On Thu, 26 Feb 2015 19:32:58 +0100
>     "Richard Scheffenegger" <rscheff@gmx.at <mailto: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.
>
>
>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>

Re: [Codel] About Packet Drop in Codel

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

The delay to that individual packet's data may be increased, but the queue
length is reduced by triggering TCP's congestion control, reducing the
delay to other packets by (in aggregate) a much larger amount.

And with ECN marking, even the victim packet is not delayed extra.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 359 bytes --]

Re: [Codel] About Packet Drop in Codel

[divya singla]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

okay and can you tell about UDP ?
UDP does not respond to packet loss.Then  it would be  advantage for UDP,i
guess.


On Mon, Mar 2, 2015 at 11:52 PM, Jonathan Morton <chromatix99@gmail.com>
wrote:

> The delay to that individual packet's data may be increased, but the queue
> length is reduced by triggering TCP's congestion control, reducing the
> delay to other packets by (in aggregate) a much larger amount.
>
> And with ECN marking, even the victim packet is not delayed extra.
>
> - Jonathan Morton
>

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

Re: [Codel] About Packet Drop in Codel

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

With UDP, you're at the mercy of the application using it. With TCP, you're
merely at the mercy of the operating system.

AQM acts on UDP packets in the same way as TCP packets - in fact it can't
tell them apart. So any application which detects and responds to UDP
packet loss in the same way as TCP does, will back off just the same.

In practice, UDP is used for several different types of application:

- simple request response, such as DNS and NTP, where eliminating TCP's
connection setup overhead is important. In any case, TCP's congestion
control doesn't get a chance to do any good on such s short-lived
connection. Packet loss in this situation is tolerated by retry, with
exponential backoff as an alternative congestion control measure.

- latency sensitive and often isochronous (inelastic) flows like VoIP.
Packet loss may lead to a loss of quality, but there is little the
application can do to reduce its loss except dropping the call completely.

- as a way to implement delay sensitive and pacific congestion control
algorithms, as in uTP.

A flow isolation system, such as that in fq_codel, will often leave UDP
flows alone completely, because they tend not to be the ones using the bulk
of the bandwidth. Conversely, if a single UDP flow was responsible for the
congestion, it would let the other traffic bypass it. This is why fq_codel
is better than just plain codel, if you can get it.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1598 bytes --]

Re: [Codel] About Packet Drop in Codel

[divya singla]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

But Sir i heard that UDP does not respond to congestion.Even though its
packets are lost, it keeps sending packets at the same rate(unlike tcp)

-- please answer this too:
 Does codel implement concept of marking(ECN)  in ns2?


On Tue, Mar 3, 2015 at 12:37 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

> With UDP, you're at the mercy of the application using it. With TCP,
> you're merely at the mercy of the operating system.
>
> AQM acts on UDP packets in the same way as TCP packets - in fact it can't
> tell them apart. So any application which detects and responds to UDP
> packet loss in the same way as TCP does, will back off just the same.
>
> In practice, UDP is used for several different types of application:
>
> - simple request response, such as DNS and NTP, where eliminating TCP's
> connection setup overhead is important. In any case, TCP's congestion
> control doesn't get a chance to do any good on such s short-lived
> connection. Packet loss in this situation is tolerated by retry, with
> exponential backoff as an alternative congestion control measure.
>
> - latency sensitive and often isochronous (inelastic) flows like VoIP.
> Packet loss may lead to a loss of quality, but there is little the
> application can do to reduce its loss except dropping the call completely.
>
> - as a way to implement delay sensitive and pacific congestion control
> algorithms, as in uTP.
>
> A flow isolation system, such as that in fq_codel, will often leave UDP
> flows alone completely, because they tend not to be the ones using the bulk
> of the bandwidth. Conversely, if a single UDP flow was responsible for the
> congestion, it would let the other traffic bypass it. This is why fq_codel
> is better than just plain codel, if you can get it.
>
> - Jonathan Morton
>

[-- Attachment #2: Type: text/html, Size: 2311 bytes --]

Re: [Codel] About Packet Drop in Codel

[Rick Jones]

On 03/03/2015 10:12 AM, divya singla wrote:
> But Sir i heard that UDP does not respond to congestion.Even though its
> packets are lost, it keeps sending packets at the same rate(unlike tcp)

UDP does not and never has.  All it has ever done is send what the 
application has told it to send as the application tells it to. The 
*application* using UDP is expected to respond to congestion.

rick jones

>
> -- please answer this too:
>   Does codel implement concept of marking(ECN)  in ns2?
>
>
> On Tue, Mar 3, 2015 at 12:37 AM, Jonathan Morton <chromatix99@gmail.com
> <mailto:chromatix99@gmail.com>> wrote:
>
>     With UDP, you're at the mercy of the application using it. With TCP,
>     you're merely at the mercy of the operating system.
>
>     AQM acts on UDP packets in the same way as TCP packets - in fact it
>     can't tell them apart. So any application which detects and responds
>     to UDP packet loss in the same way as TCP does, will back off just
>     the same.
>
>     In practice, UDP is used for several different types of application:
>
>     - simple request response, such as DNS and NTP, where eliminating
>     TCP's connection setup overhead is important. In any case, TCP's
>     congestion control doesn't get a chance to do any good on such s
>     short-lived connection. Packet loss in this situation is tolerated
>     by retry, with exponential backoff as an alternative congestion
>     control measure.
>
>     - latency sensitive and often isochronous (inelastic) flows like
>     VoIP. Packet loss may lead to a loss of quality, but there is little
>     the application can do to reduce its loss except dropping the call
>     completely.
>
>     - as a way to implement delay sensitive and pacific congestion
>     control algorithms, as in uTP.
>
>     A flow isolation system, such as that in fq_codel, will often leave
>     UDP flows alone completely, because they tend not to be the ones
>     using the bulk of the bandwidth. Conversely, if a single UDP flow
>     was responsible for the congestion, it would let the other traffic
>     bypass it. This is why fq_codel is better than just plain codel, if
>     you can get it.
>
>     - Jonathan Morton
>
>
>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>

Re: [Codel] About Packet Drop in Codel

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

In fact, this is the fundamental point of AQM. Dropping (or marking)
occasional packets in order to signal congestion to the hosts, which then
know to back offand avoid filling the buffer.

A related fundamental point is that a full buffer means induced delay -
potentially lots of it.

Missing those fundamental points will make it very difficult for you to
conduct any sort of coherent research into AQM.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 497 bytes --]

Re: [Codel] About Packet Drop in Codel

[David Collier-Brown]

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