Subject: "The IETF has difficulty solving complex problems"

From: Scott W Brim <[email-masked]>
Date: Thu, 4 Aug 2005 07:05:04 +0200

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
frustrating.

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.

swb

(*) 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-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
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.
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Aug 2005 14:20:47 +0200

Well, this didn't come up in the Thursday plenary unless
my brain is more than normally fuzzy.

Firstly, it's worth re-reading section 2.3 of RFC 3774...

...OK, now you've read that, I wouldn't necessarily agree
with every word, but I think it's basically true. What I
meant to argue is that what we *are* good at is defining
elements of the Internet architecture, and the way we do
that tends to favour scaling and robustness without
needing an over-arching scalablity framework or robustness
framework. The latter part is the feature I was thinking of.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 09 Aug 2005 15:20:46 +0200

At 14:20 09/08/2005, Brian E Carpenter wrote:
>without needing an over-arching scalablity framework or robustness framework.

This is what I call the "mono" default architectural parametering of the 
Internet. The architecture permits applications to scale. The architecture 
could scale. But the architecture scalling is not tested and even mudded 
over the RFCs.
Examples: one class, one language, one IPv6 space, etc.

This leads to a robust system, but it more and more perceived as rustic. 
And the necessary evolution is carried by grassroots process (VoIP, NATs, 
P2P, middleboxes, DNS balkanisation, etc.).

Is that good overall. Maybe because it gives a common example? It worked 
until now ... I am not sure that sometime it will not anymore. No more idea 
of when as when the Gulf Steam will stop. But the impact may be even worse?
jfc