[Cake] Cake tin behaviour - discuss....

[David P. Reed]

I'll bite.
 
Assuming a lot of things (you seem to be a microsoft user, One Drive, so your OS's network stack isn't necessarily very good at all).
 
35/35 split.
 
Why?
 
THere are no "bursts" in the fundamental flows (disk transfer rates are far higher than 80 Mb/sec., so the only burstiness would come from OS schedulers on either end).
 
There should be next to zero queueing in the bottleneck, and without queue depth, best efforts and bulk are happy to sync to that share, and stable once sawtoothing around an average of 35.
 
What's more important is what studying this teaches us:
 
1. diffserv only makes a difference when queues are allowed to build in switches/routers. But the whole goal of cake is to make the queues zero length.
 
2. TCP's optimal state is to adjust rate to insure that there is no queueing delay *inside* the network. (Well, Kleinrock says it should be just under 1 packet's worth of delay at the bottleneck router, and a small fraction of 1 packet on each router that is not bottlenecked.
 
3. in terms of "end to end" control, diffserv is about the worst possible mechanism for creating "differentiated service". It is based on a very old (pre-Jacobson AIMD) idea about inter-networking sharing of capacity. Because Van finally demonstrated (unfortunately it didn't penetrate the transport layer thick skulls who invented diffserv) that when *sharing* a path's capacity, the work has to be done at the *endpoints* - simply adjusting the window size on the receive end can do it - to slow the sending rate to the point where the network buffering drops to a mean of < 1 packet at the bottleneck.
 
4. diffserv is an example of attempting to "put a function in the network" that cannot be provided fully (or much at all) by the network equipment. The function (differentiating service quality) requires attention at the TCP level, not the IP layer, with the receive end and the transmit end cooperating. As one of the creators of The End-to-end argument, this is why I continue to be frustrated at the whole "diffserv" effort, which has wasted decades of sporadic research projects, all failing. My co-author, Dave Clark, has an equally strong critique of diffserv - which is that there is no actual quantitative and *universal* definition of all its "code points" across all AS's in the network. And there never will be because of commercial considerations - even if there were *only* two code points for performance (high and low), there is no way to provide pricing incentives for routers to follow those definitions in ANY algorithm they use.
 
5. There is paradoxically intense interest in *router vendors* and network operators to have any "feature" they can seel that claims to improve game performance or create "very low latency" priceable service. You can see this in the current "5G" pitches about being able to robotically do telesurgery with sub millisecond latency (faster than the speed of light, note, but the marketers don't care about truth), merely because they have "5G magic". To have a differentiation for your company's Brand, all you have to say is "I support diffserv", and the rubes will buy it. It doesn't work, but you can blame it on the fact that the problem is the other networks on the path, not your fancy routers.
 
6. If you have a dozen independent flows through a particular router, most likely those flows will be between pairs that do not, and pragmatically cannot, know anything about the other flows sharing the bottleneck. Yet to achieve differentiation among flows, somehow each flow must adjust its *own* rate to share *unequally* with the other flows.
There is 0.000 information bits/second about the differentiated service requirements shared between the distinct flows.
 
7. Every time I or others have pointed out that diffserv cannot work, we get met with nasty, very nasty personal attacks. I even wrote a short paper about it, which was killed by the referees (apparently diffserv fanboys). So we generally have just waited for the idea to die.
But it just won't die. It has never worked. But that just makes people want to imagine it will work if they only hold their breath real deep and wish.
 
On Saturday, April 25, 2020 7:07am, "Kevin Darbyshire-Bryant" <kevin at darbyshire-bryant.me.uk> said:



> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> I’m confused as to what the ‘correct' behaviour should be under the
> following (real life) scenario:
> 
> Downstream VDSL wan link 79.5Mbit/s cake shaped to 77Mbit/s - diffserv4, so Bulk
> 4.8Mbit, Best effort 77Mbit, Video 38.5, Voice 19.
> 
> Download from ‘onedrive’ from 1 box, using 5 flows, classified as
> Bulk. Little other traffic going on, sits there at circa 70Mbit, no problem.
> 
> If I started another download on another box, say 5 flows, classified as Best
> Effort, what rates would you expect the Bulk & Best effort tins to flow at?
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200425/1bd32fd8/attachment.html>