[Codel] hard limit codel

[Codel] hard limit codel

[Dave Taht]

I reserve comment until after the liquor wears off:

http://www.iaeng.org/publication/IMECS2015/IMECS2015_pp615-619.pdf

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Codel] hard limit codel

[Kathleen Nichols]

...otherwise known as "limiting the size of buffers"?

Go ahead, Dave, surely liquor doesn't keep you from laughing.

Gee, I thought the code was copyrighted.

On 4/15/15 8:23 PM, Dave Taht wrote:
> I reserve comment until after the liquor wears off:
> 
> http://www.iaeng.org/publication/IMECS2015/IMECS2015_pp615-619.pdf
> 

Re: [Codel] hard limit codel

[Rich Brown]

Dave,

> I reserve comment until after the liquor wears off:
> 
> http://www.iaeng.org/publication/IMECS2015/IMECS2015_pp615-619.pdf

Please don't fisk this. The paper is *way* too long to be worth a sentence-by-sentence refutation of every inaccuracy or outright wrong-headed understanding of Codel... :-)

Instead, rejoice in the SpaceX launch. Was it wonderful?

Rich

> -- 
> Dave Täht
> Open Networking needs **Open Source Hardware**
> 
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel

Re: [Codel] hard limit codel

[Eric Dumazet]

Oh well. Today really was a bad day for me.

Fortunately, tomorrow is almost there. 

On Wed, 2015-04-15 at 21:16 -0700, Kathleen Nichols wrote:
> ...otherwise known as "limiting the size of buffers"?
> 
> Go ahead, Dave, surely liquor doesn't keep you from laughing.
> 
> Gee, I thought the code was copyrighted.
> 
> On 4/15/15 8:23 PM, Dave Taht wrote:
> > I reserve comment until after the liquor wears off:
> > 
> > http://www.iaeng.org/publication/IMECS2015/IMECS2015_pp615-619.pdf
> > 
> 
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel

Re: [Codel] [Cake] hard limit codel

[Toke Høiland-Jørgensen]

Rich Brown <richb.hanover@gmail.com> writes:

> Please don't fisk this. The paper is *way* too long to be worth a
> sentence-by-sentence refutation of every inaccuracy or outright
> wrong-headed understanding of Codel... :-)

I think this paragraph pretty much sums it up:

"Actually, the throughput of hard limit CoDel is signifi- cantly lower
than the original CoDel only when the RTT is large (500ms), the
bandwidth is high (64 Mbps) with only one TCP flow, in which case the
throughput is only 4.1 Mbps, 63% lower than that of the original CoDel.
Though it may seem to be a significant loss, we argue that it is
acceptable because even in the worst case, a bit rate of 4 Mbps is
sufficient to support today’s 720p videos. The link utilization is much
higher when either of the three conditions changes."

Surely, 4Mbps is enough for everybody?



I'll add, though, that I have seen the sentiment expressed here ("we
need to limit the max delay of CoDel") in other contexts. And, well,
delay spikes *is* a problem!

-Toke

Re: [Codel] [Cake] hard limit codel

[Jonathan Morton]

> On 16 Apr, 2015, at 14:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> I'll add, though, that I have seen the sentiment expressed here ("we
> need to limit the max delay of CoDel") in other contexts. And, well,
> delay spikes *is* a problem!

Yes, they are.

But in general AQM can’t be used to solve that problem without also suffering poor throughput; combining AQM with FQ *does* solve it.  Just like FQ is unfair to single flows competing against a swarm, but classifying the swarm traffic into a separate traffic class fixes that problem too.

Which of course is why cake uses AQM, FQ *and* Diffserv, all at once.

The linked paper didn’t measure HLC against fq_codel, even though they mention fq_codel.  That’s a major shortcoming.

 - Jonathan Morton

Re: [Codel] [Cake] hard limit codel

[Andrew McGregor]

Of course it fails at high RTT.  Unfortunately, long RTTs are pretty
common... for almost anything EXCEPT VIDEO.  Video, on the other hand,
is almost always served a) by application paced servers and b) over
the shortest RTT available.  So video isn't even a question for
high-RTT evaluations.  Even the upload stream from a VC client (not
usually TCP at all in the first place) is not usually going half way
round the world.

On Thu, Apr 16, 2015 at 10:00 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 16 Apr, 2015, at 14:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> I'll add, though, that I have seen the sentiment expressed here ("we
>> need to limit the max delay of CoDel") in other contexts. And, well,
>> delay spikes *is* a problem!
>
> Yes, they are.
>
> But in general AQM can’t be used to solve that problem without also suffering poor throughput; combining AQM with FQ *does* solve it.  Just like FQ is unfair to single flows competing against a swarm, but classifying the swarm traffic into a separate traffic class fixes that problem too.
>
> Which of course is why cake uses AQM, FQ *and* Diffserv, all at once.
>
> The linked paper didn’t measure HLC against fq_codel, even though they mention fq_codel.  That’s a major shortcoming.
>
>  - Jonathan Morton
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel

Re: [Codel] [Cake] hard limit codel

[Kathleen Nichols]

You are taking this much too seriously. This was written in order to
write a
paper. There is no study of the "problem" just a presentation of the
"solution".

They probably even submitted a patent.

On 4/16/15 5:00 AM, Jonathan Morton wrote:
> 
>> On 16 Apr, 2015, at 14:50, Toke Høiland-Jørgensen <toke@toke.dk>
>> wrote:
>> 
>> I'll add, though, that I have seen the sentiment expressed here
>> ("we need to limit the max delay of CoDel") in other contexts. And,
>> well, delay spikes *is* a problem!
> 
> Yes, they are.
> 
> But in general AQM can’t be used to solve that problem without also
> suffering poor throughput; combining AQM with FQ *does* solve it.
> Just like FQ is unfair to single flows competing against a swarm, but
> classifying the swarm traffic into a separate traffic class fixes
> that problem too.
> 
> Which of course is why cake uses AQM, FQ *and* Diffserv, all at
> once.
> 
> The linked paper didn’t measure HLC against fq_codel, even though
> they mention fq_codel.  That’s a major shortcoming.
> 
> - Jonathan Morton
> 
> _______________________________________________ Codel mailing list 
> Codel@lists.bufferbloat.net 
> https://lists.bufferbloat.net/listinfo/codel
> 

Re: [Codel] [Cake] hard limit codel

[Toke Høiland-Jørgensen]

Kathleen Nichols <nichols@pollere.com> writes:

> You are taking this much too seriously. This was written in order to
> write a paper.

Gotta love "publish or perish" :)


To their credit, getting a whole paper out of a ten-line patch is not
too shabby... :P

-Toke

Re: [Codel] [Cake] hard limit codel

[Kathleen Nichols]

Yeah, clearly writing papers and getting patents is the most important
thing.
The rest of us can all go home now. Oh, wait, I am home.

If ever proof were needed that there are too many conferences with too
little
serious review...

On 4/16/15 8:02 AM, Toke Høiland-Jørgensen wrote:
> Kathleen Nichols <nichols@pollere.com> writes:
> 
>> You are taking this much too seriously. This was written in order to
>> write a paper.
> 
> Gotta love "publish or perish" :)
> 
> 
> To their credit, getting a whole paper out of a ten-line patch is not
> too shabby... :P
> 
> -Toke
>