Does socket represent an interface between ... ? - TCP-IP

This is a discussion on Does socket represent an interface between ... ? - TCP-IP ; "Anne & Lynn Wheeler" wrote in message news:m33b0vgtnt.fsf_-_@garlic.com... >> That was an April Fools joke, but I remember when it actually >> happened. IIRC, it was 1996. > > re: > http://www.garlic.com/~lynn/2007m.html#24 Does socket represent an > interface between ... ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 38 of 38

Thread: Does socket represent an interface between ... ?

  1. Re: OSI abandoned!

    "Anne & Lynn Wheeler" wrote in message
    news:m33b0vgtnt.fsf_-_@garlic.com...

    >> That was an April Fools joke, but I remember when it actually
    >> happened. IIRC, it was 1996.

    >
    > 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 ... ?
    >
    > i pulled the copy out of my email archive ... ... as i mentioned in
    > the
    > previous post, should be able to find it in one of the online usenet
    > archives. here is version ... posted Mar 31 1988, 7:00 pm
    > http://groups.google.com/group/comp....3b59f7f112234b
    >
    > so are you referring to a warmed version of the above nearly a decade
    > later? ... or when some specific party/organization ... taking nearly
    > another decade to actually accept it.


    These are April Fools jokes. Check the date. Either that, or I have no
    idea what that was all about.

    As recently as 5 January 1994, the OSI suite was still being called out
    in US MIL-STD documents. I have one such right here now.

    I was at a DoD meeting in 1996, I think it was, or perhaps it was 1995,
    when a rep from ISO had just arrived from an ISO meeting. He told us
    that the mood at the ISO meeting he just came from was very down, and
    figured it was about to stop the networking protocol effort. But this
    was years after 1988.

    Anyway, the original disagreement I had was concerning the
    internetworking layer. The OSI suite certainly did support such a layer,
    as do all the IP RFCs from way back when. There is NO functional
    disagreement between the old 4-layer concept in early RFCs and the OSI
    7-layer model. It's simply a case of the 7-layer model being more
    thorough.

    For example, Layer 1 of the old 4-layer model simply lumps together the
    physical layer and the data link layer of the 7-layer model. We all know
    that it makes more sense NOT to lump those two together. And in fact,
    the IEEE even divides Layer 1 and 2 into two sublayers each
    (respectively PMD and PHY, and MAC and LLC), because that's a clearer
    way of describing how their standards operate.

    I also disagreed that the ISO/OSI 7-layer model is somehow not
    applicable to IP. That's false. The model works perfectly well with IP.
    Here is a site that tells it like it is:

    http://www.tcpipguide.com/free/t_His...renceModel.htm

    Quoting from the bottom of the page:

    "Key Concept: The Open Systems Interconnection Reference Model (OSI
    Reference Model or OSI Model) was originally created as the basis for
    designing a universal set of protocols called the OSI Protocol Suite.
    This suite never achieved widespread success, but the model became a
    very useful tool for both education and development. The model defines a
    set of layers and a number of concepts for their use that make
    understanding networks easier."

    Bert


  2. Re: OSI abandoned!


    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.


  3. Re: Does socket represent an interface between ... ?

    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


  4. Re: Does socket represent an interface between ... ?

    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

  5. Re: Does socket represent an interface between ... ?

    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.

  6. Re: Does socket represent an interface between ... ?

    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


  7. Re: OSI abandoned!

    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


  8. Re: Does socket represent an interface between ... ?

    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

  9. Re: Does socket represent an interface between ... ?

    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

  10. Re: OSI abandoned!

    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).

  11. Re: OSI abandoned!

    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

  12. Re: OSI abandoned!

    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


  13. Re: Does socket represent an interface between ... ?

    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


  14. Re: Does socket represent an interface between ... ?

    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

  15. Re: OSI abandoned!

    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

  16. Re: Does socket represent an interface between ... ?

    "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


  17. Re: OSI abandoned!

    "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


  18. Re: Does socket represent an interface between ... ?

    "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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2