J.Henshall@EDINBURGH.AC.UK (06/06/89)
Things have gone a little quite on the Western Front, so here goes with a wee poke into the embers of architectural fundamentalism. What is going to be the outcome of the impending battle of placement of X? There can be no question of the fundamental importance of the inclusion of X in the OSI portfolio, but how does it relate to the architectural design? X requires a reliable byte stream environment for operation, any other 'higher' issues being dealt with by it's internal design. This, sensibly, dictates that X should be defined as an extended application 'stack' sitting directly on top of Transport. The primary arguments for this lie clearly in aspects of efficiency - reduced overhead in establishment of a window, and in the data minimisation over the 'wire' during operation - but this will be countered by the fundamentalist argument, i.e. X can only be seen within OSI as an application and as such must operated via ACSE. This is perhaps the best forum for open discussion of the principles at stake here, so lets have a debate...any takers? John
colella@EMU.NCSL.NIST.GOV (Richard Colella) (06/07/89)
What is going to be the outcome of the impending battle of
placement of X? There can be no question of the fundamental
importance of the inclusion of X in the OSI portfolio, but how
does it relate to the architectural design? X requires a
reliable byte stream environment for operation, any other 'higher'
issues being dealt with by it's internal design. This, sensibly,
dictates that X should be defined as an extended application
'stack' sitting directly on top of Transport. The primary
arguments for this lie clearly in aspects of efficiency - reduced
overhead in establishment of a window, and in the data
minimisation over the 'wire' during operation - but this
will be countered by the fundamentalist argument, i.e. X
can only be seen within OSI as an application and as such
must operated via ACSE.
>From the practical side, what you are suggesting is that an appropriate
place for X is directly over transport. There is some work on X in the
POSIX group that has recently started. The POSIX folks tend to be
less concerned with architectural purity and more oriented towards
things that work. Maybe that's the way to achieve the goal of X
in the OSI environment. People will use what works, not necessarily
what is architecturally pure. I'm not an architectural purist, so
I won't even try to take that one up.
Regards,
Richardcollin@hpindda.HP.COM (Collin Park) (06/09/89)
OK, I'll start with the standard disclaimer, the following opinions are not necessarily those of anyone but myself; in particular they do not necessarily represent the opinions of my employer. Seems to me (not an X expert) that if what X needs is reliable non- duplicated ordered byte-stream communications, and nothing else (e.g., graceful release), then putting it on transport is the way to go. There are undoubtedly those who would say, no, that doesn't preserve the architectural purity of osi. This is a true statement, but what does "architectural purity" buy the customer (end user, sys admin, or application developer)? Seems to me the surest way to kill OSI is to require applications that used to run over tcp/ip to now run over TPx/S/P/ACSE. I don't know of any good argument to increase the communications overhead of X-windows by requiring S/P/(and at connection-time, ACSE). If we don't try to call X an OSI application, then there's no need that I know of to require that it run in its "proper" place in the osi architecture. ------------------------------------------------------------------------------ Unless explicitly stated otherwise, opinions expressed above are my own and do not explicitly reflect those of the Hewlett-Packard Company or any other person or entity. collin park Hewlett-Packard Company collin%hpda@hplabs.hp.com 19420 Homestead Road -- MS 43LT Cupertino, CA 95014 USA
Christian.Huitema@MIRSA.INRIA.FR (06/13/89)
There is currently a proposal on the table, by DEC, using a full suite, including ACSE and presentation over a full duplex session. To sum it up: * ACSE is used for connection management operations, e.g. open window or kill window; * X-window protocol items are carried as octet strings in an ``unstructured octet string'' presentation context. This proposal has several advantages over the short sighted approach of ``just using the transport service'': * it is fully conforming to the architecture, * as a consequence, the client part could be easily implemented on those systems which provide T & S ``as a single package'', e.g. IBM OSI offers for mainframes, * using the presentation service allows for the packing of several X-requests in a single S (or T) message, which has significant performance benefits. It is untrue to assert that the use of S + P ``must cost millions of instruction''. In fact, by taking advantage of the limited number of session services that can be negociated, it would be possible to implement the session in an X server with very minimal overhead, e.g. half a dozen instructions. I have some reservations on this approach, though. In my opinion, it is somewhat too ``minimalist'', and a real ``OSI X-Window'' should include a proper definition of the X protocol in the ASN-1 language; however, I realize that the time to develop + demonstrate such a tool could be a bit long, and that its advantages have to be weighted against achieving an ANSI (then ISO) standard in a short time frame. Christian Huitema
S.Kille@CS.UCL.AC.UK (Steve Kille) (06/19/89)
Basically agree with all this. It is clearly useful to map the X thru ASN.1. Use of ROS would be worth considering. Another reason for mapping onto ACSE is that it will give natural hooks for authentication and encryption services, which you would not get from a mapping onto transport. X is clearly in need of these services! Steve
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (06/20/89)
If X was designed without reference to the OSI model, including ASN.1, all the Application Layer Service Elements, Presentation, and Session, what is the use of trying to graft the model on after the fact? Is X being rewritten to comply with OSI or to interoperate with some other OSI services, like ASN.1? Why? It just sounds awfully peculiar to me. I thought the model was for designing new systems, not explaining old ones. Never occured to me that that was what the OSI model was for, universal explanation and interpretation. :-) Kent England, Boston University
mrose@cheetah.nyser.net (Marshall Rose) (06/20/89)
You OSI weenies really need a sanity check (-: There are two philosophies: 1. put X on top of transport, minimize changes, and optimize performance; or, 2. put X in the application layer, use ROS, et. al., and so on. I suggest that #1 is something that will work in short order, be relatively competitive with TCP-based X's and generally be a good thing. I think that #2, whilst interesting, is a research project. /mtr
S.Kille@CS.UCL.AC.UK (Steve Kille) (06/20/89)
Marshall, John asked about "the right way to map X onto OSI". I interpreted "right" in my answer as "correct in terms of OSI". I'll agree that there are research aspects to this. If you have an urgent need to run X over an OSI net, the mapping onto transport is a sensible short term fix. I do my work on TCP/IP and X.25(80) nets. With the possible exception of X.400, real OSI services are still a good way down the road. I see no reason to rush an X/OSI mapping. Steve
donp@APOLLO.COM (Don Preuss) (06/20/89)
> If you have an urgent need to run X over an OSI net, the mapping onto > transport is a sensible short term fix. I do my work on TCP/IP and X.25(80) > nets. With the possible exception of X.400, real OSI services are still a > good way down the road. I see no reason to rush an X/OSI mapping. > > Steve The reason this is coming now, and the reason for the urgency in making a decision is that there is currently a proposal on running X over OSI in X3H3.6. Since it is being considered in a standards body, this needs to be discussed. At the recent NIST OSI Workshop I held an ad hoc meeting of people interested in this problem. There was a large attendence from members of the VT sig, plus a few other people knowledgeable and/or interested in this. The primary reason I held the meeting was to get a sense of the workshop on where X should belong, and get some feedback on the DEC proposal. The feeling is that although X will run more quickly and efficiently directly on transport, and that there will be fewer duplication of services, it should really sit on top of the OSI stack, and use ACSE and presentation. This will allow future use of presentation security, CCR and management features of OSI, in addition to authentication and whatever else might creep up. The only place where a major (compared to transport) performance hit comes when running over S+P is on OPEN DISPLAY. Instead of just doing a CR, we are using ACSE. However, once the connection is established, we could use a generic-octect transfer syntax, and for a very small cost in perfomance, run over presentation. ] I have some reservations on this approach [running on S+P] , though. In my opinion, it is ] somewhat too ``minimalist'', and a real ``OSI X-Window'' should include ] a proper definition of the X protocol in the ASN-1 language; however, I ] realize that the time to develop + demonstrate such a tool could be a ] bit long, and that its advantages have to be weighted against achieving ] an ANSI (then ISO) standard in a short time frame. ] ] Christian Huitema I agree completely. donp Arpa: donp@apollo.com, apollo!donp@eddie.mit.edu UUCP: ...uunet!mit-eddie!apollo!donp -------
zweig@p.cs.uiuc.edu (06/24/89)
> Written Jun 9, 1989 by collin@hpindda.HP.COM in comp.protocols.iso > ---------- "Re: X-WINDOWS & OSI" ---------- > [stuff omitted] > I don't know of any good argument to increase the communications > overhead of X-windows by requiring S/P/(and at connection-time, ACSE). > If we don't try to call X an OSI application, then there's no need > that I know of to require that it run in its "proper" place in the > osi architecture. Since X (according to what I've gleaned of its innards from talking with X-hackers) already determines the sorts of things the presentation layer is concerned with (byte-order, etc.) and basically _contains_ a session-layer protocol, I don't think I understand the beef on this bone being picked. Certainly 2 or 3 seconds of ACSE muddling when I open an x-session (assuming a reasonably bad ACSE implementation) isn't going to be noticed, and once we're connected the Presentation and Session layers are null. There is a common misapprehension that "null" protocol layers involve calling functions and telling them not to do anything and that this can add substantially to the overhead of communication. Wrongo! I can give you a half-dozen tricks (one in particular) that can enable a module up in user space to talk directly to the transport mechanism, while still "thinking" it's talking to the presentation layer. Delegate the functionality and use pointers intelligently and null P/S means 0 runtime overhead. It's not a problem. The OSI layering is a _conceptual_ layering, not a software-architectural layering. There's no reason at all that an application can't DMA right to an ethernet board in an ISO/OSI compliant implementation, so long as the application is written so that it "thinks" it's interacting with the appropriate presentation-layer entities. More specifially, the person who wrote the application-layer entity thinks he's dealing with what he thinks the presentation layer is; maybe a compiler optimizes away the unnecessary baggage..... If you think 7-layers means 7 function calls, 7 buffer-copies, and a (Craig?) Partridge in a pear tree, somebody has told you some seriously incorrect things. -Johnny Zweig University of Illinois at Urbana-Champaign Department of Computer Science --------------------------------Disclaimer:------------------------------------ Rule 1: Don't believe everything you read. Rule 2: Don't believe anything you read. Rule 3: There is no Rule 3. -------------------------------------------------------------------------------
mrose@cheetah.nyser.net (Marshall Rose) (06/25/89)
** FLAME ON ** Thank you so much for pointing out the very obvious (null layers needn't introduce additional overhead), and the incorrect (you can use null layers in this situation). ** FLAME OFF ** If the question is: can we define a mapping from X onto ACSE and Presentation? The answer is yes. However, we now have to decide what this means exactly. OSI defines a presentation service and protocol. If you retain the service but use a different (e.g., null) protocol, you aren't OSI any more. Ditto for session. To be as-null-as-possible and still use OSI protocols, we can start by selecting the kernel facilities of the session layer. These can be implemented fairly efficiently with only a modest amount of additional burden. However, at each layer you still have to prepend a header (PCI for you OSI purists) when data goes down and strip off and interpret the header when the data comes up the on the other system. Since session deals with strings of octets, this can all be handled reasonably. At the presentation layer, things are more complicated since we must now introduce an abstract syntax for the data structuctes exchanged by the X-based applications. The X11 protocol defines these structures concretely. So, you can either define a simple octet string syntax and let the X application do the work, or you can redefine all the X structures in terms of ASN.1 and let presentation (conceptually) do the (de-)serialization. The first alternative, whilst legal, is probably contrary to the spirit of OSI. The second alternative, whilst philosophically correct, is going to be a performance pig. At the application layer, we note that the X protocol is really an RPC on a connection-oriented presentation service. So, to be true to the spirit of OSI, we should be re-cast the X operations in terms of the ROSE (just as we recast the X datastructures in terms of ASN.1). Of course, we needn't use ROSE if we just use the existing X framework. ACSE, per se, isn't such a big deal, though use of the Directory in order to map application entity names into presentation addresses, may introduce some additional delay during association establishment. In other words, at each layer above transport, you get two choices: wedge the tried-and-true X way into OSI, or do it the "right" OSI way. The former will lead to a system, which, while performant, probably plays overly fast and loose with the OSI framework. The latter will lead to a system with interesting research characteristics. I prefer a third approach, which is the direct mapping of X onto transport as an interim measure. When we have experience building large OSI applications and have a better understanding of what works and what doesn't, then a thorough osification of X would be in order. ** FLAME ON ** Next time, before preaching about how efficiently null layers can be realized in real systems, it would be worthwhile to consider how germane your proselytizing is for the converation at hand. ** FLAME OFF ** /mtr
karl@asylum.SF.CA.US (Karl Auerbach) (06/25/89)
In article <99600003@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes: > >Certainly 2 or 3 seconds of ACSE muddling when I open an x-session (assuming >a reasonably bad ACSE implementation) isn't going to be noticed, and once >we're connected the Presentation and Session layers are null. Real ASN.1 encoding and decoding is not a null function. Unless you make some serious restrictions, it can be a real CPU burner -- not just at the start end end of the session, but for every byte transferred. Are you suggesting going half way and doing ACSE but not a real ASN.1 revision of X? > Rule 1: Don't believe everything you read. I didn't. --karl--
jg@max.crl.dec.com (Jim Gettys) (06/27/89)
> Certainly 2 or 3 seconds of ACSE muddling when I open an x-session (assuming > a reasonably bad ACSE implementation) isn't going to be noticed, and once > we're connected the Presentation and Session layers are null. I don't see how you can justify such a statement under any circumstances. Are you seriously suggesting that applications should take additional SECONDS just to get a connection started?????!????!!!??? Not to mention applications which may want to have multiple connections open. 2-3 seconds delay sure would be noticed on my machine. Most of the X tools I use are up in under a second. Every time you start an application, it has to open a connection to the X server. This wants to happen fast; acceptable is only when it is less than human perception; so this sets an upper bound on a local net of 50 milliseconds or less. There are other things that need to be done besides connection setup; you only get a small fraction of the entire budget of time to play with. This is easy to do under TCP with current workstations. Adding several seconds to connection setup is crazy. - Jim Gettys
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (06/29/89)
I really dont understand why ACSE should cost 2 or 3 seconds. Opening the session + the association is done with a single message exchange, after transport set up. There is no reason that a transport set up would cost much more than a TCP set up, and there is no fundamental reason, apart from poor software enginnering, that a single message exchange should cost more over transport than it costs over TCP. Given that the current proposal proposes to *use* this single exchange for an useful purpose -- opening a window -- I dont think that the delay will much more important than that of running over TCP-IP. One can estimate the overhead by deriving it from the current size of the connection message using S+P+ACSE, approx 250 bytes; I dont see how processing 250 bytes of data would cost ``2 to 3 seconds'' -- I would rather expect milliseconds. Real delays derives from synchronisations, i.e. sending messages and waiting for responses, and they are protocol independant; the opening of a window will always introduce such a synchronisation. I can find only two explanations for the alleged long delays. One would be the responsive time from a name server embedded in the association package, but then one should compare it to the response time of the DNS. The other one would be the massive CPU overhead introduced by security procedures, e.g. computing a 150 digits RSA signature; but this is quite another game. Christian Huitema
rick@gateway.mitre.org (07/23/89)
Running X directly over Transport certainly makes sense from X's point of view, but I have my doubts about it being accepted as a "standard" way to offer X in an OSI environment. I understand there is a paper going around ANSI on how to map X to ACSE and Presentation primitives. The OSI upper layers may cost you some at startup time, but I don't think the overhead will be significant after that. On balance, I think this approach is better. There is also an OSI work item called "Terminal Management" that discusses a rather X-like capability. Anybody up to date on how it's going, and how its contributors see the relationship between X and Terminal Management? -Rick Wilder