On Wed, 1 Jun 2016, moeller0 wrote:
Hi Jonathan,
On Jun 1, 2016, at 15:51 , Jonathan Morton wrote:
On 1 Jun, 2016, at 15:25, Benjamin Cronce wrote:
1) Ideally, regardless of platform, should an AQM or scheduler have the
responsibility of changing anything other than ECN?
This was in p
My take on it was doing it in iptables was inefficient, error prone,
and slow. Interfacing to other people's iptables implementations was
and remains especially error prone.
My view has always been that iptables should be used mostly for firewall rules.
I had also had delusions of being able to a
Hi Jonathan,
> On Jun 1, 2016, at 15:51 , Jonathan Morton wrote:
>
>
>> On 1 Jun, 2016, at 15:25, Benjamin Cronce wrote:
>>
>> 1) Ideally, regardless of platform, should an AQM or scheduler have the
>> responsibility of changing anything other than ECN?
>
> This was in part my original obje
> On 1 Jun, 2016, at 15:25, Benjamin Cronce wrote:
>
> 1) Ideally, regardless of platform, should an AQM or scheduler have the
> responsibility of changing anything other than ECN?
This was in part my original objection to having the squash/wash feature in
Cake.
The other part is that if we
On 01/06/16 13:25, Benjamin Cronce wrote:
I'm just going to ask two questions just to reflect on
1) Ideally, regardless of platform, should an AQM or scheduler have the
responsibility of changing anything other than ECN?
2) Should you be deciding the responsibility of CAKE based on the
imp
On Wed, Jun 1, 2016 at 6:57 AM, Sebastian Moeller wrote:
> Hi Kevin
>
> On June 1, 2016 1:47:42 PM GMT+02:00, Kevin Darbyshire-Bryant <
> ke...@darbyshire-bryant.me.uk> wrote:
> >
> >
> >On 01/06/16 12:41, moeller0 wrote:
> >> Hi Toke,
> >>> I'm guessing this was probably discussed before and I'v
Hi Kevin
On June 1, 2016 1:47:42 PM GMT+02:00, Kevin Darbyshire-Bryant
wrote:
>
>
>On 01/06/16 12:41, moeller0 wrote:
>> Hi Toke,
>>> I'm guessing this was probably discussed before and I've simply
>>> forgotten; but why does this (rewriting dscp bits) need to be part
>of
>>> the qdisc when you
On 01/06/16 12:41, moeller0 wrote:
Hi Toke,
I'm guessing this was probably discussed before and I've simply
forgotten; but why does this (rewriting dscp bits) need to be part of
the qdisc when you can do it with iptables?
Well, cake looks at the DSCP bits already, if it can do the re
Hi Toke,
> On Jun 1, 2016, at 13:20 , Toke Høiland-Jørgensen wrote:
>
> moeller0 writes:
>
>> So, my take on this is that we want to be able to re-map DSCP to zero. On
>> ingress if we do not trust our upstream to do the right thing on egress if
>> we do
>> not want to leak internal informati
moeller0 writes:
> So, my take on this is that we want to be able to re-map DSCP to zero. On
> ingress if we do not trust our upstream to do the right thing on egress if we
> do
> not want to leak internal information to our upstream. As far as I can tell
> DSCP
> is supposed to be domain speci
So, my take on this is that we want to be able to re-map DSCP to zero. On
ingress if we do not trust our upstream to do the right thing on egress if we
do not want to leak internal information to our upstream. As far as I can tell
DSCP is supposed to be domain specific and I consider a home net
On 01/06/16 11:13, Dave Täht wrote:
I still think squashing is very important, and essentially required by
several rfcs.
I'm now wondering if we're falling into a terminology trap. The original
tc/cake implementation of 'squash' was effectively to use 'besteffort'
(ie diffserv1) ie. igno
I still think squashing is very important, and essentially required by
several rfcs.
On 6/1/16 3:02 AM, Kevin Darbyshire-Bryant wrote:
> To try and keep everyone in the loop this has also been sent to the cake
> list.
>
> LR;DR - There's a pull request to the LEDE tree to integrate cake as a
> p
To try and keep everyone in the loop this has also been sent to the cake
list.
LR;DR - There's a pull request to the LEDE tree to integrate cake as a
patch to tc as well as a small, separate core package for
kmod-sched-cake. This is a good thing. The pull request is
https://github.com/lede-
14 matches
Mail list logo
