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.

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

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-

"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

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-

[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

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-

[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

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

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

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-

[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

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-

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

[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

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

"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

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

>
>

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