rfg@nsc.nsc.com (Ron Guilmette) (08/25/88)
I'm sitting here looking at a document that says that "The XYZ implementation
of TCP/IP comforms to the ISO/OSI reference model."
I'm not really a networking kinda guy so I don't know if that's a lie or not.
Is it?
I seem to recall having heard once that TCP/IP is NOT COMFORMANT with ISO/OSI.
--
Ron Guilmette
National SemiConductor
Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfghedrick@athos.rutgers.edu (Charles Hedrick) (08/25/88)
Saying that something conforms to the OSI reference model is essentially meaningless, so yes, TCP/IP does conform. The reference model is the basic conceptual layering. You can use those layers to analyze just about any protocol suite. What you're thinking of is the ISO protocol suite. That's a specific set of protocols, and TCP/IP doesn't follow it. As far as I can tell, vendor statements that their (non-ISO) protocol follows the OSI reference model is almost entirely hype. At best it means that the design is close enough to ISO that eventual migration to the ISO protocols will be easier than with a protocol suite that is very different in philosophy.
mckenzie@LABS-N.BBN.COM (Alex McKenzie) (08/26/88)
It is my personal understanding (as an active participant in some of the ISO groups) that the Reference Model was developed by ISO as a guide to how ISO should think about the functional decomposition of service/protocol standardization. This is something of concern to ISO internally; not something of external concern. Thus there is no Conformance Statement clause in the Reference Model standard, and (consequently) no objective way to evaluate the claim that something does or doesn't "conform to the reference model". Rather, the Reference Model was made an International Standard so the world outside ISO could see and understand (perhaps not agree with) the rules which were to govern the development of standards for particular services and protocols by ISO. Regards, Alex McKenzie
LYNCH@A.ISI.EDU (Dan Lynch) (08/26/88)
Ron, The OSI model is intended to be a reference model for discussing and describing computer to computer communications. It is an idealization of how that communications should take place. It was developed in the late 70's. It has a sevenlayer description that rather clearly describers what should happen on each computer and with their communications devices. TCP/IP when looked at from that model perspective has 4 or 5 layers distinctly differentiated. (Of ocurse, TCP/IP does all of the work, it just does it with a different number of layers -- if you like cake, who cares if it is 5 or 7 layers?) But, TCP/IP does not interoperate with the ISO implementations of OSI. Saying that would be very "confusing". I have seen IBM and DEC and Apple documents that all compare their proprietary protocols to the OSI model They all essentially say they conform to the OSI model. They do, as does TCP/IP. It just does not mean much. What matters is "can the two computers send meaningful traffic back and forth?" Dan -------
cpw%sneezy@LANL.GOV (C. Philip Wood) (08/26/88)
The question is: Does OSI conform to ARM? The answer is: No. Phil Wood, cpw@lanl.gov
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (08/26/88)
Dan: You were absolutely right when you stated, "...TCP/IP does not interoperate with the ISO implementations of OSI. Saying that would be very "confusing"." It is confusing! What *is* an ISO implementation of OSI. OSI is merely a architectural reference model. It is not a protocol nor is it a protocol suite. I have written networking software ten (10) years ago that is con- formant to the OSI model. I doubt that you can find any software suite that allows two (2) or more computer systems to exchange information that is not conformant to the OSI model. The model is a formalized statement of the logical process to establish a communication link and exchange information. Now if you had said that IP/TCP is not interoperable with the ISO IP/T4 protocols or the Internet protocol suite is not interoperable with the DECNet protocol suite. That would be less "confusing". Merton
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (08/27/88)
If there were a Supreme Court of Science (and if it hadn't been packed), I'd be delighted to accept a case which held that the protocol sub-suite consisting of TCP-or-UDP-over-IP is a more appropriate realization of stated "OSI" "Reference Model" principles than is the protocol sub-suite consisting of X.25-and-X.75, on a contingency fee basis. However, since as Charles Hedrick rightly observes, "TCP/IP" isn't in the set of International Standards Organization-sanctioned protocols, and since "conform to OSI" really ought to connote "interoperate with other protocols/ protocol interpeters in the ISO-sanctioned set", if there were a Supreme Court of Semantics, I daresay I'd only be willing to attempt to defend your XYZ Corp.'s blurb on a win-lose-or-draw flat fee basis-- and that a large enough one to be able to retire comfortably on. (And if I won, I'd be sure that that court was packed.) Or, if legal metaphors are not to your taste, a fair way of answering your question is, "Not in any practical sense, even though a sufficiently subtle protocol theologian could probably have a lot of fun with it." cheers, map P.S. In case the reference to the "ARM" in Phil Wood's message was not familiar, it stands for the ARPANET Reference Model, which preexists the ISO/OSI RM in fact, though not on paper (i.e., the ARM didn't get written up [or down] until some years after it had been "invented" ... and used). -------
CERF@A.ISI.EDU (08/29/88)
Just about anything that is layered can be claimed to be conformant. The TCP/IP protocols don't necessarily include all layers of OSI (e.g., there isn't a distinct session or presentation layer, for instance). I don't think there is much advantage in conformance to the reference model - the great advantages come from having a set of compatible and interoperable protocols supported by many vendors. This is certainly the case for the bulk of the TCP/IP implementations and will presumably be the case, some day, for many of the OSI implementations also. Vint Cerf
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (08/30/88)
In article <12425583151.27.PADLIPSKY@A.ISI.EDU> >PADLIPSKY@A.ISI.EDU (Michael Padlipsky) writes: >I'd be delighted to accept a case which held that the protocol sub-suite >consisting of TCP-or-UDP-over-IP is a more appropriate realization of >stated "OSI" "Reference Model" principles than is the protocol sub-suite >consisting of X.25-and-X.75 Seems to me this argument of "OSI implies X.25 and X.75" is a little obsolete. In the US, I don't expect to have to run OSI protocols over virtual circuit networks, but rather that future OSI-IP internetworks will be "equivalent" to the Internet, that is, a connectionless, datagram network. In fact, I am looking forward to running OSI applications, like directory service, on top of tcp/ip protocols. Of course, in Europe (except UK) the situation is different. Kent England, Boston University
karn@thumper.bellcore.com (Phil R. Karn) (08/31/88)
> Does OSI conform to ARM? > > No. And, of course, one might ask the question: "Do the 'OSI Protocols' conform to TCP/IP?" The answer again, sadly, is also no. But even if you limit the discussion to reference models, the "OSI Model" is hopelessly out of date. By the time you delete the unnecessary layers (e.g., Session), combine distinct layers that really shouldn't be separate (e.g., Application and Presentation), create the sublayers required by modern concepts like internetworking (the Internet and Subnet Layer) and multiple access networks (e.g., the Media Access Layer), about the only morsel you'd still have left from the original OSI model is that "Layering is often a useful tool in building networks". Then when you add Postel and Cohen's paper showing how a fixed number of layers is simply unworkable in the real world, what you finally end up with looks remarkably like the ARPANET Reference Model (ARM). But does ISO ever revise its preconceived ideas and admit its mistakes? Of course not. It just covers them over with even more paper and ad hype. "No Need for XYZ, Just TCP!" --Seen on a British billboard Phil
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/01/88)
Kent England: Just for the record, it seems to ME that there's no connection whatsoever between my observation that TCP/UDP-IP is philosophically closer to the "Reference Model" than X.25-X.75 and "this argument of 'OSI implies X.25 and X.75'" you mention. If anything, the observation is more reasonably misconstruable as a suggestion that OSI precludes X.25-X.75 than that it implies 'em, although it doesn't say that either. Of more interest, however, is whether you'll actually be able to satisfy your stated expectation that you won't "have to run OSI protocols over virtual circuit networks " "[i]n the US": As long as DDN and GOSIP mandate X.25, neither ARPA nor ISO IP users will be able to avoid paying (in one or more senses) for unasked-for subnet functionality, in the long haul, as it were. Are you, perhaps, counting on ISDN to save the day? (For that matter, does anybody out there know for sure whether ISDN, unlike X.25, WILL offer datagram service, and, unlike X.75, dynamic/"real" alternate routing?) If so, you'd be better advised to argue with the proprietors of DDN and the propounders of GOSIP about the non-OSIness of X.25, not with me, since the bold-face line in the middle of p.154 of _The Elements of Networking Style_ (Prentice-Hall, 1985) proves that I haven't lumped OSI and X.25 for several years--even if I'll never forgive the panacea pedlars who had tricked me into lumping them previously. cheers, map -------
mrose@TWG.COM (Marshall Rose) (09/01/88)
Phil, you make me sad. But now I will make you angry! Neither you nor I are unbiased observers. In as much as you have given your slanted view (i.e., no need for session, presentation should be application-specific, etc.), I might as well give my slanted views. The problem with you TCP/IP extremists is that you only have one tool, a hammer. It's a nice stainless steel hammer which gets the job done quite handily. But it is still a hammer. As such, every problem to you guys looks like a nail. (In fairness, OSI extremists are the same way). Although at the lower layers, OSI (levels 3&4) is still quite silly at times; at the upper layers, I think the TCP/IP community could learn quite a few things. Some of which you might even find useful. I won't bother launching into an assault on TCP/IP at this point, for two reasons: 1) you wouldn't appreciate it, and 2) I'm using it to get things done today. The problem is that you snipe at the parts you don't like, rather than trying to appreciate the entire picture. On the whole, OSI has a lot of good points going for it, even though some of the actual parts are pretty lousy. /mtr
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (09/02/88)
I would like to invoke Robert's Rules and move that this discussion be closed. The discussion has degenerated to the point that it is only fanning *flames* between proponents of T4/IP and TCP/IP and does not increase the understanding or appreciation of either the ISO OSI Reference Model or the TCP/IP protocol suite. The simple answer to the question is that TCP/IP does conform to the model. Those of us who purvey services, equipment, and systems to DoD are well aware that OSD (Office of the Secretary of Defence) has mandated the use of the ISO protocol suite for interoperability between the US and its allies. The only thing that seems to be worth discussing is interoperability between the ARPA and ISO protocol suites.
philipp@MOE.MCRCIM.MCGILL.EDU (Philip Prindeville) (09/03/88)
Mike (or anyone else), Care to set me straight on X.25 and its place in the ISORM? I have always found this a dilema. If you use the D-bit (end-to-end delivery confirmation), it becomes a transport protocol (or tries to be anyway). But in other respects, it is deficient as a transport protocol: for example, it provides no transport level addressing; sessions must use the network level addressing and "hints" in the call request user data field (sigh). As for its network (and data link) layer, it provides services that should be going on at the transport layer, such as acknowledgement and flow-control. So aesthetically, how does it "stack up"? Thanks, -Philip
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/03/88)
Marshall--
So impressed am I by your philosophical breakthrough that I can't
bring myself to wait to find Phil Karn's offending msg (which doesn't seem
to have shown up on the "bulletin board" through which I read TCP-IP yet)
before congratulating you on it. By dismissing any objections about what's
wrong and assuring the objectors that they don't understand what's right,
you've hit upon an extremely powerful concept:
The Whole Has Nothing To Do With The Sum Of Its Parts
Profound.
I now understand that if you gild the ricebowl heavily enough, it doesn't
matter at all that the top few coils of clay were intertwined rather than
slavishly stacked one on the other according to the pious precepts of
Pottery. TWHNTDWTSOIP, after all. And what a relief: No more worries
about the Session functionality that ought to be performed AFTER the
Presentation functionality on the way into the Host but BEFORE it on
the way out--in, say, multi-cast teleconference settings--for me. No
more nagging doubts over whether the Common Application Service Element
isn't just a way of evading the n-entities/n-1 entitites prescription
when certain Presentation functionality needs to be performed DURING
Application functionality rather than before or after (depending on
whether you're going into or out of the Host), nor over whether the
Association Control Service Element isn't just a euphemism for doing
Session functionality IN the Applications layer, either. Those weren't
Epicycles, they were just irrelevancies, and I'll never have to say
"It should be Layer [sic] 5-7" again.
Silly me, ever to have thought that what's obviously a hammer was a
Swiss Army knife, or that if you have to drive screws with a hammer it's
at least better than attempting to drive screws with a kinky Slinky.
Yup. I've seen the light. No more vain exercises in technoaesthetic
criticism or fruitless demands for philosophical consistency instead of
political compromise for me. Why, since you've assured me that The Whole
Has Nothing To Do With The Sum Of Its Parts, I've even come to realize
that as many as five of the seven apples in your little barrel can be
rotten and you can still have ... applesauce!
dazzled cheers, map
-------mrose@TWG.COM (Marshall Rose) (09/04/88)
Michael --
In some dusty file on me in Washington, D.C., there is a directive
which states:
DO NOT ALLOW THIS PERSON NEAR NUCLEAR WEAPONS.
It is in circumstances like this that I can appreciate why this is so.
Otherwise, I would certainly have atomized you by now!
From Karn's perspective (in a message which you admit you hadn't seen),
he asserted that you do not need a session layer and that the
presentation layer should be application-specific. This points
precisely to my hammer and nail analogy:
You TCP/IP purists are so convinced that you have the world's most
wonderful transport protocol (which is probably true, certainly it is true
in comparison to TP4) that you have spent relatively little time on the
things that go above TCP. Yes, you have applications, and yes they work
(fairly well, given their limited scope), but there is very little
unified thought behind them other than that age-old maximum, "Use TCP raw".
The OSI people are miles ahead of your ARMites in this regard. There is
where the "whole picture" I was referring to is, rather than what you
took out of context.
With regards to those little nagging questions you have. Now I must
congratulate you for having left your ARMrest in even considering such
issues. You are showing quite a bit of profound thinking. I happen to
disagree myself with the way some of the upper-layers of OSI is
arranged. Regardless, at least they have a framework, it does work
(at least I use it quite heavily and it works for me), and we can learn
from that.
I'd comment on the rest of your message, but I will wait until after
you've read Karn's original message. No point in attacking you unjustly...
/mtrbrennan@merk.UUCP (Rich Brennan) (09/04/88)
>map: Tastes Great! >mtr: Less Filling! >map: It's a floor wax! >mtr: It's a desert topping! >map: It's a candy mint! >mtr: It's a breath mint! etc. etc. etc. Into which "reference model" do you think this "discussion" fits? The Lite Beer RM: Rodney Dangerfield: I back the "ARM" because it doesn't get any respect. Bob Eucher: I favor the OSIRM because the government put it in the "front row". The World Wrestling Federation RM: Hulk Hogan: Oh yeah? Well I bet my 7 layer RM could just crush your RM. Andre the Giant: Think so?!?!? My RM will hit your RM so hard your whole protocol stack will die! The Three Stooges RM: Moe: "Spread out! Larry: Hey Moe, leave him alone! Moe: C'mere, porcupine, I'll tear your tonsils out! (just kidding, fellas :-) Rrrrrrich. -- ...!{uunet,linus!alliant}!merk!root Rich Brennan
nick@tarantula.spider.co.UK (Nick Felisiak) (09/04/88)
In <13887.589071350@twg.com>, : Marshall Rose <mrose@twg.com> responds to Phil Karn > > Phil, you make me sad. But now I will make you angry! > > Neither you nor I are unbiased observers. In as much as you have given > your slanted view (i.e., no need for session, presentation should be > application-specific, etc.), I might as well give my slanted views. [ Most deleted for brevity, etc] > The problem is that you snipe at the parts you don't like, rather than > trying to appreciate the entire picture. On the whole, OSI has a lot of > good points going for it, even though some of the actual parts are > pretty lousy. > > /mtr > The problem I (and I suspect, a lot of the TCP community) have, is that the ISO group have wantonly re-invented, or changed layers which work perfectly well - the change of the Ethernet type field being a classic example. There is a lot good about some of the higher level stuff - but there's a lot bad as well. TCP satisfies most of the requirements of an international standard - it works, and it's non-proprietary. It has a shortcoming in that its network layer does not fit in with the c 1920 style of communication understood and supported by most of the PTTs. ISO has made a lot of people a lot of bucks running seminars; it has yet to make anyone a worthwhile communication service. Meanwhile, the PR engine has managed to give it enough momentum that millions of Pounds/Dollars are being spent discarding working systems in favour of (as yet) unproven ideas. Sorry if this is a bit strong, but it is late on a Friday ... ah well. Usual disclaimers apply - I'm sure the company line is different. Nick Felisiak (nick@spider.co.uk) (nick%spider.co.uk@uunet.uu.net) Spider Systems Ltd Edinburgh Scotland
billn@kinetics.UUCP (Bill Northlich) (09/06/88)
In article <8809012053.AA08613@ETN-WLV.EATON.COM> mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes: >I would like to invoke Robert's Rules and move that this discussion be closed. >The discussion has degenerated to the point that it is only fanning *flames* I vote nay. Lots of stuff on the net (uucp, anyway) may be drivel, but a spirited exchange between map and mtr is worth a few extra hittings of the space bar to me. >... OSD (Office of the Secretary of Defence) has mandated the use of the ISO >protocol suite for interoperability between the US and its allies. They mandated use of Ada about 10 years ago... /billn
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/07/88)
Philip--
Many thanks for the great straight-line (which came at a particularly
good time, since I'm enjoying a temporary remission from the smoking-ban-
engendered chemical lobotomy at the moment, owing to the finally decent
weather where I am, which means I don't come back in from taking the
medication of choice for my condition more tired than when I went out,
for a delightful change).
How do _I_ think X.25 "stacks up" against the ISORM _aesthetically_, you
ask? I don't. I think it throws up.
Turning from the aesthetic to the technical, you do seem to me to be on
the right track in noting that the "D" bit is rather L4-ish, or at least
not very L3-ish. The other alphabits (M and Q, as I recall) are also
hard to swallow. Indeed, despite the ISORM's stated precept that protocols
must be peer to peer, the D bit seems to allow a given Host ("DTE") X.25
protocol interpreter to interact with the remote Comm Subnet Processor
("DCE") X.25 PI, the M and Q bits allow it to interact with the remote
Host/DTE X.25 PI, and most of everything else allows/requires it to interact
with the proximate CSNP/DCE's X.25 PI--always assuming I've remembered
aright which is DTE and which DCE. That situation, as I've observed in
passing elsewhere, sure looks like a POLY-PEER to me.
So there's no need to get into any lawyering over whether X._7_5 is or
isn't "Open", or to dredge up any of the other X.25-X.75 inelegancies,
to conclude that X.25 does not instantiate ISORM principles at all
scrupulously. The poly-peerage alone is evidence enough. (More
technoaesthetic points on the topic can be found in RFC 874, or even
in Chapter 9 of _The Elements of Networking Style_, where you not only
get the Cover Cartoon and Prefatory Afterthoughts that don't come with
the RFC, but you'll also get a useful suggestion as to how to visualize
a poly-peer that I really shouldn't mention in "public".)
Nor should the disparity be surprizing, viewed historically. To the
best of my knowledge, belief, and personal recollection, the claims that
X.25 "is" ISORM L3-1 were advanced eight or so years ago by the ISORMites
(i.e., those panacea pedlars whose "ricebowl" was going to be the ISORM--
not to be confused with the ISORMists, who, even if I find them to be
backing the wrong horse [or the wrong end of the horse, if you prefer], do
seem to be trying to work within the international standards bodies to do
networking rather than ricebowl-gilding). The idea was to support their
claim that the ISORM Suite was "nearly here" by pointing to the "already
here" L3-1. (They did, as a matter of fact, have me fooled for a year
or two.) The key fact is that the ISORM is the product of the International
Standards Organization, whereas the X.25 stuff comes from CCITT, an entirely
different body which consists of representatives of "the PTTs" (or Postal,
Telephone, and Telegraph state monopolies [in most parts of the world]).
More some other time. I must go raise my norepinephrine levels now.
Perhaps somebody else can take up the tale of how ISO and CCITT currently
stand in their attempts to reconcile the ISORM and X.25; all I "know"
about it is that some ISORMist friends told me a year or three ago that
it had been deemed politcially desirable to (appear to, at least) do so.
grateful cheers, map
-------PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/07/88)
Marshall--
"I would certainly have atomized you by now!" you say? How scholarly.
Even if Robert's Rules did apply here, I'd have a final point of personal
privilege coming, so I'll ignore Merton Campbell Crockett, smile most
aprreciatively at Rich Brennan, and go along with Bill Northlich. Indeed,
just to demonstrate that threats of nuclear retaliation don't intimidate
me, I must go one more round, even though I do believe that if you'd read
my last msg more carefully you'd have felt like the atomizee rather than
the atomizer. I, after all, wasn't the one who said "OSI (levels 3&4) is
still quite silly at times" and "some of the actual parts are pretty lousy"
while complaining about those who weren't "trying to appreciate the entire
picture"; I merely called you on it.
Phil Karn's msg--which I presume is what made you "sad", not Phil himself,
even making due allowances for your rhetorical practices (which do take me
back to the old days when I was teaching Freshman Comp. and the book called
them Propaganda Techniques)--turned out to be no surprize when I saw it.
My reading of it is that he deplores the hypocrisy of those ISORMites who
tout The RM in public while the protocol designers flout it in private, as
I deplore it too, of course. Why else would his climactic paragraph say
"But does ISO ever revise its preconceived ideas and admit its mistakes?
Of course not. It just covers them over with ever more paper and
ad[vertizing] hype[rbole]."?
(Note, by the way, that it's a PT to say I "admit" I hadn't read it when
I sent my last msg. Actually, I SAID I hadn't read it. Nor did I need to,
since I could deal perfectly well with your response on its own demerits,
given that what you'd said about there being problems with some of the
constituents but "TCP extremists" [another PT] didn't understand the
whole led directly to my apparently too effective restatement. [In case
you're wondering, yes, sarcasm is viewed unfavorably by some observers,
but I don't account it an out-and-out Propaganda Technique like, say, the
mud-slinging "extremists" bit. But, then, it's been a long time since I
studied such things and it would only use up too much of my norepinephrine
reserves if I worried about them any more.] And while I'm parenthesizing,
I should also mention that I have tried to be quite scrupulous about not
accusing you of using questionable linguistic ploys _consciously_; I
merely note that for whatever reason your msg to me was rife with them,
and, indeed, rather hope it wasn't being done consciously.)
I don't see Phil saying We've Got the Only Answer, even if he did
omit the implicit "joke" symbol after the billboard line, and I'm certain
I haven't, despite your infelicitous hammer metaphor. What _I'm_ saying
is that it's intellectually dishonest to claim that The RM Is The
Only Answer with one side of the mouth and ignore its stated precepts
with the other side of the mouth. Yet that's what the ISORMites are
doing. (I still cherish hopes that you yourself are an ISORMist, by
way, even if I've never gotten a [presumably jocular] death
threat from an ISORMist--or even an ISORMite, come to think of it--
before.)
Whatever useful stuff is being attempted at Layer [sic] 5-7 by the
ISORMists, it seems quite clear to me that it's being done despite,
not because of, the RM, with it's stated adherance to rigidly hierarchical,
5<->6<->7 layering/strait-jacketing. Nor, as best I can determine, are the
appeals to "CASE" and "ACSE" being made just because the particular, current
Session and Presentation Standards are tainted apples at best; rather, it
seems to be because you _do_ need certain Session and Presentation
functionality "right now" in certain Application settings. (With my
usual luck, the one _Connexions_ I can't find is the one the Index tells
me has your piece on "Applications in an OSI Framework" in it, so I can't
offer you your own words, but I do recall thinking that it was still more
evidence for my years-old "Layer [sic] 5-7" complaint when I read it.)
There is, I submit, a legitimate technical interest in whether there are
_correctable_ flaws inherent in The RM, no matter who has or hasn't
embraced The RM as a matter of organizational/governmental policy.
Do you suppose we can discuss without propaganda the question of whether
or not the L5-6-7 separation _ought_ to be viewed as mandatory, both
ways (i.e., both into the Host from the net and on up, and out of the
Host from the user/Application PI and on down), in which I for one
have a long-abiding technical interest, and leave emotionalism for
some other time? Or is my asking that just opening the door for a
non-nuclear threat like (shudder) immersion in the sauce of rotten apples?
(Jocularly intended sarcasm aside, I'm really not convinced it's worth
the norepinephrine depletion to me if we can't raise the level of debate
a few notches. Wanna try a round or two with above-the-belt blows only,
if only for the sake of novelty? Or shall we let it go--each, I daresay,
quite convinced that he has "won"?)
nonetheless, cheers, map
-------mrose@TWG.COM (Marshall Rose) (09/08/88)
Mike -- I am willing to give up my humorous metaphors and remarks regarding nuking you, if you are willing to talk in plain simple english in each and every message you send in the future. Frankly, I get a headache trying to read your messages! Needless to say, this does not make me particularly receptive to your arguments, which may, for all I know, might be quite reasonable and sane. Unfortunately on the average I refer to a dictionary 3 times in the course of an hour when reading just ONE of your messages. The problem, as far as I can tell, is that you arguing against opponents who do not read this list. As surprising as it may seem, I am a moderate, and am viewed as somewhat heretical by the OSI community by even suggesting that the lessons learned in the Internet might be applicable. My favorite line which came up in a conversation back in April at an OSI tutorial: "The Internet was an interesting experiment, but X.25 is the only real networking solution". Yes, I thought it was funny too. Even more funny considering the person who gave the tutorial deeply believed this. I was tempted to refer everyone to your book, particularly later on when the speaker said one didn't need something like TCP over a LAN, but alas, I could not remember the full title of your tome (too many big words, you know), so I did not speak up. Now, at this point I guess I should respond, point by point to your message. But frankly, who cares? I don't understand half the arguments you make, due to your use of excessively obscure english. I guess I can not just see your "larger picture". This isn't a personal attack, but I hope you take it personally(!) and clean-up your writing style so more of us can understand what you are trying to say. With regards to who's atomized who: I have received (privately) one message congratulating me on stomping you with my last message. Although this is not conclusive proof, it is good for my ego. Your turn (and please try to avoid using words which aren't found in my Webster's abridged dictionary, thanks). /mtr
LYNCH@A.ISI.EDU (Dan Lynch) (09/09/88)
Hey, Michael and Marshall, I'd love to see you two duke it out (Or violently agree) on the Layer 5-7 "in ain't the same as out" issue that surfaced in the recent messages. I'll even put up with some of Michael's verbal meanderings out of eleemosynary feelings. Dan -------
backman@interlan.UUCP (Larry Backman) (09/09/88)
[] Does anyone remember the original Saturday night live shows? The ones where Jane Curtin and Chevy Chase did their version of point-counterpoint? "Chevy, you arrogant male *#***" "Jane, you ignorant slut" The current religious wars bring that to mind! ` Larry Backman Interlan, Inc.
IGJM400@INDYCMS.BITNET (Gary McCabe) (09/09/88)
ISORMite, ISORMist, TCP/ist, ....Hmmmmm
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (09/09/88)
In article <12429004411.28.LYNCH@A.ISI.EDU> LYNCH@A.ISI.EDU (Dan Lynch) writes: >Hey, Michael and Marshall, I'd love to see you two duke it out (Or violently >agree) on the Layer 5-7 "in ain't the same as out" issue that surfaced in >the recent messages. > >Dan >------- I agree with Dan. If map and mtr could turn this discussion around and try to find some common ground and consensus between their two opposing viewpoints, I wonder if they wouldn't have the start of a new model that might take this discourse up to another plateau? The only thing good about the ISORM, or the TCP/IP model, is that it gives us a map (no pun :-) and a glossary for conversing about protocols. Neither model seems entirely adequate. Network management, for example, seems to have broken both models. [no flames, please]. Thankfully, that doesn't stop the implementors or protocol-builders. I think the considerable expertise of Padlipsky, Rose, Karn, et al could make some progress along these lines and transform this discussion from a memorable summer diversion into the beginning of something new. How about it? We need some common ground. [Let's see; where did I put my Kevlar flak jacket and fire extinguisher?]
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/09/88)
Marshall-- Gee, since you put it that way I guess I shouldn't even "invoke cloture"; how about I'll just call a halt? 'bye, map P.S. If enough onlookers send private msgs requesting it I'll type in what my wrap-up msg would have been and send it back to them, also in private. -------
mrose@TWG.COM (Marshall Rose) (09/10/88)
Fine. It's over for now. By the way, the total is now 6 messages congratulating me and only 1 with a slightly negative bent. Again, while not conclusive, it is good for me ego! /mtr ps: I liked your last message, no big words!
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (09/10/88)
Michael: I didn't hear (read) a second to the motion nor a call for a vote on the motion. I might suffer withdrawal symptoms from contrived erudition and misspelled words should you terminate your exchange of missives at this instance. On the basis of the dispatches promulgated by yourself and Marshall, one can only hope that English (American or British) is a second language and that you can express yourselves more elegantly in Ada, ALGOL, BASIC, BLISS (-16 or -32), C, COBOL, FORTRAN, LISP, JOVIAL, SNOBOL, WATFOR, WATFIV, etc.. I probably should include TECO and any number of assemblers in the preceding list. Merton
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (09/10/88)
Kent: I agree that the ISO OSI model has to be re-examined; however, I doubt that it has any particular relevance to the discussion of a protocol or any suite of protocols. While it is useful to clearly state the logical procedures that must be performed to establish a link to reliably transfer data between two (2) points on a network, it is somewhat absurd to codify these logical procedures as the ISO has done and then attempt to define a suite of protocols to implement these logical procedures. I am not stating that there is no need to have a protocol "stack"; however, I don't understand the apparent, wide-spread belief that each protocol in the "stack" must be implemented as isolated procedures or separate processes. From practical experience in implementing message handling and distribution systems and communication networks, the logical procedures defined in the OSI model are, by necessity, repeated in each layer of the protocol "stack" in order to ensure a reliable communication link. Do you have an extra Kelvar jacket and fire extinguisher? Merton
jon@CS.UCL.AC.UK (Jon Crowcroft) (09/10/88)
Dan, hear hear here - lets here a technical discussion - we are computer *scientists* are'nt we... i dont understand why both iso7498 fans and rfc79? fans are so partisan, rather than regarding both worlds as partial solutions to be implemented/converged to by vendors, whatever, and getting on with how we could both do better next time (being a scientist by training, i dont believe in 'getting it right' - see Karl Popper, Objective Knowledge, pp1 to about 800). Just how is TP4 'broken' (apart from unreliable close, and packet mode rather than byte stream, and a reference number rather than ports). So whats wrong with CLNP, cept maybe it mandates a few things that weren't mandated in IP/ICMP. So whats so good about everyone and their brother building wrong transaction protocols over UDP because they claim TCP costs too much, doesnt do transactions etc etc etc You guys in the US shouldnt have to worry over the X.25 alternative, but in Europe, we gonna have hi-speed ISDN to map 7498 into - now theres a problem to think about, do we want TP4/CLNP over a reliable 640 Mbps bit pipe to carry video and bronze-medallion reference models, or X25 pkt and LLC levels, or might we want to listen to what the Dave Clarks and Cheritons of the world are messing with... i guess marshall is right that ISO represents the Big picture, but its a Cecil B. de Mille picture that lasts about 20 years, except for being remembered by a few old dears at xmas - where's the Citezen Kane of protocol architectures (ow, mixed metaphors arent part of physics training) sorry to rant on, i hate working on saturdays jon
cperry@BERT.MITRE.ORG (Chris Perry) (09/11/88)
Jon, If I get your drift right, you're saying that X.25/LLC (and similar CO networks) aren't sufficient for the B-ISDN of the future, yes? What I surmise, particularly from Dave Cheriton's Blazenet writings and from AT&T/Bellcore's current work on high-speed switching fabrics, is that we must begin to look at protocol architectures that exploit the coming broadband media. Not just live with multi-megabit networks, but push them for all they are capable of. I guess I'm not sure X.25 is capable of that, nor is a 128-octet LAP. How we engineer upper-layer protocols for extraordinarily reliable, high-volume, low-latency traffic makes for interesting and important research, seems to me. Next question is, who's going to pay the bill for building these behemoths? (Sorry folks, that's a big word for a big animal.) And who's going to set an agenda for exploring what we can do with them? Regards, Chris
bzs@BU-CS.BU.EDU (Barry Shein) (09/11/88)
> 'bye, map > >P.S. If enough onlookers send private msgs requesting it I'll type in >what my wrap-up msg would have been and send it back to them, also >in private. Nah, send it in public, I can't stand the suspense. -Barry Shein, ||Encore||
smb@ulysses.homer.nj.att.com (Steven Bellovin[jsw]) (09/11/88)
The primary difference between TCP/IP and ISO/OSI is that ISO/OSI was designed by a much larger committee. --Steve Bellovin
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (09/13/88)
Kent:
I must admit I don't really understand what you mean by the phrase "articulated
TCP/IP model" and what value it might have were I to understand it. That does
not imply that I understand the ISO "Open System Interconnect (OSI) model" nor
the "Digital Communication Architecture (DCA) model" fully. Although I may
have used concepts outlined in each of these models when developing network
software, my approach is governed by my education received from the "Department
of Intuitive Logic, School of Hard Knocks, University of Experience". Formally,
I have a degree in the weird (social) science of Economics which is concerned
about the utilization of limited resources which definitely influences my view
of the hows and wherefors of networking.
The two (2) figures, below, might be regarded as my models of networking. The
one on the left the theoretical model. The one on the right the practical.
+--------------------+---+ +------------------------+---+
| Application | M | | Application | M |
+-------------+----+-+ a | | +-------------+----+-+ a |
| Generic Transport | n | | | Generic Transport | n |
+--------------------+ a | | +--------------------+ a |
| Network | g | | | Network | g |
+--------------------+ e | | +--------------------+ e |
| Specific Transport | m | | | Specific Transport | m |
+--------------------+ e | +------------------------+ e |
| Data Link | n | | Data Link | n |
+--------------------+ t | +------------------------+ t |
| Physical Link | | | Physical Link | |
+--------------------+---+ +------------------------+---+
What I understand to be the "session layer" is only an aspect of management
which has access to all "layers". Without management being vertical, what
happens and what stops the no longer necessary activity when the application,
process, or pseudo-process unceremoniously aborts or "core dumps"?
The figure on the left is for the modular architecture and "black box" crowd
that assume memory is cheap and will be cheaper in the future *and* that
time is no consideration because you can always buy a faster engine. The
figure on the right is for the practical chaps who realize that money does
have a cost and one *does* get stuck with less than optimal equipment for
both the near and far terms.
The "generic transport layer" may or may not exist; however, it is depicted
here to provide a mapping between the local machines representation and that
which is understood by the "network layer". Also, the "specific transport
layer" may or may not exist; however, it is depicted here to provide a map-
ping between the "network layer" representation and the data representation
that is required to receive or transmit data over a specific communication
link.
In this model the "network layer" is assumed to have a choice of paths and
networks which can be used to communicate with the distant end; hence, the
need for a "specific transport layer". It is also assumed that the "network
layer" can perform a store and foreward operation between networks without
involving an application process.
In the right hand figure, the vertical added to the "application layer" allows
one to define an "end node" which is technically compliant to the model with-
out having all of the layers. It also requires well defined interfaces at
each layer because it implies that the "application layer" can enter the
"protocol stack" at any layer.
It doesn't seem to make much sense to allow the "application layer" to go
down to the "physical link layer"; however, I'm sure that someone can provide
a reason why it would be desirable.
If nothing else, the above figure along with the other models might provide
a way to get to a more robust and practical communications model.
Mertonlear@NET.BIO.NET (Eliot Lear) (09/14/88)
For those who don't have access to webster...
net> webster eleemosynary
" * _
el.ee.mos.y.nary \.el-i-'mas- n-.er-e\ adj [ML eleemosynarius, fr. LL
eleemosyna alms] : of, relating to, or supported by charity
--
Eliot Lear
[lear@net.bio.net]yba@arrow.bellcore.com (Mark Levine) (09/17/88)
In article <8809101902.AA03190@bert.mitre.org> cperry@BERT.MITRE.ORG (Chris Perry) writes: >What I surmise, particularly from Dave Cheriton's Blazenet writings >and from AT&T/Bellcore's current work on high-speed switching fabrics, >is that we must begin to look at protocol architectures that exploit >the coming broadband media. >And who's going to set an agenda for exploring what we can do with >them? Seems to me you have stated the answer above the question. The group I work with, the Integrated Media Architecture Laboratory at Bellcore, is decidedly in the business of exploring what we can do with BISDN and fast networked media, not to mention how to construct the network. There seems to be quite a bit of interest from people in the telecommunications business now. By the by, ATT and Bellcore are VERY different organizations, and they aren't really allowed joint cooperative work as I understand a certain modification of consent decree (but I am not an official company spokesman, either!). I know you did not make it explicit, but they have a "thing" about lumping ATT and Bellcore work together like that. We need to look at hardware architectures for the things connected to those networks at least as hard as the protocols employed. I suspect all the manufacturers of that hardware (CPE) will be as interested in doing their own research as the carriers of the information between that hardware. Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com