From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C936E200CCC for ; Wed, 11 Apr 2012 12:37:20 -0700 (PDT) Received: by werm1 with SMTP id m1so1524058wer.16 for ; Wed, 11 Apr 2012 12:37:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=D6e6X2qBKIGrUUVvfnlgg0LEhriWszG01kkt/S/uUo4=; b=kNWtwhj3nxfR4lOi9r9D2bTAKeztGS8edHii21VwVCScHnaYoyXeoLVdFTI1nbd7kg /blV/L7+mLNJ6rCWGfLApD+BBwj6AL8xqcx867Yrrc3YNi5K044QLLOT884++BBWKqUS eTqtWY9BzYRiXnLDw1kcn08mOI9NUsPtCHZ0pjv5DcxkuP6+GbHKsbkLxjlTH60viiaN ad3vOAN5DFq0H/eJxohOSo7Jfi5rzSodOT1bdcuC3yJl6nL8/3jkZMb8cM8gOdrvbSwf CD6nUFOepQqU/c274bBSZDcYeTHb4pjCIWbbwfu+rBYD4Ic38JX+OnmSDEWKRWq3YP1A yMZw== MIME-Version: 1.0 Received: by 10.216.136.145 with SMTP id w17mr9010230wei.98.1334173037995; Wed, 11 Apr 2012 12:37:17 -0700 (PDT) Received: by 10.223.155.141 with HTTP; Wed, 11 Apr 2012 12:37:17 -0700 (PDT) X-Originating-IP: [198.28.92.5] In-Reply-To: References: Date: Wed, 11 Apr 2012 21:37:17 +0200 Message-ID: From: Maciej Soltysiak To: Dave Taht Content-Type: multipart/alternative; boundary=0016e6d7ee85ffa9d204bd6c5daf X-Gm-Message-State: ALoCoQmz3CGPbs0RCmsbrcpXz46ZzMBpNzwfRZfTMeeccRZNUffM2PFVXr7bThvycWXd07TKfexA Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] some of the advanced stuff (sort of) in cerowrt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:37:21 -0000 --0016e6d7ee85ffa9d204bd6c5daf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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=C3=A4ht > 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 > --0016e6d7ee85ffa9d204bd6c5daf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!
=C2=A0
Those are very exciting things you're taking about Dave and surely= the way to go forward.
=C2=A0
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, bufferblo= at;=C2=A0improves=C2=A0"snappiness"; provides flexibility and eas= e to using apps. By that I mean:
1) QoS, ACM and bufferbloat work - which is very good at the moment fo= r me and I appreciate that very much!
1b) TCP FastOpen - indeed sounds exciting and but also Proportional Ra= te Reduction (http://lwn.net/Ar= ticles/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 in= tertwined (?)=C2=A0but cero=C2=A0has these=C2=A0packages currently (3.3.1-4= ) broken.
3) miniDLNA - DLNA is a good low-latency (?) / high-throughput use-cas= e within the wireless (laptops, picture frames) and wired (TV, NAS) home ne= twork. Also minidlna package is broken too.
4) Some still sexy stuff for me: DNSSEC, IPv6

Regards,
Maciej
=C2=A0
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&= #39;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
availabl= e to a wider audience to play with, on something that cost 100
bucks...<= br>
Simply getting to where we had a reliable, well understood, base
platform for real world day to day use - AND research - has taken all
ye= ar, 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 lon= g enough as it is! - but
the intent was to make them available as option= s. I plan to make as
many of these available as possible in the next builds, and
installabble= via the opkg utility.

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

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

* HIP. B= oeing uses this to control industrial machinery inside of
other peoples&= #39; lans. It holds great potential as =C2=A0means to keep your
refriger= ator updated and safe, as well as provide a useful abstraction
for separating a host's location, from it's identity.
I'd ho= ped to try this for things like snmp monitoring.

regrettably openhip= has a tough problem right now with puzzle
generation in the D1 crypto s= tep on mips and while fascinated by
problems like that normally, ENOTIME. I'm going to build it, merely to<= br>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 th= e few universal single signon
facilities that actually works. It's amazing how much nicer my life is<= br>when I'm at a facility that has it on. I don't ever have to logi= n 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 te= chnologies. IPsec is supposed to be an intrinsic part of any
ipv6 implem= ention. It usually is not, as it's rather thoroughly
over-engineered (and underthought-out when it was developed), but
Strong= swan 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
corpo= rate firewalls that I gave up on it, but that doesn't mean it's aproblem 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
ava= ilable, 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 appli= cations 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 t= he 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 b= een 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
1= 0% 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 w= alker got previous version of ccnx to build, I updated to the
latest release and broke it. :(

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

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

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

* tcp-ledbat: ledbat is the underlying p= rotocol of current bittorrent,
and it has problems.TCP-ledbat is an implementation for tcp, and is
avai= lable by default.

* Test tools: One of the things I'm happiest a= bout now is that the
netperf tool now has the ability to change socket p= riorities,
tcp congestion control algorithms, and TOS/Diffserv settings on the
fly = - for both sides of the test - via remote control.
Interestingly - Diffs= erv settings don't generally survive an ipv4
connection across the i= nternet, 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 applicatio= ns where it's absolutely
required. (which is a broader category than most people think. Without
m= ulticast dns, dhcp, and radvd, none of our networks would work at
all) B= eing able to use it again, at a higher level application, seems
like a u= seful avenue to explore in the context of a home. Available
since the first cerowrt boot camp has been a version of multicast ftp
(u= ftp), pimd is on by default, mrd6 is there but too buggy to use...

T= hat about covers all the sexy stuff that I can remember.

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

happy hacking.

--
Dave T=C3=A4ht
SKYPE: d= avetaht
US Tel: 1-= 239-829-5608
http://www.buffer= bloat.net
_______________________________________________
Cerowrt= -devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
=

--0016e6d7ee85ffa9d204bd6c5daf--