Complex Problems (Was: Re: Discipline of Internet Protocol Engineering)

[Dave Crocker]

Keith,

>> IETF work has been notably successful only when it has done bite-sized
>> bits of coherent work. It has attacked complex issues successfully
>> only when it has attacked the issues piecemeal.

KM> I think we have had far more failures than successes by attacking issues
KM> piecemeal. 

This sub-thread has really excellent potential for becoming a rat-hole.
However the divide-and-conquer principle that I am citing clearly is
interpreted differently by different people.  So, perhaps it is worth
trying to dodge the rat-holes, while trying to explore the matter
substantively:


Solving a big, complicated problem by trying to develop a single,
coherent specification -- no matter how many documents; the point is
about making all the bits of work proceed in lock-step -- is a
well-known way to ensure failure. One only needs to look at OSI in
general, and X.400 in particular. (And by way of anticipating one of the
rat-holes, I'll note that X.400 achieved the rare success of having too
much be integrated all at once, but still lack core bits of
functionality.)

The usual logic for explaining this problem is that the complexity of
juggling all the issues, across the entire service, simply buries the
development effort. At best, it ensures that the work is produced much,
much later, often after the market has found an alternate solution. (And
that is, most certainly, what happened to OSI. I can elaborate on this
is some detail, if anyone really challenges this point.)

Breaking down a complex problem into smaller pieces that are
individually useful does two things that are quite good:

1) It permits each piece of work to be useful, even if some other piece
of work has a persistent problem; and 2) it permits turning the crank on
the specification engine more quickly and more frequently. This means
that we get operational experience more quickly and can then, quickly,
refine the specifications to match actual field knowledge. With large,
integrated efforts, the inter-dependencies mean that the whole of the
work is not useful until the most problematic part is completed. And it
means that it is quite a few years before there is any feedback from the
user community;. If there was a problem with the major design decisions
that were made, they become essentially impossible to change, because
things took so long to delivery.


A couple of examples of the success stories in the Internet:

(As an aside, I'll note that TCP and IP were originally one protocol,
but the divide-and-conquer approach was adopted prior to fielding the
technology.  This makes exploring and delivering new transport modules
far easier.  Had this not been done, we'd be using TCP even when a UDP
would have been sufficient.)

Is IP a failure?  Besides independent development of TCP and UDP, from
the IP core, ICMP has been able to proceed independently, as has
different address-mapping efforts and, for that matter, address
interpretation efforts.

Is email a failure? Transfer services and content services have
proceeded with considerable independence. This permits multiple transfer
services. (Though folks might think there is only SMTP, there are
others, and there used to be more. So another bonus from good
divide-an-conquer is vastly superior adaptability to changing
conditions, such as adoption by "fringe" or "new" networking stacks.)
And note the several large, integrated efforts to replace the
ridiculously limited capabilities of Internet mail -- notably to achieve
multi-media. By contrast the silly, ugly, inefficient functional module,
called MIME, retrofitted multi-media onto Internet mail with remarkable
success and remarkably quickly.

(One could go down a rathole about nonconformance, noting how badly we
suffer from excessive variance in email system behavior, but I claim
that is due to lack of enforcement, rather than due to any architectural
issues. Given the wide range of support for HTML, and the like, this
might be an applications-level issue. But it is not a big-vs-small
design effort issue.)

In fact, this highlights one of the other, surprising benefits of a
divide-and-conquer approach, namely that it permits post-hoc additions
that were not planned.  When the original philosophy is to do as little
as possible to be useful, knowing that more bits of related work will be
done, then it often is easier to do some of those bits many years later.


d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>