Always Late

Okay, so I haven't written anything in a while. This just means that I've been really really busy though, which is a good thing. Since I'm going to remain busy throughout the summer, I thought it might be best to send out a summary of my current projects, and share some of the lessons that I'm learning in this work. Hopefully I'll be able to sneak out a few more essays this summer as well.

Volume One

The one thing that has kept me busiest of all over the last few months was the finishing work on Internet Core Protocols: the Definitive Guide. This is volume one in a series that I'm doing for O'Reilly & Associates, detailing how the Internet family of protocols work at the bit level. This series is targeted directly to those people who are tasked with running their corporate intranets and Internet presence, and who need ready access to easy-to-use tutorial and reference material in order to do their jobs effectively. My feeling is that the size of the Internet just keeps on multiplying - and the quantity and complexity of the protocols in use on the network is also expanding at a phenomenal rate - meaning that the pool of qualified admins who can keep track of everything just keeps on shrinking.

To that end, volume one describes the basic elements of the Internet suite, including IP, UDP, TCP, ARP, ICMP and multicasting. I'm really happy with how this volume has shaped up, but won't be releasing it until volume two (Internet Application Protocols) is also in the bag. That volume will give the same sort of treatment to the common file transfer, lookup, and electronic mail protocols that define the Internet today. Additional volumes that are also being planned include Corporate Application Protocols (DHCP, NTP, SYSLOG, etc), Routing Protocols, Security Protocols, and so forth. Needless to say, this project will be on-going for at least a few years.

There have been lots of problems with this work. For one thing, most of the RFCs are just impenetrable to the average reader. Apparently, they are also impenetrable to most of the vendors, since there is also a huge degree of variance in the actual implementations, and doing interoperability testing and comparisons has added a significant amount of work to this project. For those of you who are keeping score, Solaris 7 seems to have the best IP stack on the market, doing more things "right" than anybody else.

VOIP Demolition Derby

At ComNet 99 in DC earlier this year, I gave a series of presentations on Voice-over-IP with David Willis from Network Computing Magazine, where we discussed and demonstrated some of the issues with VOIP today. Some of these, um, "challenges" include:

	Bandwidth utilization. The only codec you can get today from every vendor in the VOIP market is G.711, which uses 64 kb/s for each channel. This means that a bi-directional call will use 128 kb/s, even before you factor in stuff like IP, UDP and RTP overhead. This is way more than most networks are capable of handling on a large scale. This problem is getting resolved via smaller codecs and greater access to bandwidth, but is still much more of an issue than it should be.
	Latency. Bandwidth concerns may go away, but latency never will. Latency is one of the fundamental laws of the universe, and is no more "solvable" than the law of gravity. The kicker for VOIP in particular is that using IP packets for voice actually introduces more latency, as the packets have to be completely read before they can be forwarded (traditional circuits forward individual bits or small packets that don't have the overhead of IP+UDP+RTP). Problems with latency will never go away, and will only be minimized if folks stop trying to use IP (Voice-over-ATM and Voice-over-Ethernet have significantly less latency simply because they have less overhead; my bet is that these technologies are going to see a resurgence).
	Features. Today, you expect "hold" and "transfer" to pretty much work using traditional telephony equipment, but they don't work across vendor lines using VOIP. Pressing "hold" on a Cisco phone causes NetMeeting to drop the call, for example. Who cares about the promise of advanced features that packetized voice allows if we can't even get "hold" to work?

There are many more issues with VOIP that have to be addressed before it can be made to work reliably. Security is one of these problems (RAD makes a network analyzer that can record and play back H.323 calls), price is another, the ineffectiveness of the PC platform at real-time networking is another, and so forth. Is it a dead end? Absolutely not, but it is not the simple solution that it is pitched as. The truth is that the technology is only useful today in some limited situations, and it will be a long time before we all have VOIP phones on our kitchen walls.

Anyway, since the demo at ComNet went so well, Network Computing is hosting another set of these presentations at NetWorld+Interop. We'll be presenting several times a day, every day and have also added a set of presentations on quality-of-service (another hot topic with more smoke than products). Stop by and say hello if you'll be at the show.

Resource Configuration Management

Another of my Network Computing projects is a series of presentations on IP Configuration Management that I'll be doing throughout the summer. This will be a detailed, in-depth discussion of the protocols, technologies and products that are available to help you manage the devices on your network.

Here's the skinny: IP is a wreck when it comes to device configuration and application automation. Remember how easy it was with IPX, NetBEUI and AppleTalk? You took the PC out of the box, plugged it in, and used the existing network services to automate addressing and routing (and even application configuration, to a point). With IP, you have to manually configure everything. Although DHCP solves part of this problem, the lack of integration with other services limits its functionality dramatically. For example, most of the Dynamic DNS solutions on the market are a train wreck, and those products are only trying to get hostnames and addresses synchronized, never mind automating application configuration or network policies.

I'll also be talking about other technologies like SLP versus ACAP versus LDAP for locating network resources and setting per-user configurations. One sneak preview: SLP looks like it will be mostly useful for SOHO networks that don't have a directory in place already, since it does not use (nor provide for) any native authentication and access controls. Finding a printer with SLP is easy, but on corporate networks you don't necessarily want to incur the costs associated with explaining to a user why they can see a printer but can't print to it. Directories eliminate this cost, although the setup time and expense is much greater.

At the high-end of the scale, integrating DHCP leases with LDAP user information is one of the upcoming trends that offers to give you greater control over your infrastructure, simply by leveraging the information you already have on the network. For example, you could use this data to restrict access to a specific LAN according to LDAP user data, having the firewall compare IP addresses to the LDAP/DHCP repository. If the username associated with that IP address is good, then access is allowed, regardless of where that user may be connecting from (the current pitfall with address-centric filters). Another example: some infrastructure vendors are talking about setting end-to-end QoS based on this type of mapping, where the CEO always gets higher priority across the WAN than the mailroom clerk. There are lots of other examples here.

By the end of the day, attendees should have a good idea of what the potential solutions are, what problems lie ahead, and which vendors are playing in these spaces. Stops are currently scheduled for Las Vegas, Boston, Chicago, Washington D.C. and San Francisco. The first show will be given next Monday, prior to NetWorld+Interop in Vegas. Sign up at http://www.nwc.com/forms/ipman-signup.html if you're interested in attending.

And more...

Apart from these big projects, I have also continued writing articles, consulting for vendors and users, and doing all of the other things I do to keep the landlord happy. I've also been planning a relocation to the Denver area (postponed until after the summer, again), and have finally finished building a PC-based home entertainment center (two years after starting). These are my main excuses for not being extremely prolific with this newsletter lately anyway. I'll try not to get this far behind again.

Regards,

Eric A. Hall
President, EHS Company

Written by Eric A. Hall.
Copyright © 1998, EHS Company. net.Opinion is a trademark of EHS Company. All rights reserved.