The internet does not scale in layers. This sounds more like Bitcoin is not scalable, so we're introducing abstractions to work around its limitations.
Scaling is not a goal of the OSI model, and TCP/IP predates (and does not adhere to) the OSI model anyway. For insight into how and why this came about, I recommend Padlipsky's "The Elements of Networking Style."
Those layers are different levels of abstraction that actually sit on top of one another, but encompass the lower layers.
e.g. HTTP, SMTP, POP3, etc., all sit on top of TCP — that is to say: all of those protocols actually use TCP, they are TCP, they are all made from TCP packets/communications.
TCP sits on top of IP, that is to say: all TCP packets are in fact IP packets.
They are layers of abstraction, and each layer of abstraction is not just 'related' to the lower layer(s), or 'referencing' the lower layer(s) once in a while, each of those upper layers is in fact an instance of the lower layer.
At the bottom, it's all IP. The higher layers aren't substitutes for IP that get turned into IP when necessary, they are all IP.
If your comparison was valid, then protocols such as e.g. HTTP wouldn't actually be valid TCP packets and valid IP packets, instead HTTP would be completely separate to the lower levels it is built upon, and at some point it would be converted back and forth to the other protocols. Which is not what happens.
If your comparison was valid, then all L2 cryptotoken transactions would actually simultaneously /be/ blockchain transactions — and not just written back to it periodically.
Edit:
Here's an analogy: it's like IP protocol is letters, those letters can be grouped into words, which is the next layer up, e.g. TCP, UDP, etc., and those words can be grouped into sentences, which are like the higher level protocols, such as HTTP, SMTP, POP3, etc.
Granted, the OSI model also includes lower levels, and I'm only discussing three higher layers, but the principle is the same. The higher levels /encompass/ the lower ones, they are actually built /with/ or /from/ the lower-level components. This isn't how Lighting works. It's a separate distinct network to the main blockchain, and it then writes back to blockchain.
To be quite frank, based upon the fact you think the layers of OSI and TCP/IP are to help it scale, you clearly appear to have little (or no) understanding as to how that actually works — so your direct comparison to LN scaling here isn't just weak, it's meaningless and just plain factually wrong. And this is particularly obvious to folk who /do/ actually understand both.
— Good day to you, your bad logic and your poor argument.
"A really vicious critique of the misguided ISO networking standards attempt, written when the 'OSI model' was trendy & lots of people were babbling about the sacred seven layers."
"The Book": The Elements of Networking Style: And Other Essays & Animadversions of the Art of Intercomputer Networking, by M. A. Padlipsky (1985)
The World's Only Know Constructively Snotty Computer Science Book: historically, its polemics for TCP/IP and against the international standardsmongers' "OSI" helped the Internet happen; currently, its principles of technoaesthetic criticism are still eminently applicable to the States of most (probably all) technical Arts-all this and Cover Cartoons, too but it's not for those who can't deal with real sentences.
Standards: Threat or Menace, p. 193
A final preliminary: Because ISORM is more widely touted than TCP/IP, and hence the clearer present danger, it seems only fair that it should be the target of the nastier of the questions. This is in the spirit of our title, for in my humble but dogmatic opinion even a good proposed Standard is a prima facie threat to further advance in the state of the art, but a sufficiently flawed standard is a menace even to maintaining the art in its present state, so if the ISORM school is wrong and isn't exposed the consequences could be extremely unfortunate. At least, the threat / menace paradigm applies, I submit in all seriousness, to protocol standards; that is, I wouldn't think of being gratuitously snotty to the developers of physical standards -- I like to be able to use the same cap to reclose sodapop bottles and beer bottles (though I suspect somebody as it were screwed up when it came to those damn "twist off" caps) -- but I find it difficult to be civil to advocates of "final," "ultimate" standards when they're dealing with logical constructs rather than physical ones. After all, as I understand it, a fundamental property of the stored program computer is its ability to be reprogrammed. Yes, I understand that to do so costs money and yes, I've heard of ROM, and no I'm not saying that I insist on some idealistic notion of optimality, but definitely I don't think it makes much sense to keep trudging to an outhouse if I can get indoor plumbing . . . even if the moon in the door is exactly like the one in my neighbor's.
Appendix 3, The Self-Framed Slogans Suitable for Mounting
On the occasion of The Book's reissuance, Peter Salus wrote a review in Cisco's Internet Protocol Journal which included the following observations:
Padlipsky brought together several strands that managed to result in the perfect chord for me over 15 years ago. I reread this slim volume (made up of a Foreword, 11 chapters (each a separate arrow from Padlipsky's quiver) and three appendixes (made up of half a dozen darts of various lengths and a sheaf of cartoons and slogans) several months ago, and have concluded that it is as acerbic and as important now as it was 15 years ago. [Emphasis added] The instruments Padlipsky employs are a sharp wit (and a deep admiration for François Marie Arouet), a sincere detestation for the ISO Reference Model, a deep knowledge of the Advanced Research Projects Agency Network (ARPANET)/Internet, and wide reading in classic science fiction.
In a lighter vein, The Book has been called "... beyond doubt the funniest technical book ever written."
TCP has stronger consistency guarantees, and worse performance, than the underlying IP network. Doing it the other way around is usually considered an anti-pattern [1].
