Re: [Cake] A few puzzling Cake results

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonas Mårtensson <martensson.jonas@gmail.com> writes:

> On Tue, Apr 17, 2018 at 2:22 PM, Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
>
>> Y via Cake <cake@lists.bufferbloat.net> writes:
>>
>> > From: Y <intruder_tkyf@yahoo.fr>
>> > Subject: Re: [Cake] A few puzzling Cake results
>> > To: cake@lists.bufferbloat.net
>> > Date: Tue, 17 Apr 2018 21:05:12 +0900
>> >
>> > Hi.
>> >
>> > Any certain fomula of fq_codel flow number?
>>
>> Well, given N active bulk flows with packet size L, and assuming the
>> quantum Q=L (which is the default for FQ-CoDel at full-size 1500-byte
>> packets), the maximum rate for a sparse flow, R_s, is bounded by
>>
>> R_s < R / ((L/L_s)(N+1))
>>
>> Where R is the link rate and L_s is the packet size of the sparse flow.
>> This assumes that the sparse flow has constant spacing between its
>> packets, which is often the case for a VoIP flow...
>
>
> For 10-Mbit/s link rate and 32 bulk flows with 1500-byte packets this
> formula gives roughly 25 pps (packets per second) as maximum for a sparse
> flow. A VoIP flow is typically 50 pps (20 ms voice payload).
>
> Does this mean that cake sets the quantum to less than 750 bytes for a
> 10-Mbit/s link?

Yup, it sets it to 305 bytes. I added this to the stats output in the
latest git version.

> Do you see any benefit with cake diffserv if you increase the number
> of flows?

I have not been able to see a benefit of diffserv mode for the VoIP
flow. Even at 128 flows there's no difference; and beyond that my
testbed can't keep up anymore... Diffserv mode doesn't hurt either,
though... It may simply be that its primary utility is to allow flows to
*de*prioritise themselves...

> Does the adjusted quantum also explain the "*way* higher" TCP RTT for
> cake? How?

Nope, don't think so. I think the difference in TCP RTT is due to
differences in the CoDel implementation.

-Toke