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

Wed Apr 11 15:37:17 EDT 2012

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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20120411/2d4055ec/attachment-0002.html>