Thanks to all for the input! Toke, Jonathan -- you were absolutely right!
I sent this email because I -- I thought it inconceivable that "just" setting a single bandwidth tunable could both: * enforce / properly rate limit inbound and outbound traffic * and, simultaneously, *prevent* non-bulk streams from seeing latency. I know, I know. You've been telling everyone who will listen that cake works. I just couldn't wrap my head around that possibly being true -- But boy, I was wrong. cake is as amazing as you say. I got rid of my complex rules and swapped them out for: cake bandwidth 60Mbit besteffort internet nat ethernet Then I monitored my xbox game latency as I streamed videos, etc, to generate bulk traffic. There was no observable latency or jitter, and I did not see any issues during actual game-play either. Once again, I am truly amazed. Thank you to everyone who worked on this impressive tool! Ubuntu 19.10 finally ships with all the pieces in place (kernel, new iproute2 package) -- so cake is now finally usable "out of the box" for the average linux user. I look forward to telling everyone I know to have some cake! :) Thanks, Dan On Fri, Feb 14, 2020 at 9:18 AM Michael Richardson <[email protected]> wrote: > > > Daniel Sterling <[email protected]> wrote: > > I am looking for input / discussion on how to achieve: > > * on a "regular" SoHo network > > > * first and foremost, to the exclusion of all other goals, consistent > > low-latency for non-bulk streams from particular endpoints; usually > > those streams are easily identified and differentiated from all other > > streams based on UDP/TCP port number, > > > * and assuming the identified and prioritized streams behave > > themselves and stay non-bulk, decent throughput for all other traffic. > > > > That is to say, some endpoints are more important than others; and > > moreover some apps on some endpoints are most important. > > Distinguishing between apps is difficult in IPv4. > IPv6 lets you naturally have many IP addresses, so it could be easier, but > apps need to be taught to use "their" source address. Or OSes need to force > them, or "containers". > > In the specific case of a single network, I'd just do static DHCPv4 > allocation and change the parameters on the qos scripts. > > In general, I'd want RFC8520 to announce the type of the device, and suggest > a particular class of service. In the old days, we'd be talking RSVP to > signal desired Diffserv behaviour ("DiffEdge"), but that specification did > not, unfortunately, gain market momentum. > > > I put a linux laptop between CPE (WAN) and LAN. AT&T fiber in my case, > > 100+ mbit up and down. > > It's not a terrible thing to use a laptop, but at 100Mb/s, an Omnia Turris or > equivalenet running latest OpenWRT may be more foolproof. (I'm always the > fool) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
