Ascription is an Anathema to any Enthusiasm

Scale free networks are said to be robust. But they are robust in only a peculiar statistical sense. Consider, as an example, the road network. The roadways in most regions are scale free networks. They are robust in the sense that if you select a random road in the network and remove it from service the effect on traffic is very slight. Obviously this is just a trick; the randomly selected road is typically going to be some minor dirt road way out on the tail of the distribution. The effect of it’s removal will likely go unoticed until somebody decides to drive up there next fall to collect a load of firewood.

Random attacks are only one kind of risk systems need to guard against. Pick the right intersection and you can do plenty of harm to a region’s road network. The random failure model assumes that the source of trouble is uncorrolated with the topology of the network. Scale free networks seem almost brittle if the failures are aligned with the hubs in the network.

There are key intersections in the local road network that often fail, because traffic is perfectly aligned with the network’s hubs and a simple fender bender can take the intersection out of service. It would be much worse than it is if the system didn’t adapt. The failing hubs attract the attention of highway engineers and they adjust the traffic flows to reduce the incidence traffic related failures.

Various sources of failure raindown on systems like these. If the rain is totally random then the scale free network is robust because the hubs are hidden in a mist of far far less critical hubs. If the system threads are aligned with the topology of the network, like traffic on the roads, then the system can respond in one of three ways. It can add resources to the hub. You can change the topology of the network. You can offensively attempt to stop the source of the failures.

For example shift this over into a biological frame. Radiation rains down on the animal continously triggering numerous tiny failures but the scale free system design makes that chance of total system failure from quite low. The body’s various organs serve as hubs and each one of the has evolved to accumulate redundancy and numerous of special case adaptions to deal with the problems that arise from the ebb and flow of the work they perform. And then there is always good hygiene.

But notice that changing the topology of the network isn’t on the list. I suspect that’s because I don’t really know anything about biology. Maybe that if you want to see changing topology you have to shift from single species to ecologies?

It’s hard for individuals to shift topology. The city maybe at risk because it has only one bridge over the river and the traffic engineer can say “you really need to build in some redundancy,” but it is hard to get a redundent topology to emerge if the system has already condensed into a topology without one. It’s particularly difficult if your going to have to shift resources to make it happen. Displacing people from their property or taxing the efficency of the existing system to fund the shift. For this reason systems tend to fail rather than adapt. It’s notable that the scalefree topology is actually resistent to change.

It seems relevant to point out at this point that there is a large section of the US highway system that isn’t scale free. The interstate highway system – built by military minds – isn’t. That seems relevant because if you fear an attacker who is extremely smart you may prefer to design a system that forgos some of the efficency advantages of a perfectly scalefree network and instead design a system that is topologically more random. Maintaining that will be hard though, because over time the system will evolve toward the scalefree pattern as it seeks the efficency of hubs. In fact over the decades the interstate highway system has become less a grid and more a scale free network.

The assumption that adaptible systems can always respond to any problem is just plain false. We don’t have two hearts and we are unlikely to evolve a second one. The only time that it’s true is when the attack on the system isn’t fatal, but only painful enough that it allows the system time to adapt. If the system is attacked at it’s hubs with sufficent vigor it will collapse.

Since scale free system appear in so many venues these points apply in many venues. The military comming out of the second world war was very sensitive to these issues and the design of the interstate highway system reflected that. They traded efficency for a more resilient topology. The design of the internet was similarly intentionally laid out with that in mind, though most of that’s been lost. I suspect this is one reason why London’s circle line, which forms a kind of hub, was the target of the terrorist’s attacks.

The point that most caught my fancy in this fun ranting talk (realplayer) by the always interesting Andrew Odlyzko was one of his questions to the audience, i.e. why would you want to deliver a movie faster than real time?

He uses the Socratic method quite a few times during the talk with the usual collatoral damage that he looses control of the floor. The trick to getting past that problem is to enjoy the fun of trying to answer the question even though your not there. Just ignore the other students .

When I walk back from the library with a DVD in hand I’m streaming that movie faster than real time. When you download an MP3 to your iPod your moving it faster than real time. When an email message is deposited into my email client it’s moving faster than it can be read or written.

His point is that much of the industry enthusiasm for streaming content is misplaced. It’s enjoyably ironic to listen to that rant on a stream embedded in RealPlayer. If your really lucky it will pause to fill it’s buffers in the middle of the part of the rant were he dismisses the argument that streaming content is amenable to property rights protection.

This section resonated with me because I’ve been thinking a lot about streaming recently. And it sent me off thinking about the very idea of a stream. I get a stream of magazines and blog feeds into my life, for example. All those lumps of text and photos laid out pages are a kind of buffering. A way of making something asynchronous rather than synchronous.

One thing I’ve been thinking about a lot recently is collaborative streaming, i.e. ways to shift coordinate the broadcast of a stream across a large pool of participants. I want to do that to lower the barrier to entry for the broadcaster by raising slightly the costs placed on the audience members. I want to do that to change the nature of the cloud thru which the broadcast transits so that there is less power concentrated in a high capacity hub. Shifting, in the design space, were the the coordination, processing, and bandwidth problems are resolved out of the hub and into standards. The exchange standards then orchestrate the broadcast instead of the broadcaster or an intermediary.

My strawman for this is to use swarming peer to peer techniques. The stream broadcaster atomizes the stream and distributes the droplets across a swarm of participants. They then exchange the droplets, much in the manner of BitTorrent, to reassemble the stream. Of course nothing is very new in that design.

The swarm can also provide the other features you want in a streaming architecture. Time shifting, buffering, archiving, etc. I had fun puzzling about email lists from this point of view; might it be reasonable to shift to a model where email lists are distributed, archived, etc. via a peer to peer broadcast architecture. How would that be different from a group blog? It’s common to see the most usable archives for mailing lists maintained by the community around the list rather than by the single point where the list comes together.

Part his point in ranting about streaming (oh and I want to be clear that streaming was a very minor subplot in this talk) was how portions of the industry are caught in a set of interlocking delusions about what is important and thus what the future holds. That the fixation on streaming content has codependencies on the illustion that content is king, for example. The streaming enthusiasm is also codependent with quality of service arguements; if you going to stream content you need to get very high quality of service.

That arguement is surprisingly weak. Buffers are cheap. A lot of audience members aren’t particularly interested in watching your content on your schedule – i.e. time shifting is the norm not the exception. Dumb networks keep winning so arguments that run counter to that trend are inherently suspect.

Which got me to wondering exactly when does high quality streaming really matter? Two answers come to mind. There is the social reasons – there are things it’s hard to do outside a crowd – applause, wave your lighters, choral singing, debate. Of course of those arise from the comming together and don’t demand synchonisity. There are the options that expire. The betting window closes when the horse race starts. A PR person may want to nip a rumor in the bud sooner rather than later. The early bird catches the worm. Maybe it’s only one reason; maybe these are both a question of managing what options for action you have.

High quality streaming is a lot like colocation. You know distributed work, out sourcing, etc. Dr. Odlyzko spends some time on how “distance is dead” is another industry delusion. So maybe he’s trying to have it both ways.

(thanks to Paul for the pointer)

Wikipedia is electing a board. Interesting example in the space of how to structure your goverance.

In order to vote you must have at least 400 edits prior to 00:00 May 30, 2005 (UTC) on the Wikimedia project from which you cast your vote. The first edit must have been 90 days or more before the time of voting. Please note that the Election Officials have the power to disqualify votes from permanently banned users or sockpuppets.

Oh, so they have decided to disenfranchise the sock puppets. Beware the angry sock puppets!

New England towns often end up governed by a peculiar demographic because they have open town meetings. It’s the people who can spare a few hundred hours a year to pick nits at meeting. That “400 edits” rule implies a simplistic model of the distribution of value across the space of edits. Edits are not like bushel’s of wheat. I guess they have a lot of faith in the law of large numbers.

Gizmo appears to be a another SIP client. A soft phone that uses the SIP protocols to talk to… well it appears to be hard wired to one VOIP vendor’s SIP proxy. That would be SipPhone. SipPhone peers with FreeWorldDialup, so I could reach my basement asterisk server thru that. At that point I’m back in the open VOIP world.

I can see the hard wired sip proxy and tun server in the object library. I guess, I could use DNS spooffing to point it directly at my asterisk server.

Michael Robertson, SipPhone’s owner, when accouncing it wrote: “This week, a product called Gizmo is being unveiled – the first viable Skype alternative built on open source that pledges to connect to all.” Which translates as “We used open source and we are standards based (pretty much).” and it doesn’t mean “We are giving back everything we wrote to the commons.”

He has a classic column fodder product comparison table in his posting. Make’s Skype look pretty bad. Needs a few more rows, for things like encryption, what codex are supported/required, how many adopters, and how much of VOIP traffic flows thru an middleman. Needs a few more columns for other vendor’s offerings

None the less, this is a provocative offering. It certainly is much more spritely than the X-Lite softphone/SIP-client. X-Lite, on the otherhand, can register with a dozen or more VOIP vendors. Hard to displace Skype at this point. But it is not impossible. More open would help.

Update: My experiance so far has been spotty. Sometimes it works great. Other times it behaves like Alpha quality software with lots of rough edges, intermittent connections, and occational crashes. The Gizmo discussion forums are an excellent resource and the postings there are similar to my experiance. Hopefully over the next month they will work out a lot of the rough edges. One nice thing, it will allow you to call sip URL’s, though I don’t seem to be able to enter them in the address book. If it was open source all these rough edges would be attracting contributors .