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 ; I'm reading the specification for 802.11, and I cannot help but wonder why so many network standards seem to enjoy transgressing the boundaries of their abstraction layers. For instance, 802.11 keeps hinting that they are helping to solve the mobility ...

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 20 of 108

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

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

    I'm reading the specification for 802.11, and I cannot help but wonder
    why so many network standards seem to enjoy transgressing the
    boundaries of their abstraction layers. For instance, 802.11 keeps
    hinting that they are helping to solve the mobility problem, but also
    keeps issuing disclaimers throughout the document saying essentially,
    "We don't specifiy how its actually done."

    I wonder...is there a more appropriate to look at the networking stack?
    Do the wireless options that we have available now do too much in ways
    that are inappropriate or misleading? For example, 802.11 has an ESS
    feature that implies that its wireless LANs can grow arbitrarily large.
    Has anyone use this in this way? Has anyone tried to implement
    mobility over a massive interconnection of 802.11 LANs?

    Then there is Bluetooth, whose specification I have not read, but had a
    glimpse of it a few years ago. It gave me the impression that someone
    showed little restraint in feature provision. I was so impressed that
    I waited for it to port my luggage off the aircraft.

    Zigbee? I got the same impression. Not horrifically complicated, but
    not exactly bare-metal.

    Perhaps that's the problem. Perhaps we should not be putting so many
    "services" in the hardware.

    How about a wireless transceiver that does as well as it can at layers
    1 & 2, then ***STOPS***. No security (beyond link-access-control).
    Power-management facilities available but minimally specified.
    Link-layer addresses *only*. No "services". No mention of printers,
    PDA's, kiosks, users, clouds, networks. No notion of a world-wide
    network. The ideal link-layer device would get data from interface A
    to interface B and get out of the way.

    I think if each layer were approached with this mindset, we'd actually
    do better than we have done so far.

    -Le Chaud Lapin-


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

    unoriginal_username@yahoo.com writes:
    >I'm reading the specification for 802.11, and I cannot help but wonder
    >why so many network standards seem to enjoy transgressing the
    >boundaries of their abstraction layers.

    ....
    >Perhaps that's the problem. Perhaps we should not be putting so many
    >"services" in the hardware.

    ....
    >I think if each layer were approached with this mindset, we'd actually
    >do better than we have done so far.


    Try being a member of a standards committee sometime.
    Or perhaps it is better to never be a member of one of those.
    It can be a very frustrating time.

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

    unoriginal_username@yahoo.com hath wroth:

    Oh cool. 5 newsgroups and a genuine troll posting. I'll bite.

    >I'm reading the specification for 802.11, and I cannot help but wonder
    >why so many network standards seem to enjoy transgressing the
    >boundaries of their abstraction layers.


    Because laws are made to be broken and specifications are made to be
    stretched. More realistically because the original authors of 802.11
    didn't anticipate the multitude of wireless uses and abuses which we
    enjoy today.

    >For instance, 802.11 keeps
    >hinting that they are helping to solve the mobility problem, but also
    >keeps issuing disclaimers throughout the document saying essentially,
    >"We don't specifiy how its actually done."


    Do you really want your application or hardware micro-managed by an
    IEEE committee? The specs should specify what must and what should be
    done, not how it's to be accomplished.

    >I wonder...is there a more appropriate to look at the networking stack?


    Sure. You could build a monolithic proprietary solution that would
    satisfy you and nobody else. Everything would work exactly the way
    you want and expect. Too bad nobody else would want that.

    >Do the wireless options that we have available now do too much in ways
    >that are inappropriate or misleading? For example, 802.11 has an ESS
    >feature that implies that its wireless LANs can grow arbitrarily large.
    >Has anyone use this in this way? Has anyone tried to implement
    >mobility over a massive interconnection of 802.11 LANs?


    I presume a "massive interconnection of 802.11 LANs" means a mesh
    network. Sure. There are lots of mesh networks. If this is not what
    you're thinking, could you be a bit more specific?

    >Then there is Bluetooth, whose specification I have not read, but had a
    >glimpse of it a few years ago. It gave me the impression that someone
    >showed little restraint in feature provision. I was so impressed that
    >I waited for it to port my luggage off the aircraft.


    Yep. An elephant is a horse designed by the 4,000 members of the
    Bluetooth SIG. However, there is hope. The next generation of
    Bluetooth will be based on the abandoned IEEE 802.15.3a UWB effort.
    Hopefully, initial implementations will be limited to short range
    video, but I doubt it. My guess is that it UWB will attempt to grab
    market share from Wi-Fi and duplicate many of its features and
    applications. Sigh.

    >Zigbee? I got the same impression. Not horrifically complicated, but
    >not exactly bare-metal.


    http://standards.ieee.org/getieee802....15.4-2003.pdf
    679 pages, most of which are copies of applicable rules from every
    country involved. If you ignore these "annex" sections, it's only 195
    pages. Meanwhile:
    802.11-1999 528 pages
    802.11b-1999 96 pages
    802.11g-2003 78 pages
    I don't see the problem.

    >Perhaps that's the problem. Perhaps we should not be putting so many
    >"services" in the hardware.


    Services implies something a user would have access to. What services
    are you finding in the 802.11/Bluetooth/Zigbee stack that you find
    superfluous? Before you answer, please consider that all these specs
    only define layers 1 and 2 (PHY and MAC). You will not find any layer
    3 (NET) features (i.e. routing) in any of these. Now, which services
    that are defined in layers 1 and 2 do you find superfluous?

    >How about a wireless transceiver that does as well as it can at layers
    >1 & 2, then ***STOPS***.


    That's exactly what all these specs do. They specify layers 1 and 2
    and stop.

    >No security (beyond link-access-control).
    >Power-management facilities available but minimally specified.


    No way. All the problems with wireless security are a result of a
    failure to properly implement wireless security at the MAC layer. You
    can do encryption at any layer, but methinks it's best done at the
    lowest layer to prevent spoofing.

    >Link-layer addresses *only*. No "services". No mention of printers,
    >PDA's, kiosks, users, clouds, networks. No notion of a world-wide
    >network. The ideal link-layer device would get data from interface A
    >to interface B and get out of the way.


    None of these services are mentioned in any of the specs you
    mentioned. They're all applications layer and are implemented by
    applications vendors, not standards committees. You're complaining to
    the wrong people.

    >I think if each layer were approached with this mindset, we'd actually
    >do better than we have done so far.


    Not to worry. Yet another new and improved MAC layer is coming our
    way:
    http://portal.acm.org/citation.cfm?id=1080847
    Sigh...


    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

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


    Jeff Liebermann wrote:
    > I presume a "massive interconnection of 802.11 LANs" means a mesh
    > network. Sure. There are lots of mesh networks. If this is not what
    > you're thinking, could you be a bit more specific?


    That's just it. The 802.11 spec seems like it could theoretically
    support an unlimited-size mesh network that solves the mobility
    problem, but in truth it does not. The result is that the imprudent
    reviewer ends up thinking that the solution to the mobility problem is
    best handled using 802.11-like technology. IMO, they never should have
    hinted at anything. They should have said, "This is what we provide,
    this is all you get, and if you want more, figure it out yourselves.."
    At least this way there is no potential for confusion.

    > Yep. An elephant is a horse designed by the 4,000 members of the
    > Bluetooth SIG. However, there is hope. The next generation of
    > Bluetooth will be based on the abandoned IEEE 802.15.3a UWB effort.
    > Hopefully, initial implementations will be limited to short range
    > video, but I doubt it. My guess is that it UWB will attempt to grab
    > market share from Wi-Fi and duplicate many of its features and
    > applications. Sigh.
    >


    >
    > Services implies something a user would have access to. What services
    > are you finding in the 802.11/Bluetooth/Zigbee stack that you find
    > superfluous? Before you answer, please consider that all these specs
    > only define layers 1 and 2 (PHY and MAC). You will not find any layer
    > 3 (NET) features (i.e. routing) in any of these. Now, which services
    > that are defined in layers 1 and 2 do you find superfluous?


    I'm going to have to take another look at Bluetooth, but when I was
    reading the spec before, I thought I saw something about printing. I
    would rather my link-layer spec never mention the word "printer"
    anywhere.

    > >No security (beyond link-access-control).
    > >Power-management facilities available but minimally specified.

    >
    > No way. All the problems with wireless security are a result of a
    > failure to properly implement wireless security at the MAC layer. You
    > can do encryption at any layer, but methinks it's best done at the
    > lowest layer to prevent spoofing.


    I guess. I think that maintaining link integrity (as in
    interface-to-interface) is enough. End-to-end security is probably
    best handled at Network Layer and above.

    > >Link-layer addresses *only*. No "services". No mention of printers,
    > >PDA's, kiosks, users, clouds, networks. No notion of a world-wide
    > >network. The ideal link-layer device would get data from interface A
    > >to interface B and get out of the way.

    >
    > None of these services are mentioned in any of the specs you
    > mentioned. They're all applications layer and are implemented by
    > applications vendors, not standards committees. You're complaining to
    > the wrong people.


    I vaguely remember "services" from the Bluetooth spec. I'll check
    again.

    -Le Chaud Lapin-


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

    "Le Chaud Lapin" hath wroth:

    >I vaguely remember "services" from the Bluetooth spec. I'll check
    >again.


    They're called "profiles". See:
    http://en.wikipedia.org/wiki/Bluetoo...tooth_profiles
    http://www.palowireless.com/infotoot...l/profiles.asp
    for a list. Most profiles are an API (applications program interface)
    to either interface to a piece of hardware, emulator the hardware, or
    provide some type of useful feature.

    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

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


    Jeff Liebermann wrote:
    > "Le Chaud Lapin" hath wroth:
    >
    > >I vaguely remember "services" from the Bluetooth spec. I'll check
    > >again.

    >
    > They're called "profiles". See:
    > http://en.wikipedia.org/wiki/Bluetoo...tooth_profiles
    > http://www.palowireless.com/infotoot...l/profiles.asp


    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.

    -Le Chaud Lapin-


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

    [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

    In <1147787267.786310.306240@j73g2000cwa.googlegroups. com> on 16 May 2006
    06:47:47 -0700, "Le Chaud Lapin" wrote:

    >Jeff Liebermann wrote:
    >> "Le Chaud Lapin" hath wroth:
    >>
    >> >I vaguely remember "services" from the Bluetooth spec. I'll check
    >> >again.

    >>
    >> They're called "profiles". See:
    >> http://en.wikipedia.org/wiki/Bluetoo...tooth_profiles
    >> http://www.palowireless.com/infotoot...l/profiles.asp

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

    --
    Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
    John Navas

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

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


    You think so? Like what?

    I guess if there is a paucity of resources (RAM, bandwidth, power),
    some reaching might be necessary. But to see little tiny radios
    talking about printing, video...it's just too much. It also kills
    reusability. I shudder to think of so much energy being put into
    creating (numerous) veritical applications.

    Someone should...

    2. Do the physical-layer and link-layer and *stop*.

    3. Do the protocol stack from network layer up to whatever layer
    presents a regular interface for application programmers, then *stop.*
    Note that this is the hardest part. IMO, people who dream in
    quadrature should not be dibbling and dabbling in PKI infrastructures.
    There are exceptions of course, but lets face it...historically, we
    have got most of the upper layers not-quite-right, so we should
    distribute the mental effort.

    4. Application developers should write their RPC-like applications,
    and stop. They should not have to reinvent the world of security, but
    the facility by which they control security should be present.

    The results would be a lot clearer, cleaner, and portable.

    -Le Chaud Lapin-


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

    [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

    In <1147798538.564284.98660@j73g2000cwa.googlegroups.c om> on 16 May 2006
    09:55:38 -0700, "Le Chaud Lapin" wrote:

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


    >[SNIP]
    >The results would be a lot clearer, cleaner, and portable.


    We'll just have to agree to disagree.

    --
    Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
    John Navas

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

    On Tue, 16 May 2006 09:55:38 -0700, Le Chaud Lapin wrote:

    > The results would be a lot clearer, cleaner, and portable.
    >


    So, do you intend to hold everyone at gunpoint, to ensure that they follow
    your standards?

    Thanks,
    Rich


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

    > I think if each layer were approached with this mindset, we'd actually
    > do better than we have done so far.


    First off, pick a relevant newsgroup and don't shotgun it to a bunch of
    them.

    We had what you're talking about in the earliest days of networking. And as
    a result we had a boatload of incompatible methods for speaking on the wire.
    I'd venture we don't want to go back to those days. Especially not when
    wireless is a considerably more limited medium. It's one thing to be
    wasteful on the wire, over the air it's expensive (carrier fees, wattage,
    speed, etc).



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

    Rich Grise wrote:
    > So, do you intend to hold everyone at gunpoint, to ensure that they follow
    > your standards?


    On the contrary, I would let the standards fight for best of breed.

    That's essentially what happens now with computers. Many CPU's, many
    architectures, C is doing just great against Lisp (for example).

    I would love to see a new, programmable, USB-based RF transceiver.
    It's job would be to simply transmit and receive frames, perhaps with
    link-layer addresses encoded, much like Ethernet is done on the wire.
    I would keep the collision-avoidance technology, but beyond that, I
    would do nothing else.

    I am almost certain that if someone were to do this, the network-layer
    people would figure out how to use it.

    -Le Chaud Lapin-


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

    [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

    In <1147914276.670023.94920@j55g2000cwa.googlegroups.c om> on 17 May 2006
    18:04:36 -0700, "Le Chaud Lapin" wrote:

    >I would love to see a new, programmable, USB-based RF transceiver.
    >It's job would be to simply transmit and receive frames, perhaps with
    >link-layer addresses encoded, much like Ethernet is done on the wire.
    >I would keep the collision-avoidance technology, but beyond that, I
    >would do nothing else.
    >
    >I am almost certain that if someone were to do this, the network-layer
    >people would figure out how to use it.


    Probably no real demand; else it would exist.

    --
    Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
    John Navas

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

    John Navas wrote:
    > >I would love to see a new, programmable, USB-based RF transceiver.
    > >It's job would be to simply transmit and receive frames, perhaps with
    > >link-layer addresses encoded, much like Ethernet is done on the wire.
    > >I would keep the collision-avoidance technology, but beyond that, I
    > >would do nothing else.
    > >
    > >I am almost certain that if someone were to do this, the network-layer
    > >people would figure out how to use it.

    >
    > Probably no real demand; else it would exist.


    God forbid that a doctor would ever utter these words to a patient with
    terminal illness.

    There is a real demand to fix major problems with computer networking.

    There is a real demand for a generalized solution to the mobility
    problem. But no solution exists. There is real demand for integrated
    security for network programming. But no solution exists. There is
    real demand for a naming system that is far better than DNS. But no
    solution exists. There is real demand for large-scale multicasting.
    There is real demand for a "socket" model that is not as horrific as
    sockets.

    There is real demand for many things, but no solutions exist because
    those who would provide the solutions simply are not.

    The fact that $300 million has been ear-marked to do what IPv6 failed
    to do is testament to the demand:

    http://www.geni.net/index.php

    -Le Chaud Lapin-


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

    In comp.dcom.lans.ethernet Le Chaud Lapin wrote in part:
    > John Navas wrote:
    >> Probably no real demand; else it would exist.


    > God forbid that a doctor would ever utter these words to
    > a patient with terminal illness.


    Perhaps uncompassionate, but often still true. However, we
    do not need to be concerned with compassion about computer
    networks. So "The Truth" (whatever that might be) matters
    far more than decorum.

    > There is a real demand to fix major problems with computer
    > networking.


    No and yes: There are certain problems with computer networking.
    There is _some_ demand to fix them. But not a lot because most
    people are fairly satisfied with networking as-is.

    The Best is the enemy of the Good. Or in this case: The Good
    is the enemy of the Best. It reduces the drive to improve.
    "Satisficing". IBM PC architecture is horrible, x86 is
    bletcherous, according to "experts". Yet both persist.

    > There is a real demand for a generalized solution to the
    > mobility problem. But no solution exists.


    Many people seem happy with IEEE 802.11b/g for medium range and
    Bluetooth for short-range. This layered approach is very much how
    the Internet was built. A network of networks. Minimal direction,
    and lots of local choice. I could go to Greentooth and my 802.11g
    wouldn't care.

    > There is real demand for integrated security for network
    > programming. But no solution exists.


    Many people seem happy with SSL, HTTPS, certificates, etc.
    Fewer seem happy with JS, java and especially ActiveX.
    But this has nothing to do with the languages, and everything
    to do with site security and client behaviours. MS has chosen
    some egregious defaults (useradmin, autoexec HTML email).

    > There is real demand for a naming system that is far better
    > than DNS. But no solution exists.


    Many people are happy with DNS. Glass half-full, half-empty,
    or twice as large as necessary?

    > There is real demand for large-scale multicasting.


    There is. And this one is the least solved. Caching proxies
    help in some situations.

    > There is real demand for a "socket" model that is not as
    > horrific as sockets.


    So make your name by creating one!

    > There is real demand for many things, but no solutions exist
    > because those who would provide the solutions simply are not.


    Do not complain what others are not doing. They have a right
    to be lazy. Do it yourself!

    > The fact that $300 million has been ear-marked to do what
    > IPv6 failed to do is testament to the demand:


    IPv6 has problems, arguable worse than IPv4.
    That's why it hasn't been much used.

    Some solutions are "good enough". Better solutions might be
    possible. Or they might just introduce further (perhaps worse)
    problems. This is what politicians frequently do with new laws.
    Human beings react, and that reaction can be larger than the
    original impulse.

    -- Robert


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

    [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

    In <1147923094.748202.271780@i39g2000cwa.googlegroups. com> on 17 May 2006
    20:31:34 -0700, "Le Chaud Lapin" wrote:

    >John Navas wrote:
    >> >I would love to see a new, programmable, USB-based RF transceiver.
    >> >It's job would be to simply transmit and receive frames, perhaps with
    >> >link-layer addresses encoded, much like Ethernet is done on the wire.
    >> >I would keep the collision-avoidance technology, but beyond that, I
    >> >would do nothing else.
    >> >
    >> >I am almost certain that if someone were to do this, the network-layer
    >> >people would figure out how to use it.

    >>
    >> Probably no real demand; else it would exist.

    >
    >God forbid that a doctor would ever utter these words to a patient with
    >terminal illness.


    Meaningless analogy.

    >There is a real demand to fix major problems with computer networking.


    Of course. Which is why the market is more interested in effective pragmatic
    solutions than in purist solutions that actually increase the risk of
    problems.

    >There is a real demand for a generalized solution to the mobility
    >problem. But no solution exists. There is real demand for integrated
    >security for network programming. But no solution exists. There is
    >real demand for a naming system that is far better than DNS. But no
    >solution exists. There is real demand for large-scale multicasting.
    >There is real demand for a "socket" model that is not as horrific as
    >sockets.
    >
    >There is real demand for many things, but no solutions exist because
    >those who would provide the solutions simply are not.


    I respectfully disagree. Actual products on the market are the result of the
    market finding effective solutions to actual demands.

    >The fact that $300 million has been ear-marked to do what IPv6 failed
    >to do is testament to the demand:
    >
    >http://www.geni.net/index.php


    That's a huge stretch.

    --
    Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
    John Navas

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

    On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:

    > In comp.dcom.lans.ethernet Le Chaud Lapin wrote in part:
    >> John Navas wrote:
    >>> Probably no real demand; else it would exist.

    >
    >> God forbid that a doctor would ever utter these words to
    >> a patient with terminal illness.

    >
    > Perhaps uncompassionate, but often still true. However, we
    > do not need to be concerned with compassion about computer
    > networks. So "The Truth" (whatever that might be) matters
    > far more than decorum.
    >
    >> There is a real demand to fix major problems with computer
    >> networking.

    >
    > No and yes: There are certain problems with computer networking.
    > There is _some_ demand to fix them. But not a lot because most
    > people are fairly satisfied with networking as-is.
    >
    > The Best is the enemy of the Good. Or in this case: The Good
    > is the enemy of the Best. It reduces the drive to improve.
    > "Satisficing". IBM PC architecture is horrible, x86 is
    > bletcherous, according to "experts". Yet both persist.

    ^^^^^^^^^^^
    ....

    Damn! If you learn something new every day, I guess I can go back to bed:

    http://www.islandnet.com/~egbird/dict/b.htm

    BTW, I agree, and I have had a modicum of experience with processors. :-)

    Cheers!
    Rich


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

    "Le Chaud Lapin" hath wroth:

    >I would love to see a new, programmable, USB-based RF transceiver.

    (...)
    >I am almost certain that if someone were to do this, the network-layer
    >people would figure out how to use it.


    These are mutually exclusive requirements. No company is going to
    develop an expensive and complex chip specifically designed for an
    untested application without first making sure they have absolute
    control over the necessary patents and then insuring that they have a
    market. It's the chicken or the egg problem. You don't get the chips
    without the applications. The applications don't get written without
    first having the chips. Emulators are possible, but can't be easily
    sold, perform badly, and often don't adequately emulate the working
    environment.

    There has to be a need and paying customers to justify development
    costs. Doing the same old thing slightly better is not sufficient. At
    this time, my guess is a 2 times improvement in performance or cost is
    what will be required. I don't see that happening with just an
    improved MAC layer. For example, UWB (ultra wide band) has
    substantial performance benefits over 802.11b/g, and opens a new
    market in wireless video connections, which is sufficient to justify
    chip development by Intel (which is traditionally 18 to 24 months
    later than promised).

    What I find amusing is your interest in "simplifying" the MAC layer
    and possibly the other layers. The cheapest component in today's chip
    designs is memory and CPU cycles. The more you do in software, the
    cheaper the product. Adding features and functions are only limited
    by available horsepower, memory, and power consumption. Obviously,
    this would tend to create complex software with the usual bugs which
    is probably what you're really complaining about. So, a fairly simple
    idea, like eliminating cables, turns into a complex feature infested
    pretzel, like Bluetooth. I don't have a problem with this because to
    implement the same thing in a highly modular fashion is both difficult
    and expensive in chip count. Moving the applications support to some
    off-chip device, really raises the costs. Also, it's perfectly
    acceptable to tolerate some level of complexity, inefficiency,
    non-elegance, and cute tricks, to obtain sufficient versatility to
    sell the chips and the technology into a wider market area.

    Ask yourself why TCP/IP won over OSI 7 layer (as implemented by 3Com),
    LAN Manager (Microsloth), Netware (Novell), Lantastic (Artisoft), and
    a mess of smaller networking vendors (MosesNet, Ungerman Bass,
    DaVinci, etc)? If elegance of design was the chief requirement, we
    should all be running OSI 7 layer 3com networks. If performance was a
    major issue, we should be running Netware. If ease of integration was
    the main requirement, we should now be running LAN Manager. If
    simplicity were a requirement, we should be running NETBEUI. If
    meeting a specific application requirement (i.e. CAN), we should be
    running one of the minor network vendors products. Yet, TCP/IP has
    successfully met all these requirements, but admittedly in a mediocre,
    non-elegant, and compromise fashion. It's not elegant, it's not fast,
    it doesn't configure easily, and it's not optimized for any particular
    application. In other words, if you can do everything, then
    inefficiency in design is more than acceptable.

    Also, you might consider that limiting applications vendors to
    anything above the MAC (hardware) layer is not really going to solve
    many problems. The big problem is applications coexistence. For
    example, can a bluetooth headset coexist with 802.11, EV-DO, and IrDA
    communications, in the same box or in the same chip? How do you
    bridge between them? Will the necessary CPU cycles slow down the user
    playing games on their cell phone? By standardizing the applications
    interface along with the communications protocol, many of these
    interactions are standardized. Removing the API's and interfaces
    would simply re-create the problem they were intended to solve.

    Good luck. You'll need it.


    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

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

    In comp.dcom.lans.ethernet Rich Grise wrote in part:
    > On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:
    >> "Satisficing". IBM PC architecture is horrible, x86 is
    >> bletcherous, according to "experts". Yet both persist.

    >
    > BTW, I agree, and I have had a modicum of experience with processors. :-)


    IMHO, a strong case can be made that IBM intended for
    the original 5120 PC to be a flop. A sacrificial lamb.
    They did everything against the proven IBM ways to success:
    outsourced, open architecture, minimal testing/err chk.
    And chose the i8088, arguably the worst CPU of the day.

    But, as time has shown, they failed at failure. The PC succeeded!

    -- Robert

    >
    >


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

    In article ,
    redelm@ev1.net.invalid says...
    > In comp.dcom.lans.ethernet Rich Grise wrote in part:
    > > On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:
    > >> "Satisficing". IBM PC architecture is horrible, x86 is
    > >> bletcherous, according to "experts". Yet both persist.

    > >
    > > BTW, I agree, and I have had a modicum of experience with processors. :-)

    >
    > IMHO, a strong case can be made that IBM intended for
    > the original 5120 PC to be a flop. A sacrificial lamb.
    > They did everything against the proven IBM ways to success:
    > outsourced, open architecture, minimal testing/err chk.
    > And chose the i8088, arguably the worst CPU of the day.


    The 5120 was pretty much a flop. The original PC was the 5150.
    ;-)

    > But, as time has shown, they failed at failure. The PC succeeded!


    --
    Keith

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