[Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt

[Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt

[Dave Taht]

It occurs to me that jim and I haven't talked about one of the side
goals of cerowrt that much.

We spent a lot of time, early on, trying to find bits of network
research that seemed promising, make them more usable, and more
available to a wider audience to play with, on something that cost 100
bucks...

Simply getting to where we had a reliable, well understood, base
platform for real world day to day use - AND research - has taken all
year, and along the way we had to solve a lot of niggling problems.

So here's a list of extra stuff that we felt was potentially useful
and interesting.

And until now, although we'd made the packages more or less work, we
didn't always build them - the build takes long enough as it is! - but
the intent was to make them available as options. I plan to make as
many of these available as possible in the next builds, and
installabblevia the opkg utility.

To me, this is the interesting stuff! Getting to use - understand -
and leverage these fascinating new technologies could eat my entire
life, and darn it, I have another build to do...

I'm always up to adding (or hearing about!) more. There's a huge list
of stuff on the onboard web pages we ship by default and think is
stable and are willing to support, but this is the bleeding edge stuff
that we'd hoped people would try out in the longer run.

* HIP. Boeing uses this to control industrial machinery inside of
other peoples' lans. It holds great potential as  means to keep your
refrigerator updated and safe, as well as provide a useful abstraction
for separating a host's location, from it's identity.
I'd hoped to try this for things like snmp monitoring.

regrettably openhip has a tough problem right now with puzzle
generation in the D1 crypto step on mips and while fascinated by
problems like that normally, ENOTIME. I'm going to build it, merely to
find out if I can get someone else to connect to me on the same arch
and have puzzles fail or succeed...

* Kerberos Kerberos is one of the few universal single signon
facilities that actually works. It's amazing how much nicer my life is
when I'm at a facility that has it on. I don't ever have to login to
anything. While I build the package, convincing the universe to go to
kerberos seems difficult, but as an example of what could be done, if
we get fed up with dealing with capcha I wanted it out there.

* VPN technologies. IPsec is supposed to be an intrinsic part of any
ipv6 implemention. It usually is not, as it's rather thoroughly
over-engineered (and underthought-out when it was developed), but
Strongswan has been part of cerowrt since day one. Convincing people
to try it (and get past the hurdles of cert generation, which is a
PITA) has been a problem.

I ran into so many problems trying to get it to work inside of
corporate firewalls that I gave up on it, but that doesn't mean it's a
problem on the edge in the home. Yet. But I do note that it will work
much better over ipv6 in that you have nearly infinite address space
available, and it does, by default, work with ipv6.

I note that people keep trying to make tcp do everything, and it
can't. UDP based applications can be made work much better, with a
crypto assist...

Frustrated with ipsec, I got openvpn to work, over both udp and tcp.
As it turned out, the only thing I could get through the firewall in
france was openvpn over tcp, and working through that was a profound,
painful demonstration of the benefits of e2e connectivity over udp!

Both are built into cerowrt at present.

* TCP fast open. We've been tracking this work closely, but patches
are not going to land for a month or two more, and will need to bake a
bit. You can look up this topic on the web - it looks promising to cut
10% or more of the typical latency of a short tcp connection.

* CCNX: Both jim and I are huge fans of this project, check it out.

Steve walker got previous version of ccnx to build, I updated to the
latest release and broke it. :(

* Openflow: Stanford in particular is doing research into making
multiple switches act as one big switch, with a common configuration
language. It's interesting, especially if you think bridging can
scale.

* Mesh routing protocols: While the default in cerowrt is babel, we've
been tracking the progress of quagga-re closely, which includes bgp,
ripng, ospf, ospfv6, isis, and babel. We also make available olsr, and
xorp - which is roughly a superset of quagga, with additional support
for multicast routing that I haven't explored, because xorp is kind of
large. It is however widely used.

Regrettably the xorp package is mildly broken at present (just needs
love from someone) and someone needs to fix it, if they care. At the
moment, quagga gets most of the other interesting protocols available,
so I don't care. That much.

* tcp-ledbat: ledbat is the underlying protocol of current bittorrent,
and it has problems.TCP-ledbat is an implementation for tcp, and is
available by default.

* Test tools: One of the things I'm happiest about now is that the
netperf tool now has the ability to change socket priorities,
tcp congestion control algorithms, and TOS/Diffserv settings on the
fly - for both sides of the test - via remote control.
Interestingly - Diffserv settings don't generally survive an ipv4
connection across the internet, ipv6 settings do.

There are innumerable test tools that we have available (shaperprobe,
ditg, lft traceroute, etc)

* Multicast: Multicast was a hot topic in the 90s and nearly dead now,
except for those few critical applications where it's absolutely
required. (which is a broader category than most people think. Without
multicast dns, dhcp, and radvd, none of our networks would work at
all) Being able to use it again, at a higher level application, seems
like a useful avenue to explore in the context of a home. Available
since the first cerowrt boot camp has been a version of multicast ftp
(uftp), pimd is on by default, mrd6 is there but too buggy to use...

That about covers all the sexy stuff that I can remember.

I've finished adding these all back in the build that I could, for my
next attempt at a release late this week.

happy hacking.

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

Re: [Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt

[Maciej Soltysiak]

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

Hi!

Those are very exciting things you're taking about Dave and surely the way
to go forward.

But looking at cerowrt from my living room's perspective, if I may, I must
say that most crucial is the stuff that reduces latency,
bufferbloat; improves "snappiness"; provides flexibility and ease to using
apps. By that I mean:
1) QoS, ACM and bufferbloat work - which is very good at the moment for me
and I appreciate that very much!
1b) TCP FastOpen - indeed sounds exciting and but also Proportional Rate
Reduction (http://lwn.net/Articles/458610/)
2) UPNP / NATPMP / mDNSresponder - to help different apps reaching out - i
am sort of losing grasp of which package does what, they seem to be
intertwined (?) but cero has these packages currently (3.3.1-4) broken.
3) miniDLNA - DLNA is a good low-latency (?) / high-throughput use-case
within the wireless (laptops, picture frames) and wired (TV, NAS) home
network. Also minidlna package is broken too.
4) Some still sexy stuff for me: DNSSEC, IPv6

Regards,
Maciej

On Tue, Apr 10, 2012 at 7:58 PM, Dave Taht <dave.taht@gmail.com> wrote:

> It occurs to me that jim and I haven't talked about one of the side
> goals of cerowrt that much.
>
> We spent a lot of time, early on, trying to find bits of network
> research that seemed promising, make them more usable, and more
> available to a wider audience to play with, on something that cost 100
> bucks...
>
> Simply getting to where we had a reliable, well understood, base
> platform for real world day to day use - AND research - has taken all
> year, and along the way we had to solve a lot of niggling problems.
>
> So here's a list of extra stuff that we felt was potentially useful
> and interesting.
>
> And until now, although we'd made the packages more or less work, we
> didn't always build them - the build takes long enough as it is! - but
> the intent was to make them available as options. I plan to make as
> many of these available as possible in the next builds, and
> installabblevia the opkg utility.
>
> To me, this is the interesting stuff! Getting to use - understand -
> and leverage these fascinating new technologies could eat my entire
> life, and darn it, I have another build to do...
>
> I'm always up to adding (or hearing about!) more. There's a huge list
> of stuff on the onboard web pages we ship by default and think is
> stable and are willing to support, but this is the bleeding edge stuff
> that we'd hoped people would try out in the longer run.
>
> * HIP. Boeing uses this to control industrial machinery inside of
> other peoples' lans. It holds great potential as  means to keep your
> refrigerator updated and safe, as well as provide a useful abstraction
> for separating a host's location, from it's identity.
> I'd hoped to try this for things like snmp monitoring.
>
> regrettably openhip has a tough problem right now with puzzle
> generation in the D1 crypto step on mips and while fascinated by
> problems like that normally, ENOTIME. I'm going to build it, merely to
> find out if I can get someone else to connect to me on the same arch
> and have puzzles fail or succeed...
>
> * Kerberos Kerberos is one of the few universal single signon
> facilities that actually works. It's amazing how much nicer my life is
> when I'm at a facility that has it on. I don't ever have to login to
> anything. While I build the package, convincing the universe to go to
> kerberos seems difficult, but as an example of what could be done, if
> we get fed up with dealing with capcha I wanted it out there.
>
> * VPN technologies. IPsec is supposed to be an intrinsic part of any
> ipv6 implemention. It usually is not, as it's rather thoroughly
> over-engineered (and underthought-out when it was developed), but
> Strongswan has been part of cerowrt since day one. Convincing people
> to try it (and get past the hurdles of cert generation, which is a
> PITA) has been a problem.
>
> I ran into so many problems trying to get it to work inside of
> corporate firewalls that I gave up on it, but that doesn't mean it's a
> problem on the edge in the home. Yet. But I do note that it will work
> much better over ipv6 in that you have nearly infinite address space
> available, and it does, by default, work with ipv6.
>
> I note that people keep trying to make tcp do everything, and it
> can't. UDP based applications can be made work much better, with a
> crypto assist...
>
> Frustrated with ipsec, I got openvpn to work, over both udp and tcp.
> As it turned out, the only thing I could get through the firewall in
> france was openvpn over tcp, and working through that was a profound,
> painful demonstration of the benefits of e2e connectivity over udp!
>
> Both are built into cerowrt at present.
>
> * TCP fast open. We've been tracking this work closely, but patches
> are not going to land for a month or two more, and will need to bake a
> bit. You can look up this topic on the web - it looks promising to cut
> 10% or more of the typical latency of a short tcp connection.
>
> * CCNX: Both jim and I are huge fans of this project, check it out.
>
> Steve walker got previous version of ccnx to build, I updated to the
> latest release and broke it. :(
>
> * Openflow: Stanford in particular is doing research into making
> multiple switches act as one big switch, with a common configuration
> language. It's interesting, especially if you think bridging can
> scale.
>
> * Mesh routing protocols: While the default in cerowrt is babel, we've
> been tracking the progress of quagga-re closely, which includes bgp,
> ripng, ospf, ospfv6, isis, and babel. We also make available olsr, and
> xorp - which is roughly a superset of quagga, with additional support
> for multicast routing that I haven't explored, because xorp is kind of
> large. It is however widely used.
>
> Regrettably the xorp package is mildly broken at present (just needs
> love from someone) and someone needs to fix it, if they care. At the
> moment, quagga gets most of the other interesting protocols available,
> so I don't care. That much.
>
> * tcp-ledbat: ledbat is the underlying protocol of current bittorrent,
> and it has problems.TCP-ledbat is an implementation for tcp, and is
> available by default.
>
> * Test tools: One of the things I'm happiest about now is that the
> netperf tool now has the ability to change socket priorities,
> tcp congestion control algorithms, and TOS/Diffserv settings on the
> fly - for both sides of the test - via remote control.
> Interestingly - Diffserv settings don't generally survive an ipv4
> connection across the internet, ipv6 settings do.
>
> There are innumerable test tools that we have available (shaperprobe,
> ditg, lft traceroute, etc)
>
> * Multicast: Multicast was a hot topic in the 90s and nearly dead now,
> except for those few critical applications where it's absolutely
> required. (which is a broader category than most people think. Without
> multicast dns, dhcp, and radvd, none of our networks would work at
> all) Being able to use it again, at a higher level application, seems
> like a useful avenue to explore in the context of a home. Available
> since the first cerowrt boot camp has been a version of multicast ftp
> (uftp), pimd is on by default, mrd6 is there but too buggy to use...
>
> That about covers all the sexy stuff that I can remember.
>
> I've finished adding these all back in the build that I could, for my
> next attempt at a release late this week.
>
> happy hacking.
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt

[Dave Taht]

On Wed, Apr 11, 2012 at 12:37 PM, Maciej Soltysiak <maciej@soltysiak.com> wrote:
> Hi!
>
> Those are very exciting things you're taking about Dave and surely the way
> to go forward.
>
> But looking at cerowrt from my living room's perspective, if I may, I must
> say that most crucial is the stuff that reduces latency,
> bufferbloat; improves "snappiness"; provides flexibility and ease to using
> apps. By that I mean:
> 1) QoS, ACM and bufferbloat work - which is very good at the moment for me
> and I appreciate that very much!

this is what I care about primarily. However, when we first sought
funding for this project last year, nobody understood bufferbloat or
how important low latency was in the home and elsewhere, so a lot of
other things got glopped on to make it more appealing to corporate and
university sponsors.

I DO care a lot about ipv6 and security, and all the other stuff, but
fixing bufferbloat is my own top interest. I'm

> 1b) TCP FastOpen - indeed sounds exciting and but also Proportional Rate
> Reduction (http://lwn.net/Articles/458610/)

I mentally lump these together and am more dubious of the latter.

> 2) UPNP / NATPMP / mDNSresponder - to help different apps reaching out - i
> am sort of losing grasp of which package does what, they seem to be
> intertwined (?) but cero has these packages currently (3.3.1-4) broken.
> 3) miniDLNA - DLNA is a good low-latency (?) / high-throughput use-case
> within the wireless (laptops, picture frames) and wired (TV, NAS) home
> network. Also minidlna package is broken too.

I have created a bug for these https://www.bufferbloat.net/issues/362
but "broken" how, is a question.

> 4) Some still sexy stuff for me: DNSSEC, IPv6

Well, I've encountered enough problems with dnssec on by default, that
I'm thinking seriously of leaving it off by default. That said, we won't
find more problems if we don't leave it on, so, on alternate tuesdays,
I intend to leave it on.

Also, it would be good to rewrite the bind9 forwarders file with a
known good dnssec provider if your upstream works with dnssec and
respects NXDOMAIN. Right now that's a manual, (if underdocumented)
process. (you can figure it out with a couple dig queries)

 It really speeds up dns to use your isp's forwarder - comcast's
dnssec implementation is GREAT, and their anycast servers are like,
9ms away, no matter where you are.

I wish we could find someone could lick bug 113 thoroughly and so far, no luck.

>
> Regards,
> Maciej
>
> On Tue, Apr 10, 2012 at 7:58 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> It occurs to me that jim and I haven't talked about one of the side
>> goals of cerowrt that much.
>>
>> We spent a lot of time, early on, trying to find bits of network
>> research that seemed promising, make them more usable, and more
>> available to a wider audience to play with, on something that cost 100
>> bucks...
>>
>> Simply getting to where we had a reliable, well understood, base
>> platform for real world day to day use - AND research - has taken all
>> year, and along the way we had to solve a lot of niggling problems.
>>
>> So here's a list of extra stuff that we felt was potentially useful
>> and interesting.
>>
>> And until now, although we'd made the packages more or less work, we
>> didn't always build them - the build takes long enough as it is! - but
>> the intent was to make them available as options. I plan to make as
>> many of these available as possible in the next builds, and
>> installabblevia the opkg utility.
>>
>> To me, this is the interesting stuff! Getting to use - understand -
>> and leverage these fascinating new technologies could eat my entire
>> life, and darn it, I have another build to do...
>>
>> I'm always up to adding (or hearing about!) more. There's a huge list
>> of stuff on the onboard web pages we ship by default and think is
>> stable and are willing to support, but this is the bleeding edge stuff
>> that we'd hoped people would try out in the longer run.
>>
>> * HIP. Boeing uses this to control industrial machinery inside of
>> other peoples' lans. It holds great potential as  means to keep your
>> refrigerator updated and safe, as well as provide a useful abstraction
>> for separating a host's location, from it's identity.
>> I'd hoped to try this for things like snmp monitoring.
>>
>> regrettably openhip has a tough problem right now with puzzle
>> generation in the D1 crypto step on mips and while fascinated by
>> problems like that normally, ENOTIME. I'm going to build it, merely to
>> find out if I can get someone else to connect to me on the same arch
>> and have puzzles fail or succeed...
>>
>> * Kerberos Kerberos is one of the few universal single signon
>> facilities that actually works. It's amazing how much nicer my life is
>> when I'm at a facility that has it on. I don't ever have to login to
>> anything. While I build the package, convincing the universe to go to
>> kerberos seems difficult, but as an example of what could be done, if
>> we get fed up with dealing with capcha I wanted it out there.
>>
>> * VPN technologies. IPsec is supposed to be an intrinsic part of any
>> ipv6 implemention. It usually is not, as it's rather thoroughly
>> over-engineered (and underthought-out when it was developed), but
>> Strongswan has been part of cerowrt since day one. Convincing people
>> to try it (and get past the hurdles of cert generation, which is a
>> PITA) has been a problem.
>>
>> I ran into so many problems trying to get it to work inside of
>> corporate firewalls that I gave up on it, but that doesn't mean it's a
>> problem on the edge in the home. Yet. But I do note that it will work
>> much better over ipv6 in that you have nearly infinite address space
>> available, and it does, by default, work with ipv6.
>>
>> I note that people keep trying to make tcp do everything, and it
>> can't. UDP based applications can be made work much better, with a
>> crypto assist...
>>
>> Frustrated with ipsec, I got openvpn to work, over both udp and tcp.
>> As it turned out, the only thing I could get through the firewall in
>> france was openvpn over tcp, and working through that was a profound,
>> painful demonstration of the benefits of e2e connectivity over udp!
>>
>> Both are built into cerowrt at present.
>>
>> * TCP fast open. We've been tracking this work closely, but patches
>> are not going to land for a month or two more, and will need to bake a
>> bit. You can look up this topic on the web - it looks promising to cut
>> 10% or more of the typical latency of a short tcp connection.
>>
>> * CCNX: Both jim and I are huge fans of this project, check it out.
>>
>> Steve walker got previous version of ccnx to build, I updated to the
>> latest release and broke it. :(
>>
>> * Openflow: Stanford in particular is doing research into making
>> multiple switches act as one big switch, with a common configuration
>> language. It's interesting, especially if you think bridging can
>> scale.
>>
>> * Mesh routing protocols: While the default in cerowrt is babel, we've
>> been tracking the progress of quagga-re closely, which includes bgp,
>> ripng, ospf, ospfv6, isis, and babel. We also make available olsr, and
>> xorp - which is roughly a superset of quagga, with additional support
>> for multicast routing that I haven't explored, because xorp is kind of
>> large. It is however widely used.
>>
>> Regrettably the xorp package is mildly broken at present (just needs
>> love from someone) and someone needs to fix it, if they care. At the
>> moment, quagga gets most of the other interesting protocols available,
>> so I don't care. That much.
>>
>> * tcp-ledbat: ledbat is the underlying protocol of current bittorrent,
>> and it has problems.TCP-ledbat is an implementation for tcp, and is
>> available by default.
>>
>> * Test tools: One of the things I'm happiest about now is that the
>> netperf tool now has the ability to change socket priorities,
>> tcp congestion control algorithms, and TOS/Diffserv settings on the
>> fly - for both sides of the test - via remote control.
>> Interestingly - Diffserv settings don't generally survive an ipv4
>> connection across the internet, ipv6 settings do.
>>
>> There are innumerable test tools that we have available (shaperprobe,
>> ditg, lft traceroute, etc)
>>
>> * Multicast: Multicast was a hot topic in the 90s and nearly dead now,
>> except for those few critical applications where it's absolutely
>> required. (which is a broader category than most people think. Without
>> multicast dns, dhcp, and radvd, none of our networks would work at
>> all) Being able to use it again, at a higher level application, seems
>> like a useful avenue to explore in the context of a home. Available
>> since the first cerowrt boot camp has been a version of multicast ftp
>> (uftp), pimd is on by default, mrd6 is there but too buggy to use...
>>
>> That about covers all the sexy stuff that I can remember.
>>
>> I've finished adding these all back in the build that I could, for my
>> next attempt at a release late this week.
>>
>> happy hacking.
>>
>> --
>> Dave Täht
>> SKYPE: davetaht
>> US Tel: 1-239-829-5608
>> http://www.bufferbloat.net
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



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