[Cake] diffserv in cake

[Cake] diffserv in cake

[Dave Taht]

I am still way behind on email, only reading things peripherally, and
trying to keep to one subject per mail.

I have never thought the schemes we currently have in cake for
diffserv will survive exposure to what ISPs and other users consider
the "real world".

It was my hope, instead, that with ease we could add new models for
how to handle diffserv handling along existing htb based schemes.

I have long pursued every isp that I have contact with to talk about
their stuff, and none have responded.

We have not even tried to address vlans, for example... and probably should.

However the API lets us add new models easily, and I am thus, certain,
no matter what we deliver, that some big user will diss us as to what
we got wrong, fix it internally, and end up with a conflicting api for
whatever they deploy, and diss us for not intuiting their needs well
enough. I'm prepared to live with that.

Dave Täht
I just invested five years of my life to making wifi better. And,
now... the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi

Re: [Cake] diffserv in cake

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> It was my hope, instead, that with ease we could add new models for
> how to handle diffserv handling along existing htb based schemes.

Uh, I know: Let's allow the user to install a custom BPF filter that
classifies packets into classes... </sarcasm>

I'd say we either pick one, or allow arbitrary classification with tc
filter. In my book, the diffserv4 that mirrors 802.11e is a fine choice :)

-Toke

Re: [Cake] diffserv in cake

[Sebastian Moeller]

On Oct 30, 2015, at 13:35 , Dave Taht <dave.taht@gmail.com> wrote:

> publicly please for as many emails as possible.

	Argh, my old nemesis again Reply instead of Reply-All, sorry. It will sink in but habit change slowly (which for good habits is a boon)


> 
> I will answer with that "diffserv support is totally new - wg's barely
> concluded”

	Good point. But that also allows us to come up with something completely new instead of modeling after older stuff that always kept some legacy compatibility in mind. None of the existing schemes make too much sense in a home network I believe, potentiay a wrong believe ;)

Best Regards
	Sebastian

> 
> 
> On Fri, Oct 30, 2015 at 8:29 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Dave,
>> 
>> 
>> On Oct 30, 2015, at 13:13 , Dave Taht <dave.taht@gmail.com> wrote:
>> 
>>> I am still way behind on email, only reading things peripherally, and
>>> trying to keep to one subject per mail.
>>> 
>>> I have never thought the schemes we currently have in cake for
>>> diffserv will survive exposure to what ISPs and other users consider
>>> the "real world".
>>> 
>>> It was my hope, instead, that with ease we could add new models for
>>> how to handle diffserv handling along existing htb based schemes.
>>> 
>>> I have long pursued every isp that I have contact with to talk about
>>> their stuff, and none have responded.
>>> 
>>> We have not even tried to address vlans, for example... and probably should.
>>> 
>>> However the API lets us add new models easily, and I am thus, certain,
>>> no matter what we deliver, that some big user will diss us as to what
>>> we got wrong, fix it internally, and end up with a conflicting api for
>>> whatever they deploy, and diss us for not intuiting their needs well
>>> enough. I'm prepared to live with that.
>> 
>>        Now I am puzzled, if that is our prediction we actrually should go and make the diffserv scheme configurable in cake, but then the discussion whether to expose target and limit are somewhat moot given how much ABI we will be committing to ;)
>> 
>> Best Regards
>>        Sebastian
>> 
>> 
>>> 
>>> Dave Täht
>>> I just invested five years of my life to making wifi better. And,
>>> now... the FCC wants to make my work, illegal for people to install.
>>> https://www.gofundme.com/savewifi
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>>