[Cake] Modification of DRR with deficit saving

[Dave Taht]

On Thu, Jan 4, 2018 at 7:23 AM, Luca Muscariello
<luca.muscariello at gmail.com> wrote:
> I think the closest scheduler to Cake is this one, if I have to compare:
>
> https://team.inria.fr/rap/files/2013/12/KOR05.pdf

Try as I might, at workloads that I've been able to create (I did just
add 10GigE capability to my testbed), it's seemingly nearly impossible
to have more than a few hundred flows in memory (compared to
potentially thousands actually active), and it's unclear how to go
about thinking about it sanely.This tends to point to cake's 8 way set
associativity as being overkill, but haven't got around to trying
higher bandwidths, lower target RTTs, or, as I said, higher
bandwidths.

'course, while I disagree with this statement in the paper, and do
care a lot about handling overload sanely,

"In overload, it is necessary to apply per-flow admission control in
order to preserve good performance for admitted flows. Note that no
scheduler can avoid drastic performance degradation when offered
traffic exceeds capacity. PDRR has the advantage of allowing"

I wish I had reasonable proof that what we do in cake is truly sane,
or had some curve to apply to flows per the available bandwidth.

>
> J. Roberts et al. Implicit Service Differentiation using Deficit Round
> Robin, In Proc of ITC 2005.
>
> Luca
>
>
> On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton <chromatix99 at gmail.com>
> wrote:
>>
>> > On 4 Jan, 2018, at 4:29 pm, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> >
>> > This popped up in my Google Scholar notifications:
>> >
>> > https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf
>> >
>> > Basically, they are proposing to permit a queue to accumulate a larger
>> > deficit while empty to allow light users to achieve the same throughput
>> > as heavy users (users being an endpoint with potentially multiple
>> > flows).
>> >
>> > Not sure how useful this really is, but it's somewhat related to Cake's
>> > src/dst user fairness feature, so may be of interest.
>>
>> They're trying to solve the same problem as DRR++ does, not the same one
>> as Triple Isolation does.
>>
>> As a result, they've basically proposed a bugfix to the original DRR (ie.
>> you should keep replenishing the deficit until it saturates, even if the
>> queue is temporarily empty), without gaining the full benefit of DRR++.
>>
>> Not interesting at all.
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Cake mailing list
>> Cake at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619