Historic archive of defunct list debloat-proposals@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: debloat-proposals@lists.bufferbloat.net
Subject: [Debloat-proposals] shortening the OODA loop
Date: Thu, 22 Sep 2011 14:27:01 -0700	[thread overview]
Message-ID: <CAA93jw7C4Mb8BrJTz-aH4vVeRhGG4k-MPXAgXuTLGKYCo5A0+A@mail.gmail.com> (raw)

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

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

                 reply	other threads:[~2011-09-22 21:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw7C4Mb8BrJTz-aH4vVeRhGG4k-MPXAgXuTLGKYCo5A0+A@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=debloat-proposals@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox