From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9EC2A21F36E for ; Mon, 15 Dec 2014 14:52:10 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id v63so8790393oia.15 for ; Mon, 15 Dec 2014 14:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0w2sfJzhaH1XjFcCBEJ8Lc+bMc7uFN0jXYPSJ1E8PhU=; b=Jj0zW18LOyGS+xfqchf+DvLA2zLzCzGuZJbLAYj4CS/yvngZkUv4s7amBABY/my7nG 1m0lV2zGiQhgcnUZp4uYPy5qqgUzSNj2Tjp6759le4vQ9Odj87jwmqPrl9HZN8payTNO FVNve9UjfBNzeeUFpRCFrqjrSyLNJvEE17JzB6svle1+XgCALKZw55LDcvG+ucBlMaZA /vGRX4Uvuu1RxK7QBhnM9472NDNBOfptphkXEACSs8dThZzLtliOaFNVs1uNLYMRxyy2 0cY1yAwSG4Dnn++tajd2E6N0dVKmkRk/WfIzZJIHCBlFRfBFJR5I+2s6WEheNNDw+/a3 NIcg== MIME-Version: 1.0 X-Received: by 10.60.47.74 with SMTP id b10mr2849043oen.41.1418683929209; Mon, 15 Dec 2014 14:52:09 -0800 (PST) Received: by 10.202.227.77 with HTTP; Mon, 15 Dec 2014 14:52:08 -0800 (PST) In-Reply-To: References: Date: Mon, 15 Dec 2014 14:52:08 -0800 Message-ID: From: Dave Taht To: Vint Cerf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] that perpetual quest for funding 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: Mon, 15 Dec 2014 22:52:38 -0000 On Mon, Dec 15, 2014 at 12:12 PM, Vint Cerf wrote: > i wonder whether we could interest DHS S&T directorate in this - I will a= sk > Doug Maughan. Dear Vint: Thank you for responding... and apologies! now you are stuck with a long email.... It is not clear what you mean by "this", do you mean my original list below, now expanded? In my case, I was having difficulty translating from your blog entry and RFP into something I could write a proposal for. I find us (bufferbloat.net, cerowrt), living far outside of part of the language and assumptions built into it... "Researchers interested in the Expedition Lead Grant should build a team of PIs and put forward a proposal outlining a draft research roadmap both for their team(s), as well as how they propose to integrate related research that is implemented outside their labs (e.g., Individual Project Grants). For the Individual Project Grants we are seeking research proposals relating to the IoT in the following areas (1) user interface and application development, (2) privacy & security, and (3) systems & protocols research. Importantly, we are open to new and unorthodox solutions in all three of these areas, for example, novel interactions, usable security models, and new approaches for open standards and evolution of protocols. " where there is a 4th area... ...where our unorthodox solution(s) at bufferbloat.net is that the cross-disciplinary team includes everybody that *has bothered to show up*, from academia, to hackers, to industry... and outputs code, lots of it, far more so than papers. Running code. Now widely used code. The conditions of this new grant process includes: "The one year Expedition Lead Grant ranging from USD $500,000 =C2=AD $800,000 is meant both for program management as well as funding mostly graduate level research (PhD./post doc). We encourage applications from PIs who are willing to dedicate a substantial portion of their research time to this expedition. For the graduate students funded through the program we assume a significant portion of their time will be dedicated to this research."" So... I guess we could count as program management in this case? (I am getting closer and closer to writing a grant proposal for this process, but some of my answers to some of the basic questions are going to be pithy), and our devs and researchers are worldwide, with quite a few in europe. Dealing with patent-hungry US universities has become a PITA.... I have no problem with funding grad students... but I would certainly like to find a program or programs that would let us hook up grizzled old open source programmers to them, on whatever fronts seem most fire-full, on producing code that works and is deployable, however unorthodox. IoT devices look a lot more like stuff designed in the 70s and 80s than anything more modern... I am sad that code as a tangible deliverable is not called out in any of the RFPs I have looked at so far this month. Without that, you end up with riteproject.eu. As for a team of PIs, we've got plenty of candidates. As for resources, it depends on whatever volunteers show up. As for focus, well, it took 2 years longer to do what we planned to do with bufferbloat.net and cerowrt, but we did it, and a ton of the internet runs through that code right now, and more every day. As for roadmap... does ensuring that every new device have the needed code available for it, count? Does fixing each bug that crops up, count? Does maintaining what is deployed and fixing it, count? What of the below, laid out more fully, could qualify under these conditions? What is a viable roadmap that makes sense for outputting usable code, rather than papers? ... Side note ... I have to admit, after surveying the security and reliability of many IoT devices, that I feel the field needs a complete do-over, starting with the cpu designs themselves. We are facing a complexity collapse in connecting mmu-less processors to the wild and wooly internet, in particular. The only worthy projects I've found on that front are a long way away from realization, although one is insanely promising: http://millcomputing.com/docs/security/ . I would like to know what else is being done in that area. I'd sleep better= . we have spent the last 2 years on this list, on a mostly fruitless quest, for better hardware, and I really wish, in an age where a spare billion transistors is cheap, that we could also match up more EEs with more programmers, and there were more open building blocks to making better hardware. Open up any FPGA design tool, and nearly the first thing you have to do is start licensing IP components.... ... So these are the kind of problems we've been working on, in our spare times... there are easily a dozen more, some of which fit into https://docs.google.com/file/d/0B3B49KOvpS8TbnRlcDVDOTdlYmc/edit ... 0) make-wifi-fast: I have pitched this all over - meraki most recently - IEEE back in september ( http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-= 0wng-More-on-Bufferbloat.pdf ) - inside google - at ubnt, qualcomm, and elsewhere - as the research has shown that once gateways get faster than 20mbits that wifi becomes the next bottleneck, and we have at least some algorithms now, that can make APs and stations work much better at higher rates and longer distances. JG has a substantial list now of every bit of research, pending code, and ideas outstanding that can be tried to make wifi work better. Merely keeping wifi working at all - a service billions use now, and billions more will later - is becoming a problem with the AP densities we have in major cities already. Making wireless technologies work better is in everyone's interest, and yet, with the chips costing so little now, very little research has been effectively focused on them. There has been some really bright lights on the horizon for it (outlined in jg's list).... 1) VPN with fair queueing and quality of service A few weeks back I came up with a nifty way to make IPv6 based vpn's almost as performant and low latency as non-encrypted traffic. Core idea outlined here: https://plus.google.com/u/0/107942175615993706558/posts/QWPWLoGMtrm and why, here: https://plus.google.com/u/0/107942175615993706558/posts/1vv6= 9Z1LJkf It'll work. Easy. Just needs a bit of hacking for nearly any userspace vpn. Don't think ipsec is doable, could be wrong... I submitted a proposal to further develop it with newamerica, forced myself to stop writing the code as I have other things to do, like write more proposals. maybe someone else will finish the code before I get around to it. would make a nice paper, when done. Would be even better, with code, widely distributed. 2) Codel improvements We have a bunch of codel and fq_codel improvements slowly underweigh, including one that fits on 32 byte cache line and is probably realizable in hardware. Would love to develop a smarter switch with fq_codel and soft-rate limiting built in, and release it under the BSD or GPL licenses... Jon Morton has a fq_codel + classification + htb version of a new qdisc, called cake, which works with and without a software rate limit, without any of the currently needed added complexity for complex classification... All this stuff is baking, slowly, with what work we put in in our spare tim= e. 3) source specific routing Making ipv6 more routable, from/to multiple providers, and across networking domains, is needed when nat is unavailable. We've got most of that solved. (it would be neat to make a vpn work over it too!) 4) prefix distribution and mdns-proxy new ietf protocol called hnet is lagging in coding... The mdns-proxy and related work around ssdp is needed for many iot devices. a version of hnet that worked on 6lowpan would be nice. etc... 5) DNSSEC we have run into a few issues with making dnssec more deployable aside from the toy clock one. Notably fragmentation has been a problem. WIP. 6) cerowrt Since FT development of cerowrt ceased in june, multiple devs here worked to take the fully baked ideas (like bcp38 support, the sqm fq_codel'd system, dnssec, etc) into mainline openwrt, and these are now generally available as part of the ongoing chaos calmer development process for hundreds of platforms, on every architecture, with thousands of other worthy fixes and ideas. Drilling down into this list makes me very, very, very happy: http://downloads.openwrt.org/snapshots/trunk/ Enough spit and polish bug fixes have now landed in openwrt to make it worthwhile to do an incremental upgrade to cero or to flip it into the chaos calmer process, with the relevant kernel update and bufferbloat fighting improvements like "cake"... and multiple other more actively developed sub-distros have also been evolving: https://forum.openwrt.org/viewforum.php?id=3D16 The less-baked ideas in cero (notably a firewall system that does not need reloads when underlying IPs change, make-wifi-fast, the mdns-proxy, and the hnetd ipv6 distribution protocol) continue to cook, but at a vastly slower pace. It is not clear that doing cerowrt as we did it is the right thing, it might and we continue to flail at finding ways of meeting new requirements with good hardware, for example, we've hit a wall on the old mips processors of about 60mbit of inbound rate and queue management where isps are starting to deliver speeds greater than that, but seriously overbuffered and badly managed. thanks for letting my spill in your mailbox. /me goes back to writing other proposals for the next year > > v > > > On Mon, Dec 15, 2014 at 1:31 PM, Dave Taht wrote: >> >> I saw this go by today... >> >> https://drive.google.com/file/d/0B-ybA8_Lt-gwc2RUWnN5eFFoekE/view >> >> also: >> >> >> http://venturebeat.com/2014/12/12/google-launches-the-open-web-of-things= -inviting-research-proposals-to-advance-the-internet-of-things/ >> >> I really hate that I do not qualify as an "academic"[1], nor do the >> other many open source developers advancing the state of the art - and >> probably would have trouble passing that particular bar... nor do I >> know what, specifically we do here that could apply to the parameters >> of this grant program... >> >> ... but doing another cerowrt version, make-wifi-fast, tinc-fq, >> fq_codel improvement, or any of the half dozen things like making >> dnssec, ipv6, or source specific routing more deployable... >> >> that we have done as outgrowths of the bufferbloat effort... >> >> on the same budget (nearly none) as we have survived on for the last 4 >> years, is just *not in the cards*. >> >> At least not for me! It's been fun working with you all, and >> wonderfully productive... but I'd like to get off of top ramen. >> >> Are there things in the above, in the context of making home >> networking safer/smarter/faster/better, that could apply? Or any >> context, really? (benchmarking? simulation work) >> >> I did submit a proposal elsewhere for the "make fair queuing work well >> with vpns" idea that I proposed on this list earlier this month, >> rather than sit down and spend the time to actually do it... >> >> ... and I am looking over various other SBIR and NSF style grants. >> >> ... and trying to figure out what to do next year, that makes sense. >> >> -- >> Dave T=C3=A4ht >> >> [1] I would really like to find a way to partner up formally with a uni = or >> two. >> >> http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks