|
Cellular forums Home > Archive > Bluetooth discussion > May 2006 > Hey! Keep Your Hands Out Of My Abstraction Layer!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Hey! Keep Your Hands Out Of My Abstraction Layer!
|
|
| unoriginal_username@yahoo.com 2006-05-15, 2:48 am |
| 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-
| |
| Don Taylor 2006-05-15, 5:48 am |
| 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.
| |
| Jeff Liebermann 2006-05-15, 5:48 am |
| 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/getieee80...2.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
| |
| Le Chaud Lapin 2006-05-15, 5:48 pm |
|
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 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.
>
> 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 2006-05-16, 5:48 pm |
|
Jeff Liebermann wrote:
> "Le Chaud Lapin" < unoriginal_username@
yahoo.com> hath wroth:
>
>
> They're called "profiles". See:
> http://en.wikipedia.org/wiki/ Bluet...
profiles
> http://www.palowireless.com/infotoo...al/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-
| |
| John Navas 2006-05-16, 5:48 pm |
| [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" < unoriginal_username@
yahoo.com> wrote:
>Jeff Liebermann 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.
--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Le Chaud Lapin 2006-05-16, 5:48 pm |
| 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-
| |
| John Navas 2006-05-16, 5:48 pm |
| [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <1147798538.564284.98660@j73g2000cwa.googlegroups.com> on 16 May 2006
09:55:38 -0700, "Le Chaud Lapin" < unoriginal_username@
yahoo.com> wrote:
>John Navas wrote:
[color=darkred]
>[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_fo...ternet.wireless>
| |
| Rich Grise 2006-05-17, 5:48 pm |
| 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
| |
| Bill Kearney 2006-05-17, 11:48 pm |
| > 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).
| |
| Le Chaud Lapin 2006-05-17, 11:48 pm |
| 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-
| |
| John Navas 2006-05-17, 11:48 pm |
| [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <1147914276.670023.94920@j55g2000cwa.googlegroups.com> on 17 May 2006
18:04:36 -0700, "Le Chaud Lapin" < unoriginal_username@
yahoo.com> 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 <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Le Chaud Lapin 2006-05-18, 2:48 am |
| 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.
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-
| |
| Robert Redelmeier 2006-05-18, 5:48 pm |
| In comp.dcom.lans.ethernet Le Chaud Lapin < unoriginal_username@
yahoo.com> wrote in part:
> John Navas wrote:
[color=darkred]
> 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
| |
| Le Chaud Lapin 2006-05-18, 5:48 pm |
|
Robert Redelmeier wrote:
> In comp.dcom.lans.ethernet Le Chaud Lapin < unoriginal_username@
yahoo.com> wrote in part:
>
> 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.
Mmmm...I don't buy this. I think that people are fairly _disappointed_
with networking as-is, and have grown accustomed to disappointment. In
fact, in about 20 minutes, I am going to go into my office and watch a
highly paid IT person try, yet again after 3 days, to fix problems with
our network so I can (1) print (2) share files, which I have not been
able to do because of a glitch that seems to affect only a few of us.
He will fail most likely, not by virtue of his intelligence or
knowledge, but due to the complexity (the ugly kind) of our network. I
will then email my documents to the administrative assistant, and she
will print them out for me, and I will go back to my desk, and not
complain to anyone but USENET. This situation is very common. To say
"a solution would exist if it were a real problem" is an excuse for
those who have been charged to find a solution but have not.
> 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.
True. But the risk of conversion is far less with software than
hardware. Two protocols on my computer because I want to see if the
new is better than the old? No problem. Two PC's on my desk because I
want to see if the new is better than the old? No way.
> 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.
I just read a post by someone in alt.internet.wireless who is looking
for a solution to the mobility problem for a factory. He didn't write,
"I'm looking for a solution to the mobility problem", but in fact,
that's what he wants. And I've seen many other similar requests, like
university admins hoping to allow "roaming" accross campus networks,
field workers wanting roaming for their data-gathering devices. There
have been 7 new companies in the last year alone that I know of you are
trying to do "mobility". Again, the demand is very great. But after
so many broken promises, people learn to cope. That is *not* to say
that if someone actually did make something of virtue, that people
would continue using ripped nets to catch fish.
>
> Many people are happy with DNS. Glass half-full, half-empty,
> or twice as large as necessary?
Doesn't matter how much water is in the glass if the glass was
initially empty.
>
> So make your name by creating one!
I think I will. Hold your breath. ;)
>
> Do not complain what others are not doing. They have a right
> to be lazy. Do it yourself!
Not with government money. The whole point behind the grant process is
to avoid giving money to researchers who will simply squander it. They
have a right to be lazy if they do research using their own money.
>
> IPv6 has problems, arguable worse than IPv4.
> That's why it hasn't been much used.
I say a lot of these problems could have been foreseen. It took 15
years and an immeasurable waste of resources to figure that out. Back
in 1991, anyone who would have claimed that IPNG (Big-Internet) was
going to fail because there were too many cooks in the kitchen would
have been heckled out of the room. I am waiting to see what happens
with GENI.
-Le Chaud Lapin-
| |
| Robert Redelmeier 2006-05-18, 5:48 pm |
| In comp.dcom.lans.ethernet Le Chaud Lapin < unoriginal_username@
yahoo.com> wrote in part:
> I think that people are fairly _disappointed_ with networking
> as-is, and have grown accustomed to disappointment.
Semantics. Unless they're willing to do something,
this is equivalent to "fairly satisfied".
> In fact, in about 20 minutes, I am going to go into my
> office and watch a highly paid IT person try, yet again
> after 3 days, to fix problems with our network so I can
> (1) print (2) share files, which I have not been able to do
> because of a glitch that seems to affect only a few of us.
Unless you have unusual internal firewalls that aren't being
maintained as necessary, I strongly suspect the network is blameless.
The problem most likely lies in MS-Windows.
> To say "a solution would exist if it were a real problem"
> is an excuse for those who have been charged to find a
> solution but have not.
I hear your pain, but who has been so charged? No-one here, AFAIK.
And if some readers _are_ working on these problems, employment
confidentiality would prohibit them from discussing it.
> True. But the risk of conversion is far less with software
> than hardware. Two protocols on my computer because I want
> to see if the new is better than the old? No problem.
> Two PC's on my desk because I want to see if the new is
> better than the old? No way.
I do not understand. I would expect precisely the contrary:
two+ PCs is easy with a KVM. Expecting different software/protocols
to co-exist peacefully within an OS might be very difficult.
> a factory. He didn't write, "I'm looking for a solution to
> the mobility problem", but in fact, that's what he wants.
> And I've seen many other similar requests, like university
But if you don't even know enough to know where to go, how
can anyone help you? You'll be at the mercy of travelling
salesmen and their broken prosises. FWIW, I know of perfectly
working multi-acre wireless sites. In electrically very
noisy areas. You just need competant designers.
> Doesn't matter how much water is in the glass if the glass
> was initially empty.
But it is not. There are lots of tantalizing services.
[color=darkred]
> Not with government money. The whole point behind the
> grant process is to avoid giving money to researchers who
> will simply squander it. They have a right to be lazy if
> they do research using their own money.
You expect government to solve problems? Or even know
where to start? You must be as french as your nym sounds.
Why would they know? Are their motivations aligned? How?
What technical problem has any government ever solved? The dutch
have been beating back the sea/rivers for hundreds of years.
But that is an environmental problem solved by technical means.
The US went to the moon. But the moon was not a problem. Lunites
weren't about to invade :) The US FCC allocates EM spectrum.
That is a technical problem (well, closer to homestead) but I'd
hardly call the FCC's solution any good!
> I say a lot of these problems could have been foreseen.
> It took 15 years and an immeasurable waste of resources to
> figure that out.
I suspect mostly government resources, which were seized
precisely to be wasted.
> Back in 1991, anyone who would have claimed that IPNG
> (Big-Internet) was going to fail because there were too many
> cooks in the kitchen would have been heckled out of the room.
Perhaps, but only because the hecklers were too invested
in IPNG. I always look upon such events with bemusement,
because anyone who argues so unfairly is reavaling their
inner insecurities about their position.
> I am waiting to see what happens with GENI.
I'm _not_ holding my breath :)
-- Robert
| |
| John Navas 2006-05-18, 5:48 pm |
| [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" < unoriginal_username@
yahoo.com> wrote:
>John Navas wrote:
>
>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 <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Rich Grise 2006-05-18, 5:48 pm |
| On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:
> In comp.dcom.lans.ethernet Le Chaud Lapin < unoriginal_username@
yahoo.com> wrote in part:
>
>
> 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.
>
>
> 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
| |
| Jeff Liebermann 2006-05-18, 5:48 pm |
| "Le Chaud Lapin" < unoriginal_username@
yahoo.com> 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
| |
| Robert Redelmeier 2006-05-18, 5:48 pm |
| In comp.dcom.lans.ethernet Rich Grise <richgrise@example.net> wrote in part:
> On Thu, 18 May 2006 13:20:43 +0000, Robert Redelmeier wrote:
>
> 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 <pK2bg.78202$H71.34511@newssvr13.news.prodigy.com>,
redelm@ev1.net.invalid says...
> In comp.dcom.lans.ethernet Rich Grise <richgrise@example.net> wrote in part:
>
> 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
| |
| Le Chaud Lapin 2006-05-18, 5:48 pm |
|
Jeff Liebermann wrote:
> 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.
Actually, if Bluetooth had every feature one could imagine and there
were zero bugs in it, I still would not want it. What I am complaining
about is the mess. I hesitate to use the word "complexity", because
there are many things that are complex, but also beautiful. Bluetooth
and many of these other protocols are downright ugly, and it is this
ugliness, lack of coherence, malformation, whatever you want to call
it...that makes them not useable. It is often the case that the
"model", if there is one, is defective, and it's almost comical to see
engineers attempting to speak intelligently about a something that is
still in a state of a nothing.
> Ask yourself why TCP/IP won over OSI 7 layer (as implemented by 3Com),
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.
> 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.
But let's face it...if you were to apply the label "universal" to all
of these protocols, it would only stick on TCP/IP, and not because
everyone is using TCP/IP, but because TCP/IP is inherently more
universal than the others. I think we are saying the same thing here.
> 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.
Apart from power-management, I believe there exists a universal model
by which one can regard these types of hardwares. TCP/IP came very
close to finding it, but stopped short (with ARP, IP address bound to
interface instead of something else, etc.)
I also agree that CPU cycles and RAM are cheap. I would prefer that
the upper layers follow the "heavy XXXXX" model where, whatever state
is needed to create a solid coherent framework from layers 3 on up,
that is what should be done. We should get away from attaching IP
addresses to interfaces. That model alone causes a lot of problems.
-Le Chaud Lapin-
| |
| John Navas 2006-05-18, 5:48 pm |
| [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <pK2bg.78202$H71.34511@newssvr13.news.prodigy.com> on Thu, 18 May 2006
18:08:21 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>In comp.dcom.lans.ethernet Rich Grise <richgrise@example.net> wrote in part:
>
>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!
That's a joke, right?
--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Robert Redelmeier 2006-05-18, 5:48 pm |
| In comp.dcom.lans.ethernet John Navas < spamfilter0@navasgro
up.com> wrote in part:
> 18:08:21 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>
> That's a joke, right?
No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
The PC was an unexpected success. Perhaps it wasn't expected
to be a success at all! At least at senior levels. It was not
done using IBM's proven project methods. Large bureaucratic
organizations like IBM was at the time are far more likely to be
defensive (to the point of sacrifical lambs) than to be innovative.
-- Robert
>
| |
|
| In article <FK4bg.78304$H71.47443@newssvr13.news.prodigy.com>,
redelm@ev1.net.invalid says...
> In comp.dcom.lans.ethernet John Navas < spamfilter0@navasgro
up.com> wrote in part:
>
> No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
> The PC was an unexpected success. Perhaps it wasn't expected
> to be a success at all! At least at senior levels. It was not
> done using IBM's proven project methods. Large bureaucratic
> organizations like IBM was at the time are far more likely to be
> defensive (to the point of sacrifical lambs) than to be innovative.
This is only half correct. IBM, at the time, was experimenting
with skunk-works types of projects to try to get around some of the
bureaucratic stodginess they'd built up. The PC was one of these
semi-autonomous projects. No, it wasn't expected to turn the world
on its ear, and likely would have been killed if anyone thought it
really would. Of course it wasn't done with IBM's "proven project
methods". That was the point of these independent projects (every
development lab had them).
--
Keith
| |
| Anne & Lynn Wheeler 2006-05-18, 11:48 pm |
|
Keith <krw@att.bizzzz> writes:
> This is only half correct. IBM, at the time, was experimenting with
> skunk-works types of projects to try to get around some of the
> bureaucratic stodginess they'd built up. The PC was one of these
> semi-autonomous projects. No, it wasn't expected to turn the world
> on its ear, and likely would have been killed if anyone thought it
> really would. Of course it wasn't done with IBM's "proven project
> methods". That was the point of these independent projects (every
> development lab had them).
they were suppose to be independent business units ... and they were
funded to be lean and mean. however, they frequently conserved costs
by being co-located at an existing corporate facility ... and had to
deal with various bureaucratic issues at those locations.
the frequent response to claiming that you weren't suppose to be
subject to some bureaucratic process ... was that those rules only
applied to other bureaucratic processes ... IT DIDN"T apply to THEIR
bureaucratic processes. when nearly all of the bureaucrats made such
assertions ... you found that you weren't funded and/or staffed to
handle such bureaucratic processes.
on a smaller scale in the 70s, most labs were supposed to set aside
some portion of their budget for advanced technology projects ... and
you found various labs sponsoring "adtech" conferences. however, going
into the late 70s, you found some number of sites heavily using their
"adtech" resources for fire fights in normal day-to-day product
operation. as a result there was a derth of internal adtech
conferences during the late 70s and early 80s.
i managed to run one in mar82 out of SJR ... but it had been the first
in a number of years. minor post mentioning the event and listing the
CFP
http://www.garlic.com/~lynn/96.html#4a
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
| |
| Jeff Liebermann 2006-05-18, 11:48 pm |
| On 18 May 2006 11:35:39 -0700, "Le Chaud Lapin"
< unoriginal_username@
yahoo.com> wrote:
>Actually, if Bluetooth had every feature one could imagine and there
>were zero bugs in it, I still would not want it. What I am complaining
>about is the mess.
The messier it is, the better it works. I think I invented that line
after dealing with far too many complaints about my lack of
"elligance" in radio design. If it works ship it. If you ship it,
it's already obsolete because the next two generations of replacement
products are already in the pipeline.
If elligance were a sellable commodity demanded by consumers and
OEM's, you would probably have your way. It results in products that
are full of compromises, band-aids, and marginal design. I don't buy
a Bluetooth headset because it's "elligant". I buy it because it
works adequately (and looks cool). If you don't like a product, just
wait about 3 months for the replacement. Welcome to the 21st century.
Also, please realize that what you consider to be a mess is the end
result of considerable wrangling, haggling, debates, yelling, and
minor violence on the part of the various standards committees,
consortiums, forums (fora?), and conspiracies in smoke filled hotel
rooms and overpriced restaurants. (I may have a photo somewhere of
the restaurant table cloth on which SNMP was first conceived). The
compromises involved are often not optimal for best design practices,
such as where some member of the consortium refuses to contribute a
patent or supply sane license terms. Of course, after the job is
done, there's *ALWAYS* someone who thinks it could have been done
better, but somehow didn't feel that it was important to either
participate or offer their brilliance at the time when changes would
have been possible. At that point, unless you found a fatal flaw or
major issue, it's done and ossified in stone.
>It is often the case that the
>"model", if there is one, is defective, and it's almost comical to see
>engineers attempting to speak intelligently about a something that is
>still in a state of a nothing.
Nifty. A plea for serial development, where each step of the process
from conception to deliver is performed one step at a time.
Conceptually, this is the most eligant way, resulting in the fewest
bugs and complications. Unfortunately, both paying customers and
boards of directors are rather impatient beasts. They want it *NOW*
and are not willing to wait for serial development. So, the product
development cycle degenerates into parallel development, where many
engineers and programs are working with vaporware, emulators, science
fiction technology, real-soon-now component deliveries, and impossible
schedules. Welcome (again) to the 21st century.
>
>OSI, was more like a mood. I have never seen one line of OSI "code".
You haven't looked very hard. In the mid 80's, the OSI layer cake
model was conceived to replace the lack of eligance found in Unix. A
major problem with Unix was that networking was largely grafted into
the kernel and was a rather bad fit. OSI networking would solve that
by designing in the networking. It was largely conceived and
implimented by academics and institutions. There was minimal industry
participation. The design was de jure (in principle) instead of de
facto (in practice). In other words, there was little testing.
If you read the magazines of the day, everyone agreed that TCP/IP was
on its way out, was badly designed, was not sufficient scaleable to
survive much longer, and was going to be replaced by OSI model
networking. Surveys of potential large network customers revealed an
overwhelming interest in switching to an OSI model network.
The first product to arrive was by 3com. 3com 3+share, 3+mail,
3+remote, etc was the first OSI (DOS based) product. Slowest piece of
junk I've ever tried to sell and support. Here was the alleged answer
to all of TCP/IP's lack of eligance and it looked like a giant step
backwards.
The addition of X.400 email addressing and X.500 directory services
really made life miserable for the customers. Putting the routeing
and header information in the email address was considered clever at
one time. I guess none of the academics bothered to ask the users.
X.500 was even worse. Nobody could understand how it worked or how to
make it useful. It took LDAP and possibly AD to mostly clean up the
applications and user interfaces. X.500 is a great example of extreme
design elegance resulting in difficult implimentations.
I'm not going to go into what went wrong with OSI networking. Lots of
problems and corresponding allegations. It doesn't matter. What does
matter is the OSI didn't solve any of the real user problems and
didn't meet the market requirements. However, it wasn't a mess and
was rather eligant.
>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.
Well, there's some truth in that. If you have a spare moment, try to
predict the applications and technology of perhaps 5 to 10 years from
now. Write it down on a piece of paper and seal it in an envelope to
be opened 5 to 10 years from now. I actually did that in about 1990
and found myself wrong on just about everything.
>But let's face it...if you were to apply the label "universal" to all
>of these protocols, it would only stick on TCP/IP, and not because
>everyone is using TCP/IP, but because TCP/IP is inherently more
>universal than the others. I think we are saying the same thing here.
Exactly. Broad applications support, extensibility, and the ability
to abuse the technology to make it do something it was never intended
to do, is what makes a winner. Oh yeah, the lack IP (intellectual
property) and licensing constraints.
>We should get away from attaching IP
>addresses to interfaces. That model alone causes a lot of problems.
Enlighten me. What problems does haveing individual IP's on each
interface port cause? It allows me to route between interfaces. It
allows me to virtualize interfaces as in VPN and devices as in iSCSI.
Failover is a bit tricky, but has been done with proper hardware
support to allow moving a MAC address. I kinda like that idea which
includes IPv6 attaching an IP address to everything including the
kitchen sink. If it's IP addressable, you can talk to it with TCP/IP.
I fail to see a problem.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
| |
| John Navas 2006-05-18, 11:48 pm |
| [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In <FK4bg.78304$H71.47443@newssvr13.news.prodigy.com> on Thu, 18 May 2006
20:25:09 GMT, Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>In comp.dcom.lans.ethernet John Navas < spamfilter0@navasgro
up.com> wrote in part:
>
>No. I'm surprised the tinfoil-hatted crowd hasn't seized on this.
>The PC was an unexpected success. Perhaps it wasn't expected
>to be a success at all! At least at senior levels. It was not
>done using IBM's proven project methods. Large bureaucratic
>organizations like IBM was at the time are far more likely to be
>defensive (to the point of sacrifical lambs) than to be innovative.
You're apparently unfamiliar with the actual history. It was explicitly set
up outside of the IBM bureaucracy as a kind of "skunk works" project in order
to give it the best chance of success -- see
<http://en.wikipedia.org/wiki/IBM_PC>:
Rather than going through the usual IBM design process, which had
already failed to design an affordable microcomputer (for example the
failed IBM 5100), a special team was assembled with authorization to
bypass normal company restrictions and get something to market
rapidly. This project was given the code name Project Chess.
The team consisted of just 12 people headed by William Lowe. They
succeeded -- development of the PC took about a year. To achieve this
they first decided to build the machine with "off-the-shelf" parts
from a variety of different original equipment manufacturers (OEMs)
and countries. Previously IBM had developed their own components.
Second they decided on an open architecture so that other
manufacturers could produce and sell compatible machines -- the IBM PC
compatibles, so the specification of the ROM BIOS was published. IBM
hoped to maintain their position in the market by royalties from
licensing the BIOS, and by keeping ahead of the competition
..
--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Jeff Liebermann 2006-05-18, 11:48 pm |
| On Thu, 18 May 2006 14:21:08 -0400, Keith <krw@att.bizzzz> wrote:
>In article <pK2bg.78202$H71.34511@newssvr13.news.prodigy.com>,
>redelm@ev1.net.invalid says...
>
>The 5120 was pretty much a flop. The original PC was the 5150.
>;-)
The 5120 was not initially a flop. It was introduced in 1980 and sold
for about $10,000 per system (including the worlds biggest and
noisiest small office printer). It came with quite a collection of
transplanted Model 34/36/38 applications for what was at the time
considered a reasonable price.
However, one year later, in 1981, IBM introduced the 5150, also known
as the IBM PC for about $2,000 systems price. Sales of the 5120 came
to an immediate halt.
See:
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_1.html (9 pages)
for a terse history on the various products.
As for the x86 architecture being "bletcherous", note that the various
8088/8086 segmented registers and architecture were optimized by Intel
to run Pascal, which was deemed to be the elegant language of the
period. According to the pundits, everyone would soon be programming
in Pascal because it is sooooooooo elegant. Didn't happen.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
| |
| John Navas 2006-05-18, 11:48 pm |
| [POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]
In < p50q62to45hncfnke7lh
bklgohbck95hl8@4ax.com> on Thu, 18 May 2006 23:32:58
GMT, Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>As for the x86 architecture being "bletcherous", note that the various
>8088/8086 segmented registers and architecture were optimized by Intel
>to run Pascal, which was deemed to be the elegant language of the
>period. According to the pundits, everyone would soon be programming
>in Pascal because it is sooooooooo elegant. Didn't happen.
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.
--
Best regards, SEE THE FAQ FOR ALT.INTERNET.WIRELESS AT
John Navas <http://en.wikibooks.org/wiki/FAQ_fo...ternet.wireless>
| |
| Le Chaud Lapin 2006-05-18, 11:48 pm |
|
Jeff Liebermann wrote:
> Enlighten me. What problems does haveing individual IP's on each
> interface port cause? It allows me to route between interfaces. It
> allows me to virtualize interfaces as in VPN and devices as in iSCSI.
> Failover is a bit tricky, but has been done with proper hardware
> support to allow moving a MAC address. I kinda like that idea which
> includes IPv6 attaching an IP address to everything including the
> kitchen sink. If it's IP addressable, you can talk to it with TCP/IP.
> I fail to see a problem.
I've been doing some thinking about how to solve the mobility problem,
and after much musing,I arrived at the conclusion that network
interfaces should be regarded as dumb. The protocol stack should query
each network interface for information at certain critical instances,
but beyond that, they should be regarded as means to get data from one
node to another in a frame, using one of the casting methodds (uni,
multi, broad, etc).
Then, if this is done, no IP address would ever be directly associated
with an interface. Instead, the routing table would maintain the
mappings. Then if nodes move, you simply update your routing table,
very rapidly of course, at stategic instances. This assumes an
assertion I made back in 1990: the day will come when almost all
computers are powerful enough to maintain routing tables, not just
routers. I think it is safe to say that that day has come.
(I also said the same thing about DNS trees, but that's a different
topic).
-Le Chaud Lapin-
| |
| Jeff Liebermann 2006-05-18, 11:48 pm |
| On Thu, 18 May 2006 23:29:53 GMT, John Navas
< spamfilter0@navasgro
up.com> wrote:
> The team consisted of just 12 people headed by William Lowe. They
> succeeded -- development of the PC took about a year.
(...)
As I recall, there were several IBM groups working on competitive
models of the IBM home computer in 1980. One was an Apple ][ clone.
Others were built in traditional IBM internal development models. The
whole process took about a year to the point where management met to
decide a single winner. When asked how long it would take to deliver
the product to manufacturing, the 5150 was the fastest because of use
of off the shelf parts and outsourced options (e.g. Epson printer).
Never mind elegance, just deliver it NOW.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
| |
| Jeff Liebermann 2006-05-18, 11:48 pm |
| On 18 May 2006 17:11:02 -0700, "Le Chaud Lapin"
< unoriginal_username@
yahoo.com> wrote:
>I've been doing some thinking about how to solve the mobility problem,
>and after much musing,I arrived at the conclusion that network
>interfaces should be regarded as dumb.
Brilliant. See:
http://en.wikipedia.org/wiki/Dumb_network
and David Isen's "Stupid Network" article:
http://www.isen.com/stupid.html
Incidentally, DHCP assumes that a network interface is dumb and feeds
it the numbers it needs to tell it how to act.
>This assumes an
>assertion I made back in 1990: the day will come when almost all
>computers are powerful enough to maintain routing tables, not just
>routers. I think it is safe to say that that day has come.
You're a bit late. Mesh networks have been around for quite a while.
Ricochet/Metricom had routeing in the pole tops in 1986 with Utilnet.
Rooftop Networks and many others have done the same with Wi-Fi. The
entire basis of mesh networking is an intelligent routeing mechanism,
which is often distributed into the nodes (poletops). Nothing new
here. Your day has arrived about 20 years late.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
| |
| Wrolf 2006-05-18, 11:48 pm |
| Why did TCP/IP win over OSI?
1) As I understand it, RFCs needed two interoperating implementations
before becoming standards. ISO standards were set first by well meaning
individuals, then implementations were attempted.
2) Many participants in OSI meetings were there to learn, not
contribute.
3) OSI standards were therefore pie in the sky - you only learned after
the standards were set that performance or reliability or other killer
problems had been baked in, or that there was an overwhelmingly simpler
way that any successful implementation would have uncovered.
4) The 7 layer model proved too complex, leading to many inefficiencies
and complexities (including multiple buffer to buffer copies).
We all thought that IP would give way to OSI. Then to IPv6 when OSI
became a clear loser, since the mandate of IPv6 was much smaller, and
the main difference was a longer address.
Then DHCP, RFC 1918, NAT, and provider based address allocation solved
the "1000 computers on the loading dock", "Dentist's office", and
Internet address space exhaustion problems that IPv6 was intended to
fix (at least for now).
So the net was that OSI never offered anything worth while, the issues
that IPv6 addressed are no longer pressing.
>it's not optimized for any particular application
TCP is very carefully optimized for two applications, telnet and ftp,
and generally for interactive style applications and bulk transfer
style applications. Nagle, Jacobsen, etc.
It is robust enough that HTTP/HTTPS just uses it without provoking any
need for further optimization. As does SMB/CIFS. NFS turned out to be
a big performance loser in WAN applications because the designers
decided to bypass TCP and use UDP - but only tuned it for LAN
applications, losing out on all the then current and future
optimizations.
IP was good, but we are certainly seeing a future need for the IPv6
agenda, plus mobility and a few other issues from
http://www.geni.net/research.php.
Wrolf
| |
| Le Chaud Lapin 2006-05-18, 11:48 pm |
| Jeff Liebermann wrote:
>
> You're a bit late. Mesh networks have been around for quite a while.
> Ricochet/Metricom had routeing in the pole tops in 1986 with Utilnet.
> Rooftop Networks and many others have done the same with Wi-Fi. The
> entire basis of mesh networking is an intelligent routeing mechanism,
> which is often distributed into the nodes (poletops). Nothing new
> here. Your day has arrived about 20 years late.
I was thinking of something more wholistic. A mesh network has N
nodes, and no matter how large N is, when you have a discussion about
it, everyone knows that N is a number significantly less than the total
number of nodes in the Internet.
A more comprehensive network would be one that provided mobility over
Wi-Fi, Bluetooth, Wi-Max, CDMA transceivers, satellite, infrared,
lasers, microwave, RS-232 RF transceivers, 802.15?, etc. and integrated
with any type of wired network, including the proverbial barbed-wire
network.
And it would have to work for the whole planet. And it would have to
maintain its sanity as the mobile travels down the road at 100km/hr, as
links are broken and reestablish rapidly. This would have to occur
over several hundred kilometers. As long as a connection of any kind
is available, it should work. It should only not work when there is no
possibility for a link.
The session-layer end-to-end connections would have to be maintained
the whole time (timeouts not withstanding), as the networks are broken
and restablish.
It should be possible to make new connections to the mobile node as it
moves, no matter what mess the mobile node got itself into with its
multiple wireless interfaces, at any instant.
The reassociation latency should be so low that VOIP and other
real-time applications should be uneffected.
It should work with large scale multicasting (> 1,000,000 nodes).
The mobile node should be able to roam on a golf cart, while the golf
cart roams on a ship, while the ship moves past a port that provides
Wi-Fi (or other) access. The routing should remain optimal to any
location on the planet.
I could go on, but you get the point. Real mobility has not yet been
done.
Should be interesting to watch if GENI gets it right.
-Le Chaud Lapin-
| |
| Anne & Lynn Wheeler 2006-05-18, 11:48 pm |
| "Wrolf" <wrolf@wrolf.net> writes:
> Why did TCP/IP win over OSI?
>
> 1) As I understand it, RFCs needed two interoperating implementations
> before becoming standards. ISO standards were set first by well meaning
> individuals, then implementations were attempted.
>
> 2) Many participants in OSI meetings were there to learn, not
> contribute.
>
> 3) OSI standards were therefore pie in the sky - you only learned after
> the standards were set that performance or reliability or other killer
> problems had been baked in, or that there was an overwhelmingly simpler
> way that any successful implementation would have uncovered.
>
> 4) The 7 layer model proved too complex, leading to many inefficiencies
> and complexities (including multiple buffer to buffer copies).
there were also organization issues ... ISO had a "rule" that you
couldn't have standards work on protocols that didn't confirm to the
osi model.
we had taken high-speed protocol proposal to x3s3.3 (ansi iso
chartered body repsonible for networking and transport layer). it
would go directly from transport to mac ... including support for
internetworking. it was rejected because
1) lan mac interface sits in the middle of layer 3, going directly
from transport to mac interface violated osi model by bypassing
layer 3/4 interface.
2) osi has no provisions at all for supporting internetworking ... so
anything that supported internetworking violates osi model
3) lan mac interface in the middle of layer 3 violates osi model,
so anything that interfaces to lan mac violates osi model.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
in some sense, osi was similar/analogous to the arpanet,
pre-internetworking ... having relatively homogeneous operation w/o
gateway and internetworking support.
i've frequently asserted that the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was larger than the arpanet/internet (from just about the beginning
until possibly mid-85) because the internal network had a kind of
gateway support in every node ... which arpanet didn't get until the
great switch-over to internetworking on 1/1/83.
misc. recent postings on the subject:
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006j.html#34 Arpa address
http://www.garlic.com/~lynn/2006j.html#45 Arpa address
http://www.garlic.com/~lynn/2006j.html#46 Arpa address
http://www.garlic.com/~lynn/2006j.html#49 Arpa address
http://www.garlic.com/~lynn/2006j.html#50 Arpa address
http://www.garlic.com/~lynn/2006j.html#53 Arpa address
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
| |
| Anne & Lynn Wheeler 2006-05-19, 2:48 am |
| "Wrolf" <wrolf@wrolf.net> writes:
> It is robust enough that HTTP/HTTPS just uses it without provoking any
> need for further optimization. As does SMB/CIFS. NFS turned out to be
> a big performance loser in WAN applications because the designers
> decided to bypass TCP and use UDP - but only tuned it for LAN
> applications, losing out on all the then current and future
> optimizations.
tcp has minimum 7 packet exchange, vmtp (rfc1045) has minimum
5 packet exchange, xtp has 3 packet exchange for reliable
communication
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
most tcp implementations assumed relatively few long running
sessions. http totally changed all that. as some of the webservers saw
increased load, some of them started finding 95+ plus processor cpu
being spent running FINWAIT list ... checking for dangling packets on
termination. it was crisis period for some webservers and required a
bit of rework to handle the situation.
we were called in to consult with this small client/server startup
that wanted to do payments on the server. we worked with them creating
and deploying a payment gateway and webservers communicating with the
payment gateway to do financial transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
this small client/server startup had this technology called https.
the way that https was suppose to work for e-commerce was that the
client typed in a host name url. the browser contacted a the server.
the server returned a ssl domain name digital certificate. the
browser verified the digital certificate and then cross checked that
the domain name (in the url typed in by the user) is the same as the
domain name in the returned digital certificate. if they matched, then
there was some assurance that the webserver that the person thot they
were talking to ... was in fact the webserver they were talking
to. this was a countermeasure to webserver impersonation/spoofing.
so what happened? relatively quickly, webservers found that https
reduced their processing capacity by 80-90percent ... that webservers
could support to 5-6 times more load if they just used http instead of
https.
so webservers changed to use plain http for the shopping experience
and saved https for the checkout/pay experience. the webserver
provides a button to click for checkout/pay that invokes https.
the issue here is that the button now provides the url for invoking
the https process. now it means that the url domain name provided
in the button from the webserver is matched against the domain
name in the digital certificate provided by the webserver. misc
past posts on ssl certificates
http://www.garlic.com/~lyn/subpubkey.html#sslcert
the process was suppose to check that the domain name provided by the
user matches the domain name provided by the webserver digital
certificate. now the processes checks that the domain name provided by
the webserver matches the domain name in the digital certificate
provided by the webserver. if it were really a fraudulent webserver
.... it would be an incompetent crook that wouldn't specify a domain
name in their checkout button that didn't correspond to the domain
name in the certificate they supply.
misc. postings discussing the change in SSL process negating the
original assumptions about what integrity was provided by SSL.
http://www.garlic.com/~lynn/aadsm19.htm#26 Trojan horse attack involving many major Israeli companies, executives
http://www.garlic.com/~lynn/aadsm20.htm#6 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005u.html#20 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
| |
| Jeff Liebermann 2006-05-19, 2:48 am |
| On 18 May 2006 18:45:48 -0700, "Le Chaud Lapin"
< unoriginal_username@
yahoo.com> wrote:
>Jeff Liebermann wrote:
[color=darkred]
>I was thinking of something more wholistic. A mesh network has N
>nodes, and no matter how large N is, when you have a discussion about
>it, everyone knows that N is a number significantly less than the total
>number of nodes in the Internet.
Welcome to capacity planning, queuing theory, and network simulation.
I used to do that 15 years ago (when things were simpler). The
basics: Every system has its limits. Systems can be broken by either
starving them or overloading them. Each component of a system has an
individual and often independent overload point. The ideal and most
efficient system is one where all the overload points occur
simultaneously. Overload capacity planning should be limited by
economics, not technology. That's all about as "wholistic" (it's
holistic) as I could possibly imagine. Now, how is a new and improved
protocol stack going to fit into such a system? Are you prepared to
optimize the components of your "wholeistic" solution? All I see is
trading one problem for another.
>A more comprehensive network would be one that provided mobility over
>Wi-Fi, Bluetooth, Wi-Max, CDMA transceivers, satellite, infrared,
>lasers, microwave, RS-232 RF transceivers, 802.15?, etc. and integrated
>with any type of wired network, including the proverbial barbed-wire
>network.
Is being "comprehensive" a customer defined requirement? I don't
think I've ever seen the term used on an RFC, proposal, bid, or
contract. The closest approximation is SDR (software defined radio),
where the ability to configure a radio in software allows rapid
switching between the aforementioned modes. To the best of my limited
knowledge, nobody is proposing that the SDR radio be optimized for any
of the items you've listed, or that it be able to handle all of them.
Comprehensive is beginning to sound more like "conglomerated".
>And it would have to work for the whole planet.
Suggestion: Instead of redefining the protocols and network model,
how about simply defining the RF communications technology that would
satisfy all the previously mentioned requirements. It would work at
any frequency, over any medium, comply with any FCC/ISO regulation,
and operate with any network protocol. It could be used for cellular,
mobile data, HF communications, FSO (free space optics), or Infra-red.
In other words, why stop at "fixing" the protocol stack when you can
redefine the communications medium? Totally "wholeistic" methinks.
All you have to do is change literally everything and convince a few
dozen regulatory fiefdoms that everything they're doing is wrong.
>And it would have to
>maintain its sanity as the mobile travels down the road at 100km/hr, as
>links are broken and reestablish rapidly.
Well, such an error detection and correction mechanism will be very
useful on noisy and unreliable channels as found in most RF
environments. However, it would massive overkill and a huge waste in
an environment that is fairly noise free, such as telephony. You
could use FEC (forward error correcting) which is great for one way
satellite channels, but horribly inefficient in its use of bandwidth
in other applications. Of course, this new protocol could be
self-adjusting, self-configuring, self-healing, and self-correcting.
However, this does not go well with your interest in reducing
complexity.
>This would have to occur
>over several hundred kilometers.
.... and also work over a few meters as in the current indoor Wi-Fi
LAN's. I guess self-adjusting timing should do that.
>As long as a connection of any kind
>is available, it should work.
Reality check. There many different types of noise and interference.
Building a universal noise and interference reduction mechanism is not
a trivial exercise. If you don't make an effort to reduce noise and
interference, you may have a "connection" of sorts, but no intact
packets will arrive.
>It should only not work when there is no
>possibility for a link.
So, it works at any S/N (signal to noise ratio)? Impressive if you
can do it. BER (bit error rate) is totally dependent on the
communications channel S/N ratio. The faster you shovel data through
the communications channel, the higher the S/N ratio has to be in
order to maintain a useable S/N ratio. For 802.11, the BER standard
is 1 glitch in 10^5 or 10^6 bits. Some vendors use a PER (packet
error rate) of 10^4 or 10^5 packets. You can communicate is very poor
S/N ratios, but you won't be going very fast (i.e. PSK31). In
wireless, *EVERYTHING* is a tradeoff.
>The session-layer end-to-end connections would have to be maintained
>the whole time (timeouts not withstanding), as the networks are broken
>and restablish.
Sounds more like you're complaining about your cell phone service.
Cellular can usually maintain a connection until something changes.
Usually, it's the driver moving out of range of one cell site, and
discovering the next cell site has no available channels. The same
thing happens in various ways on a wireless channel. As long as
nothing changes, you'll stay connected. Add more users, move a few cm
in any direction, nuke your dinner in the microwave, and the comm
channel turns to useless, and you drop the connection. I don't see
how you're going to maintain a connection in the presence of capacity
of all the multitude of things that can change the channel S/N ratio.
>It should be possible to make new connections to the mobile node as it
>moves, no matter what mess the mobile node got itself into with its
>multiple wireless interfaces, at any instant.
I just can't wait until someone tried UWB (3.1 to 10.6GHz) while
moving and re-discovers Doppler shift. Wheeee. Of course, your
self-adjusting protocol will instruct the MAC layer to tell the radio
to move slightly in frequency for one user.
>The reassociation latency should be so low that VOIP and other
>real-time applications should be uneffected.
That's what 802.11r (fast roaming) is trying to accomplish. It will
require synchronization between access points. That's easy enough in
a homogenous network of almost identical hardware. That impossible
with a tangle of proprietary devices, separated by random routers and
cross connected only through the internet. For example, the total
latency on my DSL connection is about 30msec. If I had to send a few
packets to my neighbors access point to allow you to fast switch from
mine ot theirs, it would take 60msec for the first packet to arrive.
Assuming a mess of packets are exchanged, it could easily take perhaps
500msec to switch. That's acceptable if you don't mine losing 2
syllables.
>It should work with large scale multicasting (> 1,000,000 nodes).
Ah, video over the internet. I can't wait. Reality check. Work out
the numbers for HDTV over DSL (at 1.5Mbits/sec).
>The mobile node should be able to roam on a golf cart, while the golf
>cart roams on a ship, while the ship moves past a port that provides
>Wi-Fi (or other) access. The routing should remain optimal to any
>location on the planet.
Ah, self-configuring again. Don't forget self authorization
(password) and self-authenticating (RADIUS) along with the usual
privacy mechanisms. It's been done already so there's nothing new
here. Whether any of the vendors want to do this is another question.
I'm sure the ISP's have some rather interesting opinions on the merits
of having your cell phone update their routing.
>I could go on, but you get the point. Real mobility has not yet been
>done.
Most of the cellular wireless data providers have done quite well with
wireless mobility.
>Should be interesting to watch if GENI gets it right.
They'll succeed only if they can offer at least a 2 times feature
benefit, 2 times cost benefit, or 2 times performance benefit. Doing
the same old things in a new and more elegant way, is not worth the
effort. Actually, I'm not sure 2 time is sufficient. I think the old
rule of thumb was that a competitor to IBM had to have a 4x advantage
or nobody would buy.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
| |
|
| Le Chaud Lapin wrote:
> Rich Grise wrote:
>
> 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.
>
Most of these people have jobs at companies and are expected to work on
what they are assigned, not what they feel is "neat".
| |
|
| Jeff Liebermann wrote:
> On 18 May 2006 11:35:39 -0700, "Le Chaud Lapin"
> < unoriginal_username@
yahoo.com> wrote:
>
>
> The messier it is, the better it works. I think I invented that line
> after dealing with far too many complaints about my lack of
> "elligance" in radio design. If it works ship it. If you ship it,
> it's already obsolete because the next two generations of replacement
> products are already in the pipeline.
>
> If elligance were a sellable commodity demanded by consumers and
> OEM's, you would probably have your way. It results in products that
> are full of compromises, band-aids, and marginal design. I don't buy
> a Bluetooth headset because it's "elligant". I buy it because it
> works adequately (and looks cool). If you don't like a product, just
> wait about 3 months for the replacement. Welcome to the 21st century.
>
> Also, please realize that what you consider to be a mess is the end
> result of considerable wrangling, haggling, debates, yelling, and
> minor violence on the part of the various standards committees,
> consortiums, forums (fora?), and conspiracies in smoke filled hotel
> rooms and overpriced restaurants. (I may have a photo somewhere of
> the restaurant table cloth on which SNMP was first conceived). The
> compromises involved are often not optimal for best design practices,
> such as where some member of the consortium refuses to contribute a
> patent or supply sane license terms. Of course, after the job is
> done, there's *ALWAYS* someone who thinks it could have been done
> better, but somehow didn't feel that it was important to either
> participate or offer their brilliance at the time when changes would
> have been possible. At that point, unless you found a fatal flaw or
> major issue, it's done and ossified in stone.
>
>
> Nifty. A plea for serial development, where each step of the process
> from conception to deliver is performed one step at a time.
> Conceptually, this is the most eligant way, resulting in the fewest
> bugs and complications. Unfortunately, both paying customers and
> boards of directors are rather impatient beasts. They want it *NOW*
> and are not willing to wait for serial development. So, the product
> development cycle degenerates into parallel development, where many
> engineers and programs are working with vaporware, emulators, science
> fiction technology, real-soon-now component deliveries, and impossible
> schedules. Welcome (again) to the 21st century.
>
>
> You haven't looked very hard. In the mid 80's, the OSI layer cake
> model was conceived to replace the lack of eligance found in Unix. A
> major problem with Unix was that networking was largely grafted into
> the kernel and was a rather bad fit. OSI networking would solve that
> by designing in the networking. It was largely conceived and
> implimented by academics and institutions. There was minimal industry
> participation. The design was de jure (in principle) instead of de
> facto (in practice). In other words, there was little testing.
>
> If you read the magazines of the day, everyone agreed that TCP/IP was
> on its way out, was badly designed, was not sufficient scaleable to
> survive much longer, and was going to be replaced by OSI model
> networking. Surveys of potential large network customers revealed an
> overwhelming interest in switching to an OSI model network.
>
> The first product to arrive was by 3com. 3com 3+share, 3+mail,
> 3+remote, etc was the first OSI (DOS based) product. Slowest piece of
> junk I've ever tried to sell and support. Here was the alleged answer
> to all of TCP/IP's lack of eligance and it looked like a giant step
> backwards.
>
> The addition of X.400 email addressing and X.500 directory services
> really made life miserable for the customers. Putting the routeing
> and header information in the email address was considered clever at
> one time. I guess none of the academics bothered to ask the users.
> X.500 was even worse. Nobody could understand how it worked or how to
> make it useful. It took LDAP and possibly AD to mostly clean up the
> applications and user interfaces. X.500 is a great example of extreme
> design elegance resulting in difficult implimentations.
>
> I'm not going to go into what went wrong with OSI networking. Lots of
> problems and corresponding allegations. It doesn't matter. What does
> matter is the OSI didn't solve any of the real user problems and
> didn't meet the market requirements. However, it wasn't a mess and
> was rather eligant.
>
>
> Well, there's some truth in that. If you have a spare moment, try to
> predict the applications and technology of perhaps 5 to 10 years from
> now. Write it down on a piece of paper and seal it in an envelope to
> be opened 5 to 10 years from now. I actually did that in about 1990
> and found myself wrong on just about everything.
>
I get the distinct feeling that Le Chaud Lapin has never participated in
a large scale "standards" effort. (Along with a lot of other folks.) I
was involved in efforts to standardize transactions between insurance
agencies and companies in the 80s. (Independent Property Casualty
Agencies and Companies to be precise. And trust me, it matters.) Typical
ground rules of these processes are:
Everyone is dedicated to mom, apple pie, and the betterment of mankind.
Everyone always tells the truth.
No one is out to sabotage a competitor.
Everyone is competent to discuss the matters at hand.
And if you believe this, I have a bridge ....
Thus standards look like the mess they are. When companies in your
industries who've never implemented even a trial of what you're working
on and have no plans to do so keep wanting to study things forever or
include things that will never be used, well at some point you have to
decide if you are going to fight for a pure great design or one you know
you can implement and get working.
It's an ugly, messing, cynical process behind the scenes with lots of
fake comradely for the "public face".
| |
|
| Don Taylor wrote:
> unoriginal_username@
yahoo.com writes:
> ...
> ...
>
> 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.
One of the understatements of the last few 1000 years. :)
| |
| William P.N. Smith 2006-05-19, 5:48 pm |
| Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> 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*|
| |
| Anne & Lynn Wheeler 2006-05-19, 5:48 pm |
|
"Le Chaud Lapin" < unoriginal_username@
yahoo.com> 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 Laye | | |