* Re: [Cerowrt-devel] that perpetual quest for funding
2014-12-15 20:12 ` Vint Cerf
@ 2014-12-15 22:52 ` Dave Taht
0 siblings, 0 replies; 3+ messages in thread
From: Dave Taht @ 2014-12-15 22:52 UTC (permalink / raw)
To: Vint Cerf; +Cc: cerowrt-devel
On Mon, Dec 15, 2014 at 12:12 PM, Vint Cerf <vint@google.com> wrote:
> i wonder whether we could interest DHS S&T directorate in this - I will ask
> 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
$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/1vv69Z1LJkf
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 time.
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=16
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 <dave.taht@gmail.com> 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äht
>>
>> [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
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply [flat|nested] 3+ messages in thread