On Sun, 23 Jul 2006 12:43:23 -0700 Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
| phil-news-nospam@ipal.net hath wroth:
|
|>In the beginning I really failed to do the research I should have done.
|
| It's often helpful to understand the existing technology before
| attempting to change it.
|
|>What I rarely understand are the social engineering issues. Things like
|>the squabbling that takes place in standards committees, and why it is
|>they will go ahead and make choices towards less than optimal technology.
|>Of course I do understand why some patent holders of some technology would
|>lobby to have their technology chosen. But it makes no sense to me why
|>the rest would accept that technology if it is not the actual and true
|>best technology to choose.
|
| Those are not social issues. They're political and financial.


Social is a broader category that includes political and financial.

| Standards are invariably built upon the intellectual property and
| patents of the participating companies. The results may not be
| technically ideal dues to the necessary tradeoffs. If you want to
| have something adopted, there has to be compromises. What you are
| apparently assuming is that the committee will adopt the technically
| superior combination of ingredients at the expense of IP and patents.
| It's quite the opposite.

If you had a committee intent on designing the best technology, then
it could do so. If element A and element B cannot coexist unless one
of them is less than optimal, then that's where technical tradeoffs
might have to be made, or more research done to solve a problem.

Committees formed of manufacturers, however, tend to be more about
promoting their technology to the others, rather than making something
that works better.

I'd expect a little better of IEEE than what I have seen, although to
a great degree they have done reasonably well.

The early TCP/IP standards were developed in quite different ways, and
in many ways are quite superior to what you could get by a committee
of manufacturers.



|>I would have used OFDM right from
|>the beginning,
|
| Try again. In 1996, when 802.11 was being debated, OFDM wasn't a
| viable technology because the expensive and elaborate processing power
| necessary to implement OFDM wasn't there yet. OFDM only became
| popular when sufficient CPU horsepower was available almost as an
| accidental side effect of telco DMT (discrete multitone) DSL research.

The concept of the technology was known long before that. Driving
the demand for a technology can create the ability to make it work
sooner. Would you have simply never done OFDM had the DMT work never
been done? That would be stupid. The CPU speed to do OFDM really
was around even in 1996. It just wants _architectured_ in a way most
suitable for it.

This is like a chicken and egg problem. They won't make the technology
unless there is a demand for it. There won't be a demand for it if we
decide to only use what already exists. Someone has to think ahead to
get out of that vicious circle.

So basically, it sounds like the 802.11 group was stuck in a vicious
circle and the telco group decided to get out of it.


|>But for the infrastructure, I definitely would not have any
|>device intentionally discard data frames from other devices unless there
|>was a good reason to do so (uncorrectable errors, security authentication
|>fails, not addressed to this or known reachable devices, known to have a
|>better path elsewhere, etc).
|
| Why not? All ethernet cards do exactly that. The PAD (packet
| assembler/disassembler) in the front end of the ethernet card acts as
| a filter. It asks "is this packet for me?". If not, it discards it
| before decoding the packet. Saves quite a bit on processing power
| (and current consumption). However, if you have surplus processing
| horsepower, by all means, feel free to decode everything.

And some provide a means for more complex checking, such as multiple
MACs. A device that needs to build the network, though, will have to
do some kind of processing of most everything, unless that is delegated
to a smarter co-processor or whatever might be on board.


|>If I were to make an access point device that actually would talk to
|>another access point device, many problems would be solved that are today
|>merely solved by having redundant equipment, often utilizing more channels
|>than necessary.
|
| Where were you in 1996 when such things were being discussed? The
| original concept of a wireless access point was a central access
| point, with directly connecting wireless clients. If there were
| additional access points, they would be connected with ethernet. In a
| corporate or business environment, that was all that was deemed
| necessary. There were other grandiose topology schemes mentioned, but
| all of them fell apart when it came time to weigh the added complexity
| against the cost and necessity. Poorly defined repeater and WDS modes
| were thrown in as a pacifier for those that wanted extensible wireless
| networks.

In 1996 I had no interest in doing wireless. I was doing other things.

But I do think it is not outside of reason to ask for _every_ wireless
device in a home or small office to be able to communicate with _every_
other device there, when it has traffic specifically for it.


|>I've heard horror stories of multi-office buildings being
|>overloaded on wireless, and now I can see why.
|
| Yep. The surest sign of success is pollution. Wireless is certainly
| successful.

I wouldn't necessarily use success. The term "popular" comes to mind
as being more appropriate. Of course manufacturers would consider it
to be successful if larger numebrs of units are sold, regardless whether
the buyers find it usable or not. Of course non-usable can result in
later sales going down. Ultimately I think people need to determine
where they really need wireless and use it there and avoid it in other
places.


|>Perhaps some of these
|>issues are perptrated by the vendors themselves in an effort to drive up
|>more sales by making people have to buy even more devices just to make
|>their network function.
|
| Actually, quite the contrary. Most of the original participants were
| academics, not greedy corporate exploiters. Note that the fastest
| speed considered useful in 1996 was 2Mbits/sec.

So why would they want to make each frame spedn air time TWICE?


|>Given the existance of third part firmware, it
|>sure suggests that the original vendors are either doing that, or are just
|>not keeping up with what is technically possible to do, especially in the
|>area of switching frames and routing packets.
|
| Ummm... I'm not sure that alternative firmware has had much of an
| impact on Linksys and others. For example, Linksys apparently shot
| itself in the foot with the WRT54G v5, that originally could not
| handle alternative firmware. Apparently they thought that the Linux
| hacker market was so small as to not worth dealing with. Had the v5
| mutation not been such a bug pile, they might have been correct.

It's always hard for something like Linux to penetrate corporate
culture. I still find people in _technical_ business that have
never even heard of Linux at all. Most have, but they still think
it's just some geek novelty. While it hasn't caught up with Windows
for desktop usage (as long as you compare current Linux to current
Windows ... today's Linux certainly beats Win98), Linux is widely
used in a lot of embedded systems. Even Linksys did for a while in
the early WRT54G. And somehow they did realize it would be good to
have the WRTG54GL on the market. Maybe they figured Linux developers
could find and open up new wireless uses.


|>So perhaps I really should look at 3rd party firmware, but not so much
|>for just loading something someone has written to do something better,
|>but perhaps to actually get into doing this writing myself. OpenWRT
|>sure seems like a good starting point. Assuming the limitations where
|>a device refuses to talk to another instance of itself is not in the
|>hardware, maybe I really can make an access point talk to another access
|>point, and make a client bridge really talk to another client bridge,
|>and do both of these things in the same one device. It's all in the
|>programming (hopefully).
|
| There's no hardware limitation that prevents the implementation of
| code for getting two access points to talk to each other. Of course,
| this has already been done with WDS, but I'm always interested in
| improved implementations.
|
| Reminder: Did you catch my comments about the antenna problem with
| using a single box for both indoor and outdoor coverage? Having a
| single box do everything *MIGHT* be a problem as the placement of the
| box and antenna will be a compromise between indoor omni coverage, and
| outdoor directional coverage. Sometimes, it's best to have two
| separate wireless boxes.

Agreed. But I would't make two different kinds of boxes _just_ to do
that separation. Some people might just want coverage out to the deck
in the back of the house, and one box doing everything might well be
fine for that. if something really does need a 2nd box, then either of
the boxes shoudl be able to perform that role. And it should be as
simple as just putting it there if the firmware is smart enough.

That's not to say there isn't need for other kinds of boxes. Other kinds
of connections in embedded system boxes might be nice to have, such as
USB, Firewire, serial, eSATA, SCSI, PS/2, POTS, SDI, HDMI, and many more.
Putting _everything_ that _anyone_ might need is just too impractical.
But ethernet and wireless in one box is good enough to get quite a lot
going.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-23-1717@ipal.net |
|------------------------------------/-------------------------------------|