On Thu, Jul 28, 2016 at 2:24 PM, Bjoern A. Zeeb
<bzeeb-lists@lists.zabbadoz.net> wrote:
> On 28 Jul 2016, at 8:56, Dave Taht wrote:
>
>> At both ietf and BBF this past week a frequent topic of conversation
>> was how to get more open source involvement in standards orgs...
>>
>> ... and one counter-thrust of mine has always been to get more
>> standards org members involved in open source, because that dialog has
>> to go both ways.
>>
>> I thought I would point at several useful upcoming conferences in the
>> hope that perhaps there would be some members of ietf/isoc "out there"
>> planning some outreach in this regard.
>
>
> There’s gazillions of conferences as you say.  Being a BSD guy I could give
> you a list of those but that’s missing the point I think.

Well, honestly, I think a pointer to those conferences would be good too!

Bugs accumulate at the interfaces between the layers.

> What you should do is do the reference implementations for at least 2
> different (Open Source) Operating Systems before or rather along writing a
> document.

While I agree that running code and rough consensus and two
implementations is the best strategy...

One person rarely has the in-depth chops to handle internals of more
than one OS. Usually there is a need for a large team of complementary
skills. A huge problem for standards orgs are the demands of the GPL.

An over-long anecdote:

In 2012 Kathie Nichol's original codel code was in C++, in ns2. I
ported it (from that and their paper - with a ton of help!) to
C/Linux. Eric Dumazet wrote/rewrote the entire thing (not a line of my
code remains) and made it fast, and a week later, wrote fq_codel in a
single saturday afternoon, based on our earlier work with sfqred.
There were years of experimentation (decades in the case of kathie and
van) prior to that, that resulted in something that simple and
elegant. We've spent years, now, with the sqm-scripts, dealing with
the vagaries of the cable, dsl and PP* link layers. We've got nowhere
on getting a dsl firmware maker (other than free.fr) to put in the
code needed to apply them properly at the right layer there... despite
only needing BQL-like buffer management in the dsl firmware. 50 lines
of code. Not there. Grump.

We've now spent 4 years trying to standardize fq_codel. We (toke,
mostly) had to produce a text only RFC draft - due to the GPLness of
the original fq portion of the fq_codel code, so that someone else
with BSD chops could do a port, when funding was found. That happened,
finally, a few months ago.

The ns2 (BSD, kathie) and ns3(andrew mcgregor) (GPL) versions of this
code are still, almost, kinda, still out of tree patches for those
simulators, because they required a whole bunch of other
infrastructure to "get in there" (too many contributors to list)
There's been the hope that the ns3 version would finally be merged in
this release cycle, I don't know if it made it yet.

Work on "cake" (successor to the sqm-scripts) is dual BSD/GPL licensed
in the expectation that writing a RFC will be basically impossible
without reference to source code as the algorithms are too complex to
write down in english. If people have lost skills to read stuff in C,
tough, I'm not going to do a yang model.

...

honestly, if I'd known how hard it would be and how long it would take
to do, I'd have never started standardizing fq_codel. I would have
moved on, instead, to applying it to wifi, and the code would have
been available for Linux users to use 6+ billion wifi devices ago.

I've never worked so hard in my life to give away something for free,
and I'm ill-inclined to ever do it again. (at the moment).

4 years now spent, not doing stuff that would have been more
immmediately valuable, had we stuck to coding, at the current pace of
the internet's growth. I sure as heck hope that 5 years from now I can
look back at all the work of the aqm wg and see products using it
deploying faster than the internet is growing, but am pessimistic.

...

So my meta point is, standardizing something takes a lot of resources,
a lot of different kinds of people, a lot of time, and a lot of things
that should happen in parallel that end up happening in sequence.

One thought for a new ietf process might be the concept of a "funded
working group", along the lines of how linux foundation, the apache
foundation work, that handles the baseline needs of the group for
coding, testing and rfc-writing resources.

...

Innovating in userspace is much easier, except that userspaces have
evolved in radically different ways also. I have no idea, none,
whatsoever, about what would be required, to make the outputs of the
homenet wg actually work outside of openwrt (and we're working on
debian support), on iOS, OSX, Android, and Windows. Standardization
may help (but there were few if any actual home router vendors in the
room) - and certainly APIs for much stuff would be nice to have. Been
trying to get all the OS vendors to discuss sane standard APIs to the
dscp/ecn bits for over a year now, with no progress.

>That will (a) guarantee running code

Having a QA team and userbase also helps.

> and (b) a lot of documents
> will be written better, more understandable, and cover the bits that
> actually matter and won’t be “theory” only which people who have to
> implement them after the facts go head->desk().

+1. Actually implementing stuff first filters out the bad idea
quotient and noise on the mailing lists by a lot.

> That brings me to (c) as
> you’ll have a valuable contribution to actually go to one of the conferences
> and present your work there and engage with that community (and, yes, that
> can be an overlapping effort, e.g., go and discuss while you are working on
> the prototype to see what field experts think about it;  their feedback then
> will influence your implementation and the document and you are back at (a)
> and (b)).

I don't regard my end goals as writing a paper, or going to
conference. My end goals are running, deployed, correct, useful code.

I wish more people shared those, of course, and that academia, in
particular, rewarded those that made good, oft-used, deployed code,
more than those that made good, underread papers.

Certainly conference attendance is a tremendous source of contacts,
and collaborators, and far more than the actual meetings themselves, I
love the $RANDOM in the hallways and beer bofs, and that's why I go to
several different kinds of conferences, and only attend ietf once a
year.

To paraphrase what I said earlier...

the bugs accumulate between the cracks of the organizations. As for
APIs, does posix still have a pulse?

> Just half a ct from me
>
> /bz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org