TCP/IP First-Step [Electronic resources] نسخه متنی

What's the Secret?

Now there's a question! What's the secret behind the great mystery? How can TCP/IP work so ubiquitously? How can it possibly support every applicationliterally? Sure, some of the applications have similarities, but a world of difference lies between others! How can it possibly be equally useful in a business environment and in online interactive gaming? Surely, some secret enables TCP/IP to achieve feats of Herculean proportions.

The mystery deepens when you stop to consider the fact that not only does it support an incredibly large array of applications, it does so globally! That means TCP/IP must span countries and support applications and computers that use a tremendous variety of languages.

A slightly more subtle aspect of TCP/IP's universality is that it binds together all kinds of different networks. Think about it; the Internet is a collection of networks. The owners of those networks are free to choose whatever products they want. Consequently, the Internet is composed of virtually every type of network gear you could possibly imagine. Different languages, different hardware manufacturers, even different network technologies are all bound together by TCP/IP.

Getting back to the original point: What's the secret? How can TCP/IP possibly do all it does? As so often happens in life, no single answer explains it all. However, a couple of points go a long way toward helping you understand how TCP/IP can work as universally as it does:

Open standards

Functional abstraction

Open Standards

The concept of open standards dominates information technologies. In essence, it means no secrets: Everyone agrees on the technical specifications for a technology and those specifications are made publicly available. Anyone can build products based on that technology. The good news in an open-standard industry is that consumers can be confident that productsmade by different manufacturerswork well together.Chapter 3, "The Quest for Freedom of Choice," takes a much closer look at open standards. For now, know that using open standards is the way TCP/IP overcomes the challenges of supporting communications over a network made up of different products and technologies made by different manufacturers. The other way TCP/IP works so universally, alluded to earlier, is found in the concept of functional abstraction.

Generalizing to See the Patterns

A wise old saying holds that sometimes you can't see the forest because all the trees are in the way! That's a humorous way of saying that when you look at details, all you can see are those details. The same is true with technologies. Perhaps the best way to think about this aspect of TCP/IP follows: divide first, then conquer!

It is impossible to figure out how to support each application individually. Too many exist. Instead, TCP/IP benefits by using open standards as a forum for communicating to software vendors. That way, software vendors design their products so they work with TCP/IP. Although that simplifies things greatly, and certainly explains how things work today, it leaves one wondering if there wasn't a chicken-and-egg conundrum to resolve. In fact, there was!

This conundrum is relatively easy to explain, but remarkably difficult to solve in real life. Before a communications protocol such as TCP/IP can be successful, it has to support a lot of applications. After a while, it supports so many applications that you can safely assume it has been installed on a majority of computers. When it reaches that point, it becomes easy to convince software vendors to design their software for TCP/IP compatibility. The catch is figuring out how to support that initial batch of applications! Those applications, by virtue of having existed before TCP/IP was created, weren't designed for compatibility. Rather than falling into the trap of trying to design a communications protocol to work with each individual software application, it becomes necessary to divide…and then to conquer!

Generalization comes into play here. You can lump various applications into broad categories for a more manageable number. Instead of developing protocols that work with each specific application, the challenge is reduced to developing protocols that work with groups of related applications. You need to look past the details to see the trendsthe commonalitiesthat make this possible.

Generalizing from TCP/IP's Perspective

TCP/IP benefits by generalizing the network performance requirements of various application types. When you look at network performance requirements for all application types, you quickly see that only two true general types exist:

Those that require timely communications

Those that require highly reliable communications

That might sound too simple, but it's true! Literally every single application you can think of fits into one of those two categories. It's just not obvious because those two categories lie one layer of abstraction beyond the obvious.

Categorizing is a useful approach to managing large amounts of anything. For example, when faced with a bewildering array of software, most people look at the individual software packages and then start categorizing them. Another approach is to categorize by function. It would, of course, be equally valid to categorize by manufacturer or even by the color of the box they came in. The actual categories are much less significant than the fact that you are categorizing.

A Closer Look at the Example

The example works only if you use function to categorize the software. Tens of thousands of software packages might be available, but they are easily reduced into a manageable number of categories such as word processing, web browsers, electronic mail, games, chat, videoconferencing, and so on. Figure 2-1 shows this: All software applications can be distilled into a finite and manageable number of categories. In other words, they are abstracted by some common trait. To keep the example simple, categories are limited to three.

The next level of generalization isn't quite as intuitive as the one in Figure 2-1. Basically, you look at each generalized category and try to find another basis for further categorization. At this level, manufacturer and box color aren't options because you're not looking at individual software productsyou're looking at functional categories. You could, for example, further generalize categories by minimum hardware requirements (such as the required amount of memory or disk space). Alternately, you could look at network performance requirements.

That second generalization enables you to further reduce categories. In this case, you go from an unlimited number of applications, to handfuls of functional categories, to two network performance requirements. TCP/IP looks at applications this way. From TCP/IP's perspective, just two types of applications exist: those requiring reliable delivery and those requiring timely delivery. Figure 2-2 illustrates this.

It really is that simple: TCP/IP doesn't try to work with every application (or with every application type). It does, however, bend over backward to satisfy two general types of network performance.

The Need for Reliable Communications

The first broad network performance requirement category is characterized by reliable data delivery needs. Perhaps the best example of a reliable delivery service is the U.S. Postal Service. Their legendary motto assures you that the mail will be delivered regardless of the prevailing regional meteorological conditions. Of course, the mail is delivered quicker on nice, sunny days than when there's a foot of snow accumulating, but that's okay! The guarantee is that the mail will get delivered. Nobody said anything about timeliness! You should be thrilled when the mail arrives in a timely fashion. Timeliness is just a pleasant bonus. The delivery itself is the only thing guaranteed by the U.S. Postal Service.Chapter 9, "Best-Effort Deliver: It's Now or Never," introduces you to them. These applications require a timely delivery of data, but do not take any extra steps to ensure reliable delivery.

The Need for Timely Communications

Several types of applications have such strong timeliness requirements that data delivered lateor earlyis worthless. Consequently, it is simply discarded! That might sound absurd, but it's true. An example of such an application is talking live over the Internet. Known as voice over IP (VoIP), this technology is a classic example of an application that requires timeliness instead of reliability when it comes to data delivery.

VoIP doesn't always match the quality of a good, old-fashioned telephone connection. In fairness, it was never intended to match it. VoIP was designed to be cheaper, not better, than the traditional telephone system. If you have a solid, fast, and problem-free network, VoIP's connection quality is surprisingly good. If, however, you are using VoIP to communicate across long distances and using a network prone to congestion, you will notice that speech gets clipped, garbled, and even dropped! That's by design. While those symptoms might be bad, trying to correct them might be even worse.

Here's how it works: When you talk, the sounds of your voice get chopped into tiny pieces. Each piece is carefully wrapped up and shipped off to the person with whom you are conversing. For that person to understand you, each of those pieces must be put back together in the right order. Putting them together out of sequence creates a small but noticeable interruption in the sounds.

The Internet is a dangerous and unpredictable place and sometimes bad things happen to good data. In the case of the VoIP session, say that 1 in every 1000 pieces sent gets lost, damaged, or just arrives late. Although that's not a horrendous error rate, it can be made worse, particularly with late arrivals.

For the sake of simplicity, assume you are calling your best friend using VoIP across the Internet. That communications session generates 500 pieces of data, each individually wrapped and sent on its merry way through the Internet. Each piece could, theoretically, take a different path through the Internet. Thus, you can't guarantee in which order you receive them. In a perfect world, they would arrive sequentially, but this is far from a perfect world. Plus, the conversation is real time, so your PC must process the data and send it on to you as quickly as it is received. Therein lies the requirement for timely delivery!

Continue the example: If you receive the first 100 pieces of data fine and in the proper sequence, all is well. However, you have a decision to make if you receive piece number 102 when you were expecting 101. You have no way of knowing if it's about to be delivered or if piece 101 was lost in transit.

It almost doesn't matter; because the conversation is real time, your computer is obligated to forward the data as it is received. You notice a minor disturbance in the flow of your friend's voice as you hear the contents of data piece 100 and then 102, skipping 101. Although losing that piece of data might make for a slight annoyance, it's better than the alternative! What if, for example, that missing piece showed up just as you were listening to piece 102? What if your computer sent it on you? You would actually hear a second glitch in the conversation. You would have heard 100, 102, and then 101. In this particular case, guaranteed delivery creates a bigger problem. Data that's late gets thrown away, thereby creating a disturbance. That's better than trying to jam it where it doesn't belong. Doing so creates a second disturbance.

Like applications requiring reliable data delivery, applications requiring timely delivery regard the reliable delivery as a pleasant bonus. It's not a bonus that they are willing to wait for, though. If the data arrives, it arrives. If it doesn't…on to the next packet!

Timely delivery is better known as best-effort delivery. Best-effort delivery suggests that the communications protocol makes one attemptits best effortto get the data delivered. If it isn't delivered, it isn't delivered. Your communications protocol has already given its best shot and does not try again.