CircleID

Karl, I'd like to separate your discussion into two distinct but related issues.

The bulk of your article talks about protocol design, albeit slightly obliquely. I will be the first to agree that the art of protocol design isn't anywhere near the engineering discipline I'd like it to be. The IETF has BCPs on the administrative processes of the IETF, but the nearest they come to a BCP on the actual subject of protocol design is currently RFC 3205, "On the use of HTTP as a Substrate". With all due respect to the work of the IETF, the title itself is a misnomer: it's a guild of craftsmen, not engineers, because the field itself is more "craft" than "discipline".

I don't know how inflammatory active members of the various IETF groups will find that remark. It's not intended to be inflammatory: some of the craftsmanship is high grade stuff in my opinion, but without a solid engineering discipline behind the process, an opinion like mine is just an aesthetic judgement. And, in broad terms, that's the trouble with protocol design today: there's too much "taste" and not enough cold, hard, quantifiable paradigm.

In fact, if your description of SIP is correct, aesthetic compromises (the inclusion of everyone's favourite pet encoding) are undermining one of the few rough engineering maxims we have: specifically, "if there are several ways of doing the same thing, choose one." [RFC 1958, 3.2] Engineering discipline demands that aesthetic preferences be subordinate to sound design, and we're obviously not there yet. Of course, it doesn't help that the design principles themselves read like a list of aesthetic judgements.

That brings me to my second issue: the question of turning the Internet into a lifeline grade infrastructure. You ask how it can be done, but I would first ask whether the project is a sensible goal at all from an engineering perspective. I grant you that a protocol like SIP suffers from poor engineering—or rather that it suffers from the lack of a surrounding engineering discipline, but even if it were as good as it could be, would it still be sensible to talk about making it "lifeline grade"?

It strikes me that there is a fundamental disconnect between a loose global collection of networks with a basic agreement to make a "best effort" at delivering individual packets and any kind of "lifeline grade" service. While it's true that you can build a "reliable" service on top of an unreliable one, the classic example being TCP/IP, there are fundamental limits to that reliability. TCP presents a stream-oriented connection free (with high probability) of duplication and errors over an IP transport that promises far less, but that guarantee is reached by detecting errors and recovering from them, not by magically making the path between endpoints any better than it was. If it takes all day—or all week—to deliver one kilobyte of data reliably, TCP will do it. This is not a step towards "lifeline grade infrastructure".

The beauty of the Internet is that it delivers the vast majority of packets placed on it to the desired destination at a cost approaching zero. It seems to me that this is fundamentally incompatible with any kind of "lifeline grade infrastructure" which must provide guarantee upon guarantee, each of which invariably increases the cost of delivery. It also seems to me that we are far better off with two or three "consumer grade" lifelines than a single "lifeline grade" one. The ideal emergency phone would communicate over the first available working medium of VOIP, POTS, and the emergency CB channel, rather than resting wholly on one super-reliable medium.

But that's just my intuition on the matter. I don't have an engineering paradigm in which I can demonstrate my assertions formally, particularly since I don't have a formal model of a "lifeline" and other project goals.

Brett, I really appreciate how well you isolated the essential question whether we want the internet to be a lifeline grade utility.

And I do like your suggestion that lifeline grade *applications* ought to utilize multiple kinds of communications mechanisms to find one that works.

No matter what we say or think, people are beginning to treat the internet as something on which they feel safe building their businesses, even if they are not yet ready to entrust their personal safety.  (But I have heard of people doing surgery via the net - I still shudder at the thought.)

So whether we think the net ought to be a lifeline grade utility, we could help avoid a lot of future unhappy users if we tried to at least narrow the gap between the net and a true lifeline utility.

The approach I suggested in the paper I referenced contained severl suggestions.  One was was legal liability for flaws, using some sort of negligance standard (not strict liability.) I know that people do not like this, but I feel that some sort of compulsion is needed to incite people to move to the more boring, slower, and less fun approaches that the elder engineering disciplines use; techniques such as design rules and testing from the get-go.

I picked on SIP because it is such an easy target.  On the other hand, clearly there are engineering wonders accomplished on the net - the network time protocol being one that I consider akin to magic.

Much of my perspective is colored from my family experience - my grandfather repaired radios, my father repaired TVs, and I have spent far to many 3am's laying on a concrete floor in a wireing closet trying to figure out why a network is malfunctioning.  I tried, and suceeded, in the early 1990's to construct an internet "butt set" that, useful as it was (and still is) on its own, it was meant to be part of a more elaborate system to help monitor and diagnose the net.

From that perspective I am perhaps more sensitive than most to the need to engineer the net so that it can be maintained, diagnosed, and repaired.

There has been a lot of resistance to incorporating mechanisms to monitor, diagnose, and troubleshoot the net except on a piecemeal basis.

We need to stop thinking of the net as a collection of individual machines but, rather, as a great distributed process.  (I was part of a DARPA project to work on this except that it, unfortunately, my time was devoured by my position on the ICANN board.)

Ultimately I believe that much of the net needs to become homeostatic - self healing (it already is in many regards, such as routing and soft tables such as ARP caches) - even if the control loops will for the foreseeable future, require the permission of people.

Unfortunately I see the design to be moving, and ossifying, in ways that make control, and time-to-recover, more difficult rather than less difficult.  And many implementations are weak and waiting to be pushed into failure by the arrival of a new peer implementation that does the protocol in a slightly, but still legitimate way.