Subject: RE: [arch-d] Defining terms

From: [email-masked] (Noel Chiappa)
Date: Wed, 22 Mar 2006 08:51:58 -0500 (EST)

> From: Alexis Turner <[email-masked]>

    > the current Internet is nothing but a series of patches building upon
    > endless series of patches. At some point, engineering a system that is
    > held together by tape and string .. becomes an excercise in both
    > futility and stubborness .. 
    > Who on this list would realistically disagree with that? Can we
    > honestly say the current system is not broken as hell?

Basically nobody (maybe nobody at all) disagrees with that. The problem
arrives when you get to the next step:

    > It is at that point that the system designers must take a step back,
    > learn from their mistakes, and start over from the beginning.
    > ...
    > If we continue to insist on making something that works with the
    > current system, the predecessors will remain broken.

I'm not sure if quite as many agree with this position (that a re-think is
needed), but that's not the issue. The problem comes when you consider any
non-incremental change - and moreover consider *how to get it adopted
widely*.

It's relatively easy for me (or any number of other talented system
architects) to sit back, reflect on what went wrong, and what we've learned,
and come up with cool new architectures. (Been there, done that, as have
several others.) It's also relatively easy for me (or any number of other
talented engineers) to figure out an interoperable way to deploy this
wonderful new architecture. (Been there, done that too.)

What nobody has ever figured out a good way to do is get such a new
architecture actually deployed, i.e. get community consensus that this
wonderful new architecture is the way to go. By definition, any
non-incremental change represents something of a leap into the dark - and a
system this size, and in widespread production use, contains a lot of people
who have the kidney-output-fluid scared out of them by the concept of large
jumps into the dark.

Plus to which there will be large fractions of people who say "oh, that's a
bad idea, we need to do this other thing instead" - and of course, the more
radical the change, the more likely there are to be people (smart people,
people with experience) who have a different view of what the Right Thing is.

Look at how difficult it is for something as simple as HIP to get any
traction - and even now, it's still pretty much a fringe thing, which will
take many years, if ever, to really catch on widely and ubiquitously. Now
multiply the difficulty of doing anything that relatively minor by an
exponential factor for anything major - e.g. a whole new routing
architecture. (Been there too...)

I wrote a longer screed on this issue a month or two back, in reply to Tony
Li (can't be bothered to dig up a URL for it, sorry - gotta run) - you might
want to re-read that for a longer discussion of this problem.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Mar 2006 10:57:48 -0600

> wonderful new architecture is the way to go. ...
>

I could not agree more.

To gain more perspective to this, I found it very interesting to hear  
from Dave Clark last night that we (the IETF) have had these problems  
at least since 1992.  Being a relative newcomer to the IETF (my first  
IETF was in 1997 and only 2001 I started to come to these events even  
semi-regularly), I have had great illusions of the IETF leading the  
Internet to the future and the IAB doing real work in its role of the  
architectural oversight.

However, what I can say from my limited experience to being in the  
IAB, many of the IAB members are painfully aware of the difficulties  
related to IAB's architectural role.  Personally, given my current  
stand, I would go as far as suggesting that the IAB should be renamed  
to be the Internet Activities Board, if for no other reason to remove  
the illusion that they were _doing_ anything substantial on the  
longer-term architectural issues.  Yes, the IAB could _facilitate_  
architectural work, and in a way they are (we were) doing that by  
creating this list.  It remains to be seen what the new IAB decides  
to do.

Scaling back to more technical issues, what I find encouraging is  
that HIP version 1 is now basically done.  The drafts are ready,  
waiting for security area review, and we found a volunteer for that.   
There are three interoperating open source implementations.  Some non- 
research projects are starting to adopt HIP.  If this is anyhow going  
along Geoffrey Moore's Chasm model, HIP is now entering early  
adoption phase and some people are looking for the first pins to bowl  
over.  Sure, the chasm is still ahead and HIP may never get over it,  
but at least it is affecting people's thinking in SHIM6, BTNS, and  
some other working groups.  Hence, it looks like that medium-scale  
architectural work (such as HIP) is not complete waste of time, even  
at the IETF.  It just requires a number years to have any effect; in  
HIP's case the idea is now about 7-8 years old.

So, my still-untested recipe for architectural work seems to have the  
following ingredients:

1. Prepare to _continuously_ work on it for at least 5 years; 10  
years might be more realistic.

2. Try to gain enough of social traction early on so that the work  
continues even when the first leaders tire.

3. Do not hope the IETF leadership to lead.  They are too busy  
preserving, conserving, and struggling with the inevitable power  
games.  What you can ask for, though, is a little bit of footing to  
use as a marketing ground within the IETF and/or IRTF.

4. Early on, try to understand the assets out there and plan for  
piecewise deployment.  This seems to be where HIP may still trip.   
Even if we have thought about this quite a lot, it looks like both  
updating the stack and adding infrastructure (at least records to the  
DNS) at the same time is just too much.  Opportunistic HIP may have  
better prospects, but it hasn't been completed yet.

5. Remember the list of issues that kill the next big thing:
- works badly with NATs
- 80% solution already available
- needs a kernel change
- requires updating routers or other network boxes
- requires new infrastructure
- requires changing existing applications
- no business benefit for the players
- lot of research papers before its deployed
- lengthy standardization effort before its deployed
- not configurable by normal users (i.e., needs any configuration)
- cannot be used until everyone has it
While you cannot do meaningful architectural changes without ticking  
some of these boxes, trying to avoid them may pay off.

--Pekka

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 23 Mar 2006 07:35:20 -0600

Dear Pekka,

This was a terrifically helpful posting. Thank you for sending it.

Spencer

---

From: David Meyer <[email-masked]>
Date: Thu, 23 Mar 2006 06:15:29 -0800

> Internet to the future and the IAB doing real work in its role of the  

	I don't know if I'd call mine "illusions", but me too.

> longer-term architectural issues.  

	I couldn't disagree more. The IAB has a large role in the
	operational aspects of the IETF; RFC 2850 designs it this
	way. However, the IAB is also constituted in such a way
	that it can *facilitate* long term architectural
	work. That it hasn't happened to date is a different
	matter, which IMO is a function of what the folks on the
	IAB are trying to accomplish. As you (and many on this
	list) know, some of us on the IAB are trying to push some
	more *architectural* agendas.

> Yes, the IAB could _facilitate_  

	s/could/is/ 

	I admit its a slow, frustrating and difficult process,
	and that there are deep wounds that surround that the
	IAB's role is in all of this. And as you know, I've been
	trying to education people about this (since I didn't
	really understand this when I came to the IAB; see e.g.,
	http://www.1-4-5.net/~dmm/talks/NANOG35/iab).

> years might be more realistic.

	Totally.

> continues even when the first leaders tire.

	Yep.

> use as a marketing ground within the IETF and/or IRTF.

	While I'm not good with authority of any kind (shocking
	to you all, I know), I find this statement not only
	unfair, but it also forms a kind of ad hominem attack on
	the I*. Yes there are politics (inevitable when humans
	are involved, it seems), but really, this kind comment is
	out of scope and inappropriate. And BTW, you might also
	want to disclose your conflict(s) of interest on this
	point; that would give your readers the context they
	need to interpret your comments.

	That being said, one of the many things I've learned
	during my year in "IETF leadership" (IAB in my case, but
	I've also been lucky enough to be liaison to the IESG, so
	I get to see into that process a bit as well) is that the
	I* is populated by some very hard working people who, for
	the most part, sincerely care about the Internet and its
	future.

	In any event, yes, there are politics, etc, but
	notwithstanding that, if you want to get something done,
	you

	(i).	Have to actually do something
	(ii).	Be willing to take some chances

	Both are difficult in the best of circumstances, and the
	challenges are only exacerbated in a volunteer
	organization like the IETF. So yes, the IETF can be
	frustrating at times (what isn't), but my sense is that
	there's a lot more that's good about the IETF than
	bad. And BTW, one can complain all day. That's not going
	to help the IETF, or the larger Internet community. OTOH,
	working towards our shared goals will. 

	So how about leaving this kind of poison behind and
	focusing on our shared goals?

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 23 Mar 2006 06:26:44 -0800

>	As you (and many on this

	Looking at the way I phrased this, I would have rather I
	said something more like:

	"the IAB is pursuing many *architectural* agendas."

	The reason I wanted to make this clarification is that

	(i).	The IAB is very much concerned about the
		architectrual direction (and evolution) of the
		Internet Architecture, and  

	(ii).	The IAB uses consensus based decision making

	Dave

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 09:33:06 -0500

>non-incremental change - and moreover consider *how to get it adopted

That depends on whether we are engineers or scientists.  If we are 
scientists and honest with ourselves, we need to honestly look at 
what our experience is telling us.  The guidelines for science 
(according to Newton) are

1.  Nature is essentially simple; therefore, we should not introduce 
more hypotheses than are sufficient and necessary for the explanation 
of observed facts.  This is a hypothesis, or rule, of simplicity and 
verae causae.

2.  Hence, as far as possible, similar effects must be assigned to 
the same cause.  This is a principle of uniformity of nature.

3.  Properties common to all those bodies within reach of our 
experiments are assumed (even if only tentatively) as pertaining to 
all bodies in general.  This is a reformulation of the first two 
hypotheses and is needed for forming universals.

4.  Propositions in science obtained by wide induction are to be 
regarded as exactly or approximately true until phenomena or 
experiments show that they may be corrected or are liable to 
exceptions.  This principle states that propositions induced on the 
basis of experiment should not be confuted merely by proposing 
contrary hypotheses.

paraphrased from Newton's Principia 1726
by Gerald Holton
in Thematic Origins of Scientific Thought

And while we deal in the nether land between nature and mathematics I 
think these apply.  Over the last 30 years we have accrued quite a 
lot of experience.  I contend that no one working on this was stupid. 
So what they have found and what they did tell us something about the 
structure we are trying to find.  We just haven't teased out what 
that nice elegant structure is yet.  So what is the data telling us.

Take care,
John

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Mar 2006 10:36:04 -0600

Dave,

I don't want to dive into this rat hole too deeply, but we seem to  
have a very different view of what is "doing" vs. "facilitating", or  
what "long-term" means.  I wouldn't call *anything* I did or we did  
while I was at the IAB as *doing* logn-term architectural _work_.   
Putting together the much needed bad traffic workshop, working  
specifying on what are open architectural issues, or clarifying  
existing architectural principles, is not what I would call long-term  
architectural work.  I would call all that facilitating or, at best,  
short-term architectural work.

To clarify, I am not saying that the IAB is not doing good work.  It  
is.  The work it is doing is _MUCH_ needed.  But from my personal  
point of view, I could not see the IAB _doing_ or _leading_ any long- 
term architectural work.  And, based on my experience, I think it  
should NOT.  That's why I suggest renaming it back to be the  
Activities board instead of being the Architecture board.

Had I known what the IAB really is, I had never accepted the  
nomination, because I cannot do the kind of work the IAB does.  I am  
a researcher and maybe an architect, and my ability to raise  
consensus when there are political or company undertones is nil or  
negative.  Had the IAB name not contained the Architecture word, I  
might not have had those illusions I did.

Now, this discussion does not belong to this list but to the IETF  
discuss list, if anywhere.   The only reason why I send this message  
out is that I am still pretty annoyed by the IAB members claiming  
they are doing architectural work and, very understandably, not doing  
what I would call such work.  So, a terminology issue perhaps, but  
unfortunately one that makes me quite emotional.

--Pekka