[Cake] diffserv based on firewall mark

[Cake] diffserv based on firewall mark

[ching lu]

My current config is HTB+fq-codel.

I deprioritize bittorrent traffic by marking related connections in
iptables (e.g. detect by port number) and route them to corresponding
HTB class and qdisc.

How can i archive the same goal using the cake qdisc?

I am aware that cake supports Diffserv by DSCP, but i think it is not applicable

1. i do not know to turn on DSCP for Winodws 8 (or above) client  <-
someone may know
2. ingress traffic do not have DSCP


Thanks in advance

Re: [Cake] diffserv based on firewall mark

[Jonathan Morton]

> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
> 
> I deprioritize bittorrent traffic by marking related connections in
> iptables (e.g. detect by port number) and route them to corresponding
> HTB class and qdisc.
> 
> How can i archive the same goal using the cake qdisc?

Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.

You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.

If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.

 - Jonathan Morton

Re: [Cake] diffserv based on firewall mark

[ching lu]

For egress, setting DSCP field should work.

iptables -> wan egress -> cake

But is it possible to set DSCP to 0x0 after cake's classification? i
do not know how ISP handle non-zero DSCP, there seems to be no
standard for this.


For ingress, DSCP field may not be set by network peer at all, and i
have multiple LAN interfaces

AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"

The trick of setting DSCP by iptables do not work because cake comes first

On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
>>
>> I deprioritize bittorrent traffic by marking related connections in
>> iptables (e.g. detect by port number) and route them to corresponding
>> HTB class and qdisc.
>>
>> How can i archive the same goal using the cake qdisc?
>
> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
>
> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
>
> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
>
>  - Jonathan Morton
>

Re: [Cake] diffserv based on firewall mark

[moeller0]

Hi,


> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
> 
> For egress, setting DSCP field should work.
> 
> iptables -> wan egress -> cake
> 
> But is it possible to set DSCP to 0x0 after cake's classification? i
> do not know how ISP handle non-zero DSCP, there seems to be no
> standard for this.

	Interestingly cake, at some point in the past offered exactly that functionality, but it got removed due to added complexity with very little practical applicability (and a potential layering violation, but one could equally argue that the current layering is partly sub-optimal/wrong and hence violating it to better reflect reality might be acceptable). But current cake does not offer this. If you are willing to daisy-chain two routers, you could run cake on the respective egress interfaces connecting both routers, and do the DSCP cleaning on the outer router’s egress interface toward the internet…

> 
> 
> For ingress, DSCP field may not be set by network peer at all, and i
> have multiple LAN interfaces
> 
> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> 
> The trick of setting DSCP by iptables do not work because cake comes first

	Hence Jonathan’s recommendation to make sure that cake follows iptables, by setting it up on egress interfaces only…

Best Regards
	Sebastian

> 
> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
>>> 
>>> I deprioritize bittorrent traffic by marking related connections in
>>> iptables (e.g. detect by port number) and route them to corresponding
>>> HTB class and qdisc.
>>> 
>>> How can i archive the same goal using the cake qdisc?
>> 
>> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
>> 
>> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
>> 
>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
>> 
>> - Jonathan Morton
>> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] diffserv based on firewall mark

[ching lu]

How to archive "cake follows iptables"? is it "wan ingress -> iptables
-> wifi egress/LAN egress -> ifb egress -> cake"?


On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> Hi,
>
>
>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
>>
>> For egress, setting DSCP field should work.
>>
>> iptables -> wan egress -> cake
>>
>> But is it possible to set DSCP to 0x0 after cake's classification? i
>> do not know how ISP handle non-zero DSCP, there seems to be no
>> standard for this.
>
>         Interestingly cake, at some point in the past offered exactly that functionality, but it got removed due to added complexity with very little practical applicability (and a potential layering violation, but one could equally argue that the current layering is partly sub-optimal/wrong and hence violating it to better reflect reality might be acceptable). But current cake does not offer this. If you are willing to daisy-chain two routers, you could run cake on the respective egress interfaces connecting both routers, and do the DSCP cleaning on the outer router’s egress interface toward the internet…
>
>>
>>
>> For ingress, DSCP field may not be set by network peer at all, and i
>> have multiple LAN interfaces
>>
>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
>>
>> The trick of setting DSCP by iptables do not work because cake comes first
>
>         Hence Jonathan’s recommendation to make sure that cake follows iptables, by setting it up on egress interfaces only…
>
> Best Regards
>         Sebastian
>
>>
>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>
>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
>>>>
>>>> I deprioritize bittorrent traffic by marking related connections in
>>>> iptables (e.g. detect by port number) and route them to corresponding
>>>> HTB class and qdisc.
>>>>
>>>> How can i archive the same goal using the cake qdisc?
>>>
>>> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
>>>
>>> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
>>>
>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
>>>
>>> - Jonathan Morton
>>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] diffserv based on firewall mark

[moeller0]

Hi Ching,

> On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> 
> How to archive "cake follows iptables"? is it “wan ingress -> iptables

Yes.

> -> wifi egress/LAN egress -> ifb egress -> cake”?

	Except that if you instantiate cake on the interface connecting to the outers LAN/WLAN side (lets call this LAN for short), cake will reside on that interfaces egress and hence you require no ifb for traffic coming in from the internet (as a plus cake will even without the fancy new deNAT options see the full intrnal IP addresses, useful for dual and triple isolation options). In the direction facing the internet you can instantiate cake on an ifb interface for LAN and then put the iptables DSCP cleaner on the WAN egress side (and the WAN ingress side, unless you trust your ISP to deliver reasonable DSCP values, which should be like never*)

Best Regards
	Sebastian

8) DSCP are only ever guranteed to be meaninful inside a dscp domain, and in reality your home net is a different domain from the ISP’s. It would have been nice if the DSCP field would have been separeted into 2 3bit fields, the first for the actual sender to request one of 8 differential classes and the other 3bits for the current domain to store its actually used DSCP bits. I claim the 3 bits should be enough for anybody  ;)


> 
> 
> On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
>> Hi,
>> 
>> 
>>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
>>> 
>>> For egress, setting DSCP field should work.
>>> 
>>> iptables -> wan egress -> cake
>>> 
>>> But is it possible to set DSCP to 0x0 after cake's classification? i
>>> do not know how ISP handle non-zero DSCP, there seems to be no
>>> standard for this.
>> 
>>        Interestingly cake, at some point in the past offered exactly that functionality, but it got removed due to added complexity with very little practical applicability (and a potential layering violation, but one could equally argue that the current layering is partly sub-optimal/wrong and hence violating it to better reflect reality might be acceptable). But current cake does not offer this. If you are willing to daisy-chain two routers, you could run cake on the respective egress interfaces connecting both routers, and do the DSCP cleaning on the outer router’s egress interface toward the internet…
>> 
>>> 
>>> 
>>> For ingress, DSCP field may not be set by network peer at all, and i
>>> have multiple LAN interfaces
>>> 
>>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
>>> 
>>> The trick of setting DSCP by iptables do not work because cake comes first
>> 
>>        Hence Jonathan’s recommendation to make sure that cake follows iptables, by setting it up on egress interfaces only…
>> 
>> Best Regards
>>        Sebastian
>> 
>>> 
>>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>>> 
>>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
>>>>> 
>>>>> I deprioritize bittorrent traffic by marking related connections in
>>>>> iptables (e.g. detect by port number) and route them to corresponding
>>>>> HTB class and qdisc.
>>>>> 
>>>>> How can i archive the same goal using the cake qdisc?
>>>> 
>>>> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
>>>> 
>>>> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
>>>> 
>>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
>>>> 
>>>> - Jonathan Morton
>>>> 
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>> 

Re: [Cake] diffserv based on firewall mark

[ching lu]

[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]

2016年10月12日 下午6:05，"moeller0" <moeller0@gmx.de>寫道：
>
> Hi Ching,
>
> > On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> >
> > How to archive "cake follows iptables"? is it “wan ingress -> iptables
>
> Yes.
>
> > -> wifi egress/LAN egress -> ifb egress -> cake”?
>
>         Except that if you instantiate cake on the interface connecting
to the outers LAN/WLAN side (lets call this LAN for short), cake will
reside on that interfaces egress and hence you require no ifb for traffic
coming in from the internet (as a plus cake will even without the fancy new
deNAT options see the full intrnal IP addresses, useful for dual and triple
isolation options). In the direction facing the internet you can
instantiate cake on an ifb interface for LAN and then put the iptables DSCP
cleaner on the WAN egress side (and the WAN ingress side, unless you trust
your ISP to deliver reasonable DSCP values, which should be like never*)

The bandwidth shaper won't work correctly if cake(s) are registered on
multiple LAN interface, ifb is necessary

e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi, and 50M
on LAN ?

I think the diffserv support of cake model is not suitable for home network
currently. The setup is much more complex


>
> Best Regards
>         Sebastian
>
> 8) DSCP are only ever guranteed to be meaninful inside a dscp domain, and
in reality your home net is a different domain from the ISP’s. It would
have been nice if the DSCP field would have been separeted into 2 3bit
fields, the first for the actual sender to request one of 8 differential
classes and the other 3bits for the current domain to store its actually
used DSCP bits. I claim the 3 bits should be enough for anybody  ;)
>
>
> >
> >
> > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> >> Hi,
> >>
> >>
> >>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
> >>>
> >>> For egress, setting DSCP field should work.
> >>>
> >>> iptables -> wan egress -> cake
> >>>
> >>> But is it possible to set DSCP to 0x0 after cake's classification? i
> >>> do not know how ISP handle non-zero DSCP, there seems to be no
> >>> standard for this.
> >>
> >>        Interestingly cake, at some point in the past offered exactly
that functionality, but it got removed due to added complexity with very
little practical applicability (and a potential layering violation, but one
could equally argue that the current layering is partly sub-optimal/wrong
and hence violating it to better reflect reality might be acceptable). But
current cake does not offer this. If you are willing to daisy-chain two
routers, you could run cake on the respective egress interfaces connecting
both routers, and do the DSCP cleaning on the outer router’s egress
interface toward the internet…
> >>
> >>>
> >>>
> >>> For ingress, DSCP field may not be set by network peer at all, and i
> >>> have multiple LAN interfaces
> >>>
> >>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> >>>
> >>> The trick of setting DSCP by iptables do not work because cake comes
first
> >>
> >>        Hence Jonathan’s recommendation to make sure that cake follows
iptables, by setting it up on egress interfaces only…
> >>
> >> Best Regards
> >>        Sebastian
> >>
> >>>
> >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <
chromatix99@gmail.com> wrote:
> >>>>
> >>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
> >>>>>
> >>>>> I deprioritize bittorrent traffic by marking related connections in
> >>>>> iptables (e.g. detect by port number) and route them to
corresponding
> >>>>> HTB class and qdisc.
> >>>>>
> >>>>> How can i archive the same goal using the cake qdisc?
> >>>>
> >>>> Modify your iptables rules to set the DSCP rather than a
kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as
CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will
pick that up appropriately.
> >>>>
> >>>> You also need to make sure Cake sees your packets *after* they’ve
been through the firewall, which generally means attaching it to the egress
port in each direction, not the ingress port.  You’ve probably already done
this, if you’re happy with your HTB setup.
> >>>>
> >>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi),
you should loop the inbound traffic through a common IFB device (and attach
Cake to that instead of the physical interfaces) to simplify configuration.
> >>>>
> >>>> - Jonathan Morton
> >>>>
> >>> _______________________________________________
> >>> Cake mailing list
> >>> Cake@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/cake
> >>
>

[-- Attachment #2: Type: text/html, Size: 6449 bytes --]

Re: [Cake] diffserv based on firewall mark

[Dave Taht]

I still defend the idea of the diffserv "squash" option cake once had.
It was essentially RFC compliant, simple to use, and because iptables
was too late on inbound, needed, no matter the layer violation.

Re: [Cake] diffserv based on firewall mark

[Kevin Darbyshire-Bryant]

On 12/10/16 11:21, Dave Taht wrote:
> I still defend the idea of the diffserv "squash" option cake once had.
> It was essentially RFC compliant, simple to use, and because iptables
> was too late on inbound, needed, no matter the layer violation.

Yeah I liked it too, so much I even thought about having a wash value 
per tin....which is a bit mad.  It wouldn't be that hard to revert the 
commit though and bring it up to date with the latest triple-isolate 
related tweaks should someone need it and be able to compile a bit of code.


cough cough cough, nothing to see here

https://github.com/kdarbyshirebryant/sch_cake/tree/squashwash
https://github.com/kdarbyshirebryant/tc-adv/tree/squashwash

nothing at all.  Move along.  Oooh look squirrels!

KDB


> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] diffserv based on firewall mark

[moeller0]

> On Oct 12, 2016, at 12:21 , Dave Taht <dave.taht@gmail.com> wrote:
> 
> I still defend the idea of the diffserv "squash" option cake once had.
> It was essentially RFC compliant, simple to use, and because iptables
> was too late on inbound, needed, no matter the layer violation.

As stated I am not sure whether that is a relevant layering violation to begin with… I believe that Jonathan found a way to have a dscp qdisc stacked on top of cake that does the squashing afterwards. I am uncertain whether that only worked in theory (so whether research stopped after finding the dscp qdisc) or whether that was actually tested to DTRT in allowing cake to use the internally set DSC values but re-map them to 0 before putting them on the wire?

Best Regards
	Sebastian

Re: [Cake] diffserv based on firewall mark

[moeller0]

Hi Ching?

> On Oct 12, 2016, at 12:17 , ching lu <lsching17@gmail.com> wrote:
> 
> 
> 2016年10月12日 下午6:05，"moeller0" <moeller0@gmx.de>寫道：
> >
> > Hi Ching,
> >
> > > On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> > >
> > > How to archive "cake follows iptables"? is it “wan ingress -> iptables
> >
> > Yes.
> >
> > > -> wifi egress/LAN egress -> ifb egress -> cake”?
> >
> >         Except that if you instantiate cake on the interface connecting to the outers LAN/WLAN side (lets call this LAN for short), cake will reside on that interfaces egress and hence you require no ifb for traffic coming in from the internet (as a plus cake will even without the fancy new deNAT options see the full intrnal IP addresses, useful for dual and triple isolation options). In the direction facing the internet you can instantiate cake on an ifb interface for LAN and then put the iptables DSCP cleaner on the WAN egress side (and the WAN ingress side, unless you trust your ISP to deliver reasonable DSCP values, which should be like never*)
> 
> The bandwidth shaper won’t work correctly if cake(s) are registered on multiple LAN interface, ifb is necessary
> 
> e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi, and 50M on LAN ?

	Yes that seems true, if you instantiate cake on br-lan (which I believe would be the relevant interface) you will shape both wireless and wired traffic, but most likely also internal traffic… But that can be solved by one more router/AP ;) 

> 
> I think the diffserv support of cake model is not suitable for home network currently.

	I have no real opinion on that, but could you explicitly state what short coming you see that is a showstopper? DSCP cleaning on ingress is BTW not really required to happen before cake, as long as cake is set to besteffort it will ignore DSCP markings anyway, and if you want to re-map/re-classify packets vie DSCP on ingress you are pretty much out of scope for a typical home network. Cleaning up on egress, as to not leak internal configuration to the upstream seems indeed sub-optimal, but cake is not alone in that regard…

> The setup is much more complex

	Well, DSCP setup is complex no matter how you slice and dice it… but maybe you have an idea what a shaper (like cake) could/should do to make this simpler?

Best Regards
	Sebastian

> 
> 
> 
> >
> > Best Regards
> >         Sebastian
> >
> > 8) DSCP are only ever guranteed to be meaninful inside a dscp domain, and in reality your home net is a different domain from the ISP’s. It would have been nice if the DSCP field would have been separeted into 2 3bit fields, the first for the actual sender to request one of 8 differential classes and the other 3bits for the current domain to store its actually used DSCP bits. I claim the 3 bits should be enough for anybody  ;)
> >
> >
> > >
> > >
> > > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> > >> Hi,
> > >>
> > >>
> > >>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
> > >>>
> > >>> For egress, setting DSCP field should work.
> > >>>
> > >>> iptables -> wan egress -> cake
> > >>>
> > >>> But is it possible to set DSCP to 0x0 after cake's classification? i
> > >>> do not know how ISP handle non-zero DSCP, there seems to be no
> > >>> standard for this.
> > >>
> > >>        Interestingly cake, at some point in the past offered exactly that functionality, but it got removed due to added complexity with very little practical applicability (and a potential layering violation, but one could equally argue that the current layering is partly sub-optimal/wrong and hence violating it to better reflect reality might be acceptable). But current cake does not offer this. If you are willing to daisy-chain two routers, you could run cake on the respective egress interfaces connecting both routers, and do the DSCP cleaning on the outer router’s egress interface toward the internet…
> > >>
> > >>>
> > >>>
> > >>> For ingress, DSCP field may not be set by network peer at all, and i
> > >>> have multiple LAN interfaces
> > >>>
> > >>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> > >>>
> > >>> The trick of setting DSCP by iptables do not work because cake comes first
> > >>
> > >>        Hence Jonathan’s recommendation to make sure that cake follows iptables, by setting it up on egress interfaces only…
> > >>
> > >> Best Regards
> > >>        Sebastian
> > >>
> > >>>
> > >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> > >>>>
> > >>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
> > >>>>>
> > >>>>> I deprioritize bittorrent traffic by marking related connections in
> > >>>>> iptables (e.g. detect by port number) and route them to corresponding
> > >>>>> HTB class and qdisc.
> > >>>>>
> > >>>>> How can i archive the same goal using the cake qdisc?
> > >>>>
> > >>>> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
> > >>>>
> > >>>> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
> > >>>>
> > >>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
> > >>>>
> > >>>> - Jonathan Morton
> > >>>>
> > >>> _______________________________________________
> > >>> Cake mailing list
> > >>> Cake@lists.bufferbloat.net
> > >>> https://lists.bufferbloat.net/listinfo/cake
> > >>
> >
> 

Re: [Cake] diffserv based on firewall mark

[ching lu]

[-- Attachment #1: Type: text/plain, Size: 7085 bytes --]

There is no need for cleansing dscp for wan ingress, I think it is
unnecessary, too

In https://www.bufferbloat.net/projects/codel/wiki/Cake/

There is a statement:

"The only way we know how to “fix” bittorrent is to classify it somewhat,
somehow, as “background”."

But in fact, there is no simply way to classify bittorrent INGRESS traffic

DSCP -> unreliable, easily spoofed by attacker, and the value is most
likely 0x0
firewall mark -> cake do not use firewall mark/connmark

Finally, I guess most likely home users will use bit torrent.

2016年10月12日 下午8:04，"moeller0" <moeller0@gmx.de>寫道：

> Hi Ching?
>
> > On Oct 12, 2016, at 12:17 , ching lu <lsching17@gmail.com> wrote:
> >
> >
> > 2016年10月12日 下午6:05，"moeller0" <moeller0@gmx.de>寫道：
> > >
> > > Hi Ching,
> > >
> > > > On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> > > >
> > > > How to archive "cake follows iptables"? is it “wan ingress ->
> iptables
> > >
> > > Yes.
> > >
> > > > -> wifi egress/LAN egress -> ifb egress -> cake”?
> > >
> > >         Except that if you instantiate cake on the interface
> connecting to the outers LAN/WLAN side (lets call this LAN for short), cake
> will reside on that interfaces egress and hence you require no ifb for
> traffic coming in from the internet (as a plus cake will even without the
> fancy new deNAT options see the full intrnal IP addresses, useful for dual
> and triple isolation options). In the direction facing the internet you can
> instantiate cake on an ifb interface for LAN and then put the iptables DSCP
> cleaner on the WAN egress side (and the WAN ingress side, unless you trust
> your ISP to deliver reasonable DSCP values, which should be like never*)
> >
> > The bandwidth shaper won’t work correctly if cake(s) are registered on
> multiple LAN interface, ifb is necessary
> >
> > e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi, and
> 50M on LAN ?
>
>         Yes that seems true, if you instantiate cake on br-lan (which I
> believe would be the relevant interface) you will shape both wireless and
> wired traffic, but most likely also internal traffic… But that can be
> solved by one more router/AP ;)
>
> >
> > I think the diffserv support of cake model is not suitable for home
> network currently.
>
>         I have no real opinion on that, but could you explicitly state
> what short coming you see that is a showstopper? DSCP cleaning on ingress
> is BTW not really required to happen before cake, as long as cake is set to
> besteffort it will ignore DSCP markings anyway, and if you want to
> re-map/re-classify packets vie DSCP on ingress you are pretty much out of
> scope for a typical home network. Cleaning up on egress, as to not leak
> internal configuration to the upstream seems indeed sub-optimal, but cake
> is not alone in that regard…
>
> > The setup is much more complex
>
>         Well, DSCP setup is complex no matter how you slice and dice it…
> but maybe you have an idea what a shaper (like cake) could/should do to
> make this simpler?
>
> Best Regards
>         Sebastian
>
> >
> >
> >
> > >
> > > Best Regards
> > >         Sebastian
> > >
> > > 8) DSCP are only ever guranteed to be meaninful inside a dscp domain,
> and in reality your home net is a different domain from the ISP’s. It would
> have been nice if the DSCP field would have been separeted into 2 3bit
> fields, the first for the actual sender to request one of 8 differential
> classes and the other 3bits for the current domain to store its actually
> used DSCP bits. I claim the 3 bits should be enough for anybody  ;)
> > >
> > >
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> > > >> Hi,
> > > >>
> > > >>
> > > >>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
> > > >>>
> > > >>> For egress, setting DSCP field should work.
> > > >>>
> > > >>> iptables -> wan egress -> cake
> > > >>>
> > > >>> But is it possible to set DSCP to 0x0 after cake's classification?
> i
> > > >>> do not know how ISP handle non-zero DSCP, there seems to be no
> > > >>> standard for this.
> > > >>
> > > >>        Interestingly cake, at some point in the past offered
> exactly that functionality, but it got removed due to added complexity with
> very little practical applicability (and a potential layering violation,
> but one could equally argue that the current layering is partly
> sub-optimal/wrong and hence violating it to better reflect reality might be
> acceptable). But current cake does not offer this. If you are willing to
> daisy-chain two routers, you could run cake on the respective egress
> interfaces connecting both routers, and do the DSCP cleaning on the outer
> router’s egress interface toward the internet…
> > > >>
> > > >>>
> > > >>>
> > > >>> For ingress, DSCP field may not be set by network peer at all, and
> i
> > > >>> have multiple LAN interfaces
> > > >>>
> > > >>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> > > >>>
> > > >>> The trick of setting DSCP by iptables do not work because cake
> comes first
> > > >>
> > > >>        Hence Jonathan’s recommendation to make sure that cake
> follows iptables, by setting it up on egress interfaces only…
> > > >>
> > > >> Best Regards
> > > >>        Sebastian
> > > >>
> > > >>>
> > > >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <
> chromatix99@gmail.com> wrote:
> > > >>>>
> > > >>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
> > > >>>>>
> > > >>>>> I deprioritize bittorrent traffic by marking related connections
> in
> > > >>>>> iptables (e.g. detect by port number) and route them to
> corresponding
> > > >>>>> HTB class and qdisc.
> > > >>>>>
> > > >>>>> How can i archive the same goal using the cake qdisc?
> > > >>>>
> > > >>>> Modify your iptables rules to set the DSCP rather than a
> kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as
> CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will
> pick that up appropriately.
> > > >>>>
> > > >>>> You also need to make sure Cake sees your packets *after* they’ve
> been through the firewall, which generally means attaching it to the egress
> port in each direction, not the ingress port.  You’ve probably already done
> this, if you’re happy with your HTB setup.
> > > >>>>
> > > >>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi),
> you should loop the inbound traffic through a common IFB device (and attach
> Cake to that instead of the physical interfaces) to simplify configuration.
> > > >>>>
> > > >>>> - Jonathan Morton
> > > >>>>
> > > >>> _______________________________________________
> > > >>> Cake mailing list
> > > >>> Cake@lists.bufferbloat.net
> > > >>> https://lists.bufferbloat.net/listinfo/cake
> > > >>
> > >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 9213 bytes --]

Re: [Cake] diffserv based on firewall mark

[moeller0]

Hi Ching,

> On Oct 12, 2016, at 14:40 , ching lu <lsching17@gmail.com> wrote:
> 
> There is no need for cleansing dscp for wan ingress, I think it is unnecessary, too
> 
> In https://www.bufferbloat.net/projects/codel/wiki/Cake/
> 
> There is a statement:
> 
> “The only way we know how to “fix” bittorrent is to classify it somewhat, somehow, as “background”."

	Which was true at the time. In the mean time cake grew new “isolation” modes that will attempt to provide on a first level per-(internal)-IP-address fairness and iside each internal IP-address “band” also per-flow fairness. This should allow to restrict the bad effect of bit-torrent traffic on the machine actually running the torrent client. Which seems like a goos compromise since most torrent clients allow configurations to alleviate the issue somewhat for that specific machine (like bandwidth limits). These additional modes do require a bit of testing and especially on ingress they will not be 100% robust (too many in-rushing bit-torrent connections might cause buffers upstream of the cake-managed link to fill and cause increased latency), but that just comes with instantiating a shaper on the wrong end of the real bottleneck. As a sidenote the more bandwidth difference exist between real bottleneck and the artifical cake-managed bottleneck the better ingress shaping will work…


> 
> But in fact, there is no simply way to classify bittorrent INGRESS traffic

	Yes, and no…

> 
> DSCP -> unreliable, easily spoofed by attacker, and the value is most likely 0x0\

	Well, if BT clients would mark CS1/BK that would be a decent 1st step, except that will also tell ISPs which packets to drop first… (which might be actually in the users interest)

> firewall mark -> cake do not use firewall mark/connmark

	If you can firewall mark you can also re-map dscp… But I believe the real issue is that bit-torrent was designed to have no clear unambiguous signature so figuring out which packets belong to bit-torrent flows is the tricky bit…

> 
> Finally, I guess most likely home users will use bit torrent.

	But that is a guess? Numbers/real data would be better; that said with even windows update allowing peer-to-peer distribution of updates bit-torrent-like traffic probably is something most home-users will see occasionally.

Best Regards
	Sebastian


> 
> 2016年10月12日 下午8:04，"moeller0" <moeller0@gmx.de>寫道：
> Hi Ching?
> 
> > On Oct 12, 2016, at 12:17 , ching lu <lsching17@gmail.com> wrote:
> >
> >
> > 2016年10月12日 下午6:05，"moeller0" <moeller0@gmx.de>寫道：
> > >
> > > Hi Ching,
> > >
> > > > On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> > > >
> > > > How to archive "cake follows iptables"? is it “wan ingress -> iptables
> > >
> > > Yes.
> > >
> > > > -> wifi egress/LAN egress -> ifb egress -> cake”?
> > >
> > >         Except that if you instantiate cake on the interface connecting to the outers LAN/WLAN side (lets call this LAN for short), cake will reside on that interfaces egress and hence you require no ifb for traffic coming in from the internet (as a plus cake will even without the fancy new deNAT options see the full intrnal IP addresses, useful for dual and triple isolation options). In the direction facing the internet you can instantiate cake on an ifb interface for LAN and then put the iptables DSCP cleaner on the WAN egress side (and the WAN ingress side, unless you trust your ISP to deliver reasonable DSCP values, which should be like never*)
> >
> > The bandwidth shaper won’t work correctly if cake(s) are registered on multiple LAN interface, ifb is necessary
> >
> > e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi, and 50M on LAN ?
> 
>         Yes that seems true, if you instantiate cake on br-lan (which I believe would be the relevant interface) you will shape both wireless and wired traffic, but most likely also internal traffic… But that can be solved by one more router/AP ;)
> 
> >
> > I think the diffserv support of cake model is not suitable for home network currently.
> 
>         I have no real opinion on that, but could you explicitly state what short coming you see that is a showstopper? DSCP cleaning on ingress is BTW not really required to happen before cake, as long as cake is set to besteffort it will ignore DSCP markings anyway, and if you want to re-map/re-classify packets vie DSCP on ingress you are pretty much out of scope for a typical home network. Cleaning up on egress, as to not leak internal configuration to the upstream seems indeed sub-optimal, but cake is not alone in that regard…
> 
> > The setup is much more complex
> 
>         Well, DSCP setup is complex no matter how you slice and dice it… but maybe you have an idea what a shaper (like cake) could/should do to make this simpler?
> 
> Best Regards
>         Sebastian
> 
> >
> >
> >
> > >
> > > Best Regards
> > >         Sebastian
> > >
> > > 8) DSCP are only ever guranteed to be meaninful inside a dscp domain, and in reality your home net is a different domain from the ISP’s. It would have been nice if the DSCP field would have been separeted into 2 3bit fields, the first for the actual sender to request one of 8 differential classes and the other 3bits for the current domain to store its actually used DSCP bits. I claim the 3 bits should be enough for anybody  ;)
> > >
> > >
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> > > >> Hi,
> > > >>
> > > >>
> > > >>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com> wrote:
> > > >>>
> > > >>> For egress, setting DSCP field should work.
> > > >>>
> > > >>> iptables -> wan egress -> cake
> > > >>>
> > > >>> But is it possible to set DSCP to 0x0 after cake's classification? i
> > > >>> do not know how ISP handle non-zero DSCP, there seems to be no
> > > >>> standard for this.
> > > >>
> > > >>        Interestingly cake, at some point in the past offered exactly that functionality, but it got removed due to added complexity with very little practical applicability (and a potential layering violation, but one could equally argue that the current layering is partly sub-optimal/wrong and hence violating it to better reflect reality might be acceptable). But current cake does not offer this. If you are willing to daisy-chain two routers, you could run cake on the respective egress interfaces connecting both routers, and do the DSCP cleaning on the outer router’s egress interface toward the internet…
> > > >>
> > > >>>
> > > >>>
> > > >>> For ingress, DSCP field may not be set by network peer at all, and i
> > > >>> have multiple LAN interfaces
> > > >>>
> > > >>> AFAIK, the order is "wan ingress -> ifb egress -> cake -> iptables"
> > > >>>
> > > >>> The trick of setting DSCP by iptables do not work because cake comes first
> > > >>
> > > >>        Hence Jonathan’s recommendation to make sure that cake follows iptables, by setting it up on egress interfaces only…
> > > >>
> > > >> Best Regards
> > > >>        Sebastian
> > > >>
> > > >>>
> > > >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> > > >>>>
> > > >>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com> wrote:
> > > >>>>>
> > > >>>>> I deprioritize bittorrent traffic by marking related connections in
> > > >>>>> iptables (e.g. detect by port number) and route them to corresponding
> > > >>>>> HTB class and qdisc.
> > > >>>>>
> > > >>>>> How can i archive the same goal using the cake qdisc?
> > > >>>>
> > > >>>> Modify your iptables rules to set the DSCP rather than a kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will pick that up appropriately.
> > > >>>>
> > > >>>> You also need to make sure Cake sees your packets *after* they’ve been through the firewall, which generally means attaching it to the egress port in each direction, not the ingress port.  You’ve probably already done this, if you’re happy with your HTB setup.
> > > >>>>
> > > >>>> If you have multiple LAN interfaces (eg, both Ethernet and wifi), you should loop the inbound traffic through a common IFB device (and attach Cake to that instead of the physical interfaces) to simplify configuration.
> > > >>>>
> > > >>>> - Jonathan Morton
> > > >>>>
> > > >>> _______________________________________________
> > > >>> Cake mailing list
> > > >>> Cake@lists.bufferbloat.net
> > > >>> https://lists.bufferbloat.net/listinfo/cake
> > > >>
> > >
> >
> 

Re: [Cake] diffserv based on firewall mark

[ching lu]

[-- Attachment #1: Type: text/plain, Size: 9573 bytes --]

2016年10月12日 下午9:07，"moeller0" <moeller0@gmx.de>寫道：
>
> Hi Ching,
>
> > On Oct 12, 2016, at 14:40 , ching lu <lsching17@gmail.com> wrote:
> >
> > There is no need for cleansing dscp for wan ingress, I think it is
unnecessary, too
> >
> > In https://www.bufferbloat.net/projects/codel/wiki/Cake/
> >
> > There is a statement:
> >
> > “The only way we know how to “fix” bittorrent is to classify it
somewhat, somehow, as “background”."
>
>         Which was true at the time. In the mean time cake grew new
“isolation” modes that will attempt to provide on a first level
per-(internal)-IP-address fairness and iside each internal IP-address
“band” also per-flow fairness. This should allow to restrict the bad effect
of bit-torrent traffic on the machine actually running the torrent client.
Which seems like a goos compromise since most torrent clients allow
configurations to alleviate the issue somewhat for that specific machine
(like bandwidth limits). These additional modes do require a bit of testing
and especially on ingress they will not be 100% robust (too many in-rushing
bit-torrent connections might cause buffers upstream of the cake-managed
link to fill and cause increased latency), but that just comes with
instantiating a shaper on the wrong end of the real bottleneck. As a
sidenote the more bandwidth difference exist between real bottleneck and
the artifical cake-managed bottleneck the better ingress shaping will work…
>
>

This is very interesting feature

> >
> > But in fact, there is no simply way to classify bittorrent INGRESS
traffic
>
>         Yes, and no…
>
> >
> > DSCP -> unreliable, easily spoofed by attacker, and the value is most
likely 0x0\
>
>         Well, if BT clients would mark CS1/BK that would be a decent 1st
step, except that will also tell ISPs which packets to drop first… (which
might be actually in the users interest)
>
> > firewall mark -> cake do not use firewall mark/connmark
>
>         If you can firewall mark you can also re-map dscp… But I believe
the real issue is that bit-torrent was designed to have no clear
unambiguous signature so figuring out which packets belong to bit-torrent
flows is the tricky bit…
>

You may be able to detect your bittorrent client's connection by iptables
(e.g. restrict its port range, or use DSCP for outgress).

After the connmark is set, it can be reused by tc filter, for both
ingress/outgress traffic

for windows update traffic, I do not know how to classify it yet

> >
> > Finally, I guess most likely home users will use bit torrent.
>
>         But that is a guess? Numbers/real data would be better; that said
with even windows update allowing peer-to-peer distribution of updates
bit-torrent-like traffic probably is something most home-users will see
occasionally.
>
> Best Regards
>         Sebastian
>
>
> >
> > 2016年10月12日 下午8:04，"moeller0" <moeller0@gmx.de>寫道：
> > Hi Ching?
> >
> > > On Oct 12, 2016, at 12:17 , ching lu <lsching17@gmail.com> wrote:
> > >
> > >
> > > 2016年10月12日 下午6:05，"moeller0" <moeller0@gmx.de>寫道：
> > > >
> > > > Hi Ching,
> > > >
> > > > > On Oct 12, 2016, at 11:35 , ching lu <lsching17@gmail.com> wrote:
> > > > >
> > > > > How to archive "cake follows iptables"? is it “wan ingress ->
iptables
> > > >
> > > > Yes.
> > > >
> > > > > -> wifi egress/LAN egress -> ifb egress -> cake”?
> > > >
> > > >         Except that if you instantiate cake on the interface
connecting to the outers LAN/WLAN side (lets call this LAN for short), cake
will reside on that interfaces egress and hence you require no ifb for
traffic coming in from the internet (as a plus cake will even without the
fancy new deNAT options see the full intrnal IP addresses, useful for dual
and triple isolation options). In the direction facing the internet you can
instantiate cake on an ifb interface for LAN and then put the iptables DSCP
cleaner on the WAN egress side (and the WAN ingress side, unless you trust
your ISP to deliver reasonable DSCP values, which should be like never*)
> > >
> > > The bandwidth shaper won’t work correctly if cake(s) are registered
on multiple LAN interface, ifb is necessary
> > >
> > > e.g. if ingress bandwidth limit is 100M, then setting 50M on wifi,
and 50M on LAN ?
> >
> >         Yes that seems true, if you instantiate cake on br-lan (which I
believe would be the relevant interface) you will shape both wireless and
wired traffic, but most likely also internal traffic… But that can be
solved by one more router/AP ;)
> >
> > >
> > > I think the diffserv support of cake model is not suitable for home
network currently.
> >
> >         I have no real opinion on that, but could you explicitly state
what short coming you see that is a showstopper? DSCP cleaning on ingress
is BTW not really required to happen before cake, as long as cake is set to
besteffort it will ignore DSCP markings anyway, and if you want to
re-map/re-classify packets vie DSCP on ingress you are pretty much out of
scope for a typical home network. Cleaning up on egress, as to not leak
internal configuration to the upstream seems indeed sub-optimal, but cake
is not alone in that regard…
> >
> > > The setup is much more complex
> >
> >         Well, DSCP setup is complex no matter how you slice and dice
it… but maybe you have an idea what a shaper (like cake) could/should do to
make this simpler?
> >
> > Best Regards
> >         Sebastian
> >
> > >
> > >
> > >
> > > >
> > > > Best Regards
> > > >         Sebastian
> > > >
> > > > 8) DSCP are only ever guranteed to be meaninful inside a dscp
domain, and in reality your home net is a different domain from the ISP’s.
It would have been nice if the DSCP field would have been separeted into 2
3bit fields, the first for the actual sender to request one of 8
differential classes and the other 3bits for the current domain to store
its actually used DSCP bits. I claim the 3 bits should be enough for
anybody  ;)
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Wed, Oct 12, 2016 at 5:10 PM, moeller0 <moeller0@gmx.de> wrote:
> > > > >> Hi,
> > > > >>
> > > > >>
> > > > >>> On Oct 12, 2016, at 10:11 , ching lu <lsching17@gmail.com>
wrote:
> > > > >>>
> > > > >>> For egress, setting DSCP field should work.
> > > > >>>
> > > > >>> iptables -> wan egress -> cake
> > > > >>>
> > > > >>> But is it possible to set DSCP to 0x0 after cake's
classification? i
> > > > >>> do not know how ISP handle non-zero DSCP, there seems to be no
> > > > >>> standard for this.
> > > > >>
> > > > >>        Interestingly cake, at some point in the past offered
exactly that functionality, but it got removed due to added complexity with
very little practical applicability (and a potential layering violation,
but one could equally argue that the current layering is partly
sub-optimal/wrong and hence violating it to better reflect reality might be
acceptable). But current cake does not offer this. If you are willing to
daisy-chain two routers, you could run cake on the respective egress
interfaces connecting both routers, and do the DSCP cleaning on the outer
router’s egress interface toward the internet…
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>> For ingress, DSCP field may not be set by network peer at all,
and i
> > > > >>> have multiple LAN interfaces
> > > > >>>
> > > > >>> AFAIK, the order is "wan ingress -> ifb egress -> cake ->
iptables"
> > > > >>>
> > > > >>> The trick of setting DSCP by iptables do not work because cake
comes first
> > > > >>
> > > > >>        Hence Jonathan’s recommendation to make sure that cake
follows iptables, by setting it up on egress interfaces only…
> > > > >>
> > > > >> Best Regards
> > > > >>        Sebastian
> > > > >>
> > > > >>>
> > > > >>> On Wed, Oct 12, 2016 at 3:26 PM, Jonathan Morton <
chromatix99@gmail.com> wrote:
> > > > >>>>
> > > > >>>>> On 12 Oct, 2016, at 08:52, ching lu <lsching17@gmail.com>
wrote:
> > > > >>>>>
> > > > >>>>> I deprioritize bittorrent traffic by marking related
connections in
> > > > >>>>> iptables (e.g. detect by port number) and route them to
corresponding
> > > > >>>>> HTB class and qdisc.
> > > > >>>>>
> > > > >>>>> How can i archive the same goal using the cake qdisc?
> > > > >>>>
> > > > >>>> Modify your iptables rules to set the DSCP rather than a
kernel-internal mark.  You probably want "-j DSCP —set-dscp-class CS1”, as
CS1 is the “bulk low priority” code.  Cake’s default Diffserv mode will
pick that up appropriately.
> > > > >>>>
> > > > >>>> You also need to make sure Cake sees your packets *after*
they’ve been through the firewall, which generally means attaching it to
the egress port in each direction, not the ingress port.  You’ve probably
already done this, if you’re happy with your HTB setup.
> > > > >>>>
> > > > >>>> If you have multiple LAN interfaces (eg, both Ethernet and
wifi), you should loop the inbound traffic through a common IFB device (and
attach Cake to that instead of the physical interfaces) to simplify
configuration.
> > > > >>>>
> > > > >>>> - Jonathan Morton
> > > > >>>>
> > > > >>> _______________________________________________
> > > > >>> Cake mailing list
> > > > >>> Cake@lists.bufferbloat.net
> > > > >>> https://lists.bufferbloat.net/listinfo/cake
> > > > >>
> > > >
> > >
> >
>

[-- Attachment #2: Type: text/html, Size: 12847 bytes --]

Re: [Cake] diffserv based on firewall mark

[Jonathan Morton]

> On 12 Oct, 2016, at 15:40, ching lu <lsching17@gmail.com> wrote:
> 
> DSCP -> unreliable, easily spoofed by attacker

I’d like to address the “easily spoofed by attacker” point specifically.

Cake’s interpretation of Diffserv is as a three-way tradeoff between throughput priority, latency priority, and altruism.  If you choose a DSCP meaning “low latency” such as CS6 or EF, Cake gives it higher weight than average, but *only* if the aggregate bandwidth of supposedly low-latency traffic is below a reasonable fraction of the link bandwidth.  Beyond that point, it gets *lower* weight than average, but is still able to use spare bandwidth that happens to be available.

There is no way to get “absolute priority”, which this type of attacker would presumably want, just by setting a particular DSCP.  The default “best effort” DSCP is in fact interpreted as “throughput priority”, which is what most bulk traffic wants.  In this respect, Cake differs from the original IP Precedence specification (which is long obsolete) and most other naive Diffserv implementations.

In short, Cake does not unreasonably *trust* the DSCP field, but instead offers explicit incentives for traffic to set it correctly.  This adheres to the relevant PHB specifications, which are published as RFCs and thus can be used as a standard.

The CS1 or “Background” DSCP is the one with an altruistic meaning.  It has low priority whichever side of the bandwidth threshold it lies, so it always mostly yields to other traffic.  Clients are of course permitted to not set it, but that’s what your firewall rules are for.  The Diffserv spec explicitly allows you to change the DSCP on entry to your own network, which is what I suggested in my first reply.

Setting the DSCP with iptables rules should work just as well and in the same way as using the “firewall mark” functionality as you already do.  Set it up that way in the first instance, directly replacing each HTB+fq_codel combination with a Cake instance, and see how it works.

 - Jonathan Morton

Re: [Cake] diffserv based on firewall mark

[Sebastian Moeller]

Hi there,

On October 12, 2016 5:36:32 PM GMT+02:00, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 12 Oct, 2016, at 15:40, ching lu <lsching17@gmail.com> wrote:
>> 
>> DSCP -> unreliable, easily spoofed by attacker
>
>I’d like to address the “easily spoofed by attacker” point
>specifically.
>
>Cake’s interpretation of Diffserv is as a three-way tradeoff between
>throughput priority, latency priority, and altruism.  If you choose a
>DSCP meaning “low latency” such as CS6 or EF, Cake gives it higher
>weight than average, but *only* if the aggregate bandwidth of
>supposedly low-latency traffic is below a reasonable fraction of the
>link bandwidth.  Beyond that point, it gets *lower* weight than
>average, but is still able to use spare bandwidth that happens to be
>available.
>
>There is no way to get “absolute priority”, which this type of attacker
>would presumably want, just by setting a particular DSCP.  The default
>“best effort” DSCP is in fact interpreted as “throughput priority”,
>which is what most bulk traffic wants.  In this respect, Cake differs
>from the original IP Precedence specification (which is long obsolete)
>and most other naive Diffserv implementations.
>
>In short, Cake does not unreasonably *trust* the DSCP field, but
>instead offers explicit incentives for traffic to set it correctly. 

With the slight complication that there is no canonically agreed upon value for correct, and cake' does not make it easy to predict how much traffic a specific priority tier will allow before degrading the requested priority, no? In short cake adds to the confusion independent of whether cake's rationale is sane... 


>This adheres to the relevant PHB specifications, which are published as
>RFCs and thus can be used as a standard.

The problem I see is that in the DSCP RFC it is explicitly stated that markings only are supposed/guaranteed to have meaning inside a dscp domain... With the home net typically being regarded as a domain independent of the ISPs...


>
>The CS1 or “Background” DSCP is the one with an altruistic meaning.  It
>has low priority whichever side of the bandwidth threshold it lies, so
>it always mostly yields to other traffic.  Clients are of course
>permitted to not set it, but that’s what your firewall rules are for. 
>The Diffserv spec explicitly allows you to change the DSCP on entry to
>your own network, which is what I suggested in my first reply.

They even recommend that IIRC, including recommending re-mapping to zero if in doubt.

Best Regards
        Sebastian

>
>Setting the DSCP with iptables rules should work just as well and in
>the same way as using the “firewall mark” functionality as you already
>do.  Set it up that way in the first instance, directly replacing each
>HTB+fq_codel combination with a Cake instance, and see how it works


>
> - Jonathan Morton

Re: [Cake] diffserv based on firewall mark

[ching lu]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

> Setting the DSCP with iptables rules should work just as well and in the
same way as using the “firewall mark” functionality as you already do.  Set
it up that way in the first instance, directly replacing each HTB+fq_codel
combination with a Cake instance, and see how it works.
>
>  - Jonathan Morton

I might test how cake distribute ingress bandwidth if I use bittorrent and
YouTube at the same time, hopefully ingress traffic has correct DSCP value

[-- Attachment #2: Type: text/html, Size: 522 bytes --]

Re: [Cake] diffserv based on firewall mark

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 846 bytes --]

On Thu, 13 Oct 2016, ching lu wrote:

>> Setting the DSCP with iptables rules should work just as well and in the
> same way as using the “firewall mark” functionality as you already do.  Set
> it up that way in the first instance, directly replacing each HTB+fq_codel
> combination with a Cake instance, and see how it works.
>>
>>  - Jonathan Morton
>
> I might test how cake distribute ingress bandwidth if I use bittorrent and
> YouTube at the same time, hopefully ingress traffic has correct DSCP value

Ingress traffic probably has no DSCP set. Your ISP would be getting the packets 
from some other ISP (possibly several layers of this) who get it from the 
sender. Each time the packet is handed off from one organization to another, the 
DSCP settings loose their meaning and have a really good chance of being 
stripped.

David Lang

[-- Attachment #2: Type: TEXT/PLAIN, Size: 137 bytes --]

_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] diffserv based on firewall mark

[Y]

Hi , I am yuta.

I request to add TCP ACK priority first.

Bye Bye.

On Wed, 12 Oct 2016 13:52:14 +0800
ching lu <lsching17@gmail.com> wrote:

> My current config is HTB+fq-codel.
> 
> I deprioritize bittorrent traffic by marking related connections in
> iptables (e.g. detect by port number) and route them to corresponding
> HTB class and qdisc.
> 
> How can i archive the same goal using the cake qdisc?
> 
> I am aware that cake supports Diffserv by DSCP, but i think it is not applicable
> 
> 1. i do not know to turn on DSCP for Winodws 8 (or above) client  <-
> someone may know
> 2. ingress traffic do not have DSCP
> 
> 
> Thanks in advance
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


-- 
Y <intruder_tkyf@yahoo.fr>

Re: [Cake] diffserv based on firewall mark

[Sebastian Moeller]

Hi yuta,

It would maybe be more convincing if you could share data showing how ack priority would help cake. I know that it has long been recommended, but I am missing recent data showing that it still would work for cake and fq_codel, as these tend to boost all sparse flows, and ack flows often are sparse... But feel free to ignore me, I am not advancing cake's development.

Best Regards
       Sebastian

On October 12, 2016 9:42:47 PM GMT+02:00, Y <intruder_tkyf@yahoo.fr> wrote:
>Hi , I am yuta.
>
>I request to add TCP ACK priority first.
>
>Bye Bye.
>
>On Wed, 12 Oct 2016 13:52:14 +0800
>ching lu <lsching17@gmail.com> wrote:
>
>> My current config is HTB+fq-codel.
>> 
>> I deprioritize bittorrent traffic by marking related connections in
>> iptables (e.g. detect by port number) and route them to corresponding
>> HTB class and qdisc.
>> 
>> How can i archive the same goal using the cake qdisc?
>> 
>> I am aware that cake supports Diffserv by DSCP, but i think it is not
>applicable
>> 
>> 1. i do not know to turn on DSCP for Winodws 8 (or above) client  <-
>> someone may know
>> 2. ingress traffic do not have DSCP
>> 
>> 
>> Thanks in advance
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>-- 
>Y <intruder_tkyf@yahoo.fr>
>_______________________________________________
>Cake mailing list
>Cake@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cake