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-

(E-Mail Removed) 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.

(E-Mail Removed) 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 (E-Mail Removed)
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" <(E-Mail Removed)> 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 (E-Mail Removed)
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" <(E-Mail Removed)> 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 <(E-Mail Removed) .com> on 16 May 2006
06:47:47 -0700, "Le Chaud Lapin" <(E-Mail Removed)> wrote:

>Jeff Liebermann wrote:
>> "Le Chaud Lapin" <(E-Mail Removed)> 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 <http://en.wikibooks.org/wiki/FAQ_for_alt.internet.wireless>

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 <(E-Mail Removed). com> on 16 May 2006
09:55:38 -0700, "Le Chaud Lapin" <(E-Mail Removed)> 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 <http://en.wikibooks.org/wiki/FAQ_for_alt.internet.wireless>

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