Carl Malamud: Internet Talk Radio, flame of the Internet.
This is Geek of the Week. We’re talking to Bob Bob Kummerfeld, former chairman of the computer science department at the University of Sydney, and one of the codeveloper of a suite of messaging protocols known alternatively as ACSnet, SUN3, SUN4, MHSnet. This sounds like the protocol of many names. Welcome to Geek of the Week, Robert.
Bob Kummerfeld: Thanks Carl.
Malamud: What is ACSnet, or SUN3, and I guess I can see why you wouldn’t call it SUN3.
Kummerfeld: Well, let me go back. We started this development a long while ago in about 1979, 1980. And at that stage we wanted to build a system to send messages between our machines and machines of other universities. And we called it the Sydney University Network. And it went through version 1, 2, 3. But unfortunately another company started up with a similar acronym for their name, and so we had to change it from SUN to something else. And more recently it’s become MHSnet. The package is a messaging thing. It allows you to send binary messages of any size. And on top of that we built email, file transfer, and any message-oriented sort of service.
Malamud: Now, this sounds like a mix between many of the things that we know and love. UUCP…[crosstalk]you know, the different messaging protocols.
Kummerfeld: Mm hm. Yeah. Sure.
Malamud: How does this differ let’s say from the Usenet model which evolved around the same time?
Kummerfeld: Yep. Well, in fact UUCP was released in about 19— Well. Sorry, it escaped from Bell Labs in about 1979. And we looked at that and thought well, that’s really ad hoc, maybe could do something better. And that began the development. And it was really a research project. But once again that sort of escaped out of our department and became much more widely used. The sort of things that distinguish it from other systems are that it can send any binary message of any size, over any sort of virtual circuit. It has—
Malamud: Any virtual circuit. Do you build on top of existing networks, or “virtual circuit” do you mean underlying telex lines, for example?
Kummerfeld: Could be, yes. Anything that can get bits across. In fact the low-level protocol adapts to the underlying circuit, whether it be virtual or real. It can run over dialup lines, it can run over X.25, it can run over IP and TCP connections.
Malamud: This is very similar to UUCP which can be run on top of TCP/IP—
Kummerfeld: That’s right
Malamud: —on top of a telephone line—
Kummerfeld: Sure
Malamud: —on top of X.25.
Kummerfeld: Yep.
Malamud: Okay.
Kummerfeld: But you know if— The low-level protocol that we have does things like full duplex transmission, which the original UUCP didn’t do. It adapts to the underlying circuit so that if you’ve got a noisy telephone line, it will increase the size of the packet and give better— Sorry, if you’ve got a clean telephone line it’ll increase the size of the packet, and you get higher throughput. If you’ve got a noisy telephone line it will decrease the size and so get better throughput that way.
Malamud: And these are features that you had in the in the early 80s [crosstalk] or are these things that you just added last year.
Kummerfeld: Sure. Oh no no, these are things that were in in the early 80s.
Malamud: Now what was built on top of this basic infrastructure for moving data?
Kummerfeld: Okay. Well, the lowest level then is the node-to-node or machine-to-machine thing that runs above the virtual circuit. But above that, we have a routing layer, which decides the best store-and-forward path. Essentially it’s a store-and-forward network, just like UUCP. But above the node-to-node protocol we have a routing architecture which will pick the best route through the network, and…then above that, you put your messaging protocol. And we used it, and still use it, for things like electronic mail, for sender-initiated file transfer. So just as I can send you electronic mail, I can also send you a file.
Malamud: Is this good?
Kummerfeld: I think this is a really great thing to have. Because how do I send you a file if I don’t have this? What do I do? I have to encode it into say a MIME message… Not very convenient. Also, you end up with a huge electronic mail message if it’s a binary file. Or maybe I can use FTP but then I’ve gotta put it in some anonymous “incoming” directory somewhere. Security might be a problem there. Or I’ve gotta have an account on your machine, so I can dump it into a directory. It’s just not very convenient whereas with our system we say “Send you the file.”
Malamud: So as the originator of Geek of the Week I can on an unsolicited basis send every user a thirty-megabyte file—
Kummerfeld: Absolutely.
Malamud: Are they gonna be happy with this?
Kummerfeld: No, but I can send you a thirty-megabyte mail message… Well, maybe I can’t but I mean you know, you can send unsolicited files—or messages already, using other mechanisms. We just make it easier.
Malamud: Um, and what other features are in the mail and messaging part of the suite?
Kummerfeld: Well the mail is just RFC 822. Or now these days you can send MIME or whatever. Because once it leaves our system it’s passed up to whatever delivery system you’ve got. Or to inject it into the the service, you can use whatever user agent you have.
Malamud: So it’s standard Internet mail, built on top of a different…[crosstalk] transport.
Kummerfeld: Yeah. Different transport. A different message transport, and I guess we don’t use SMTP. We use our system to do it.
Malamud: And does that still exist? Are there people in Australia [crosstalk] that actually use this?
Kummerfeld: Oh yes. Yes. This fact went through…four revisions, the final one appearing in about 1988. And at that stage we still didn’t have Internet in Australia. And at that time there were about 1,000 sites. Mainly in universities, but quite a few commercial ones as well. As the Internet has come on, of course, the ones in universities have gone away. Now there are still a few. Many people run it still because it’s so convenient to be able to send files around. But in fact the network is still growing. Because there are now commercial sites that’re out there dialup lines. They can’t afford the IP connection. It’s very expensive in Australia. And so there are still a lot of people using it.
Also, um…
Malamud: If you’re just doing messaging, what is the level of overhead of using the MHSnet protocol as a way of sending mails versus for example a typical TCP/IP SLIP connection? Have you measured the difference in overhead?
Kummerfeld: We haven’t measured the difference in overhead but what we’ve measured is the performance difference. And in fact we do about 10% better compared to FTP on transferring a file, in terms of throughput.
Malamud: And people are using it and you’re gatewaying it into the so-called core of the Internet, TCP/IP world.
Kummerfeld: Sure.
Malamud: What are the issues in putting those gateways together? Do you lose anything on either side?
Kummerfeld: Well, of course if you’ve got RFC 822 mail, then you don’t lose anything because it’s…it’s just that message no matter what system it’s in. If it’s say, FTP, then it’s a little different because, how do I gateway to FTP for sending? In fact we have another message service built on top of this which allows you to fetch files. You can send out a small message which says “Give me that file over there,” and it will send it back to you using the other protocol. And we built gateways with that to anonymous FTP. And I tend to use that in preference to anonymous FTP because anonymous FTP is interactive, whereas what we have allows me to say, “Get that file,” and then go on and do other things. A little while later a message pops up saying “The file’s here,” and I go—you know, I’ve got it.
Malamud: There’s a common wisdom that says we’re all converging on a common set of protocols. Now there’s no common…feeling of what that protocol is but we’re seeing BITNET appearing to be going away—
Kummerfeld: Oh yeah.
Malamud: —and the Internet core protocols.
Kummerfeld: Sure.
Malamud: Do you think we’re gonna live in a world of a single common set of protocols, or do you think—
Kummerfeld: No…no, I think there’s be a place for these sorts of things for a long while to come. And there’ll be new things which will pop up, and all things will go away. You know, we’ll have a mixed environment for…forever. That’s my opinion.
The MHSnet package has gone. That has been commercialized and is now being used by the Australian government to send messages between its embassies and posts around the world. And the reason they chose it is because it will run over things like 55 baud telegraph circuits, which apparently is all you can get into Mogadishu or somewhere. And so there’s a place for other such protocols, you know. IP and SMTP doesn’t work very well over 55 baud telegraph circuits. So I think there’s going to be quite a wide range of protocols and systems around for a long while to come.
Of course, you know, we’ve moved on from this and— I should say before I go on that to give credit where credit’s due a lot of this development was done by my coworker Piers Lauder, and we’re continuing to work on protocols and networks. This work really finished up in 1988. We haven’t done too much to it since then.
Malamud: Bob Kummerfeld, you’re the author of MHSnet and you pretty much completed your work in 1988. But you’ve continued working on messaging systems. And I presume that means you’ve been doing X.400 development.
Kummerfeld: Ha. You’re joking. Well in fact, in the early days I was quite attracted to the X.400 idea, and looked at it very carefully and contemplated doing some implementation work. But then after looking at it in more detail I realized it was a very complex…just overkill…thing. And I dropped the idea entirely. And in fact I think the whole OSI model has being now discredited and is slowly going away. I think there are much simpler things to do. Much simpler ways of solving the same problems.
Malamud: For example.
Kummerfeld: Well, we did it with the MHSnet. We could have branched off in the mid-80s and gone on the X.400 path. But I could see that it was just too complex, and so we ended up with three layers rather than seven. And we ended up with very simple message formats rather than a very complex—you know, P1, P2.
Malamud: Is there anything good that we can get out of X.400, or is the fact that it’s all bundled together make the total effort a loss?
Kummerfeld: Um, I think actually the total effort is probably a loss. I’m sad to say, but I think…you know, there are things that just sound so obvious these days. Things like the store-and-forward model in general. And the idea of administrative domains and so on. I think those ideas are falling out in other areas. And maybe we got that out of it, I’m not sure.
Malamud: But things like the feature-rich conversion, and return receipts, and all the functionality. Isn’t this something people want in their messaging service?
Kummerfeld: Oh yes, sure. And those things are appearing in things like MIME…email in the Internet. There is now an effort to provide the sort of receipts that people want, using MIME types. I think we’re going to get to the same functionality through a different path.
Malamud: Um, are we going to see an explosion in store-and-forward services, or is this a paradigm who’s done and [crosstalk] we’re gonna go real-time and do phone calls?
Kummerfeld: No, no. Oh, no. I disagree with that entirely. I think there’s still a big future in messaging. And in fact I think there’s a lot of hype these days about things like video on demand. I think that that will be available, but only in a very limited way. You’ve just gotta think about the amount of bandwidth that’s required for these sort of on-demand, interactive services. You just can’t deliver enough to service all the television sets in America. Or even all the television sets in a small town. There’s just not enough bandwidth. Instead we’re gonna have a mix of things, and I think messaging will play a big part in that. You know, I would like to be able to have the equivalent of the video shop, so that I can say, “Right, I want that particular movie,” and gets delivered, maybe not…immediately, but it will turn up on my home system in the next hour or so, or maybe tomorrow, or maybe next week depending on how much I’m willing to pay. And I think that’s where messaging and store-and-forward is going to be very important in the future.
Malamud: So delivery of MPEG movies as mail messages.
Kummerfeld: Absolutely. Yes.
Malamud: What else do you think we’re gonna make our messaging protocols do? MIME gives us a few hints, I think. There’s pointers to external information. There’s different body parts that can be played simultaneously, or can be played one after the other. What are some of the other things we can expect out of our messaging protocols over the next few years?
Kummerfeld: Hm. Well…
Malamud: Obviously, if you knew all of that you’d be off implementing it and making a fortune, but give us some guesses. What’s tomorrow’s email look like?
Kummerfeld: Um, well I think you probably said it all just there, that things will become more complex, more structured. You will be able to have, as we now have in MIME, various media types—you know, audio, still pictures…
Malamud: What about EDI? Is that something that we’re waiting on some breakthrough in order to be able to do electronic data interchanges in a mail message?
Kummerfeld: Yeah… Mmm, no I think that all the information is there. There are other various protocols now around. We looked at EDIFACT, for example. There’s an effort in the IETF to come up with a way of encapsulating EDIFACT messages inside MIME-format email. I think all of the technology is there to be able to do EDI right now.
Malamud: EDI has been a long time in coming. There’s over a thousand people involved in the ANSI X12 committee, more than attend the IETF. It’s been—
Kummerfeld: Sure but this isn’t really a technical issue and I think. I think it’s more of a business and a political and a legal issue. I think the technology is there and is not a problem. I think it coming up with agreements that the lawyers can approve. I think that’s where the problems are.
Malamud: Is the problem the structure of the purchase order, or is the problem the security and the reliability…
Kummerfeld: Security, reliability, yes all those things.
Malamud: That’s often been solved by building a custom value-added network specifically for an EDI application. Is Internet ready to begin delivering this kind of work?
Kummerfeld: No, I don’t think so. But there is some wonderful efforts going on in the IETF to move it in that direction. Thing like the Integrated Services Group just forming, and many other groups—the security groups, quality of service, and all this sort of thing. I think the Internet will…eventually be able to provide the sort of service guarantees that people want. But at the moment it can’t. I think that’s obvious. Anyone who uses the Internet on a regular basis knows that from day to day performance can vary enormously, that security is a real issue. It’s okay 99% of the time, but I don’t my credit card to fall into someone’s hands in that other 1%.
Malamud: Well you know, in the real world my credit card 1% of the time falls in the wrong hand. And when I send a package by Federal Express, it almost always makes it but sometimes it doesn’t.
Kummerfeld: Yeah, that’s true.
Malamud: Are we expecting too much out of the Internet?
Kummerfeld: Well, I think what we’re doing is we’re comparing to the telephone system. And how many times have you picked up the phone and not got dial tone? Very rarely—if ever. How many times have you dialed a number and had a message back saying, “Sorry, congestion in the network. I can’t put that call through?” [crosstalk] Very—
Malamud: Well I’ve lived in some countries where that has happened, but in the United States we certainly don’t expect that, and Australia you don’t, obviously.
Kummerfeld: No, no. Except on Mother’s Day or…well, anyway. So, I think that’s what we’re comparing it to. We’re comparing it to a network which is vastly overengineered in order to give you the guaranteed bandwidth at any time of the day or night. Whereas—
Malamud: Should the Internet be the same thing? I mean, phone calls are reasonable cost as a general rule.
Kummerfeld: That’s because it’s an almost ubiquitous service, that everybody has one and everybody contributes a little, and so there’s a profit margin there for someone to wire the entire country. And maybe when the Internet gets to that stage, and I think it will, then we’ll be able to engineer it to the extent that the phone system is.
Malamud: So is this a question of our policymakers encouraging a policy of universal service? Should we give this to one company so they’re able to give us universal service?
Kummerfeld: You mean the monopoly situation. Well, I’m not sure about that either. You know, I’ve seen the monopolies…both government monopolies and commercial ones. And unless they have some visionaries behind them, they tend to take the easiest path to profits. And at the moment I’m not sure the Internet is the best path. I think what will drive in that direction is entertainment, convergence of the cable industry, telecommunications, telephone, and the computer industry. HDTV, all of that. I think that’s what’s going to bring widespread network services—you know, the network service into every home. And then we’ll see the sort of overengineered, highly-reliable, large bandwidth at a low cost.
Malamud: And how does the Internet as we know it fit into this world of cable providers and HDTV, and some video on demand from your local neighborhood cable company? What’s the role of an internetwork in this converged world?
Kummerfeld: Well, it’s to carry everything as bits, rather than analog. And to carry programs either in real-time or as messages. So we’re sending video, we’re sending audio, and so on. But also to carry data, to carry text, to carry that sort of information. So that we can do other things. We can do the…what’s usually quoted? The home shopping. We can type on our keyboard and order something we don’t really want but…we’re attracted to it. That’s the reason for the integrated services. That’s the reason for an Internet-style network into the home.
Malamud: The network can be a closed community, what I call the suburbs of the Internet like CompuServe in which what you do is what’s on there—which is good; some people live in the suburbs for reasons.
Kummerfeld: Mm, but they still get— You know, they still have the ability to commute to other areas. And unfortunately with things like CompuServe… I’m not familiar with CompuServe but I understand that there’s a very limited Internet connectivity from CompuServe, perhaps only email. And I think that that is a real mistake.
Malamud: How do we fix that mistake? Do we hope people migrate into, or use market pressure to force our provider to do that?—
Kummerfeld: Yes.
Malamud: Do we pass laws and say if you’re going to provide a network you must connect to other networks?
Kummerfeld: Well, I’m not familiar with the history of how the telephone system was built in the US…
Malamud: What about Australia?
Kummerfeld: Well, Australia it was a government monopoly right from the beginning. And that had good and bad effects. One of the bad effects was that they were very conservative and are still conservative to some extent. They only provided services that were sort of site. But, they were able to wire the entire country at a reasonable price. In the US I understand there were many many small phone companies to begin with, and mismatch of standards and there a need for regulation and government, legislation, to get these people to connect up. So perhaps we need a sort of mixture of approaches. We need something like the fabled information superhighway that’s going act as the backbone, and maybe that might be government-controlled, government-provided. And then we need all the small phone companies out on the edges, providing local connectivity like the cable companies and so on. We need a mixture of things.
Malamud: Bob Kummerfeld, when we look at messaging systems, there is a common wisdom out there that says you have messaging and you have directories. This comes out of the once-proud OSI effort. But we hear that in many other places. It’s common in the trade press to say the Internet will only work when you can find somebody’s address. Are messaging and directories in fact coupled as [crosstalk] things that have to go together?
Kummerfeld: Oh yes. Well, they don’t have to go together but for example on our system we built a directory service which was above the messaging. You send off a message and it got potentially multicast out to various servers that would then come back with an answer saying, “Yes, this person lives out here,” or, “I’ve got the information.” [crosstalk] Very simple system—
Malamud: Well, that would be helpful.
Kummerfeld: It was a very simple system. Part of the routing architecture of MHSnet allowed you to multicast messages. So you could send in an efficient way, a single message to many people. And so this allowed us to multicast out to the—well, we called them whois servers but that’s a term which is already taken. But you could potentially send it to multiple places and ask for them to consult their database, which was just a flat file, and send back a result.
Malamud: Now why hasn’t what seems to be like such a simple easy idea been moved into the Internet, for example on our whois databases? I have to manually go to each whois service and saying, “Do you know about this person?” I can write a little shell script hack which searches ’em, but it’s certainly not a multicast-type application.
Kummerfeld: Well, it’s all to do with scale. And you know, we didn’t push the idea any further. I think there certainly is scope for building these sort of distributed databases in the Internet, using Internet-style technology—simple, straightforward approaches rather than complex ones.
Malamud: Is the Domain Name System what we should be using for our white pages service? Is that how we should find somebody?
Kummerfeld: No, I don’t think so. I think the Domain Name Service is built for a different reason. You know, it’s built basically for address resolution. But something like that…sure. And there are efforts here in the IETF to study this problem and to come up with a unified white pages service for the Internet. And perhaps it will involve using a multicast, distributed database.
Malamud: A unified white pages service. Now does this mean a tree of directories and chaining and those concepts from the X.500 world?
Kummerfeld: Mmm, yeah, I was going to say, it sounds like X.500. Possibly. Possibly.
Malamud: What’s another model?
Kummerfeld: Well, I’ll tell you, the problem with X.500—and I don’t know what your experience is, but certainly my experience is that when you ask for someone’s address, you’re very often don’t find it because the server, the leaf, in their organization is down. And that’s very common in my experience. And so I think that pushing all the information right down to the end of the tree like that is probably the wrong way to go. I think it would be better to have a smaller number of large, well-maintained, reliable servers that handle a really large portion of the network.
Malamud: And do you allow…do you require the user to maintain his or her own record, or you have some central registrar that does it for you?
Kummerfeld: Yes, now you’re getting to the nub of the problem. I think the hardest part of directories services it keeping the directories up to date. And people move and they forget to change their entry. There are many problems. Many many problems in keeping the information up to date. But, it can’t be run with a bunch of volunteers. It has to be done professionally and with people who are dedicated to the task.
Malamud: There’s a protocol by Mike Schwartz known as Netfind and what Netfind does—it’s not a protocol, it’s some software; it’s a server. And it basically punts. It says, “No, we don’t have a directory but we’ve got all these little bitty sources of information and I’ll kind of root around and maybe find that person for you and maybe not.”
Kummerfeld: Sure. Try finger and all those other things. Yeah.
Malamud: Is that a better way of doing things, [crosstalk] that different model of…can that coexist with the directories.
Kummerfeld: Well that’s… Well, okay, that’s more the intelligent agent-type model, where you send off a request and it says, “Okay well I’ll try this, I’ll try that, I’ll try something else.” And you know, it’s a layer above the other services. And that’s a useful thing to have as well. You know, there’s Vint Cerf’s Knowbot service, same sort of idea. But I think there’s a huge future for intelligent agents like this, of all types, in the network. You know, finding information for me. Or—
Malamud: And are these agents that are stored inside of let’s say a mail message as a safe Perl script or a safe Tcl script?
Kummerfeld: Mm hm. Could be, could be. There’s an issue of privacy here, of course. If I want to send my preferences out saying what sort of movies I like, maybe I wouldn’t like people to see that. And so maybe what we have to do is to split it up and send out some of that information saying what I want, but then have the final filtering done back at your own machine.
Malamud: And so agents come and visit my machine and I look at whose agent it is and decide whether or not to tell you what movies I’ve been watching.
Kummerfeld: That’s right. Yeah, I think so.
Malamud: Is this just a pipe dream or is this actually something that we’re were close to be able to do?
Kummerfeld: No, this is an area that I’ve been working on just recently. In fact my wife Judy Kaye is also a computer scientist and her area is user modeling. And we’ve been collaborating on some of these things. I’ve been looking at the distributed nature and the protocols necessary to pass around these sort of requests. And she’s been looking at the user modeling angle, that part of it.
Malamud: What’s user modeling?
Kummerfeld: Ah, well. [crosstalk] You’ll have to—
Malamud: Are these uses that kind of stand up and twirl around on a walkway or.
Kummerfeld: You’ll have to interview Judy on this. Well, it’s basically keeping some information about you—your likes and dislikes and your knowledge—trying to build a model of the user, of what the user knows. So—
Malamud: So my model might for example say I don’t like receiving mail, and your intelligent agent would walk in and see that and…go away because it’s a polite agent.
Kummerfeld: Something like that.
Malamud: Well there you have it. This has been Geek of the Week. We’ve been talking to Bob Kummerfeld from the University of Sydney. Thanks a lot.
Malamud: This is Internet Talk Radio, flame of the Internet. You’ve been listening to Geek of the Week. You may copy this program to any medium, and change the encoding, but may not alter the data or sell the contents. To purchase an audio cassette of this program, send mail to radio@ora.com.
Support for Geek of the Week comes from Sun Microsystems. Sun, the network is the computer. Support for Geek of the Week also comes from O’Reilly & Associates, publishers of the Global Network Navigator, your online hypertext magazine. For more information, send mail to info@gnn.com. Network connectivity for the Internet Multicasting Service is provided by MFS DataNet and by UUNET Technologies.
Executive Producer for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysadmins. This is Carl Malamud for the Internet Multicasting Service, town crier to the global village.