Re: [Hist Trivia] IP Protocol Layers
Randy Bush wrote: I.e., layering is, IMO at least, a model. Fine for describing things, but not necessarily a good blueprint for an implementation. compilation systems can be constructed which will procuce efficient inlined code for nicely modularized (layered) source. just not for programs which use type-free pointers and similar analysis-defeating features. randy They can also do disastrous things, e.g., creating in-lined chunks that thrash the instruction cache. It's not just the layers that need to be spec'd, but the interfaces between them. Even then all you have is a specification, not necessarily an appropriate design for an implementation. Greg Minshall wrote: ...i value protocol model AND mechanism correctness over some amount of last ounce optimization. It's also not just about optimization - sometimes the best way to think about a concept isn't the best (most flexible, simplest to code, simplest to debug, ...) way to implement it. Mahadevan Iyer wrote: A problem well-stated is a problem half-solved. Agreed - half. Joe
Re: [Hist Trivia] IP Protocol Layers
Also seems to be a good electric fence - you can cross layers, but very carefully. Randy Bush wrote: I.e., layering is, IMO at least, a model. Fine for describing things, but not necessarily a good blueprint for an implementation. compilation systems can be constructed which will procuce efficient inlined code for nicely modularized (layered) source. just not for programs which use type-free pointers and similar analysis-defeating features. randy
Re: [Hist Trivia] IP Protocol Layers
* From [EMAIL PROTECTED] Tue Jul 17 13:21:47 2001 * Date: Tue, 17 Jul 2001 14:58:35 -0500 (CDT) * From: Timothy J. Salo [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Subject: [Hist Trivia] IP Protocol Layers * X-Loop: [EMAIL PROTECTED] * * Can anyone point me to an early reference describing the Internet * protocol layers in IP terms, rather than OSI terms? * * One recent text used the following terms. However, I don't know whether * this description has a long history, or is simply revisionist history. * *Application *Transport (TCP, UDP) *Internet (IP, etc.) *Network Interface (LAN and WAN technologies). Tim, This is the Internet protocol stack as understood by the creators of TCP/IP. It is documented (at least) in section 1.1.3 (Internet Architecture) of RFC 1122, a document that encapsulates a great deal of the early wisdom on the Internet protocols. Note, however, that RFC 1122 deliberately OSIzed the terminology by using Link Layer instead of Network Interface. Also, the term transport was imported from OSIland; we did not really have a name for that layer. See RFC 793, for example. * * By 1983 the Internet protocols were already being recast in OSI terms. * Vint Cerf, in The DoD Internet Architecture Model, described the * following layers: * *Application *Utility *Transport *Internetwork *Network *Link *Physical * * In May 1979, Jon Postel in IEN-94 (Internet Protocol Handbook; it was * small then - 1209 bytes) use the following layers: These were not layers, they were categories. * * * Internet Protocol Handbook * Table of Contents * * Gateway Level * Internet Datagram Protocol IEN-80 * Gateway Routing: An Implementation Specification IEN-30 * * Host Level * User Datagram Protocol IEN-88 * Transmission Control Protocol IEN-81 * Multiplexing Protocol IEN-90 * * Application Level * Name Server Protocol IEN-89 * Internet Message Protocol IEN-85 * * Appendices * Protocol Options IEN-92 * Address Mappings IEN-91 * Assigned Numbers IEN-93 * * Does anyone have a pointer to an early, more traditional, non-OSI * description of the TCP/IP protocol layers? * * (By the way, I found the concept behind RFC 157, Invitation to the Second * Symposium on Problems in the Optimization of Data Communications Systems, * rather interesting. I must admit that I hadn't thought of submitting * spam as an RFC.) !? Hardly spam. The early RFCs were used for all sorts of informal notes and announcements among the small set of early participants in the ARPAnet. There are several one-line RFCs that announce meetings, for example. Bob Braden * * Thanks, *-tjs *
Re: [Hist Trivia] IP Protocol Layers
End-to-End Transparent Transport of the IPv4 TOS field would seem to be a fundamental given for IPv4. It is an 8-bit field and what goes in should come out on the other end, unchanged. In my opinion, people and companies should check with the carriers that they connect to, in order to make sure that the TOS field is transported unchanged. Assuming it is, then splitting that 8-bit field into two symmetric 4-bit fields allows the entire IPv4 Internet Address Space to be increased by a factor of x16. All of the major carriers seem to be willing to go on record as saying that they DO NOT CHANGE the TOS field. That seems to be a start, at ending what some would consider to be layer violations. http://www1.ietf.org/mail-archive/ietf/Current/msg12713.html RFC-2001-07-11-000 IPv4+ and Testing of TOS Routing on New.Net Transport Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: Mahadevan Iyer [EMAIL PROTECTED] Cc: ietf [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 2:26 PM Subject: Re: [Hist Trivia] IP Protocol Layers Interestingly enough, when we wrote RFC 1958 Architectural principles of the Internet, nobody suggested layer violation is evil as a principle. The arguments against layer violation tend to be pragmatic - certain types of layer violation (such as content based routing) could lead to complex failure modes - others (such as diffserv peeking) are probably safe. It certainly shouldn't be a religious principle. Brian Mahadevan Iyer wrote: Jon Crowcroft wrote: In message v04220802b77bde136984@[10.83.97.216], Steve Deering typed: We used to use gateway instead of router (and a few still do), and i lik the fact that if you type getaway by mistake you get what people are trying to do when they are routed ... i also like the fact that MOST fancy things we do in traffic treatment (firewall, diff/int serv, header compression, checksum) ignore this layering rubbish idea and look at the whole packet and the whole state of the systems where you need to.. I always thought peeking into other layer headers to make better decisions doesn't always destroy layering. It's when the implementation gets tied to a specific other-layer technology, or it *writes* into other layer headers, or performs 'designated' other-layer functions, that layering is destroyed. Say, a diff serv implementation that tries to figure out what kind of lower layer protocol is present and if it succeeds in doing so, uses the lower layer information to make forwarding decisions, is not really destroying layering, is it. I can still deploy this diff serv implementation readily over all kinds of lower layer 'technologies' or standards, because it is not tied to any specific such technology. If it can recognise the lower layer technology, it uses that extra lower layer information to try improve performance, otherwise it just performs default operations. So for example, I can still easily transfer such an implementation from a wired-ethernet to some wireless standard without any rework. Now, isn't *that* kind of layering good? Or am I missing something.
Re: [Hist Trivia] IP Protocol Layers
Jon Crowcroft wrote: In message v04220802b77bde136984@[10.83.97.216], Steve Deering typed: We used to use gateway instead of router (and a few still do), and i lik the fact that if you type getaway by mistake you get what people are trying to do when they are routed ... i also like the fact that MOST fancy things we do in traffic treatment (firewall, diff/int serv, header compression, checksum) ignore this layering rubbish idea and look at the whole packet and the whole state of the systems where you need to.. I always thought peeking into other layer headers to make better decisions doesn't always destroy layering. It's when the implementation gets tied to a specific other-layer technology, or it *writes* into other layer headers, or performs 'designated' other-layer functions, that layering is destroyed. Say, a diff serv implementation that tries to figure out what kind of lower layer protocol is present and if it succeeds in doing so, uses the lower layer information to make forwarding decisions, is not really destroying layering, is it. I can still deploy this diff serv implementation readily over all kinds of lower layer 'technologies' or standards, because it is not tied to any specific such technology. If it can recognise the lower layer technology, it uses that extra lower layer information to try improve performance, otherwise it just performs default operations. So for example, I can still easily transfer such an implementation from a wired-ethernet to some wireless standard without any rework. Now, isn't *that* kind of layering good? Or am I missing something.
Re: [Hist Trivia] IP Protocol Layers
Interestingly enough, when we wrote RFC 1958 Architectural principles of the Internet, nobody suggested layer violation is evil as a principle. The arguments against layer violation tend to be pragmatic - certain types of layer violation (such as content based routing) could lead to complex failure modes - others (such as diffserv peeking) are probably safe. It certainly shouldn't be a religious principle. Brian Mahadevan Iyer wrote: Jon Crowcroft wrote: In message v04220802b77bde136984@[10.83.97.216], Steve Deering typed: We used to use gateway instead of router (and a few still do), and i lik the fact that if you type getaway by mistake you get what people are trying to do when they are routed ... i also like the fact that MOST fancy things we do in traffic treatment (firewall, diff/int serv, header compression, checksum) ignore this layering rubbish idea and look at the whole packet and the whole state of the systems where you need to.. I always thought peeking into other layer headers to make better decisions doesn't always destroy layering. It's when the implementation gets tied to a specific other-layer technology, or it *writes* into other layer headers, or performs 'designated' other-layer functions, that layering is destroyed. Say, a diff serv implementation that tries to figure out what kind of lower layer protocol is present and if it succeeds in doing so, uses the lower layer information to make forwarding decisions, is not really destroying layering, is it. I can still deploy this diff serv implementation readily over all kinds of lower layer 'technologies' or standards, because it is not tied to any specific such technology. If it can recognise the lower layer technology, it uses that extra lower layer information to try improve performance, otherwise it just performs default operations. So for example, I can still easily transfer such an implementation from a wired-ethernet to some wireless standard without any rework. Now, isn't *that* kind of layering good? Or am I missing something.
Re: [Hist Trivia] IP Protocol Layers
And if the terminology really is the most important contribution of OSI - I think that this is amusing, ironic, and instructive all at the same time. It's amusing and ironic because of the huge amount of effort that went to developing and promoting OSI. It's instructive because it demonstrates that even something as simple as a well-thought-out taxonomy can be really beneficial. keith - i think you're pretty close to damning with faint praise here, and you don't realize it. in high earth orbit, i can certainly agree that the high-level terminology was useful. in terms of any practical perspective though, the terminology is meaningless without an architecture, and the OSI architecture isn't all that helpful. for example, one of my favorite OSI acronyms is IONL, which stands for the internal organization of the network layer. ISO actually produced a standard on this. why? well, because in the OSI architecture, you had to accomodate both CL and CO network (sub)layers. this is simply not workable or even rationale. so, if the statement is that the OSI architecture was so general that it could accomodate every possible existing and future architecture, i guess i'd agree, but before doing so, i'd ask what's the point? /mtr ps: many of us still use router instead of intermediate-system and host instead of end-system, so i guess i have to question just how useful all that OSI stuff really was. (other than giving me the opportunity to write several books ten years ago poking fun at it...)
