Re: [Cake] Enforcing video quality question

Tue, 23 Feb 2021 03:15:28 -0800

Here is the toy QoS solution for linux, which is a simplified version of the one I uses successfully on my home network. It uses quite a few scheduler modules - sch_htb, act_connmark, em_meta etc - that may not load automatically, so they may need to be listed in /etc/modules. 

Toke, thanks for agreeing to let the attachment through.

John

On 19/02/2021 19:04, John Sager wrote:
Yes. The marks are set on egress so you can select on inside IP address, port, protocol - in fact many characteristics that iptables rules can test for. I'll put together a toy iptables rules file and a toy script with the necessary tc commands. It'll take me a few days though as I'm busy with other stuff currently. 

PS does the cake list allow attachments? It will be a small zip file.

John

On 19/02/2021 15:02, Peter Lepeska wrote:

Hi John
Does this result in the ability to set per internal host max ingress bandwidth? If so, any chance you can share a snippet of a script? I will be trying to reproduce your setup. 

Thank you!

Peter
On Fri, Feb 19, 2021 at 7:16 AM John Sager <[email protected] <mailto:[email protected]>> wrote: 

    That's basically what I do. I set marks on outgoing traffic in the mangle
    table which are copied to connmark before egress. Then on ingress the
    connmark is restored to the packet and punted to ifb0 using 'action
    connmark
    action mirred egress redirect dev $IFB' as an ingress filter on the
    incoming
    interface (ppp0 in my case). Then I have HTB classes on ifb0 which set rate     limits for different traffic classes indicated by the marks. I have only 6 
    traffic classes (I bundle all video into one class), but as marks are 32
    bits wide there is lots of scope for classes for individual IP addresses.

    John

    On 18/02/2021 19:28, Toke Høiland-Jørgensen via Cake wrote:
     > Peter Lepeska <[email protected] <mailto:[email protected]>>
    writes:
     >
     >> A user on the OpenWrt forum suggested hashlimit rules supported by
     >> iptables. How does that idea sound to you?
     >
     > That will result in a cliff-edge policer (i.e., as soon as a device goes 
     > over its limits it will see every packet get dropped). This doesn't
     > interact too well with the burstiness of TCP, so you'll likely get
     > erratic behaviour of the traffic if you do that. Doing the same thing
     > with HTB means the router will queue+shape each class (and with FQ-CoDel      > on the leaves, you'll get a nice AQM behaviour as well), so that will be 
     > smoother and less prone to bloat :)
     >
     > -Toke
     > _______________________________________________
     > Cake mailing list
     > [email protected] <mailto:[email protected]>
     > https://lists.bufferbloat.net/listinfo/cake
     >
    _______________________________________________
    Cake mailing list
    [email protected] <mailto:[email protected]>
    https://lists.bufferbloat.net/listinfo/cake


_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

<<attachment: linux_toy_qos.zip>>

_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to