From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.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 2EF68200ABA for ; Thu, 22 Sep 2011 14:27:09 -0700 (PDT) Received: by iagv1 with SMTP id v1so5801430iag.16 for ; Thu, 22 Sep 2011 14:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iA+zost2LaIhIlqEe2uxpwMU/d5NHXxD07lmzuYqSiY=; b=qAD7YkPSzgzl4QIcITSjOfL2Hik+ir+mI5tXFABTBzHLGpHuTLD3cmhZqQ54caIbvZ bXuopnnFzBQjukG7BEDO4p8Nqm2kHvCFBX7ub9Sx9V+iahkBycPqYrQxbSyEscOWqQfo fWz6n5xyDlJF+m608qMJYkROUDtTvW7tGMfsk= MIME-Version: 1.0 Received: by 10.42.174.9 with SMTP id t9mr2923454icz.183.1316726821867; Thu, 22 Sep 2011 14:27:01 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Thu, 22 Sep 2011 14:27:01 -0700 (PDT) Date: Thu, 22 Sep 2011 14:27:01 -0700 Message-ID: From: Dave Taht To: debloat-proposals@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Debloat-proposals] shortening the OODA loop X-BeenThere: debloat-proposals@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:27:09 -0000 The introduction/overview section is excellent. However, re: "The generally dysfunctional eco-system around development, deployment, and maintenance of common CPE. An open-source, easily extensible, maintainable CPE platform will enable improvements to performance, security, and implementation of new features." I like to view the methods we are using right now as 'shortening the OODA loop'[1], where, by feeding new requirements more directly into an OS kernel, and related software, then letting them trickle-down and out naturally, we more rapidly get an end result everybody can use. Those feeding those requirements into the process and contributing people and dollars get their results faster... I have no idea how to say that in a business-like document! Moving to section 2: "General Workplan" "An open source R&D platform to be used by carriers and vendors for testing reference or experimental implementations of protocols, features, and metrics" well, we had defined cerowrt's initial goals[2] as: "a build of the OpenWrt routing platform intended for use by individuals, network engineers, researchers, teachers, and students interested in advancing the state of the art on the Internet, and in particular, those investigating the problems of latency under load, bufferbloat, wireless-n, and the inter-relationships between various TCP & QoS algorithms." The latter is actually of broader scope than the former, as we'd intended to build something that was general purpose enough to layer all sorts of tools on top of, open source or proprieatry, for anybody. For example, the bismark project was once, and may be again, based on cerowrt. But this phrasing in the former seems kind of exclusive of leveraging the open source resources and people we need to actually enable the carriers and vendors, in partnership with their users, in order to create new features, demand, and products. Which gets me to: "An open source platform for vendors to use as the basis for production CPE on various hardware and various media, not unlike openWRT today but more flexible, more secure, and easier to modify" which is a much more difficult end goal than I anticipated. It almost implies a fork, an entirely separate product where we end up needing far more staffing just to keep inside the already difficult OODA loop we are trying to get inside of, risking a re-occurrence of the dysfunction we are trying to fix in the first place (a 5 lag between primary development and deployment of core OS features) After identifying openwrt as the least dysfunctional project that had the best chance of feeding back features into the mainline projects... (which we've been successfully doing).. We had intended to "*improve* openwrt to be more flexible, more secure, and easier to modify" - as well as improving the related tools[3] that everyone uses including the upstream linux kernel - fixing the underlying code in the network stack - in the hope that more polished distributions downstream, such as dd-wrt, or gargoyle - or open-embedded, android, etc - or redhat/ubuntu etc - or apple/IBM/etc - can pick up the techniques therein to improve the overall health and scalability of our increasingly complex internet. My assumption has also been that what we do can apply also to cable modems and LTE gear in the long run. As well as servers. For example, 'the basis for production CPE' may imply a functional gui component, which is something that nearly every vendor wants to customize to suit. So a bit more clarity on goal #2 above is in order. Certainly an end-product is doable, given a funding level of say, MontaVista's, but I don't think anyone wants to go there, merely picking up the pieces of what the vendors cannot seem to do seems saner. Lastly: OODA loops have one major flaw in that they are great for producing disruptive technology but terrible for the long term maintence of it (to use OODA in its more common context, it's great for armies at war, and lousy for police forces) [1] http://en.wikipedia.org/wiki/OODA_loop [2] http://jupiter.lab.bufferbloat.net/cerowrt/about.html [3] I'm going to go into the packages on top of linux (and most other unix derived OSes) that need love, later --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com