<div dir="ltr">Sanity check: the active flow list in Jim's work is very compact <div>as it counts only the flows with a packet in the queue.</div><div>So you need to read that paragraph with this in mind. Then you'll agree :)</div><div><br></div><div>I have a reasonable proof that what cake is doing is truly sane. </div><div>You just need to compare cake to Jim's monumental work and see that it fits in that class.</div><div>Then you sleep well as I do.</div><div><br></div><div>don't pay too much attention to admission control.</div><div>Even if it makes sense to me. In case of overload, i.e. too many flows in the system for too long,</div><div>nobody is happy.</div><div>Accepting more flows is making no one happier. The new one included.</div><div>So instead of dropping one random packet, dropping new SYN packets seems like the bouncer telling </div><div>you "guys: there is no room left". And it works well in the home.</div><div><br></div><div><br></div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 4:42 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jan 4, 2018 at 7:23 AM, Luca Muscariello<br>
<<a href="mailto:luca.muscariello@gmail.com">luca.muscariello@gmail.com</a>> wrote:<br>
> I think the closest scheduler to Cake is this one, if I have to compare:<br>
><br>
> <a href="https://team.inria.fr/rap/files/2013/12/KOR05.pdf" rel="noreferrer" target="_blank">https://team.inria.fr/rap/<wbr>files/2013/12/KOR05.pdf</a><br>
<br>
</span>Try as I might, at workloads that I've been able to create (I did just<br>
add 10GigE capability to my testbed), it's seemingly nearly impossible<br>
to have more than a few hundred flows in memory (compared to<br>
potentially thousands actually active), and it's unclear how to go<br>
about thinking about it sanely.This tends to point to cake's 8 way set<br>
associativity as being overkill, but haven't got around to trying<br>
higher bandwidths, lower target RTTs, or, as I said, higher<br>
bandwidths.<br>
<br>
'course, while I disagree with this statement in the paper, and do<br>
care a lot about handling overload sanely,<br>
<br>
"In overload, it is necessary to apply per-flow admission control in<br>
order to preserve good performance for admitted flows. Note that no<br>
scheduler can avoid drastic performance degradation when offered<br>
traffic exceeds capacity. PDRR has the advantage of allowing"<br>
<br>
I wish I had reasonable proof that what we do in cake is truly sane,<br>
or had some curve to apply to flows per the available bandwidth.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> J. Roberts et al. Implicit Service Differentiation using Deficit Round<br>
> Robin, In Proc of ITC 2005.<br>
><br>
> Luca<br>
><br>
><br>
> On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>><br>
> wrote:<br>
>><br>
>> > On 4 Jan, 2018, at 4:29 pm, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br>
>> ><br>
>> > This popped up in my Google Scholar notifications:<br>
>> ><br>
>> > <a href="https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf" rel="noreferrer" target="_blank">https://atlas.informatik.uni-<wbr>tuebingen.de/~menth/papers/<wbr>Menth18b.pdf</a><br>
>> ><br>
>> > Basically, they are proposing to permit a queue to accumulate a larger<br>
>> > deficit while empty to allow light users to achieve the same throughput<br>
>> > as heavy users (users being an endpoint with potentially multiple<br>
>> > flows).<br>
>> ><br>
>> > Not sure how useful this really is, but it's somewhat related to Cake's<br>
>> > src/dst user fairness feature, so may be of interest.<br>
>><br>
>> They're trying to solve the same problem as DRR++ does, not the same one<br>
>> as Triple Isolation does.<br>
>><br>
>> As a result, they've basically proposed a bugfix to the original DRR (ie.<br>
>> you should keep replenishing the deficit until it saturates, even if the<br>
>> queue is temporarily empty), without gaining the full benefit of DRR++.<br>
>><br>
>> Not interesting at all.<br>
>><br>
>>  - Jonathan Morton<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Cake mailing list<br>
>> <a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Cake mailing list<br>
> <a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
><br>
<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: <a href="tel:1-669-226-2619" value="+16692262619">1-669-226-2619</a><br>
</div></div></blockquote></div><br></div>