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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Daniel Sterling <sterling.daniel@gmail.com> writes:

> Good day list,
>
> 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.
>
>
> In my case the traffic that needs to be low-latency no matter what is
> xbox FPS gaming traffic (Call of Duty UDP traffic is especially easy
> to prioritize, as it typically uses port 3075).
>
>
> How would you customize your network to achieve those goals?
>
>
> Here is what I have done; please provide any and all feedback:
>
>
> I put a linux laptop between CPE (WAN) and LAN. AT&T fiber in my case,
> 100+ mbit up and down.
>
> I've a tc script that drastically limits bandwidth for non-prioritized
> traffic (where priority is based on UDP/TCP port number).
>
> The theory is that this ensures prioritized traffic always has plenty
> of available bandwidth to send / receive data, and will never
> experience latency unless it's misbehaved / incorrectly classified.
>
>
>
> Here is what I have NOT done:
>
> I didn't use tc_cake WITHOUT adding a layer of port-based
> prioritization. On a typical SoHo network, I don't see how it would be
> possible to ensure xbox traffic never experiences latency w/o
> prioritizing streams *before* cake sees them.
>
>
> Does this make sense?

First off, on a 100mbit+ link, my guess would be that just putting in
cake with nothing other than a bandwidth parameter would achieve the
gaming performance you want. You'd need a *lot* of other bulk flows to
saturate the link to a point where the gaming traffic would no longer be
considered "sparse" (and thus get automatic priority).

That being said, if you do want to prioritise based on port numbers,
CAKE has its own built-in priority tiers (if you don't run it in
'besteffort' mode), and that does support filtering based on TC rules.
So you don't need the prio qdisc, you can just steer the traffic into
the high-prio cake tin...

-Toke