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

From: [email-masked] (Noel Chiappa)
Date: Thu, 8 Dec 2005 15:07:10 -0500 (EST)

> From: Ted Faber <[email-masked]>

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

Minor rant (not really related to your basic point): packet formats are about
as significant to *achitecture* as the order of arguments in a system call
interface is to an OS's architecture - i.e. not very. When I spoke of
interfaces, I was speaking in a very generic sense (e.g. one in which the
interface to the internet layer is defined in only slightly more detail than
"provides unreliable datagram service throughout the entire internetwork").

Tangentially related point (which I will use immediately below): there are
two kinds of diagram one can draw of a distributed system. In the first, one
draws separate boxes for computers A and B, and smaller boxes within each of
them for the local instance of subsystem X (e.g. the internet layer). This is
a level of detail which I claim is wholly inappropriate for (most) thinking
about architectural issues. The other kind of diagram is the one where HTTP
is a box above TCP which is a box above IP - and that's the kind that is
useful in architectural thinking.

    > It's difficult to imagine a system that is architected but where all
    > components are open to multiple non-interoperable choices.

All, no.

But first you need to qualify two different kinds of "non-interoperable", and
that refers back to the point I made above: in a distributed system,
subsystem X is divided (necessarily) into lots of components, one in each
computer which is "part of" X.

In one kind of "non-interoperable", you have two different designs of
subsystem X (call them Xa and Xb), and all the Xa sub-boxes (Xa0 .. XaN) can
only talk to other Xa sub-boxes. However, entities which want to use X can
use either Xa or Xb, and Xa and Xb are "interoperable" - i.e. clients can
seamlessly use either. (For example, a lot of protocols that use crypto stuff
treat algorithms this way.) In the other (worse) kind of "non-interoperable",
the semantics of Xa and Xb are sufficiently different that clients can't
easily switch from one to the other.

Having made that point, to return to your point, the more open the
architecture is to allowing different designs for the X functionality, the
better off you are. Yes, a more difficult trick to pull off, but wise.

(Some systems, e.g. Nimrod, explicitly had an architecture in which there
were a number of defined subsystems - in the sense of "this box does this,
and this is what is needs for data, and you get back that" - whose operation
was *not* part of the specification, precisely to maximize flexibility - not
to mention the chance of screwing something up! :-)

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

Precisely. One of the goals of Nimrod was:

  "Minimize the size of the 'core' system which must be implemented on a
  system wide basis. Such minimization maximizes the flexibility, and thus
  the lifetime of the architecture."

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

---

From: Ted Faber <[email-masked]>
Date: Thu, 8 Dec 2005 14:48:08 -0800

> "provides unreliable datagram service throughout the entire internetwork").

It *is* a tangent, and most of the time I even agree with it, but there
are some features of packet header layout and design that are
architectural issues.  And I think that goes for syscall design, too.
The primary example I'm thinking of is in extensibility of those
headers/interfaces.  The extension headers in IPv6 are an indication
that the network protocol may have to be expanded and provides a
mechanism.  Many OSes have syscalls that have similar flexible
mechanisms for passing variable numbers and types of paraneters to teh
system, knowing that the syscall interface to a given feature today may
not be the interface to that service in the future.

The headers can also be a reflection of the system designers' view of
the world and more importantly of the view that the system will hold.
The world has at most 2^32 things I want to talk to, for example. :-)

But, that's really a small tangent.  In general, whether the checksum's
a CRC or IP checksum, or whether bytes are one order or the other are
details, not architectural issues.

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