Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed

[Sebastian Moeller <moeller0@gmx.de>]

> On Apr 26, 2018, at 16:42, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> I really liked you initial idea to make the threshold when to segment a superpacket based on the duration that packet would hogg the wire/shaper, as that gives an intuitive feel for the worst case inter-flow latency induced. Especially this would allow on many links intermediate sized superpackets to survive fine while turning 64K "oil-tankers" into a fleet of speedboats ;). This temporal threshold would also automatically solve the higher bandwdth cases elegantly. What was the reason to rip that out again?
> 
> It probably had something to do with needing to scale that threshold with the number of active flows, which isn't necessarily known at enqueue time with sufficient accuracy to be relevant at dequeue, in order to be able to guarantee a given peak inter-flow induced latency.  Unconditional segmentation made the question easy and didn't seem to have very much effect on the CPU (at the link rates we were targeting).
> 
> It might still be reasonable to assume the number of active flows won't change *much* between enqueue and dequeue.  So then we could set the threshold at, say, half the Codel target divided by the number of active flows plus one.

	I am too simple minded for that, I find it more intuitive (albeit less clever) to simply allow the user to give a limit for acceptable superpacket serialization delay independent of the number of bulk flows. That effectively is a configurable bandwidth threshold, once this works reasonably well, optional cleverness might be nice to add ;)

Best Regards
	Sebastian


> 
> - Jonathan Morton
>