Hey! Keep Your Hands Out Of My Abstraction Layer! - TCP-IP

This is a discussion on Hey! Keep Your Hands Out Of My Abstraction Layer! - TCP-IP ; Jeff Liebermann wrote: >Welcome to capacity planning, queuing theory, and network simulation. A friend of mine tells me Homeland Security wants to be able to dial every phone in the US within 90 seconds. Boy do I feel safe! 8*|...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 108

Thread: Hey! Keep Your Hands Out Of My Abstraction Layer!

  1. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Jeff Liebermann wrote:
    >Welcome to capacity planning, queuing theory, and network simulation.


    A friend of mine tells me Homeland Security wants to be able to dial
    every phone in the US within 90 seconds. Boy do I feel safe! 8*|

  2. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!


    "Le Chaud Lapin" writes:
    > OSI, was more like a mood. I have never seen one line of OSI "code".
    > And trust me, I searched long and hard for it. When I read about OSI,
    > I get the feeling it was "designed" by people who actually knew what
    > they were talking about, but lost the ability to program computers
    > (read implement their vague vision) several decades earlier.


    late 80s ... OSI was all the range ... possibly half the booths
    at interop 88 had various osi implementations on dipslay.
    misc. past posts mentioning interop 88
    http://www.garlic.com/~lynn/subnetwork.html#interop88

    the fed. gov. (as well as some number of organizations) was mandating
    elimination of the internet and tcp/ip and moving everything to
    osi. some of this can be seen in GOSIP .. misc. recent postings
    mentioning gosip
    http://www.garlic.com/~lynn/2006f.html#26 Old PCs--environmental hazard
    http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006j.html#34 Arpa address

    minor ref:

    GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)

    The Federal Information Processing Standard (FIPS) describing the
    Federal government's policy, including the DoD transition from TCP/IP
    to ISO international protocols.

    .... snip ...

    there have been some claims that OSI was primarily worked on by telco
    oriented individuals reflecting the copper wire, point-to-point,
    homogeneous service, enterprise/institutional oriented networks of the
    60s and 70s.

    there was no concept of cross organizational and/or internetworking
    involving different and/or heterogeneous operations (aka instead some
    sort of telco or other operation was provide a homogeneous service to
    all its participants and/or subscribers). this is somewhat the 70s,
    pre-internetworking (1/1/83) ARPANET design. the whole concept
    of LANs and WANs also didn't exist.

    ISO compounded the problem with rules about not considering
    standardization of protocols that violated OSI. recent post
    in this thread
    http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  3. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    "William P.N. Smith" wrote in message
    news:3gjr62pf3s39gaj4abgjr662rtnsj3dmtr@4ax.com...
    > A friend of mine tells me Homeland Security wants to be able to dial
    > every phone in the US within 90 seconds. Boy do I feel safe! 8*|


    Are you sure he didn't just get back from seeing the movie "V for Vendetta?"
    In it the protagonist uses such a system put in place by the government
    (immediately becoming much to their chagrin) to broadcast his message...



  4. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!


    .... by the time ISO had passed OSI as a standard ... you had things
    like LANs and internetworking ... making OSI obsolete (or at least
    out-of-date). ISO then compounded the problem by dictating that only
    OSI conforming protocols, could be standardized.

    then in the late 80s, further compounding the problem, you have
    various govs. and institutions mandating elimination of tcp/ip and the
    internet ... replacing them with OSI.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  5. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    On Fri, 19 May 2006 09:55:27 -0400, William P. N. Smith wrote:
    > Jeff Liebermann wrote:
    >>Welcome to capacity planning, queuing theory, and network simulation.

    >
    > A friend of mine tells me Homeland Security wants to be able to dial
    > every phone in the US within 90 seconds. Boy do I feel safe! 8*|


    Do you mean, "every phone", or "any phone"? Hell, I can dial any phone in
    the world in a lot less than 90 seconds!

    (although, I do agree that spying on citizens is bad.)

    Cheers!
    Rich


  6. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Rich Grise wrote:
    >William P. N. Smith wrote:
    >> Jeff Liebermann wrote:
    >>>Welcome to capacity planning, queuing theory, and network simulation.

    >>
    >> A friend of mine tells me Homeland Security wants to be able to dial
    >> every phone in the US within 90 seconds. Boy do I feel safe! 8*|


    >Do you mean, "every phone", or "any phone"? Hell, I can dial any phone in
    >the world in a lot less than 90 seconds!


    They want to be able to send an announcement to every single phone in
    the US within 90 seconds. Apparently they have no idea how the phone
    sysem works. I can just see the cost estimate for making it happen.
    8*)

    >(although, I do agree that spying on citizens is bad.)


    Wha? This is Homeland Security, they are government who is here to
    help us! 8*?

  7. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    William P.N. Smith wrote:
    > They want to be able to send an announcement to every single phone in
    > the US within 90 seconds. Apparently they have no idea how the phone
    > sysem works. I can just see the cost estimate for making it happen.
    > 8*)
    >
    > >(although, I do agree that spying on citizens is bad.)

    >
    > Wha? This is Homeland Security, they are government who is here to
    > help us! 8*?


    What is interesting is that, if the phone systems were based entirely
    on network/packet/etc. type communication, this is actually feasible
    using multicasting.

    -Le Chaud Lapin-


  8. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!


    William P.N. Smith wrote:
    > Rich Grise wrote:
    > >William P. N. Smith wrote:
    > >> Jeff Liebermann wrote:
    > >>>Welcome to capacity planning, queuing theory, and network simulation.
    > >>
    > >> A friend of mine tells me Homeland Security wants to be able to dial
    > >> every phone in the US within 90 seconds. Boy do I feel safe! 8*|

    >
    > >Do you mean, "every phone", or "any phone"? Hell, I can dial any phone in
    > >the world in a lot less than 90 seconds!

    >
    > They want to be able to send an announcement to every single phone in
    > the US within 90 seconds. Apparently they have no idea how the phone
    > sysem works. I can just see the cost estimate for making it happen.
    > 8*)



    Without getting into the downsides to such a system, there are clearly
    some potential positive uses - having all the phone in a river valley
    ring with the announcement the "The dam has burst, run for higher
    ground now!" might well save some lives.

    But from a technical perspective, I think you overestimate the
    difficulty of something like this. The obvious way to do this is to do
    the "broadcast" from each telco local loop switch, given that this sort
    of warning is likely to be geographic in nature. The switch obviously
    knows all the attached phones (by definition), and these days these are
    pretty smart devices. Storing an uncompressed 60 second announcement
    would take half a megabyte of memory, and you'd need some upgraded
    software to implement the function. I would suspect that this would be
    just a software upgrade for the vast majority of local loop switches in
    the U.S. Obviously there are then some SS7 changes that have to happen
    further up the line, but those should be minimal.

    Pretty much the same approach would work with wireless, although the
    cells would have to sequence through the mobiles in the cell since they
    don't have enough capacity to handle voice traffic to all of them
    simultaneously.

    Then you need a geographic database of local loop switches, an SS7
    interface, and a PC with a microphone to send all the "broadcast"
    announcements you like.

    And I've deliberately avoided thinking about VOIP for this... ;-)


  9. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Agree with all your points.

    TCP is not optimized for transaction type requests, with all the wasted
    handshaking at the beginning and the end. The alternatives have not
    been much good, and the current workaround is to keep the TCP
    connection alive for multiple transactions, thus amortizing the initial
    and final handshaking over many transactions (HTTP GETs).

    However, this inefficiency has not led to an enhanced TCP with data in
    the initial SYN packet, nor for the reply packet to be the final packet
    for idempotent operations (GETs of static pages, if you don't get an
    answer just ask again).

    So keeping the connection alive was all that was needed, and TCP was
    not modified.

    As far as the SSL issues, they are independent of TCP.

    Wrolf


  10. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    "Wrolf" writes:
    > Agree with all your points.
    >
    > TCP is not optimized for transaction type requests, with all the wasted
    > handshaking at the beginning and the end. The alternatives have not
    > been much good, and the current workaround is to keep the TCP
    > connection alive for multiple transactions, thus amortizing the initial
    > and final handshaking over many transactions (HTTP GETs).
    >
    > However, this inefficiency has not led to an enhanced TCP with data in
    > the initial SYN packet, nor for the reply packet to be the final packet
    > for idempotent operations (GETs of static pages, if you don't get an
    > answer just ask again).
    >
    > So keeping the connection alive was all that was needed, and TCP was
    > not modified.
    >
    > As far as the SSL issues, they are independent of TCP.


    the aren't totally independent of transaction oriented philosophy.

    if you had transaction oriented transport for both HTTP & HTTPS, then
    you might have a transaction oriented HTTPS, if you had a purely
    transaction oriented HTTPS, then you would have much less overhead.

    in effect, the prevailing change to using HTTPS to encoupass the whole
    session ... to just the checkout/pay portion ... is sort of treating
    the checkout portion as a "large" transaction. However, that change
    violated fundamental corner-stone of the whole HTTPS protection and
    security scenario.

    The point of the HTTPS hand-shaking was to prove that the webserver
    the user was talking to was the webserver that the user was actually
    talking to. The security paradigm required that the user/client supply
    who they thot they were talking to ... and the webserver supply the
    proof that was who they were. posts about being called in to work with
    this small client/server startup (who had this technology called SSL)
    that wanted to do payment transactions
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    The change to the checkout/pay button resulted in the webserver
    supplying who they were claiming to be ... as well as supply the proof
    that they were who they were claiming to be. The fundamental
    step-by-step dependent security process was violated.

    so, there was VMTP (rfc 1045) that was transaction oriented and did
    reliable message in 5 packet exchange. and there was XTP that did
    reliable message in 3 packet exchange
    http://www.garlic.com/~lynn/subnetwork.html#xtphsp
    recent post in this thread
    http://www.garlic.com/~lynn/2006k.html#1 Hey! Keep Your Hands Out Of My Abstraction Layer!

    the fundamental cornerstone use of HTTPS in e-commerce is

    1) to make sure you actually are sending the account number to the
    entity that you think you are sending it to

    2) to prevent evesdropping the account number while the transaction is
    in-flight.

    So the way that HTTPS is commingly used for e-commerce invalidates
    #1. At it doesn't do anything to protect the account number before it
    is sent or after it arrives (data-at-rest as opposed to
    data-in-flight). in the past, there has been a lot of discussion that
    data breaches of transaction logs harvesting millions of account
    numbers has always been a much more attractive target than evesdropping
    the net
    http://www.garlic.com/~lynn/subpubkey.html#harvest

    the x9a10 financial standard working group was given the requirement
    to preserve the integrity of the financial infrastructure for all
    retail payments. part of the early work on the x9.59 financial
    standard was recognition that the account number was overloaded.
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subpubkey.html#x959

    on one hand, it was required to be available in a large number of
    different business processes. on the other hand, it was required to be
    kept totally confidential and never divulged in any way. these
    diametrically opposing goals met that you could bury the planet under
    miles of information hiding cryptography ... and still wouldn't be
    able to prevent account number leakage.

    so x9.59 financial standard defined a light weight payment transaction
    that was required to be authenticated (digital signature) and
    furthermore a business rule that account numbers used in x9.59
    transactions were not valid in non-authenticated transaction.

    with those two things, account numbers (by themselves) became useless
    to crooks. you could have enormous data breaches and evesdropping
    activity and the crooks still wouldn't have harvested sufficient
    information to perform a fraudulent transaction (the other way of
    viewing the account number vulnerability is that it is subject to
    simple replay attacks, the x9.59 standard definition eliminated the
    replay attack vulnerability). misc. past posts vulnerability,
    threat, exploits, and/or fraud
    http:/www.garlic.com/~lynn/subpubkey.html#fraud

    so from that standpoint ... you could have an x9.59 financial
    transaction riding XTP transaction transport ... w/o requiring the
    account number to be hidden.

    collected posts mentioning various ssl issues
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  11. [OT] Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    On Thu, 18 May 2006 23:41:20 +0000, John Navas wrote:

    > That's not entirely true. Turbo Pascal (Borland) was an early hit that
    > greatly contributed to the success of the IBM PC. But for the Microsoft
    > juggernaut it might well have continued to be an important factor.


    Borland killed itself. Their C and C++ compilers were good. Pascal evolved
    into Delphi, which at the time maybe was the best language around. But
    Borland made a few crucial mistakes.

    - They almost gave their products away, but then charged steep prices for
    support[1], at the time that Microsoft was improving their developers
    support.
    - Delphi, and later TurboC++[2] shipped with horrible GUI libraries. Good
    to develop a quick and dirty program, but you didn't want to try to
    develop something more complicated in it[3][4].
    - Later libraries were arguably better, but completely nonintuitive. While
    MS made sure some good books came to the market[5], Borland resources were
    pretty scarce.

    Then Borland changed to Inprise and that really killed of the company for
    good.

    M4

    [1] I once was asked to pay Fl 10.000 ($ 4500) for a fix for a known bug.
    Exit Borland at our site.
    [2] Or whatever the name du jour was at that time
    [3] F.i: at that time databases supported one blob per table. Having a
    coupled table per additional blob led to really horryfing code. You
    essentially had to reprogram the whole forms logic yourself.
    [4] Grids had drag-'n-drop functionality. Only it was f*cking unusable.
    You had to program everything yourself to get anything serious done.
    [5] Although programming Windows (every version) was litterally riddled
    with bugs[6], and other books weren't much better, you had something to
    get you started.
    [6] F.i. the whole chapter on memorymanagement in the 3.1 version was
    completely wrong, from start to finish.

    --
    Redundancy is a great way to introduce more single points of failure.


  12. Re: [OT] Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    And then again, all this are news from the distant past, you surely
    haven't had a serious look at what's happening nowadays...

  13. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Anne & Lynn Wheeler writes:
    > the fundamental cornerstone use of HTTPS in e-commerce is
    >
    > 1) to make sure you actually are sending the account number to the
    > entity that you think you are sending it to
    >
    > 2) to prevent evesdropping the account number while the transaction is
    > in-flight.


    so x9.59, in beside meeting the requirement to preserve the integrity
    of the financial infrastructure for all retail payments, we tried to
    eliminate the attack scenarios against account numbers and also have
    an extremely light-weight transaction that could be performed in a
    single round-trip.

    possibly the prevailing use of HTTPS in the world today is still
    hiding account numbers in e-commerce transactions. x9.59 eliminates
    having to hide account numbers as a countermeasure to various kinds of
    existing fraudulent transactions (minimizes even needing HTTPS or
    other information hiding technologies for e-commerce operations)

    this is a couple of earlier postings that look at various SSL
    and integrity issues
    http://www.garlic.com/~lynn/2006h.html#27 confidence in CA
    http://www.garlic.com/~lynn/2006h.html#28 confidence in CA

    and suggests a process where the HTTPS objectives for e-commerce
    (hiding and authentication) could be done in much the same manner that
    mapping x9.59 to XTP process could be done i.e. transaction oriented
    encrypting the contents of a XTP payload (or other extremely
    light-weight oriented operation).

    it also mentions some of the enormouse payload bloating approaches
    from the mid-90s.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  14. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Anne & Lynn Wheeler writes:
    > it also mentions some of the enormous payload bloating approaches
    > from the mid-90s.


    starting possibly mid-95, going forward for a time, appeared to be a
    period leaning towards extreme extravagance; enormously complex
    protocols (that few people understood) and humongous payload bloat (in
    some cases by one hundred times or more), were frequently viewed as
    being *better*.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  15. Re: [OT] Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    On Sat, 20 May 2006 17:53:58 +0200, Martijn Lievaart
    wrote:

    >On Thu, 18 May 2006 23:41:20 +0000, John Navas wrote:
    >
    >> That's not entirely true. Turbo Pascal (Borland) was an early hit that
    >> greatly contributed to the success of the IBM PC. But for the Microsoft
    >> juggernaut it might well have continued to be an important factor.

    >
    >Borland killed itself. Their C and C++ compilers were good. Pascal evolved
    >into Delphi, which at the time maybe was the best language around. But
    >Borland made a few crucial mistakes.
    >
    >- They almost gave their products away, but then charged steep prices for
    >support[1], at the time that Microsoft was improving their developers
    >support.
    >- Delphi, and later TurboC++[2] shipped with horrible GUI libraries. Good
    >to develop a quick and dirty program, but you didn't want to try to
    >develop something more complicated in it[3][4].
    >- Later libraries were arguably better, but completely nonintuitive. While
    >MS made sure some good books came to the market[5], Borland resources were
    >pretty scarce.
    >
    >Then Borland changed to Inprise and that really killed of the company for
    >good.
    >
    >M4


    Add to that there is little commercial use for borland these days. The
    only people who really want c and c++ are embedded programmers and
    game programmers.

    There was a recent MSDN article that described it perfectly:
    http://msdn.microsoft.com/msdnmag/is...t/default.aspx

    "When the C and C++ programming languages were invented, computers
    were slow, memory was limited, and compilers were simple and memory
    challenged, so a practical language could be little more than a veneer
    for assembly language"

    Note: I have become corporatised (is that a word) these days. The
    business managers from many companies have hammered it into me that
    its all about getting a working, fault free program to the market as
    quickly as possible. Its all about what the customer sees that counts.
    Neither Borland c++ nor MS vc++ offer that. Both were clumsy and prone
    to errors when writing large scale visual applications, and that is
    why clever business are not using either.


    >
    >[1] I once was asked to pay Fl 10.000 ($ 4500) for a fix for a known bug.
    >Exit Borland at our site.
    >[2] Or whatever the name du jour was at that time
    >[3] F.i: at that time databases supported one blob per table. Having a
    >coupled table per additional blob led to really horryfing code. You
    >essentially had to reprogram the whole forms logic yourself.


    I think thats where sybase became popular

    >[4] Grids had drag-'n-drop functionality. Only it was f*cking unusable.
    >You had to program everything yourself to get anything serious done.
    >[5] Although programming Windows (every version) was litterally riddled
    >with bugs[6], and other books weren't much better, you had something to
    >get you started.
    >[6] F.i. the whole chapter on memorymanagement in the 3.1 version was
    >completely wrong, from start to finish.


  16. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    John Navas wrote:

    >> Aha! These profiles are the things I saw. I know I'm preaching to the
    >> choir, but IMO, Bluetooth SIG did far too much. This is perfect
    >> example of overstepping (good) boundaries.
    >>
    >> At some point this will all work better when we learn to trust each
    >> layer (research group bound to that layer) to do what it does best, and
    >> nothing more.

    >
    > Not necessarily -- there are many real-world cases when stretching things
    > makes sense.


    Like Bluetooth - where the profiles mean that devices interoperate at
    the level consumers want, not only the MAC layer.


    Thomas

  17. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!


    Zak wrote:
    > John Navas wrote:
    > > Not necessarily -- there are many real-world cases when stretching things
    > > makes sense.


    Stretching things almost always make sense. Anytime we use a system,
    we have "streched" things. The point that I was making is that those
    who are not good at stretching should do their part and let others do
    theirs.

    > Like Bluetooth - where the profiles mean that devices interoperate at
    > the level consumers want, not only the MAC layer.


    That's true. I doubt thought any consumer would be able to signal a
    Bluetooth transceiver any faster than 100-150 baud.

    -Le Chaud Lapin-


  18. Re: [OT] Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    On Sat, 20 May 2006 18:08:41 +0200, OBones wrote:

    > And then again, all this are news from the distant past, you surely
    > haven't had a serious look at what's happening nowadays...


    Ah, no. Never came across Borland since then, I think that sums it up
    nicely.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  19. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Anne & Lynn Wheeler writes:
    > minor ref:
    >
    > GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE (GOSIP)
    >
    > The Federal Information Processing Standard (FIPS) describing the
    > Federal government's policy, including the DoD transition from TCP/IP
    > to ISO international protocols.


    re:
    http://www.garlic.com/~lynn/2006k.html#6 Hey! Keep Your Hands Out Of My Abstraction Layer!

    ... a little more excerpt mandating moving off internet to gosip

    U. S. Government Open Systems Interconnection Profile (GOSIP)
    VERSION 2.0
    October 1990

    1.1 BACKGROUND

    Both the government and the private sector recognize the need to
    develop a set of common data communication protocols based on the
    International Organization for Standardization's seven-layer Open
    Systems Interconnection (OSI) Basic Reference Model [ISO 1]. In the
    past, vendor-specific implementations of data communication protocols
    led to isolated domains of information, very difficult and expensive
    to bridge. Recent advances in communication technology based on the
    OSI model offer alternatives to vendor-specific network solutions.
    Most significantly, advances in open systems allow the interoperation
    of end systems of different manufacture, when required.

    This Government Open Systems Interconnection Profile (GOSIP) is based
    on agreements reached at the National Institute of Standards and
    Technology (NIST) Workshop for Implementors of Open Systems
    Interconnection. Each new version of GOSIP will reference the latest
    appropriate version of the Stable Implementation Agreements for Open
    Systems Interconnection Protocols [NIST 1], hereafter referred to as
    the Workshop Agreements. The Workshop Agreements record stable
    implementation agreements of OSI protocols among the organizations
    participating in the NIST Workshop for Implementors of OSI.

    A new version of the Workshop Agreements is created each year at the
    December OSI Implementors' Workshop meeting. It is the intent of the
    NIST Workshop that new versions of the Workshop Agreements will be
    backwardly compatible with previous versions. New editions of the
    same version of the Workshop Agreements are published at regular
    intervals during the year. These new editions contain errata and
    clarifications to the original agreements that are approved by the
    Workshop plenary. The latest editions are being distributed to all
    workshop attendees and are available through the National Technical
    Information Service (NTIS). See NIST Reference 1 for ordering
    information.

    GOSIP is also consistent with and complementary to industry's
    Manufacturing Automation Protocol (MAP) [MISC 1] and Technical and
    Office Protocols (TOP) [MISC 2] specifications. GOSIP addresses the
    need of the Federal Government to move immediately to multi-vendor
    interconnectivity without sacrificing essential functionality already
    implemented in critical networking systems. All capabilities
    described herein exist as standard products or are close enough to
    market that they can be proposed by vendors.

    .... snip ...

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  20. Re: Hey! Keep Your Hands Out Of My Abstraction Layer!

    Anne & Lynn Wheeler wrote:
    >
    > 1.1 BACKGROUND
    >
    > Both the government and the private sector recognize the need to
    > develop a set of common data communication protocols based on the
    > International Organization for Standardization's seven-layer Open
    > Systems Interconnection (OSI) Basic Reference Model [ISO 1].


    This is all fine and well, but as I stated before, I never saw an
    specification for OSI. It was more of a mood, if anything else. It
    was not something that an engineer could "implement". It still isn't.

    That hasn't stopped people from speaking of the OSI 7-layer model.
    What is happening is that people use the 7-layer model because they do
    not have anything better to look at.

    For example, layer 1 is the physical layer. People look at that and
    say, "Hey, that makes sense, I understand the notion of mechanic and
    basic signaling to be in one layer."

    Then they see layer 2 and say, "That makes sense too. I understand the
    notion of getting a blob of data from one interface to another."

    Then they see layer 3 and say, "Oh..this is fun. This makes sense too.
    I understand the notion of getting data from one node to another, no
    matter where the notes are located."

    Beyond this point, most researchers in computer networking are
    unwilling to admit that things get real fuzzy real fast. The problem
    is that the first 3 layers were easy, and all of a sudden, it's not so
    easy anymore. They secretly ask themselves, "Are there really 7 layers
    or maybe 5? Are there any layers at all? What if the appropriate way
    to think about this is not as layers, but as points of
    interconnection.."

    The uneasiness of suddendly being cast into the void where there was
    once a foundation is too much to bear, so they revert to the OSI model.

    But again, I have never, every, seen any OSI "code". I have seen
    particular engineers concoct system that embody somewhat the 7-layer
    model, but as far as I am concerned, there is not OSI protocol.

    -Le Chaud Lapin-


+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast