[Cerowrt-devel] preliminary codel and fq

Discussion:

[Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

Dave Taht

2012-05-14 20:59:23 UTC

A test release of CeroWrt is now available that has support for Kathie
Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
fair queuing implementation on top of that, fq_codel.

fq_codel is enabled on all interfaces by default. It is vastly simpler
than what we were using before (sfqred) and draws upon and improves on
the same body of ideas (head drop, fq, timestamping) but is now tied
to Kathie and Van's blinding insights as to a good drop strategy, and
Eric's successor-to-sfqred ideas as towards head of queue behavior,
modern amounts of flows, and cache line optimizations.

There is a simple_qos.sh script that can be set to your uplink and
downlink speeds, but no uci interface for it as yet, nor gui. (help on
finishing aqm-scripts and the luci interface gladly accepted)

To see all the chocolately goodness of what fq_codel can do to wired
and wireless latency, it would be good for more to play with it.

Benchmarks have been very good thus far, and more benchmarks and
analysis are highly desired.

Caveat:

This release suffers from an unrelated bug ( #379 ) and should NOT be
installed as your main router. I would love to beat this bug because
it's the only prio 1 remaining but thus far, no luck. Under lighter
loads CeroWrt appears to work just fine, but that's for me. YMMV.

Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/

--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Outback Dingo

2012-05-14 21:58:54 UTC

Permalink

Post by Dave Taht
A test release of CeroWrt is now available that has support for Kathie
Nichols' and Van Jacobson's new AQM, Codel , and Eric Dumazet's new
fair queuing implementation on top of that, fq_codel.
fq_codel is enabled on all interfaces by default. It is vastly simpler
than what we were using before (sfqred) and draws upon and improves on
the same body of ideas (head drop, fq, timestamping) but is now tied
to Kathie and Van's blinding insights as to a good drop strategy, and
Eric's successor-to-sfqred ideas as towards head of queue behavior,
modern amounts of flows, and cache line optimizations.
There is a simple_qos.sh script that can be set to your uplink and
downlink speeds, but no uci interface for it as yet, nor gui. (help on
finishing aqm-scripts and the luci interface gladly accepted)
To see all the chocolately goodness of what fq_codel can do to wired
and wireless latency, it would be good for more to play with it.
Benchmarks have been very good thus far, and more benchmarks and
analysis are highly desired.
This release suffers from an unrelated bug ( #379 ) and should NOT be
installed as your main router. I would love to beat this bug because
it's the only prio 1 remaining but thus far, no luck. Under lighter
loads CeroWrt appears to work just fine, but that's for me. YMMV.
Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/

Odd why is there no openwrt-ar71xx-generic-wndr3700-squashfs-factory.img ??
has it been combined with another ???

Post by Dave Taht
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Richard Brown

2012-05-15 21:11:04 UTC

Permalink

On May 15, 2012, at 3:00 PM, Outback Dingo wrote:

Caveat:

This release suffers from an unrelated bug ( #379 ) and should NOT be
installed as your main router. I would love to beat this bug because
it's the only prio 1 remaining but thus far, no luck. Under lighter
loads CeroWrt appears to work just fine, but that's for me. YMMV.

Get it here: http://huchra.bufferbloat.net/~cero1/3.3/3.3.6-2/

Odd why is there no openwrt-ar71xx-generic-wndr3700-squashfs-factory.img ??
has it been combined with another ???

CeroWrt has no builds for the either the WNDR3700 v1 or v3. The WNDR3700v2 and WNDR3800 both work fine (and the WNDR3800 has more flash memory, so it's a bit more futureproof...)

Best,

Rich

Sebastian Moeller

2012-05-16 16:34:54 UTC

Permalink

Hi Dave,

so I upgraded my router to the most recent version, and hey I am really impressed, thanks a lot for all the work.
(I never really stress the local network, and the internet is 5/30 so I consider to be on the safe side of #379 and decided to ignore your recommendation about the suitability for main routers).
I tried the simple_qos.sh script and for my testing it is quite nice indeed. The whole network stays quite responsive even during abuse. The whole expeience was quite pleasant (using ssh over a ssl based VPN to remote control an X11 session while stressing in and out direction); counter to my subjective experience though netalyzr was detecting 3000 odd milliseconds of buffering upstream (downstream was fine). Once I find more time I will have a go at reproducing that. (Now I have to figure out whether I need to restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW, how do you envision this to be started under the AQM tab; shall this start simple_qos or rather debloat?
Small observation, port 81 on the router seems open to the internet, easily fixed, but maybe something you might want know :)

Anyway, thanks again
Sebastian

dave taht

2012-05-16 17:09:01 UTC

Permalink

Post by Sebastian Moeller
Hi Dave,
so I upgraded my router to the most recent version, and hey I am really impressed, thanks a lot for all the work.
(I never really stress the local network, and the internet is 5/30 so I consider to be on the safe side of #379 and decided to ignore your recommendation about the suitability for main routers).
I tried the simple_qos.sh script and for my testing it is quite nice indeed. The whole network stays quite responsive even during abuse. The whole expeience was quite pleasant (using ssh over a ssl based VPN to remote control an X11 session while stressing in and out direction); counter to my subjective experience though netalyzr was detecting 3000 odd milliseconds of buffering upstream (downstream was fine). Once I find more time I will have a go at reproducing that. (Now I have to figure out whether I need to restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW, how do you envision this to be started under the AQM tab; shall this start simple_qos or rather debloat?

No, I had something more wonderful in mind.

Felix Fietkau has added fq_codel to the openwrt 3.3 kernel and to the
existing qos-scripts as of openwrt revision 31761.

Builds for 37 architectures and ~150 platforms are popping out as I write.

See

http://buildbot.openwrt.org:8010/one_line_per_build

For details.

I will be obsoleting the CeroWrt aqm and aqm-scripts and simple_qos as
soon as the new qos-scripts handles ipv6 properly, and maybe get a
chance to add a trick or two to more to it.

Erics latest patch to fq_codel has not yet landed in openwrt.

Post by Sebastian Moeller
Small observation, port 81 on the router seems open to the internet, easily fixed, but maybe something you might want know :)

Patches gladly accepted. Frankly I'd hoped to have CeroWall done by now,
but, well, the ball's on the 20 yard line, and I need to bench myself
for a while.

Hopefully someone else can take it in for the score.

Post by Sebastian Moeller
Anyway, thanks again
Sebastian

Outback Dingo

2012-05-16 17:16:05 UTC

Permalink

Post by dave taht

Post by Sebastian Moeller
Hi Dave,
so I upgraded my router to the most recent version, and hey I am really
impressed, thanks a lot for all the work.
(I never really stress the local network, and the internet is 5/30 so I
consider to be on the safe side of #379 and decided to ignore your
recommendation about the suitability for main routers).
I tried the simple_qos.sh script and for my testing it is quite
nice indeed. The whole network stays quite responsive even during abuse. The
whole expeience was quite pleasant (using ssh over a ssl based VPN to remote
control an X11 session while stressing in and out direction); counter to my
subjective experience though netalyzr was detecting 3000 odd milliseconds of
buffering upstream (downstream was fine). Once I find more time I will have
a go at reproducing that. (Now I have to figure out whether I need to
restart simple_qos.sh anytime I down or up an interface; any pointer?) BTW,
how do you envision this to be started under the AQM tab; shall this start
simple_qos or rather debloat?

No, I had something more wonderful in mind.
Felix Fietkau has added fq_codel to the openwrt 3.3 kernel and to the
existing qos-scripts as of openwrt revision 31761.
Builds for 37 architectures and ~150 platforms are popping out as I write.
See
http://buildbot.openwrt.org:8010/one_line_per_build
For details.
I will be obsoleting the CeroWrt aqm and aqm-scripts and simple_qos as soon
as the new qos-scripts handles ipv6 properly, and maybe get a chance to add
a trick or two to more to it.
Erics latest patch to fq_codel has not yet landed in openwrt.

Post by Sebastian Moeller
Small observation, port 81 on the router seems open to the internet,
easily fixed, but maybe something you might want know :)

Patches gladly accepted. Frankly I'd hoped to have CeroWall done by now,
but, well, the ball's on the 20 yard line, and I need to bench myself for a
while.
Hopefully someone else can take it in for the score.

CeroWall ?? OpenWRT iptables / qos scripts ???

Post by dave taht

Post by Sebastian Moeller
Anyway, thanks again
Sebastian

_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Dave Taht

2012-05-16 17:52:16 UTC

Permalink

The problem with most home router firewalls today is that they have a strict
"us" vs "them" concept in them, and are closely tied to what can be
NATed, or not, which limits our internet to tcp and udp.

Recently the concept of 'guest' has been added to many devices,
which doesn't work particularly well.

A problem with "us vs them" and extending this sort of thinking
to ipv6, is that interesting new protocols such as
sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
wesp, and rohc...

are all blocked by default in ipv6, too.

It doesn't need to be this way.

I have hated living in a world of purely tcp on port 80 and 443.

Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
really bothers me.

So cerowall attempted (I've never finished it) to use pattern matching
in iptables, and device renaming, to make it possible to have a nearly
default free zone (DFZ) for guests, and use a bare minimum of rules,
to pass through...

and the core idea was also be able to pass ALL protocols everywhere,
under ipv6.

The current openwrt firewall solution scales O(n) where n = the number
of interfaces
the cerowall idea scales O(n) where n = the number of different zones.

Firewalling is responsible for a minimum of 11% of the current runtime,
with the current firewall rules, with 6 interfaces in play.

CeroWall did a lot better, while opening up new vistas to play in.

--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Sebastian Moeller

2012-05-16 19:51:25 UTC

Permalink

Hi Dave,

all of this sounds interesting, and a bit scary...

While I have a hunch that I am trying to flog a quite deceased horse here,I think that closed by default is the safest way to set up a secure router. If it is easy to open it up for incoming services easily than everything is golden. As long as I control the router control and restriction actually become great concepts :) (even DPI is decidedly non-scary if I perform it my own network packages versus someone else doing it on my packages :) )

Post by Dave Taht
The problem with most home router firewalls today is that they have a strict
"us" vs "them" concept in them, and are closely tied to what can be
NATed, or not, which limits our internet to tcp and udp.
Recently the concept of 'guest' has been added to many devices,
which doesn't work particularly well.
A problem with "us vs them" and extending this sort of thinking
to ipv6, is that interesting new protocols such as
sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
wesp, and rohc…

Just to show my ignorance, but all are on top of IP packages, so why can these not be integrated into NAT default closed firewalls?

Post by Dave Taht
are all blocked by default in ipv6, too.

Which I think is the right thing to do, as long as opening a service is a few mouse clicks away.

There is too much internet enabled gear around (say like my ipod) which is not really be trustworthy nor can be audited easily to go to open by default. Having the router be restrictive does not eradicate consequences from insecure devices but mitigates it some. It should be easier to keep a single router secure than a small armada of end user devices behind this thing (and so much easier to give TLC to one firewall instead of several all using slightly different configuration methods). Hey, I just realize I am a pessimist and a spassbremse...

Post by Dave Taht
It doesn't need to be this way.
I have hated living in a world of purely tcp on port 80 and 443.
Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
really bothers me.

How is that related to restrictive handling of incoming data? I ask because I really do not know. I always assumed that blocking all incoming unless either related to an already initiated connection or explicitly allowed made sense and should allow most things to just work. (I am totally prepared to open the firewall for services I am interested in).

Post by Dave Taht
So cerowall attempted (I've never finished it) to use pattern matching
in iptables, and device renaming, to make it possible to have a nearly
default free zone (DFZ) for guests, and use a bare minimum of rules,
to pass through…

That sounds great (if the secure zone stays restrictive by default, having an easy way to go into the deep end sounds great).

Post by Dave Taht
and the core idea was also be able to pass ALL protocols everywhere,
under ipv6.

That I can not understand, as IPv6 becomes more pervasive so will exploits and security issues. I see the whole issue a bit as the dichotomy between control and laissez faire; in theory cooperation easily beats strict control, but in reality cooperation only works well in special cases. And from that perspective I see allow all incoming IPv6 as a gamble that will fail once the population of users grows beyond the early-adopter tech crowd…

Post by Dave Taht
The current openwrt firewall solution scales O(n) where n = the number
of interfaces
the cerowall idea scales O(n) where n = the number of different zones.
Firewalling is responsible for a minimum of 11% of the current runtime,
with the current firewall rules, with 6 interfaces in play.

But is that not a good part of what a network edge router should do to "earn" its living :)

Post by Dave Taht
CeroWall did a lot better, while opening up new vistas to play in.

It seems I am a chicken incapable of appreciating these vistas without worrying about what else could happen :)

Anyway, I am truly interested in learning the gains of default open routing and what risk mitigation approaches exist for the t scenario.

Best
Sebastian

Post by Dave Taht
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

d***@reed.com

2012-05-17 00:09:46 UTC

Permalink

So here's an interesting question .. can cerowrt's approach relate to FON? FON is not so successful in US, but in Europe, it is doing well. FON should also adopt codel and fq_codel.

It may not make sense quickly, but the 802.11p stuff that is going on in the world might be a big opportunity to enage with cerowrt capabilities....

-----Original Message-----
From: "Sebastian Moeller" <***@gmx.de>
Sent: Wednesday, May 16, 2012 3:51pm
To: "Dave Taht" <***@gmail.com>
Cc: "<cerowrt-***@lists.bufferbloat.net>" <cerowrt-***@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

Hi Dave,

all of this sounds interesting, and a bit scary...

While I have a hunch that I am trying to flog a quite deceased horse here,I think that closed by default is the safest way to set up a secure router. If it is easy to open it up for incoming services easily than everything is golden. As long as I control the router control and restriction actually become great concepts :) (even DPI is decidedly non-scary if I perform it my own network packages versus someone else doing it on my packages :) )

Just to show my ignorance, but all are on top of IP packages, so why can these not be integrated into NAT default closed firewalls?

Post by Dave Taht
are all blocked by default in ipv6, too.

That sounds great (if the secure zone stays restrictive by default, having an easy way to go into the deep end sounds great).

Post by Dave Taht
and the core idea was also be able to pass ALL protocols everywhere,
under ipv6.

But is that not a good part of what a network edge router should do to "earn" its living :)

Post by Dave Taht
CeroWall did a lot better, while opening up new vistas to play in.

Post by Dave Taht
--
Dave TÃ€ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net