We went to this format in part to improve readability in Acrobat, but also to herald some other changes in the way we publish Netwatcher. Since we're now fully electronic, we don't have printed page count restrictions on article sizes, and we can run a bit over the 10-page limit if the subject matter warrants. We can also include illustrations where they'd be helpful, though we do want to keep the file size under control for those who must download the issue over analog modem connections and slow lines.

Please note that in this and future issues, clicking on the article summary in the issue box to the left on this page will link you to the section of the newsletter that contains the article. If you have a later version of Acrobat, you may also be able to link directly to Web sites from the URLs we include. Give it a try, and please let us know how you like the changes.

Like most of you, we've become very dependent on e-mail, and tend to take it for granted. We've been surprised to find that many organizations are very unhappy with some aspects of their e-mail, and are unaware that there may be solutions to their problems.

For managers, bad e-mail is bad business. People can waste enormous amounts of time with an ineffective e-mail system and policy. A good one can become almost an extension of the user's familiar desktop tools. It's clear which you'd like for your workers, but not necessarily clear how to get it. That being the case, let's find out.

E-mail is a client/server relationship. The user has a mail client program that installs as an extension of the desktop communications tools. This client communicates with a mail server (or servers) to pass mail to others.

The core of the mail system is the mailbox. Classical wisdom says that everybody has a mailbox, but that's not true. You don't necessarily want to provide a mailbox to every worker, even workers who have computers. Give mailboxes to people you want to use mail to communicate with, and let others do without. Our research shows that people tend to use their mailboxes for extraneous purposes if there aren't any legitimate ones, and that this maverick use actually encourages similar behavior among other workers.

It's also true that you probably want your key workers to have several mailboxes. For example, a worker should have a "public" mailbox representing the place where most people would drop e-mail to that individual, and a "private" mailbox to be used by people who have special reasons to communicate. This is particularly important for workers who have many routine e-mails; good stuff may be lost in the shuffle.

The type of mail system is also important. There are two basic approaches to e-mail, the "proprietary" approach and the "open" approach. The former is a mail system built on a vendor's own platform (Notes, for example). This system will have a custom client software component, specialized features, etc. It will interact with open mail systems through a gateway.

Open mail systems are based on the Internet model of e-mail, with a POP3 server to pick up mail, an SMTP server to send mail, and a mail client program that interacts with both. Most commercial open e-mail servers provide both POP3 and SMTP support within a single server.

Sorry, IBM and Microsoft, but we're fans of the open mail approach. Open mail systems offer you complete vendor flexibility, easy movement of mail between platforms, and also a variety of mail client options. The mail system is also compatible with the basic mail features of the popular browsers, which may be helpful in providing workers a single interface for mail and Internet access or access to a corporate intranet.

Proprietary mail systems often restrict the features of open Internet mail. For example, many proprietary mail systems won't support mail attachments in all of the formats available on the Internet; many of our readers know this because they've had to request something other than the standard MIME encoding for Netwatcher.

If you are considering an open mail system, we'd like to buck the Microsoft trend and recommend that you pass on Internet Mail in Exchange and Outlook Mail in favor of Eudora Pro. One of the features we like about Eudora is its ability to support multiple "personalities", meaning that you can pick up e-mail from several mailboxes. If you follow our recommendation of giving key workers multiple mailboxes, this can be critical. Note that if your workers want to pick up only their "critical" one from the road, they can do so.

Eudora also supports mail filtering, a feature most users don't even know about. With filters, you can route mail from specified senders to a special mailbox, reply automatically if you're out of area and won't be checking mail, etc. Most open mail servers also support scripts and filters for special handling, so the combination of these two can do wonders.

Another feature to look for in a mail system is support for attachments. Most of your movement of work via e-mail will have to be done by attaching files, and not all mail systems support this equally. The best attachment coding option is MIME, but some systems won't support it. UUCODE is a popular system (and an old one), and Mac users tend to use BinHex. A good mail program will support any and all of these, but most won't.

Attaching files to e-mail lets you build a serviceable workflow system using e-mail alone. You mail the work as an attachment, and the text body is a list of the steps (as e-mail addresses) that the work must go through. Each worker notes his/her e-mail address with a "COMPLETED" tag and mails to the next name on the flow. If you want supervisory input at various places in the process, put your own e-mail address in each place and the work will come back for review.

This should illustrate a simple point that many companies overlook: e-mail users need training. We've found that most companies can't effectively use e-mail because their workers don't know about all the features. One organization we know has spent over $1,000 so far this year on express mail charges for a small group of employees who could have been sending files via e-mail instead. They didn't know how.

How about new and advanced mail features? The problem you'll have with anything beyond what we've talked about here is that most partners won't support the features. That can be a big problem for you if your workers must interact with people outside the company, or if you have a variety of mail clients internally. The moral is, with respect to e-mail, avoid advanced features, because you'll never know whether somebody else can support them.

Too many organizations think that MSMail Server, Notes Mail, cc:Mail or other proprietary systems are the only games in town. Look carefully at the open mail offerings, and you may be surprised at how good a system you can put together.

In a market fraught with hype, xDSL may be the current king of the hill. We've got vendors promising 6 Mbps for fifty bucks a month. Heady stuff when the average 56 kbps connection costs about $200 today.

But while it's true that no idea is quite good enough these days, so embellishment is mandatory, it's also true that there's usually a grain of value underneath all of the hype. Sometimes that grain of value is good enough to serve as the basis for real planning.

There is no issue in internetworking today as vexing as that of real-time transport over IP networks. To some, it has taken on all of the flavor of a religious war, pitting the righteous supporters of connectionless against the conservative, stogy, connection-oriented crowd.

Complicating this fight is the fact that the classical definition of connectionless networks includes the property of unreliability. Basic datagram networks, such as IP networks, don't even provide delivery assurance. That means that data injected at one end may or may not get to the other, and it's the responsibility of an overlay protocol (TCP, in most applications) to bring order from datagram chaos.

TCP introduces its own problems. Its window-based flow control, error recovery, and "slow start" mechanism to avoid congestion creates timing variations in delivery that are intolerable with some applications, particularly things like video or voice. Real-time applications don't work well over TCP, so if we really need to support them, we need something different.

We've talked about the justification for real-time-over-IP in the past. If IP is going to take the desktop by storm (which it clearly is), then it is likely that applications will be more readily built and deployed if they are IP-based. To demand a different delivery technology may increase the cost of applications, network attachment, and network transport. But if IP can't deliver what the application wants, there's no choice but to move to something that can.

Can IP cut the mustard? There are three basic approaches to making internetworks real-time-ready:

1. Add knowledge of certain flows to IP routing devices so that they will recognize and expedite real-time relationships. This is the approach taken by RSVP.
2. Use a protocol over IP that doesn't have the flow control and error recovery features of TCP, but is more directed to creating a stable flow of data. This is the approach taken by the Real-Time Protocol, RTP.
3. Create a new real-time transport feature that can coexist with IP, but which adds the features of deterministic behavior that IP lacks. With reliable lower-level protocol services to draw on, real-time services should be possible. This is the Internet Stream Protocol Version 2 (ST2) approach.

Which is best? For some, any will do. For others, none. Let's look inside each and see what we can expect.

The simplest approach to real-time transport on routed connectionless networks would seem to be imposing a "flow knowledge" requirement. This is particularly attractive given the fact that most of today's applications aren't real-time, and the impact of the requirement to recognize flows might not be particularly objectionable.

If network devices can recognize that a sequence of datagrams (a flow, or stream) should be prioritized in their resource allocation, this would insure that flow better performance. If the algorithm for allocation of resources were to take into account requirements for a specific level of performance (not just "better than Charlie"), it might be possible to insure quality of service in the traditional sense.

RSVP is targeted at doing that. In RSVP, a flow already established is identified to network elements by a series of commands that are routed along the same path as the flow. These commands let sender, receiver, and devices negotiate either a rough or a refined level of QoS – in theory. In practice, there's no assurance that the QoS desired is available because the route is selected without regard to whether devices and trunks along the path have the necessary resources.

If a network disruption occurs, RSVP's preset agreements may become obsolete because the data may take a different path. To handle this, the command/response process that negotiates resources (PATH and RESV) are repeated periodically. Thus, if the data is routed out from under the original set of agreements, the new route will be conditioned (as much as it can be) once the next PATH/RESV exchange is completed.

How well does RSVP do for QoS? That depends. In theory, if the resources needed are actually available along the path, and if the individual devices allocate them effectively, the connection can be as good as the requestor wants and the network operator will pay for. In practice, even if the individual nodes in the network really allocate resources effectively, the overall performance of the connection may fail to meet objectives (or be optimum in resource consumption) because the route selected through the network didn't account for resource levels or capabilities of trunks and devices.

RSVP may also have problems in practical applications because of the "retrospective" and "overlay" nature of the architecture. RSVP would normally require a period of time to allocate resources, during which the flow it's working to support is already underway. If the flow is of short duration, RSVP may not finish its job before the users are finished with their relationship. Because RSVP is an overlay for resource allocation, the flows use the same protocols as before, and inherit any of their disadvantages.

Another approach to real-time networking is to address the issues that TCP fails to handle. TCP is a simplex protocol: one to one. Many real-time relationships will be voice or video, which are likely to be multipoint in nature. TCP's error recovery and flow control, as previously noted, aren't suitable for real-time flows.

OK, those are what RTP is all about. This protocol is essentially a new datagram protocol that's augmented by a control exchange (RTCP). A user would invoke RTCP to establish a real-time relationship, and RTP would be used to transport the information.

RTP, unlike RSVP, is already in use in multicast meeting applications today. But the name may lead you to believe that RTP does more than it really does, and it's important to understand its limits as well as its strengths.

RTP uses UDP (the datagram protocol) for transport. It adds a header that provides information on the timing of the data stream. In effect, what this does is to say "this piece of data should follow the last by x milliseconds", which allows the terminating end of the connection to keep the outbound stream somewhat synchronized in time relative to its own elements. This doesn't eliminate the impact of overall network delay, but it can reduce the impact of delay jitter. RTP also sequence-numbers the packets to allow the receiver to detect a loss.

It doesn't recover from the loss, however. The assumption RTP makes is that it must manage the unreliability of UDP, so to speak, but not correct it. If the user wants truly reliable flows, the user must do something to impose reliability on top of RTP. One possibility is to use RSVP in conjunction with RTP to manage QoS. Another is to add a forward error correction protocol on top of RTP to replace missing elements. All of this is supported; none is explicitly included.

Another function of RTP is the "relay" function, which allows a special agent to operate on an RTP stream to accommodate some special requirement. One example is transcoding high-quality audio or video to a lower quality so that one participant with limited resources can join a conference without dragging everyone down to the low quality level those limited resources might dictate. Another is the use of a tunneling relay to get RTP through a network firewall without breaching security.

RTCP is primarily concerned with the issue of conference management (joining and dropping out) and monitoring the quality levels by allowing sequence number drops to be communicated back to the sender. Congestion problems can also be fed back to the sender, though what that party would do with this information is left to your imagination for now.

Overall, RTP is an advance over UDP in its ability to manage the conferences and provide quality feedback, and in its ability to synchronize the output stream in the face of some delay jitter. It's greatest value is in audio/video relationships, and it still has holes that other protocols (like RSVP) would have to fill.

Perhaps the most comprehensive IETF initiative to add real-time support to IP networks is embodied in the Internet Streams Protocol Version 2, or ST2, protocol (RFC 1819). ST2 is the result of a long process that started back in the 1970s. The original form of this protocol (ST) was published as RFC 1190. A working group was formed in the '90s to refine the protocol, and the draft of that group's efforts in 1995 was called "ST2". The current version of the protocol, RFC 1819, is sometimes called "ST2+" to differentiate it from that early draft, but we'll use ST2 herein.

The objective of ST2 is to establish what is effectively a connection-oriented relationship across a connectionless network, but unlike RSVP, it does it in parallel with IP and not over it.

ST2, like IP, has protocols that run over it, but unlike IP's partners, the ST2 partner protocols aren't really defined broadly as yet. PVP and NVP (Packet Voice Protocol and Network Voice Protocol) are examples. These protocols could (and do, in the PVP/NVP example) provide much the same services that RTP provides for synchronization.

Like RTP, ST2 has two components: a data transfer component and a setup component. The former is still called ST for Stream, and the latter is called the Stream Control Message Protocol (SCMP). ST2 also draws on a third external function of routing. In this, it dodges neatly the question of how route-wide resource availability is assured by fobbing the whole task of route determination off on somebody else.

The fact that routing is handled outside ST2 opens the door for the same problem set that plagues RSVP, but apparently it is the nature of IP-centric organizations and contributors to stay with the concept of distributed routing on a hop-by-hop basis. Even source routing, which would be the easiest way to impart specific QoS-topology knowledge to a network of routers, is excluded from the 1819 version, though it is under consideration.

The data transfer protocol of ST2 is very similar to that of RTP. Service is unreliable, and only priority and sequence numbering are offered by the ST header. The strength of the protocol is in its ability to manage complex relationships as a series of these simplex streams.

Streams originate at a traffic source and terminate at a target. Together, the streams associated with a relationship make up a routing tree much like that formed for RTP or MBONE, or one used in spanning-tree bridging.

Managing streams in ST2 is more sophisticated than in RTP, which also offers streams. ST2 lets the network reserve limited resources if the conference protocol prevents everyone participating at once, for example. It also lets streams of related activities be grouped so that if resource limitations force one stream of a conversation to be dropped, the whole set can be dropped.

Unlike RSVP, ST2 makes some detailed suggestions on nodal functionality (ST2 is supported in an aware node via a Local Resource Manager or LRM). QoS enforcement is a required function of each LRM, but LRMs may provide additional support like traffic shaping and policing, and preemptive transfer of resources from a low-priority stream to one of higher priority. Unlike RTP, ST2 has no mechanism for synchronization of the output stream-no timing data is provided.

The biggest downside of ST2 is the fact that it is a protocol parallel to IP and not over IP. With RTP and RSVP, IP transport meant that even if a router or two in the network were not equipped with the protocol, the traffic could still flow, though without any real-time benefits. With ST2, the only way to get the traffic through an IP-only segment of a network would be to tunnel it. While that's a viable option in theory, you might have a problem coming up with commercial sources of ST2 tunneling agents for IP.

Combined with a conference/relationship management protocol set like T.120, RT2 could be used as the basis for really sophisticated multi-party real-time relationships. But events seem to have passed it by in favor of RTP. Bay touts their support for ST2, but Cisco doesn't even mention it on their web site. While that isn't an automatic death knell, it's certainly the support equivalent of an untreated compound fracture of something load-bearing.

Real-time support over connectionless networks isn't trivial. The simple stuff like RSVP has deficiencies that are very clear, and that seems to be sapping the strength of interest in them. The protocols like RTP and ST2 that handle more complex issues are complex enough that vendors may not support them.

All of the protocols have potentially significant networking impact. In any network with limited resources, somebody pays for everyone who collects, bandwidth-wise. As applications develop, it would be nice if network operators were able to gauge the impact of each on the network, relative to its benefit, before committing to it. Because each of these protocols has to be implemented in at least some of the network hardware, there may be a chance to seize control of that issue set right now. Once the support is installed, it may be difficult to wrestle control back.

We recommend that you don't install or enable any real-time protocols until you've decided just how you want to control their proliferation – inside the company and out into the wide world. But we must also note that most of the applications that these protocols are intended to support can be supported today on LAN internetworks using basic facilities found in all the routers and hosts you're likely to have.

For users really interested in supporting real-time applications, it should be clear that the issue of route selection may be the most critical. None of these protocols can draw on independent route knowledge; they inherit whatever you're running. Link state routing protocols like OSPF will be better in support of real-time protocols because they provide more knowledge of the total route to the node selecting the next hop. Distance vector protocols like RIP will clearly have a tough time, because the number of hops doesn't necessarily correlate with the quality of the overall path.

Even OSPF won't solve the problem of resource knowledge and QoS completely. For any real-time protocol, the most significant question is how much of any downstream resource is already committed to a real-time flow. That can't be answered unless the resource state is communicated in the regular topology updates, which at present it is not. Changes to protocols like OSPF to carry this data would be possible. It would also be possible to adopt a more sophisticated protocol that is QoS-aware as the basis of route selection. Possible, but not likely in the near term. That means that any of these protocols will probably require some special attention to network design if they are to provide useful service.

In all networks, the real-time protocols will work best if there is a separate load calculation done to determine just how much real-time traffic will be flowing. The capacity to support that should then be added to the network in each location where real-time flows will originate, terminate, or pass through. If you don't do this, resources to support real-time traffic will be pulled out of the pool supporting your normal IP data traffic.

What wins? We think that RTP and RSVP, in combination, will probably prevail. ST2 provides superior facilities, but it's harder to implement and can't be overlaid on a network that doesn't have ST2-aware nodes. This makes adopting it a pretty significant commitment.

Will real-time connectionless networking really suit its applications? The truth is that it will depend on the resources and the management control placed on the applications. The jury is still out, folks. We'll keep you posted.

Future issues of Netwatcher will be dealing with some very interesting issues. We're going to look at the question of whether the Internet is really going to eat voice networking. We're going to look at the build-out of corporate networks using dark fiber – one of the great and yet unreported changes in our time. We're also going to review major ATM vendors' WAN architectures and features. There's a lot of interest in "infrastructure ATM", but is it justified?

Because future issues may become larger due to new material and/or the insertion of figures, we recommend that you check with your mail system administrator to determine if there are any limits on the maximum size of file you can receive in an e-mail. You'll need to have this limit increased to at least 300 kbytes if you want to keep up with our growth. Remember, we can't provide any special handling like ftp-ing files or fragmenting the issues.

Access the index of CIMI Corporation's recent newsletters.