Month: May 2004

All You Need is TCP: EtherSAN and Storage Networks

It’s always fun trying to get feedback on a paper due to be talked up few days later, but that’s always seems to be the way it is, at least for the UMN DISC Intelligent Storage Workshop coming up next week.

Anyway, what’s the paper about? The idea is think of the big Internet as being your storage channel. Getting the world to work like, say, fibrechannel, but you don’t use fibrechannel or some specialized separate network. Nope, we just use a really really low-latency layer1-4 dataflow processing mechanism but like Billy Joel would say “it’s still TCP to me”.

Hierarchical State Machines

Dropped by Miro Samek’s talk “Hierarchical State Machines: a Fundamentally Important Way of Software Design” at PARC last week, and still thinking about it. While the title is a bit over-the-top, some of the ideas such as a “quantum language” fit quite nicely in an RTOS. Of course, it’s architecture, architecture, architecture.

Mr. Samek himself sees the “framework” as applicable to many areas, such as real-time embedded systems, GUIs, or networking servers. He also is working on a realtime preemptive kernel which he says he will release soon. Why? As he put it himself “Obviously, what I’m doing is cottage-industry, but that’s all I can do alone.” Sounds like a good enough reason – just to try and see if it flies. That’s what exploration is all about.

Trials and Tribulations

Well, I’m beginning to make preparations for Singapore to talk to people about my paper Lessons Learned in Massive Video Production (MVP) for University Alumni Outreach on the yearlong trials of using Massive Video Production we created at ExecProducer to encourage alumni participation through produced video by students, faculty, staff, and alumni of the department.

Working with the Physics Department of the University of California at Berkeley, ExecProducer created an entirely new mechanism to subscribe, process, and approve up to 2,500 video productions viewable via the web internationally on a custom website, with links to news and information on endowments and donations. The trials were launched as part of former Chancellor Berndahl’s rejuvenation of the department after an official report critical of the future of the department was released.

Tommy, Can You Hear Me?

Norimitsu Onishi’s article in the New York Times entitled “Japanese Find a Forum to Vent Most-Secret Feelings” is fascinating. According to Mr. Onishi, “In a society in which subtlety is prized above all, face-to-face confrontation is avoided, insults can be leveled with verbal nuances and hidden meanings are found everywhere, there is one place where the Japanese go to bare their souls and engage in verbal combat: Channel 2.”

What is “Channel 2”? Simply an anonymous Internet BBS where secrets can be unburdened and read by others without retribution. Unlike American “talk radio”, where people actually want to be known, Channel 2 is a way to reveal oneself and others with no concern for social or business status.

In the DataCenter: A Tale of Two Opinions

Santa Cruz Operation, the company that purchased the rights to Unix from Novell and then launched a series of lawsuits against IBM and high profile users of Linux, has had a somewhat difficult time of it enforcing what they claim is their “rights”, enduring reactions ranging from denial of service attacks from hackers to legal wrangling over just what rights they bought from Novell in the first place.

So it’s no surprise that once again, they are tacking into the wind. But is SCO sailing into calmer legal waters, or is it simply a lull before the storm? Did the “Eldred” case championed by Dr. Lessig of Stanford Law School provide the key to a new approach? Please join me In the DataCenter as I examine SCO’s new direction in A Tale of Two Opinions. [Format: mp4/Unix or QT6+/Mac or Windows].

California, Missions, and Astronomy…

One of the nice things about Silicon Valley is the plethera of colleges and universities who offer all kinds of unusual lectures. Where else but here would we get to hear a talk combining, for example, astronomy, ancient cultures, and the California Missions?

My 4th grade daughter, an amateur astronomer, also did a California missions project this year as mandated for all California elementary students. She did a movie on Mission San Jose, a walking tour through the recently renovated mission describing all of it’s interesting history and features. One viewer said she was the “next Sister Wendy”.

The Dying American Dream and Irrational Joylessness

Mike Cassidy of the Merc wrote a nice essay on the casualties of the dot-com bubble selling out and leaving Silicon Valley. Not all of the people who worked hard here cashed out or got rich — actually, only a few did really well, although most everyone here likes to pretend they did better than everyone else. It’s a peculiar SV conceit.

I’m fourth generation Californian, born in Fremont and went to Berkeley. I’ve always lived in the Bay Area. I remember the orchards, now long gone, and how I used to ride my bike through them coming home from Parkmont Elementary school.

But I don’t resent other folks who came here trying for a bit of the gold. After all, that’s part of the American Dream. Does anyone remember the American Dream anymore?

So it makes me sad that young people have to sell everything and leave, just because so many businesses have gone on a bender about outsourcing. It is “irrational joylessness”, an almost armageddon wish-fulfillment. It is a maxim that a man who thinks he will die tomorrow will somehow make it so.

And all Craig Barrett can say is “life is tough”, as John Paczkowski noted a few days back in his column. What a wonderful guy.

Mike also spoke of experiencing a lack of enthusiasm about google, as John’s column quoted. Sounds like a few people will make out like bandits and it will assuredly be successful given it’s backers, but it won’t save that young couple Mike wrote about yesterday, nor a lot of others who have contributed to the success of the Valley.

What, me worry?

This little article just in from a dedicated Cisco engineer. Looks like Cisco is taking a “broadside” from Broadcom in the “TCP offload” universe.

Of course, notice the weasel words of “selected network streams”. In contrast, at InterProphet we showed a 10x advantage of all network streams on NT at Microsoft in their offices in Redmond in 1998 with a patented design.

So it’s taken Broadcom and Microsoft working together about 6 years to kind of make something work but not really. Not very impressive.

And SiliconTCP works for Unix and other OS’s as well. You don’t have to use Windows to get the benefit. In a world of “choice”, shouldn’t a chip be OS-agnostic? Or do they think choice is a bad idea?

Don’t know how often I read about a TCP offload mechanism which doesn’t really do the job. If a network stack worked like these chips, the Internet would be a lot more frustrating a place.

But I doubt Cisco cares, even though their engineers do. With China’s massive Huawei on the bottom end and ruthless Broadcom moving in, don’t bet on Cisco to defend their turf. After all, they’re too big to beat, right? And if a company lets things go long enough, figuring that “someone else I like better will invent it”, they take the risk someone they don’t like will do it.

Reliable Wireless and Link Layers

It is often the case that a “different” puzzle presents an opportunity for a young scientist to say “Oh, I can solve this problem because it’s different”. Well, sure… but is it simpler, or simply different?

The question begs in a discussion of using reliable link layers in wireless to solve the problem of retransmissions and poor QOS. The problem is that artifact of retransmission distorts the use of the medium, because too many retransmits / congestion events occur, biasing the statistics and becoming unfair. The solution for the wireless approach is to use the same thing that causes artifacts of noise as an architectural solution.

In the wired case, the solution is smaller packet sizes, so that when congestion occurs, congestion recovery impacts fewer events. But the increase in the number of packets than distorts the results of reliable link layer, so you get the same problem, only it’s less obvious, which is why I mention the wireless case first.

In the first case, it’s a first order effect. In the second case, it’s a second order effect dominating the first. But in neither case is it a “different” effect that can be solved independent of the other. And there’s where the delusion lies.

An old physics trick — look at the really lossy case first, and then once you’ve figured out what’s the problem, ask if a similar problem hides in the less lossy case. Given the scope of the Internet, little problems become big fast.

Of course, I got told last year that this wasn’t a problem in wireless. Oh, and we’ll eventually find weapons of mass destruction, too. Are you holding your breath?

Flamethrowers and Memories

Alex Cannera dropped an interesting paper on my desktop discussing congestion control in grid networks. And it’s results confirm what I and others have seen over the years; Vint Cerf seriously saw in 1998 that hop-by-hop reliability preserving end-to-end semantics in the routers was the real key to handling this issue. Vint also is a renowned wine expert, and treated me and William to a wonderful tour of fine wines at the Rubicon Restaurant in San Francisco where we had a memorable discussion on exactly this issue.

Of course, their terms-of-art are different from mine, since we all seem to invent new terms. So their “network of queues” is my bucket brigade mechanism. And their test demo is similar to one at InterProphet we called FlameThrower devised by Senior Hardware Engineer Todd Lawson and Software Engineer Madan Musuvathi to literally flood the other side with packets and see if it falls over.

Todd and Madan built a wirewrap version of SiliconTCP on a DEC PAM card with a NIC wired on (and that’s exciting with 100MHz logic). We demo’d this to Microsoft, venture, and lots of other companies back in Summer 1998. I have the wirewrap on my wall alongside a production board.

But the solution presented in this paper to “back pressure” the plug by disabling TCP congestion control selectively is where we part company. Herbert and Blanc/Primet quite correctly point out some of the barriers to FAST, Highspeed TCP / Scalable TCP, and XCP, but then fall back on the old link layer solution approach (which we diddle in the stack software). If only it were that simple.

Reliable link layer isn’t enough, and Vint (in looking back) clearly knew this. That’s why he saw SiliconTCP as fitting best here. This was the key reason he joined the board of InterProphet so many years ago.

Many people have made reliable link layers. We’ve done it with the boards we have here right now. But no one else made a reliable network and transport layer that spans many hops, maximizing the capacity of the aggregate network. Our boards also do this. So we did demo Vint’s vision in practice.

It’s only now that people are starting to thrash the problem that Vint saw many years ago. But they lack his insight as to the real nature of the problem. It isn’t turning off congestion control — it’s using it effectively.

So long as engineers think the answer is a simple “stack hack” instead of rethinking how to more effectively meet the protocol demands — not new protocols, not turning off the congestion, not cheating by biasing fairness — but really simply doing our job better, we’ll continue to run into this problem.