The OSI Model is Dead To Me
Hereafter I am turning my back on the OSI model. Yes, you heard me, it’s outdated crap. I was having a meaningful discussion with someone today about how you can route other things over other protocols (basically for tunneling purposes) and we got caught up on the semantics of the stupid layering of the OSI model. It’s completely outdated. As a recap, here’s how it reads:
1) Physical, 2) Data Link 3) Network 4) Transport 5) Session 6) Presentation 7) Application. Okay, pop quiz, can you tell me where HTTP lives? Now a reasonable human being understanding the semantics of the English language would say that HTTP lives on top of transport. It’s closer to telnet then it is SSL for instance, but noooo… no, my friend. Wrong. Because you are wrong and some guy in the 70’s who has no concept of how HTTP works wrote a model and now you must understand and adhere to it. It is in fact layer 7. Application. Because HTTP is an application…. or something.
Let’s look at some of the other madness. We have network and transport that are… uhm… both packets. We have SSL sitting in the session category, because… it can maintain state and TCP can’t… or something… And again, HTTP can’t either. So… this leaves nothing for actual presentation. If HTTP is to presentation as HTML is to _____ That’s right… HTML and Java and Flash and ActiveX and AJAX and all these wonderful things we’ve since come up with have no place in the OSI model. And if you tell me they are HTTP I’m going to punch you in the face. The data: directive is exactly why it isn’t HTTP. It is in fact not HTTP, it is in fact it’s own directive. And where does our friend FTP live? You guessed it… it’s presentation too. Why didn’t I notice this before? It’s not like I haven’t had to spend hours looking at it… odd.
Why is HTTP presentation layer but telnet isn’t? They are closer together than SSL is. Okay, this OSI business has got me all worked up, I’m going to stop blathering on about it. Just in case you’re wondering where we go from here id made a good suggestion that we move to the internet protocol suite which correctly bundles HTTP, telnet and SSL all together as they rightfully should be. OSI is nonsense I tell you.
December 19th, 2006 at 9:26 pm
I don’t think the OSI model is meant to be taken to the letter. As such, its point isn’t to provide a way to classify this or that protocol or application in one of its layer. One thing the OSI model gave us and which is still very much applicable today is that a layer N only needs to know how to interface with layers N-1 and N+1. For instance, a J2EE or .NET coder should not worry whether his application rides on top of ATM or GigabitEthernet. Likewise, the IP stack needn’t know anything about the framework used by the app developer.
December 19th, 2006 at 10:08 pm
I wish I could agree with that statement, but if you’re trying to tell me that HTTP (layer 7) doesn’t need to know the IP address of the user (layer 3), I think you probably haven’t spent enough time writing web applications. Not to mention things like PoF make both TCP and IP and other network device and routing information available to web applications. OSI was a great idea, it’s just so amazingly out of date it’s not practical anymore.
December 20th, 2006 at 5:34 am
people that take the OSI model literally are the same as the people who take the Bible literally.
tell me something I didn’t learn 10 years ago when OSI had already been dead for 10 years!
December 20th, 2006 at 6:38 am
Old Systems Interconnection…is taken very seriously just ask CISCO!
December 20th, 2006 at 9:54 am
dre, I think you proved my point. If you can’t take a technical specification literally it’s time to find a new technical specification.
Who needs a technical specification that’s only sorta right when you think about what the internet looked like 20 years ago? Hell, if you think about what the internet looked like 5 years ago you are wildly behind the times.
December 20th, 2006 at 11:48 am
HTTP doesn’t strictly fit into one of the OSI model layers - the protocol itself and its applications appeared well after the conception of the OSI model. You are correct, I haven’t spent much time writing web apps but (correct me if I am wrong) AFAIK an HTTP application shouldn’t make direct socket() calls for instance - it will get the IP of the client and other parameters through data formatted by the web server (which would more or less fit at the session and presentation layers).
IMHO the OSI model is a decent model for its educational value in a CS/networking class - but that’s pretty much it.
December 20th, 2006 at 9:30 pm
IP was not designed by people who used the OSI model. Therefore nothing fits into that model. If you used a network that system designed for the OSI model everything would make sense. Unfortunately the only networks systems that use OSI are so complex nobody can understand then, thus while they can almost implement them, they have no prayer of actually debugging them.
Pity, the OSI model is so simple to explain. It just isn’t what we have in the real world.
December 21st, 2006 at 12:09 pm
Henry Miller : to me, every network stack fits into the OSI model as it was originally meant to be. But TCP/IP is broken (by design but it works very well in the real world) and protocols have to span over OSI layers.
It seems to me you are mixing TCP/IP model and OSI model RSnake.
Can you tell me where in the HTTP protocol (RFC 2616) it is said you need to care about layer 3 (routing/addressing) ? If you do so, perhaps you are writing an application that serve HTTP which handles content (HTML, Java and so on…) . And there you are, content has *nothing* to do with a networking stack (which OSI is used to describe).
Regards,
Denis
January 13th, 2009 at 11:33 am
I teach OSI to low-achieving middle school students. Mid-school & High school CS is where it should be taught, & even then only as a jumping off point for investigation into the various related protocols. It is OK as part of a broad “this is the journey of your email message” narrative, & it is usefull to IT people who are troubleshooting smaller 5-10 year-old networks. Beyond that, it breaks down very rapidly, & you have to use a lot of sentences that begin with, “Yes, but…”.
I eagerly await a more appropriate descriptive model that doesn’t need cars & streets as a metaphor.
(Oh, & to the “content has nothing to do with a networking stack” people: ever try old-school real-time video teleconferencing? Its not just about bandwidth. Its about how IP handles & prioritizes packets. Thats why we’re moving to V.6)
December 30th, 2009 at 9:46 am
@Spike: actually, I have dealt with old-school real-time video streaming, and no, it’s NOT why we’re moving to IPv6.
IPv6 is all about one, and only one, thing: address space. There exists a significant desire for a return to the end-to-end model initially proposed by the original Internet architects. The implementation of “flows” in IPv6 proves fundamentally broken when compared to a protocol which works here and now, with legacy IPv4, called MPLS. And, quite unlike IPv6, MPLS also supports wormhole switching, which gives a HHHUUUGGGEEE performance boost to switching and routing performance.
To support real-time streaming video, you need guaranteed bandwidth, but you also need guaranteed latency. This is what RSVP attempts to accomplish, and is something neither IPv4, IPv6, nor MPLS address.
If you want a networking model that supports real-time, isochronous communications, you need to study how USB accomplishes this task. It’s dreadfully simple: hop-to-hop, you have synchronization frames transmitted isochronously (say, every 125 microseconds just like telcos use). Then, after the sync frames, you need to transmit your real-time data. Only *after* those, you transmit your bulk data, and only if time permits (remember, those sync frames are God; you never, ever, ever usurp a sync frame). This is the ONLY way you can support real-time, guaranteed latency flows.
Note that this also somewhat violates the concept of having a purely “dumb” infrastructure, as viewed by the Internet’s original founders.
December 30th, 2009 at 9:50 am
@RSnake: I completely agree with you concerning the OSI 7-layer cake model. However, I disagree with you concerning the HTTP protocol having a need for IP address information. As documented in the RFCs, HTTP works fine over an ATM virtual circuit. There, you’ll never find an IP address to use; instead, you’ll need ATM NSAPs.
Another example: VNC. If you read the history of the VNC protocol (called Remote Frame Buffer, or simply RFB), you’ll see that it actually started out as an ATM protocol sitting on top of AAL-5!
I think it’s more accurate to say that network layers are a useful abstraction, but as we all know, abstractions always have leaks. It’s best to think of networking layers more like the Kelvin scale, where you have “absolute 0″, the physical layer. Anything above that is anyone’s guess.