Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches

From: [email-masked] (Noel Chiappa)
Date: Wed, 7 Dec 2005 22:54:14 -0500 (EST)

> From: Joe Touch <[email-masked]>

    > Like when IEEE approved two competing - and interfering -
    > technologies for 802.11?
    > What results is fun if you like market competition, and horrible
    > if you like interoperability (the cornerstone of the _Inter_net).

Having two different non-interoperable choices for one component can be
a problem, but it's not an *architectural* problem. (And it's only a
problem when its a thing where you want to have wide-scale
intercommunication. For things like IGP's, it doesn't seem to have been
a problem to have several.)

Architecture is the fundamental framework one operates in, so it
includes things like what namespaces you have, and what their
properties are; it also includes how the overall system is divided up
into sub-systems (i.e. where the module boundaries are), and what their
interactions are (i.e. what the interfaces look like).

The kind of architectural problems the Internet has been seeing happen
when we want to expand what the overall system will do (either in
functionality, or whatever), and the basic framework won't do that
thing easily, and instead of rethinking the entire framework at some
suitable point, we make some small tweak just to do one specific thing
- or, worse yet, break some systemic assumption, and do a kludge.

The problem has been that that architectural reworking is painful, and
expensive in the short run, and the local-tweaks/kludges approaches
*look* less expensive - because they are, *in the short run*.

All of which is a completely different kettle of fish from the problems
caused by two choices for the protocol to do X.

    > All that means is we'll all have to wait _until_ the market decides,
    > which delays everybody just so a few capitalists can have fun. ;-)

It turns out to be economically advantageous to company X to lock
customers into proprietary solution P, as opposed to using generic,
open solution G (might be a protocol, might be an OS, might be a kind
of CPU). The customers eventually wake up and decide that G is better
for them. So there's always this tension, and how long it takes to go
away depends in part on the overall costs of having {P0 ... PN} instead
of G.

For end-end communication protocols, having {P0 ... PN} limits the pool
of people you can communicate with, so there's a big incentive to
migrate to G. For access protocols/technologies (your 802.11 example,
IGP's), the cost is less (and there are sometimes benefits, too), so
multiple choices will persist.

	Noel

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Dec 2005 08:57:49 -0800

Noel Chiappa wrote:
> a problem, but it's not an *architectural* problem.

Not *necessarily* an architectural problem.

However, we've allowed a number of choices which are non-interoperable
with the (at the time) existing architecture - such as NATs. Whenever we
have such choices, we do need to understand whether they alter the
existing architecture.

The problem isn't that such cases aren't made - some of us made them at
the time, and continue to do so. The problem is that immediacy and
commercial ubiquity is substituted for architectural considerations.

I wish RFCs had manditory Architectural Considerations sections; sadly,
they have manditory 'just-about-everything-else' sections instead.

> away depends in part on the overall costs of having {P0 ... PN} instead

Market tension with proprietary solutions are fine. When those solutions
are proffered as architectural extensions - in the absence or even
despite conflicting architectural analysis - then we're in trouble. Like
we are now.

Joe

---

From: Ted Faber <[email-masked]>
Date: Thu, 8 Dec 2005 09:59:30 -0800

> interactions are (i.e. what the interfaces look like).
[more stuff I agree with snipped.]

One of the things an architecture does define is those sets of things
that elements of the system do have to agree on.  You allude to
interfaces, but one could easily talk about network packet formats (or
the equivalent).  It's difficult to imagine a system that is architected
but where all components are open to multiple non-interoperable choices.

IMHO, an architecture needs to keep that set of things small - so that
one can keep track of them - and architects need to defend that small
set.

But I doubt we disagree on this.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Aaron Falk <[email-masked]>
Date: Mon, 12 Dec 2005 15:32:43 -0800

> a problem to have several.)

Diversity is a bigger problem when it comes in a "spanning layer", like IP 
(see section 2.2.1 of [1]) since these layers are intended to enable 
interoperation.   For other layers, the cost of 'let a 1000 flowers bloom' 
is less.

--aaron

[1] NewArch Final Report 
<http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>