05.15.02
TCP/IP Is Not Like An Onion
2002, May 15th
Take a class on networking at any major university or take any networking equipment vendor’s network training and they will trot out the Open Systems Interconnect (OSI) model of a network. This is a lame model. Real networking doesn’t even remotely resemble this model. However, despite the overall uselessness of the OSI model, some people have gone to the unreasonable extreme of redefining TCP/IP in terms of that model. This is even more ridiculous
TCP/IP was not designed; It has evolved as our understanding of computer communications has evolved.
The OSI model was developed by a seven committee working group of the ISO. (Don’t worry. There won’t be a quiz on this material.) The seven committees provides one possible reason that the OSI model has seven layers.
The seven layers of the OSI model are:
- Application
- Presentation
- Session
- Transport
- Network
- Data Link
- Physical
The theory of operation with each of these layers is that, as an application, you need only understand the Application layer in order to use the network. When designing the Session layer, you need not be bothered with implementation details of the Network, Data Link and Physical layers. Each layer hides the implementation details of the layers above and below. In the real world, for reasons I wish I could adequately explain, this is a very slow network.
My inadequate explanation is: speed and accuracy are the most important parts of a network. You will likely write a program that does a networking task once for millions of actual uses of that program. In order for the 7 layer model to work, each layer must hide implementation details of all layers below and all layers above. This means that you cannot depend on a particular behavior in the Physical layer at the Session layer. So, suppose that your Session layer could be simplified for the case of a reliable network. You cannot take advantage of that and skip all the intervening layers to just deliver the data. Your data must slog its way through four more layers to get to the consumer and then four layers there to get back to another Session layer. This takes time. More importantly, it represents “latency” which is sometimes hard to overcome.
Another example: Let’s suppose that you have an application that, for locally connected systems uses a broadcast behavior but for distant systems uses a monocast behavior. This allows the local systems to each receive the data using minimal bandwidth and the remote systems to receive the data in a more reliable stream. If the implementation below the Presentation layer is hidden from you, you cannot see which systems are local and which are not. So, you cannot write that application
The problem is that an application that doesn’t understand how networks work is poorly written.
An aside: There are a few lines of code that appear almost identical in almost every TCP/IP client program and another few that appear in almost every server program. These lines were published in some textbook or some journal and now everyone uses them. They are almost used as incantations, without any understanding of what they do on the part of the programmer. They are popular because, for 90% of networking, this is all you need to make the connection from client to server. Unfortunately, in many cases of the other 10%, these code fragments are misapplied or are simply inappropriate resulting in bad operation or performance or unusual behavior.
With the academic success of the OSI model, the TCP/IP networking community redefined their model of a network in terms of the OSI model. This model has the following five layers:
- Application
- Transport
- Network
- Data Link
- Physical
It is important at this point to discuss why you make a model of a system. In architecture (buildings) you build a model to show the customer what the finished job will look like. In software systems, a model is more like the architect’s blueprints. It allows a single team to coordinate the behavior of a great deal of code that they may never see. So, why design a model for an existing system? Simple, it becomes a teaching and behavior predicting tool. A good example of this is “The Ideal Gas Model” of physics. It is a pretty good predictor of the behavior of gases. It is wrong at the extremes of temperature and pressure, but it provides a teaching tool and a set of equations that are “close enough” for everyday use. It is obvious that we didn’t come up with the Ideal Gas Model and then design the behavior of gases around it. It just happens to “fit” the behavior pretty well. There are many examples of this sort of model in physics.
So, the next question becomes: Is the 5 Layer TCP/IP model a “good” model of TCP/IP networks.
Duhhh, No. It is not.
TCP/IP is really a 2 layer system. The TCP/IP part of the system is one layer and the Physical/Data Link is the other. While you can certainly design a thing to replace the TCP part of TCP/IP, it would no longer be TCP/IP then, wouldn’t it? Likewise, TCP was actually designed before IP. IP was designed to solve the problem of multipley interconnected networks. Before IP was designed, however, there wasn’t something else performing its functions at a software layer in TCP/IP because there was no such thing as IP. Get it?
The reason that there are only two layers is simple. You cannot write a program and interact with only the TCP layer because you have to use code that finds out the IP address of the system you wish to contact. This means that the TCP layer does not hide diddly-squat from you. Those magical lines of code mentioned in the aside above interact at every layer except the bottom two. These two layers are typically some form of Ethernet, at the host level, which defines them both and hides neither.
TCP/IP, while it is not “layered” is “encapsulated.” It works like this. Your application creates a hunk o’ data, HOD (which may be a single byte, or octet) and says to the network library, “Send this stuff.” If you are using TCP/IP, this HOD is wrapped up in a thing called a TCP packet and passed to the IP part of the library. There, the new packet has an IP header attached to the fron and the whole schmear gets handed over to the network card driver. That driver interacts with the network card itself to load the packet of data into a transmitter circuit in the appropriate format for transmission. So your data is encapsulated by a TCP packet. That is encapsulated by an IP packet and THAT is delivered by some means determined by you network hardware to an appropriate reciever (which may be the end host or a router.)
The key to all of this is that, while it looks like TCP sits on top of IP and IP sits on top of the network card driver and the network card driver sits on top of the network card and the network card sits on top of the interconnection, nobody designs things this way. Even if they did, you couldn’t use TCP without knowing that IP (or something like IP) was under it. The software interface is just not designed as layers.
Some of you may be wondering why I wrote all this. The truth is, I have to take a test in a few days and for that test I have to know the OSI and TCP/IP network “models.” Learning academic overkill crap just to get a little symbol on my business cards (which I don’t have) irked me a bit.
Thus endeth the diatribe.