[email protected]
[Top] [All Lists]

Re: "The IETF has difficulty solving complex problems"

Subject: Re: "The IETF has difficulty solving complex problems"
From: "JFC (Jefsey) Morfin"
Date: Thu, 04 Aug 2005 16:12:16 +0200
Dear Scott,
could we phrase it differently?
I submit that we could qualify (along with your own wording) "complex" changes as bringing a "revolution". In that case the problem becomes simpler: to try to tink if there is a way to make the "revolution" a simple "evolution".

I will take an example. The Internet faces balkanisation. Balkanisation results from the unsatisfied general need for partitionning. Sovereignty, multilingualism, bandwidth management, risk containment, etc. call for it. Let analyse what is partitionning: it is to change the Internet architectural default parameters from "mono" to "multiple" (one single DNS, one single governance, one single IANA, one language, one ASCII, etc.) while staying homogenous and preserving end to end interoperability.

Once you have accepted that, partionning is no more a "revolution" IETF cannot tackle and a balkanisation a fate to be accepted. This is only a parameting "evolution" to work on (and test) which will permit the huge added value of a stable, consistant, secure, simplicity, innovative, end to end respectful compartmentailisation.

Just beware: before every ship on earth is compartmentatilised for security and strenght, we known the Titanic case. Experimentation is such needed before we can fully use externets (compartimented external networks look-alike), "the _usage_ networks _within_ the network of the logical and physical networks".

Today, I do not know anything the IETF cannot cope with. Except accepting RFC 1958 principle that there is only one thing which will not change: that everything may change. And that architecture comes before painting :-). Even ways to get funded while staying protected from commercial funding implications (RFC 3869) could be achieved.

At 07:05 04/08/2005, Scott W Brim wrote:
This conjecture was disturbing, but calling it a feature was even more
disturbing.  After a bit of pondering, and wondering what different
groups in the IETF might mean by "complex", my first thought was that
the IETF has never, ever solved one.  For example, we do QoS in small
pieces that don't fit together well.  Some claim that CIDR was such a
solution but imho it was just a tweak on what we already had.  Our
routing protocols have been fertile ground for evolution but not
revolution -- the path vector idea came directly from deprecating EGP
"metrics", we still aren't very stable and our policy capabilities are

However, after talking to a few people I thought that perhaps we are
very good at solving complex problems but we don't recognize our
greatness.  Again let me take QoS as an example.  The problem is huge
and essentially intractable because of all the competing goals.  What
we have done, without a lot of architectural planning that I am aware
of, is to find ways to divide the problem up where there is minimum
coupling across the boundaries (see footnote (*)).  That lowers the
complexity greatly.  It is a lot cheaper to have independent,
apparently "unarchitected" solutions for different kinds of traffic
and situations.

I want us to understand what our skills are and use them consciously.
I don't know if we will have time tonight, but I'd like to hear from
the IESG/IAB on the foundation for Brian's statement and what was
initially a negative assessment of our skill.  Let's look at some
example problems and think about what we have done poorly and well.  I
predict we are better than we think, but that we are hard to satisfy.
We may think of some of the things we have done as crude hacks but
they are actually pretty good solutions.  Look at tunnels, for
example.  They are kind of abhorrent when thought of in isolation but
turn out to be an appropriate means to reduce complexity in specific
situations.  Reducing complexity through cutting up the problem at the
right points is implicit now.  We could make it one of our explicit
basic paradigms.

As a corollary to making it explicit, we should be aware of where we
use this kind of decoupling and be vigilant about it.  Some users of
the IETF "product set" want to reintroduce coupling that we have
eliminated.  Be sure the trade-offs are explicitly examined.


(*) like Chuang Tzu's butcher ...

      "The joints have openings,
      And the knife's blade has no thickness.
      Apply this lack of thickness into the openings,
      And the moving blade swishes through,
      With room to spare!

Ietf mailing list
[email protected]

Ietf mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>