Re: [Bloat] is extremely consistent low-latency for e.g. xbox possible on SoHo networks w/o manual configuration?

[Daniel Sterling <sterling.daniel@gmail.com>]

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 <mcr@sandelman.ca> wrote:
>
>
> Daniel Sterling <sterling.daniel@gmail.com> 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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>