zweig@m.cs.uiuc.edu (06/28/89)
I have gotten flamed for saying that the Presentatio Layer can be (more or less) null in an OSI-compliant implementation. The main argument seemed to involve "having" to do ASN.1/BER encoding/decoding and prepending Presentation and Session headers onto each datagram at run time. Now somebody is seriously confused, so I'll toss this to the net and see who can set everyone straight.... My understanding of ASN.1/BER is that it is a means for describing Abstract Objects (such as the english word "Hello") in a universally-understood manner. So if I am sending bits to somebody who is expecting a BER encoding of the ASN.1 description of the sequence of characters "Hello", she will first expect a sequence of octets that say "here's an english-language character [tag and type] and it is an H..." and then some more that say "Okay, here's another one, and it's an e..." and so forth. No matter if I'm running on a PDP-6 and she has a CDC 6600. We agree to use BER to encode/decode and everything is cool. However, if we have agreed in advance to use ASCII, I can just send the 5 ASCII octets 'H', 'e', 'l', 'l' and 'o'. Can't I? If I don't need ASN.1/ BER I don't see that the OSI standards force me to use it. Furthermore, this nonsense about "having to do the encoding at runtime" is laughable. That's like saying I have to calculate TCP checksums on data at the same time I send it, rather than when I store it to disk if I want. The messages in the X protocol are already known and can be encoded at compile- time. Of course, the BER decoding still needs to take place, but since the protocol in question (X) has well-known messages, I can do table-driven decoding at minimal additional overhead. And I also got flamed for failing to realize that even if the Presentation Layer/Sesseion Layers do nothing, P/S headers need to be prepended to the datagram. Aren't the headers going to be "dull" (in the sense of not costing much to calculate) with a protocol layer that isn't doing anything? Again, it seems like most of the information ought to be calculable in advance so as not to slow down operation of the protocol. I think I'm not completely wrong -- and I never like being made a fool of by other people over the Net. So I'll make a fool out of myself and say that I think these arguments are specious and that X can live in Layer 7 quite happily and a non-brain-dead OSI protocol implementation (if such a thing were to be brought into existence) would not make it unhappy and bored up there.... -Johnny The-OSI-Reference-Model-has-nothing-to-do-with-Implementation (#include <stddisclaimer.h>)
amanda@intercon.uu.net (Amanda Walker) (06/29/89)
In article <36800002@m.cs.uiuc.edu>, zweig@m.cs.uiuc.edu writes: > [...] > Furthermore, this nonsense about "having to do the encoding at runtime" is > laughable. > [...] > -Johnny The-OSI-Reference-Model-has-nothing-to-do-with-Implementation > (#include <stddisclaimer.h>) I agree completely. ASN.1/BER are *representations*, not algorithms. Once "the bits are on the wire," so to speak, how they got there is immaterial, as is what the receiving process does with them. The same issue has come up in implementations of Sun RPC & XDR. The reference sources build everything on the fly, but a "real" implementation should (I would argue) only do what it absolutely must on the fly. In RPC & XDR's case, this means that ultimately, XDR is just a way of specifying packet formats (ASN.1 is similar, if more complex). Granted, both ASN.1 and XDR allow automated tools to produce encoding and decoding routines straight from a high-level description, but I would argue that (at least in their current state) these should be considered prototyping aids more than production aids. If what's important is to get a prototype running as quickly as possible, they are great. This is not to say that, at some point, the automated tools may become good enough to use in production environments. The success of tools like GLA (a lexical analyzer generator) and MetaWare's fast LR(1) parser generator show that this sort of thing can be done well, but among the reasons for their success is to precompute as much as possible in advance, and to minimize the amount of processing that has to be done at runtime. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
cire@CISCO.COM (cire|eric) (07/03/89)
>> >From iso-RELAY@SRI-NIC.ARPA Sat Jul 1 01:33:16 1989 >> Date: 29 Jun 89 15:40:03 GMT >> From: intercon!amanda%intercon.uu.net@uunet.uu.net (Amanda Walker) >> Subject: Re: Null Protocol Layers Question >> References: <36800002@m.cs.uiuc.edu> >> Sender: iso-relay@sri-nic.arpa >> To: iso@sri-nic.arpa >> >> In article <36800002@m.cs.uiuc.edu>, zweig@m.cs.uiuc.edu writes: >> > [...] >> > Furthermore, this nonsense about "having to do the encoding at runtime" is >> > laughable. >> > [...] >> > -Johnny The-OSI-Reference-Model-has-nothing-to-do-with-Implementation >> > (#include <stddisclaimer.h>) >> >> I agree completely. ASN.1/BER are *representations*, not algorithms. Once >> "the bits are on the wire," so to speak, how they got there is immaterial, >> as is what the receiving process does with them. >> . . . >> -- >> Amanda Walker >> InterCon Systems Corporation >> -- >> amanda@intercon.uu.net | ...!uunet!intercon!amanda This is like saying that Theory has nothing to do with Application. While in many cases it is certainly true that a Model has nothing to do with Implementation it is not always the case. If the goal is to build a model that maps to many different instantiations then a completely independent model is desireable. In that case it is indeed true that the model doesn't have that much to do with an implementation. So XDR or ASN.1 are representations. Big deal. Given any representation there are many implementations some better than others. Given a particular machine and a particular representation there is at least one optimal implementation. Optimal when performance is considered. Performance is a big deal that's what's driving all of this conversation. Given different representations and their mappings to a given machine will directly impact the implementation and the resultant performance. In other words, the Model and the Representation directly impact the implementation and the resultant performance. -c cire|eric Eric B. Decker Token Ring Development cisco Systems - engineering Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941 I speak for myself here.