re:
http://www.garlic.com/~lynn/2007m.html#24 Does socket represent an interface between ... ?
http://www.garlic.com/~lynn/2007m.html#25 Does socket represent an interface between ... ?
http://www.garlic.com/~lynn/2007m.html#28 OSI abandoned!

note, something being wrong and/or incomplete doesn't preclude it from
being a great education tool ... in fact, compare&contrast can be
really useful as part of an educational activity.

and from random quotes department

Introduction to Routing
http://www.corecom.com/html/OSNconnexions.html

from above ...

.... Ten years ago, however, a similarly simplistic argument destroyed
the opportunity for OSI to standardize one of the best features of the
TCP/IP internetwork architecture-the combination of a connectionless
(datagram) internetwork protocol (which could be operated efficiently
over any underlying network technology, whether based on datagrams or
virtual circuits) with a connection-oriented end-to-end transport
protocol. The OSI position at that time was that a connection-oriented
service at the transport layer "naturally" mapped to a
connection-oriented service at the network layer, as if this were
something inherent in the very architecture of a layered model. The
OSI community wasted years dealing with this red herring, which was
intended to divert attention from the fact that a large segment of the
OSI community believed that the service provided by the network layer
was an end-to-end transport service. The TCP/IP community,
unencumbered by such nonsense, happily expanded to fill the resulting
vacuum.

.... snip ...

as per previous email reference about x3s3.3 nearly needing multiple
personalities to handle ISO ... i.e. (at least during the 80s), x3s3.3
couldn't work on protocols that violated OSI (like possibly involving
internetworking and/or LANs) ... but X3 (and other ISO chartered
standards bodies) could vote to approve such standards (that might
violate OSI i.e. various IEEE 80x standards being case in point)
http://www.garlic.com/~lynn/2007m.html#email890327

and, of course, IETF never had such a short-coming ... and as above
randomly selected quote also somewhat implies ... it would be possible
to craft an RFC on how to handle some OSI feature within an
internetworking environment. the difficulty of some of the ISO stuff
within the IETF framework ... for something to progress in the
standards process required multiple interoperable implementations
(something that wasn't required for something to become an ISO
standard).

as to having softcopy of various GOSIP (and various other) documents

misc. past posts with gosip references and/or partial extracts from
some of the documents from the period
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet

lots of past posts referencing OSI, X3S3.3 ISO standards work,
and/or efforts behind HSP (high-speed protocol) in X3S3.3
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

and pointers to RFC and IETF topics can be found in my RFC IETF index
http://www.garlic.com/~lynn/rfcietff.htm

for lots of topic drift about IETF coming to grips with another aspect
of progressing standards, hot off the press ... aka frequently RFC
standard progressing had been held up until the corresponding
normative reference(s) had also progressed.

4897 I
Handling Normative References to Standards-Track Documents,
Hartman S., Klensin J., 2007/06/13 (6pp) (.txt=13023) (BCP-97)
(Updates 3967) (Refs 3967) (was draft-klensin-norm-ref-04.txt)

above is example of RFC summary in my IETF index.
http://www.garlic.com/~lynn/rfcidx16.htm#4897

one of the things that I used to do for Postel (that would appear in the
old format STD1, "section 6.10") was cross-check current RFC standards
state consistency as reported (elsewhere) in STD1 ... and if there were
various kinds of inconsistencies, highlight/list them.

My RFC summaries include Refs and Ref'ed By (what other RFCs are
referenced as well as which RFCs reference them). I added this
relatively recently ... I had planning on doing it, but never quite got
around ... until I got email a couple yrs ago in real-time from the
crypto rump session on MD5 attacks ... wanting to know if I would
produce a list of all RFCs that referenced MD5 and/or MD5 RFCs ... which
is now carried as:
http://www.garlic.com/~lynn/rfcmd5.htm

but in the process of doing it, I expanded the Refs & Ref'ed by to all
RFC summaries. Now, the clicking on any of the RFC numbers, takes you to
the corresponding RFC summary (and clicking on the ".txt=" field in a
summary, fetches the actual RFC). In light of RFC4897, the issue is
whether I might color code the "Refs" and "Ref'ed by" RFC numbers ... as
to whether they are STD, Draft, Proposed, Informative, historic, as well
as normative. The last creates a logical consistency issue, since
"normative" is a charateristic from the referring RFC ... as opposed to
the referred to RFC.

On Jun 14, 4:21 am, don provan wrote:

> But let's not forget that it's a 7-layer model, not a four layer
> model. Do you know what happened to the top three layers?

I consider them bundled with the application program. For example, the
web browser software launches each session, not a separate module.

I don't know how these applications are written. I wouldn't be
surprised if much of the same "session layer" code were not common to
applications like MS IE and Office, for example. I know if I were
writing that code, I'd certainly do a lot of cutting and pasting. Same
goes for the presentation layer. How you decode integers, floating
point, ASCII, images, etc. is certainly something that you won't
reinvent for every application you write.

Looking down at the bottom, I think there's not so much doubt
concerning the difference between the physical layer and the data link
layer, right? The old RFCs used to lump those into a "communication
network" layer, for example, or "communication network service
interface," or "local network protocol." It depends which RFC you look
at. Surely, the 7-layer model is a more accurate portrayal of how
networks really work, in these bottom layers.

> In short, a lot of it really wasn't right, and even some that was
> logically reasonable is now, given what actual "network layer" and
> "transport layer" and "application layer" protocols have been
> implemented, inaccurate in practice.

I consider it to be more right than wrong. This is all mostly of minor
importance, as you say, but only as long as the people debating
understand the structure already. Kids just starting off should not,
IMO, be told that the 7-layer model is irrelevant.

The more basic problem is that NOT understanding the idea of a layered
protocol stack is really a big handicap. It's like any other subject
matter. You need to understand the basic structure to have a clue
what's going on. How do radios work? How do automobiles work? How do
cameras work? If you don't understand the building blocks, everything
is just one, big, mysterious black box.

Bert

Albert Manfredi writes:

> On Jun 14, 4:21 am, don provan wrote:
>
>> But let's not forget that it's a 7-layer model, not a four layer
>> model. Do you know what happened to the top three layers?
>
> I consider them bundled with the application program. For example, the
> web browser software launches each session, not a separate module.

Right, which is the point: they *are* bundled up, they are *not*
"layered".

> Looking down at the bottom, I think there's not so much doubt
> concerning the difference between the physical layer and the data link
> layer, right? The old RFCs used to lump those into a "communication
> network" layer, for example, or "communication network service
> interface," or "local network protocol." It depends which RFC you look
> at. Surely, the 7-layer model is a more accurate portrayal of how
> networks really work, in these bottom layers.

Well, no, actually. The outlook in the IP world is, as you say, that
there's an undefined packet carrying mechanism under IP. Whether it
has two layers or one or six is of no interest to IP, nor should it
be. By defining that layer as "two layers, the datalink protocol and
the hardware," you've ruled out tunnels and VPNs where and other
contraptions where the network layer, without know it, is actually
sending packets over another network layer. So the 7-layer model got
your through the simple topographies, but at the expense of making
more complex situation potentially harder for someone to understand.

> I consider it to be more right than wrong. This is all mostly of minor
> importance, as you say, but only as long as the people debating
> understand the structure already. Kids just starting off should not,
> IMO, be told that the 7-layer model is irrelevant.

Well, perhaps that's because you grew up with it. To me, it's still
just a marketing trick OSI supporters tried to pull to advertise OSI.
Yeah, those posters you get at trade shows and put up in your office
with the protocol headers on them can be useful, but they still leave
out the protocols that compete with ones the poster is trying to sell
you.

> The more basic problem is that NOT understanding the idea of a layered
> protocol stack is really a big handicap.

Yeah, I'll give you that. As I've said, it's not so much that it's bad
the 7-layer model is there, but a question of how much better of a
model would have taken its place if it hadn't been there.

-don

In article , don provan
wrote:

> Albert Manfredi writes:
>
> > On Jun 14, 4:21 am, don provan wrote:
> >
> >> But let's not forget that it's a 7-layer model, not a four layer
> >> model. Do you know what happened to the top three layers?
> >
> > I consider them bundled with the application program. For example, the
> > web browser software launches each session, not a separate module.
>
> Right, which is the point: they *are* bundled up, they are *not*
> "layered".

Even inside applications, there are usually identifiable layers. For
example, look at a typical terminal application for a PC. There is code
that deals with TCP connections, code that deals with telnet or ssh stuff,
and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
These map (more or less) to layers 5-7 (session, presentation, and
application).

In a well-designed application, you can swap components around at each
layer without affecting the other layers. The choice of whether to emulate
a VT-100 or an ADM-5 terminal can be made without regard for whether you're
running telnet, ssh, rlogin, or whatever.

On Jun 16, 8:57 am, Roy Smith wrote:
> don provan wrote:

> > Right, which is the point: they *are* bundled up, they are *not*
> > "layered".
>
> Even inside applications, there are usually identifiable layers. For
> example, look at a typical terminal application for a PC. There is code
> that deals with TCP connections, code that deals with telnet or ssh stuff,
> and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
> These map (more or less) to layers 5-7 (session, presentation, and
> application).
>
> In a well-designed application, you can swap components around at each
> layer without affecting the other layers. The choice of whether to emulate
> a VT-100 or an ADM-5 terminal can be made without regard for whether you're
> running telnet, ssh, rlogin, or whatever.

Exactly my point.

Also, the layered model is not supposed to represent *just* what
applies to the IP stack. It's supposed to represent the whole
networking subject matter.

Analogies are always questionable, but please indulge me. If you're
talking about cars, we all know there's something called the
"drivetrain." This functional block is what turns engine power into
vehicle motion. Two of it's most important subblocks are the
transmission and the differential.

Just because some cars use a combined unit, usually called
"transaxle," does not mean that a model where transmission and
differential are separated is "wrong." It simply makes it a model with
more granularity.

Bert

On Jun 15, 8:09 pm, Anne & Lynn Wheeler wrote:

> Introduction to Routinghttp://www.corecom.com/html/OSNconnexions.html
>
> from above ...
>
> ... Ten years ago, however, a similarly simplistic argument destroyed
> the opportunity for OSI to standardize one of the best features of the
> TCP/IP internetwork architecture-the combination of a connectionless
> (datagram) internetwork protocol (which could be operated efficiently
> over any underlying network technology, whether based on datagrams or
> virtual circuits) with a connection-oriented end-to-end transport
> protocol. The OSI position at that time was that a connection-oriented
> service at the transport layer "naturally" mapped to a
> connection-oriented service at the network layer, as if this were
> something inherent in the very architecture of a layered model. The
> OSI community wasted years dealing with this red herring,

This is an entirely different topic, which is interesting in its own
right, but which certainly diproves any notion that ISO protocols had
no internetworking layer.

I have two brief reactions to that quote. One is that as far as I
know, TP4 (ISO connection oriented layer 4 protocol) could run over
CLNP (ISO connectionless layer 3 protocol). The other is that running
connection oriented layer 4 over connection oriented layer 3 has a big
drawback but also provides an advantage.

The drawback is that the layer 3 boxes, routers, must maintain state
for each session. This does not scale well.

But, as bad as that is, it is the way you can truly "guarantee" QoS
parameters for that session. And it is the way IP over ATM was set up
in LANE or CLIP. People to this day claim that ATM was the only scheme
that supported "true QoS," but that's exactly the price it had to pay.
You had to set up an SVC for that IP session, and each ATM switch
along the path had to maintain state for that session.

The other disadvantage of connection oriented layer 3 is that it makes
multicast stream convergence difficult, in many-to-few multicast
trees.

> The TCP/IP community,
> unencumbered by such nonsense, happily expanded to fill the resulting
> vacuum.

That's only the parrochial view. The more complete perspective is that
the IP community has invented any number of schemes, from RSVP to
Diffserv to Intserv to MPLS to GMPLS, to try to come to grips with the
QoS vacuum in the IP world. Ultimately, what really works best so far
is to over-provision the network, if you expect to provide any sort of
QoS guarantees, e.g. as would be needed in IPTV networks. But that
works too, because prices for high bandwidth keep dropping.

But again, all of this is a diversion into an entirely new thread,
which has nothing to do either with protocol layers or with the
purported fact that ISO protocols were lacking some sort of
fundamental component that IP has, such as this internetworking layer.

Bert

In article <1182028511.966852.118440@n2g2000hse.googlegroups.c om>,
Albert Manfredi wrote:

>Also, the layered model is not supposed to represent *just* what
>applies to the IP stack. It's supposed to represent the whole
>networking subject matter.

No, the OSI 7-layer model is only a rough approximation properly used
as a teaching aid with the completely ignorant and naive or as a very
rough, known to be wrong shorthand among the knowledgablie. It is also
used by authors of trade rag inter-ad filler and others to demonstrate
their (bogus) expertise and bamboozle the completely ignorant and naive.


>Analogies are always questionable, but please indulge me. If you're
>talking about cars, we all know there's something called the
>"drivetrain." This functional block is what turns engine power into
>vehicle motion. Two of it's most important subblocks are the
>transmission and the differential.
>
>Just because some cars use a combined unit, usually called
>"transaxle," does not mean that a model where transmission and
>differential are separated is "wrong." It simply makes it a model with
>more granularity.

I like that analogy. Talk about a "drive train" is fine when you are
explaining cars to someone who knows nothing under the hood or as a
rough shorthand, even when talking about electric cars without good
equivalents to transmissions or differentials. On the other hand, it
is kooky to argue or even care about whether individual motors on wheels
are drive train sub-layers of limited slip differentials because there
are no ring gears and pinion or because they divide torque among the
wheels better than Positraction(tm).

As the saying goes, "Layering is a good tool but a bad master."


Vernon Schryver vjs@rhyolite.com

Albert Manfredi writes:

> On Jun 16, 8:57 am, Roy Smith wrote:
>> don provan wrote:
>
>> > Right, which is the point: they *are* bundled up, they are *not*
>> > "layered".
>>
>> Even inside applications, there are usually identifiable layers. For
>> example, look at a typical terminal application for a PC. There is code
>> that deals with TCP connections, code that deals with telnet or ssh stuff,
>> and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
>> These map (more or less) to layers 5-7 (session, presentation, and
>> application).
>>
>> In a well-designed application, you can swap components around at each
>> layer without affecting the other layers. The choice of whether to emulate
>> a VT-100 or an ADM-5 terminal can be made without regard for whether you're
>> running telnet, ssh, rlogin, or whatever.
>
> Exactly my point.
>
> Also, the layered model is not supposed to represent *just* what
> applies to the IP stack. It's supposed to represent the whole
> networking subject matter.

You guys are confusing modularity for layering. The reason those
techniques you speak of work is because The Application interacts with
all those pieces in a defined way so they can be swapped out. Layering
has the additional property that accessing a lower layer must be done
through any intervening layers even though the intervening layers have
absolutely nothing to do with -- and have no *reason* to have anything
to do with -- the lower layer that The Application needs to interact
with.

So, to give a concrete example, let's take the presentation "layer",
which formats data for network transmission. Since it's between the
application layer and the session, transport, and network layers, you
have to teach presentation layer all about opening and closing
connections, identifying peers, establishing network locations, for no
good reason other than that the OSI model says presentation is a
"layer". That's why, as I say, when the OSI protocol designers
actually got around to designing how application protocols worked,
they just discarded the OSI model as useless and implemented it as
functional blocks that could interact with each other as appropriate
rather than through a pointless and wasteful layering regime.

-don

Albert Manfredi wrote:
> But, as bad as that is, it is the way you can truly "guarantee" QoS
> parameters for that session.

You can never guarantee anything. Sure, you can dedicate a time slot,
frequency, or even a physical wire pair to an application, but there are
still big yellow things with words like Caterpillar and Komatsu painted on
their sides which will grind your QoS into the dirt.

I'm not saying QoS is a bad thing, just that there are no guarantees.

Even telcos, who wave the QoS banner with more enthusiasm than most anybody
else, apply statistical methods to tweak more usable channels out of scarce
resources like trans-oceanic cables (or at least they did, back before we
had managed to lay more fiber on the sea floor than we knew what to do
with).

Albert Manfredi writes:

> I have two brief reactions to that quote. One is that as far as I
> know, TP4 (ISO connection oriented layer 4 protocol) could run over
> CLNP (ISO connectionless layer 3 protocol).

Yes, they did have a TCP/IP equivalent. It was essentially the only
thing they did right, and it was pointless because there already was a
widely deployed TCP/IP equivalent: namely, TCP/IP.

> The other is that running
> connection oriented layer 4 over connection oriented layer 3 has a big
> drawback but also provides an advantage.

You're a little confused here. You had (essentially) two choices: the
afore mentioned connection oriented TP-4 over the connectionless CLNP
which used connectionless datalink layers, or you could run the NULL
transport layer (TP-0) over some stripped down network layer (CONS,
wasn't it?) that itself ran over a connection oriented datalink layer.

This did, indeed, supply the QoS qualities you mention, but at a
*huge* cost: both endpoints had to be connected to *the same* datalink
infrastructure. Oops! These days, none of us can get a network
connection out of our *buildings* without going over at least three
different datalink domains, and many of us have our phone calls taking
the same path! With the OSI connection oriented network layer model,
you'd have to start by finding out whether the server you wanted to
connect to was connected to MCI or AT&T, and then use the appropriate
one -- assuming you had it -- to contact them. It would have been
great for maintaining phone company monopolies, but not for much else.

As you say, the Internet world came up with solutions to the QoS
problem over connectionless networks, but this wasn't a case of
catch-up: such concepts weren't even a sparkle in the OSI model's
eyes for the connectionless internet that now spans our planet. OSI
could only imagine such features over phone connections (and didn't
even dream of phone connections over connectionless networks).

-don

On Jun 16, 6:36 pm, don provan wrote:

> > The other is that running
> > connection oriented layer 4 over connection oriented layer 3 has a big
> > drawback but also provides an advantage.
>
> You're a little confused here. You had (essentially) two choices: the
> afore mentioned connection oriented TP-4 over the connectionless CLNP
> which used connectionless datalink layers, or you could run the NULL
> transport layer (TP-0) over some stripped down network layer (CONS,
> wasn't it?) that itself ran over a connection oriented datalink layer.
>
> This did, indeed, supply the QoS qualities you mention, but at a
> *huge* cost: both endpoints had to be connected to *the same* datalink
> infrastructure.

I am using the concepts of a CO layer 3 and layer 4 *generically*, and
you are focusing only on the ISO suite.

In a general sense, there is no reason to assume that the link layers
MUST be identical throughout. The only essential thing is that the
link layers throughout have the same QoS knobs. Or that portions of
the transit are so over-provisioned that it doesn't matter in those
segments of the path.

My only argument there was to say that a connection oriented layer 3
is not completely without merit. But of course, its handicaps did
bring the idea down for the most part.

> As you say, the Internet world came up with solutions to the QoS
> problem over connectionless networks, but this wasn't a case of
> catch-up: such concepts weren't even a sparkle in the OSI model's
> eyes for the connectionless internet that now spans our planet.

It was a case of catch-up wrt ATM. These QoS "guarantees" (please not
to ignore the fact that I put the term in quotes, in both posts where
I used it) were certainly a major selling point of ATM, which also
created a connection oriented service in the inter-networking layer
(by being layered over SONET). ATM offered those "differentiated
services" because they were seen as something necessary. The IETF took
up the challenge because IETF members also saw some of those
"differentiated services" to be desirable.

Again, I am speaking generically of the 7-layer model and how it
applies to networks. The mistake people make, which is why this thread
has gotten so long, is to assume the 7-layer model should only apply
to ISO protocols.

Bert

On Jun 16, 6:14 pm, don provan wrote:

> The Application interacts with
> all those pieces in a defined way so they can be swapped out. Layering
> has the additional property that accessing a lower layer must be done
> through any intervening layers even though the intervening layers have
> absolutely nothing to do with -- and have no *reason* to have anything
> to do with -- the lower layer that The Application needs to interact
> with.
>
> So, to give a concrete example, let's take the presentation "layer",
> which formats data for network transmission. Since it's between the
> application layer and the session, transport, and network layers, you
> have to teach presentation layer all about opening and closing
> connections, identifying peers, establishing network locations, for no
> good reason other than that the OSI model says presentation is a
> "layer".

I don't get this. On the contrary, I would say that you teach that
encoding or decoding the way parameters are presented is done the same
way, no matter what data link layer you use, no matter what network
layer you use, etc. For an incoming MS Word file, the way you decode
the parameters coming to your MS Word application does not depend on
whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
Ditto in the opposite direction. And, of course, you can't read an
incoming Word file if you haven't gone through the presentation layer
before reaching the user.

BTW, in the drivetrain analogy, if the drivetrain is purely electric,
the functions of "transmission" and "differential" still apply,
although they are not performed with mechanical gears.

The electric motor(s) need to accommodate widely varying wheel speeds
efficiently, using means like coil shunting at high speeds, perhaps.
And you have to allow the inner and outer wheels to rotate at
different speeds in turns, so your motor controller cannot feed the
same voltage and current to each wheel (assuming separate motors in
each wheel).

So the conceptual model holds. I think the truth is that experienced
network designers understand the layered model intrinsically, without
letting it tie them up in knots trying to make it fit their specific
problem.

Bert

Albert Manfredi writes:

> I don't get this. On the contrary, I would say that you teach that
> encoding or decoding the way parameters are presented is done the same
> way, no matter what data link layer you use, no matter what network
> layer you use, etc.

Again, this is modularity, not layering. Look at it the other way:
suppose we discover something *new* to add to networking layer, an
entirely new function. If presentation is a module, it has nothing to
do with this, end of story. If presentation is a *layer* between
application layer and the lower layers, you have to teach presentation
layer about the entirely new function just so you can communicate the
necessary information from the application that wants to use the new
function to the networking layer that knows about the new function.

That's just an easy way to see the logical problem. In practice, there
are a wide range of negative effects of making presentation a "layer",
including the fact that you essentially have to teach presentation
layer your entire protocol so it knows which parts to encode in which
ways. Try to combine *two* protocols working together over the same
connection -- the kind of think OSI upper layers were built for -- and
you can see that things are really going to get complicated. If,
instead, you put presentation on the side as a function that can be
called to get the correct encodings for the correct parts of the
communications *before* the information leaves application layer,
things become much easier. This is, in fact, exactly what OSI upper
layer protocols ended up doing, but no one ever went back and
corrected the OSI model to remove the mistake.

> For an incoming MS Word file, the way you decode
> the parameters coming to your MS Word application does not depend on
> whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
> Ditto in the opposite direction. And, of course, you can't read an
> incoming Word file if you haven't gone through the presentation layer
> before reaching the user.

So how did presentation layer know it was a word file when that
information is passed in the application layer?

> So the conceptual model holds. I think the truth is that experienced
> network designers understand the layered model intrinsically, without
> letting it tie them up in knots trying to make it fit their specific
> problem.

Absolutely. Of course, they have to stop and argue about it with the
kids out of school that insist ARP is a network layer packet....

-don

Albert Manfredi writes:

> I am using the concepts of a CO layer 3 and layer 4 *generically*, and
> you are focusing only on the ISO suite.

Well, I'd say you are extending the OSI model by making up ideas that
you can fit into it without regard to whether those ideas were in the
OSI model.

> In a general sense, there is no reason to assume that the link layers
> MUST be identical throughout. The only essential thing is that the
> link layers throughout have the same QoS knobs. Or that portions of
> the transit are so over-provisioned that it doesn't matter in those
> segments of the path.

OK, it's been a long time, so perhaps I'm wrong, but as I recall, the
OSI model's network layer connection oriented variation *had no QoS*.
It depended on the datalink to provide it. This requires *a single
datalink* because the OSI model's network layer did not (generically
or any other way) provide for a way for all those QoS knobs to be
coordinated or, for that matter, to determine whether everything was
over provisioned.

> My only argument there was to say that a connection oriented layer 3
> is not completely without merit. But of course, its handicaps did
> bring the idea down for the most part.

Again, I agree there's nothing wrong with the idea of a connection
oriented layer 3, only that the OSI model's specific statements about
such a thing do not describe a particularly good way to go and, in
fact, are not the way the TCP/IP world went. TCP/IP does have a
"connection oriented layer 3", but it was done by using a single,
connectionless network layer protocol (allowing it to be carried
anywhere, regardless of the connection orientations of any datalink
layers) and added the QoS services as an additional mechanism that
could be added at will to routers along any path desiring QoS. The OSI
model doesn't even begin to have a way of describing that.

> It was a case of catch-up wrt ATM.

Nope. Again, the important difference is whether you're tied to a
particular datalink infrastructure. (Unless you consider ATM a network
layer, in which case we could go on for hours about why IP is better
before we'd even get to discussion quality of service.)

> The IETF took
> up the challenge because IETF members also saw some of those
> "differentiated services" to be desirable.

I sorry, you misunderstood me. My point was that as a practical and
useful implementation, IETF was way beyond any other game at the
internet level. I'd be a fool to suggest they didn't benefit greatly
from the earlier work in QoS at lower layers including ATM.

> Again, I am speaking generically of the 7-layer model and how it
> applies to networks. The mistake people make, which is why this thread
> has gotten so long, is to assume the 7-layer model should only apply
> to ISO protocols.

Actually, I'm speaking more about how the OSI model applies to
Internet protocols. I think you were the one that brought up the OSI
protocols as a positive example of the OSI model's connection oriented
network layer in practice.

-don provan

"don provan" wrote:

>> For an incoming MS Word file, the way you decode
>> the parameters coming to your MS Word application does not depend on
>> whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
>> Ditto in the opposite direction. And, of course, you can't read an
>> incoming Word file if you haven't gone through the presentation layer
>> before reaching the user.
>
> So how did presentation layer know it was a word file when that
> information is passed in the application layer?

Okay, now I understand what your objection is.

We agree, as things turned out, the session and presentation layers are
bundled with the application. So yes, the application has to be
identified before the file can go through the presentation layer (which
is now bundled in there with the application software).

In principle, it wouldn't have had to be this way. In principle, all
applications *could* have been written to a common presentation layer.
But of course, as you point out, that introduces its own disadvantages
when an application writer wants to innovate.

I see this as a minor inconvenience to the model, though. So we should
stick a shim just under layer 5 that says "app ID." The code to handle
session and presentation functions is still there, but it's potentially
different in different application software. But yes, IMO those layers
are still being traversed before you reach the GUI.

I see this as being a case of "when you're fluent in a language, you can
take certain liberties with its vacabulary and grammar."

> Try to combine *two* protocols working together over the same
> connection -- the kind of think OSI upper layers were built for -- and
> you can see that things are really going to get complicated.

Why wouldn't this work much like separate byte streams are identified
through separate, simultaneous TCP sessions now? A common presentation
layer would be able to keep streams open from multiple sessions at the
same time. In principle. Even today, you can keep multiple applications
open at the same time, even if they are the same application.

Bert

"don provan" wrote:

> Actually, I'm speaking more about how the OSI model applies to
> Internet protocols. I think you were the one that brought up the OSI
> protocols as a positive example of the OSI model's connection oriented
> network layer in practice.

There are many simultaneous threads with different contributors.

The ISO protocol discussion was with one person who said that ISO did
not include an internetworking layer. So I responded to that.

The connection-oriented layer 3 discussion started because a CO layer 3
was claimed to be nonsensical. So I responded that with all of its
drawbacks, it's still the only way to provide any sort of end-to-end
QoS. And that in fact, even the IETF has added elements of such a thing
to its bag of tricks. (Not true CO layer 3, but reservations, code
points, what have you.)

So, the use of a CO layer 3 for QoS was implemented by ATM that I know
of, if not in the ISO suite. Which is consistent with my position that
this 7-layer model applies generically.

And I also question whether ATM should be layer 3 or layer 2. The way it
was used in LANE and in RFC 2225 (CLIP), it was ignonimously demoted to
a layer 2 protocol. The way its future was mapped out in MPOA or in RFC
2332 (NHRP), it kind of went up to the network layer.

Bert

"Albert Manfredi" writes:

> In principle, it wouldn't have had to be this way. In principle, all
> applications *could* have been written to a common presentation layer.

That's another element of the OSI model's problem: the OSI model tells
us that all applications *have to be* written to one single common,
monolithic presentation layer. Seeing presentation in the proper role
as a functional block allows the choice of applications sharing a
presentation function or using independent presentation functions.

And this, in turn, starts to get at the *real* problem with the OSI
model, which is it presents a picture of the network just as OSI
envisioned it: as a single, monolithic solution. It discourages
considering exactly the flexibility that makes the internet what it
is. The very fact that the layers had to support fixed, predefined
interfaces makes true innovation nearly impossible.

> I see this as a minor inconvenience to the model, though.

You see it as a minor inconvenience. I see it as the model being
entirely wrong in a small way. The reason I think my view is more
reasonable is that the model cannot ever be fixed by adding anything
it doesn't already have, such as shims or an "app ID".

> I see this as being a case of "when you're fluent in a language, you
> can take certain liberties with its vacabulary and grammar."

The OSI model isn't really very useful for people that are fluent, so
this is something of a non sequitar.

>> Try to combine *two* protocols working together over the same
>> connection -- the kind of think OSI upper layers were built for -- and
>> you can see that things are really going to get complicated.
>
> Why wouldn't this work much like separate byte streams are identified
> through separate, simultaneous TCP sessions now?

Because the OSI model tells us to have a single connection. If you
have two connections, you've got two different applications, not two
application layer protocols interacting for the benefit of a single
application. (I'm being a little simplistic, mainly because I can't
really remember exactly what the OSI model says about it, but I stand
by the point that the model at least suggests the shared connection
approach, even while I admit not remember whether it actually allows
for multiple, cooperating connections between cooperating application
layer peers. I suppose I should pull out the model and read it again
if we're going to get into these details....)

-don provan