Re: [RE] Stream identification at the MAC SAP

[Richard Brand <rbrand@xxxxxxxxxxxxxxxxxx>]

Michael:
Since all of the Nat Semi NDA's have now expired I'm sure, let me correct
your explanation.  Nat Semi had a project which was funded by a major
computer company to develop an Ethernet based NIC for the forthcoming Power
PC platform.  You may even remember the CRHP sessions.  One of
the major new capabilities of the PPC was to allow users to communicate
using their PPC's not only with voice but also via a derivative of H.320
desktop videoconferencing (this was prior to H.323) which was a required
app to support on the NIC.  For this app even Microsoft was involved
by providing the telephony API extension now known as TAPI and NetMeeting
was targeted as the collaborative application incorporating the TAPI work. 
Apple and IBM had set up joint companies here in California to develop
real time apps for the platform.  I believe Kalida was one of those. 
The other was across the street from the Apple headquarters.  The
incAlliance was formed to hold the whole thing together but factionalization
inside of the individual companies caused major dissension.  In retrospect
it was too large a project to manage.
So the real application was not just legacy telephone PBX's but audio-video
telephony based on LAN like hubs.  No PBX was required and in fact
the concept was seen as a threat to some in the PBX industry, especially
to key systems if the desktop video application took off which it did not. 
The battle that was raging at the time was ATM vs Ethernet to the desktop
and the PBX vendors were all developing ATM based solutions to provide
for telephony and real time PC capable apps to compete with the rapidly
growing Ethernet based companies like 3COM and Bay Nets.  Cisco was
still a minor player in L2.  Fast Ethernet killed all that and the
battle of the access choice for the desktop data connection was over for
ATM.  However, Michael is right in saying that this just lead to the
installation of two separate wiring systems as you really needed cat 5
wire for Fast Enet so there still was no convergence.  
As I noted earlier, there were many issues which caused 802.9a &
b to fail, mostly corporate greed and stupidity in holding onto patented
technology.  But the industry push for video enabled real time applications
on both 802.3 and 802.11 networks continues as global connectivity has
come of age and there is still not a good solution for real time apps or
even high quality stored audio and video content to support a level of
QoE that our customers will pay real money for.
This is what we described in the CFI and that is the challenge of the
Residential Ethernet SG.   I have seen most if not all of the
higher layer solutions applied to Ethernet and .1 bridges which attempt
to solve the problems.  The residential alliances continue to struggle
with these problems.  Let's find the way to have 802.3 solve the problems
and move on.
See you next week.

Michael Johas Teener wrote:

Richard can fill you all in, if you are really interested, but the real reason 802.9 didn’t go anywhere had more to do with it’s intended market: as a high-performance link for telephone systems. Its isochronous services were limited to muxing standard telephone ISDN channels on top of 10Mbit Enet. It was an OK idea at the time, but since the isoch services depended on PBX support it was a very odd hybrid system. PBX companies did not embrace it, so the world ended up with two parallel wiring systems: one for telephones and one for the LAN. The telephone systems, being highly centralized, were not amenable to the kind of incremental growth that the LAN part of the universe (to get a significant telephone network upgrade, an enterprise had to buy a whole new PBX, a rather expensive proposition).

Oddly enough, with Residential Ethernet (at least the way some of us have been envisioning it), you could really toss the PBX out the window without losing any quality of service.

Anyway, it’s unfortunate that 802.9 is sometimes called an isochronous LAN, because it never was. It was, instead, a hybrid LAN/Telephone network, an entirely different beast.

On 11/11/04 5:36 PM, "Matt Squire" <MSquire@HATTERASNETWORKS.COM> wrote:

So, there was a bunch of work on trying to make isochronous LANs in the IEEE, and now all of that work is in hibernation and not in use.

Maybe that says something.

- Matt

--
---------------------------------------------------------------
                   Michael D. Johas Teener
http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
--------------------- www.plumblinks.com ----------------------