Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 850 nm solutions


There is nothing evil about economic and business considerations.  I recognize the economic advantage of developing silicon that
will work in multiple standards.  I recognize that the cost of talented personnel along with other manufacturing and competitive
issues tends to favor reduction of diversity.   I recognize that there may be individuals  in the P802.3ae TF that stand to benefit
directly, or whose company would benefit economically depending on how the standard is defined.  There is nothing evil about that.
As a customer, the only benefit that I or the company that I work for receives, is the manor in which the users would be enabled by
the standard.

As a customer who deploys very high bandwidth and extremely large networks, I want consistent standards, but I want them specialized
for the functions they are to perform.  Over the years, the larger vendors have created more "generalized", like Microsoft's Windows
NT.  For mediocre desktop and server usage it will do.  For people that require better or more reliable performance go to other
vendors and products.  While this may not have greatly effected Microsoft's market in low end systems, it has almost no share in the
very high end technology market.  10GbE is targeted at the high end technology market.  The 10GbE WAN compatible PHY is targeted for
an extremely large but very specialized market.  As a representative customer of that high end technology industry market, I would
prefer to have what I need in the standard, "up front".  Instead I may have to shop around for vendors that will deviate from  that
standard in order to deliver what is required, much like some large customers requiring vendors to support jumbo frames.  This was
also the comment by another customer concerning the need for short reach 10GbE interfaces.

The majority of the individuals in the P802.3ae TF are "LAN" people.  They understand the needs of a LAN only PHY.  There are some
that also work with WAN systems.  Both the "LAN" and "WAN" people recognize that the needs are different between LAN systems and WAN
systems.  An attempt to combine the LAN and WAN into one "UniPHY" will result in a standard that does not properly address the needs
of either the LAN or the WAN.

Last year, 1.6 terabit per second DWDM systems were field tested.  Those transport systems can provide 160 10GbE WAN channels per
fiber.  Internet content sites are increasing exponentially all over the world, with aggregated transport bandwidths getting into
the 10s of terabits per second per site.  Facilities floor space density is becoming a critical issue.  The port density as well as
per port bandwidth on data switches and servers is becoming a critical issue.  The complexity of intra-cluster port usage in storage
servers as well as data switches is becoming a critical issue.  All of this is leading to the need for data switches with multiples
of terabits per second in aggregate bandwidth per chassis, and interface cards with multiple 10Gb ports each.

The industry needs very condensed form factor equipment, the kind that will not need to have 18" of etch between the MAC and PCS.
The industry needs  a protocol that has as much bandwidth efficiency as possible because the transport signaling speed is fixed.
The industry needs transport operations and performance management based on existing systems so that it does not have to deploy
entirely greenfield operations support systems as well as untried greenfield transport technology.

It is the above reasons that I, as a customer, have taken a stand that XAUI should be 100% transparent as far as the standard is
concerned.  This will allow vendors in the future to build very high density systems, with small form factors per port, without the
additional symbol overhead that a non-transparent XAUI would put on non-XAUI MAC/PCS interfaces.  At the same time, a transparent
XAUI will allow vendors to build systems today that do need the extended etch distance.  As a customer, I have taken a stand that
the LAN PHY and the WAN compatible PHY should be separate tracks within P802.3ae, according to the objectives as written.  This will
allow for short reach block encoded parallel solutions for the LAN PHY and a single serial scrambled synchronous solution for the
WAN compatible PHY.  As a customer, I have also taken a stand that the SONET mapping proposal by Paul Bottroff and David Martin,
modified to allow for 10Byte IPG compression, be standardized instead of the 64B/66B block encoding for the WAN compatible PHY.
This will allow for the highest data transfer bandwidth available with the shortest amount of  time to market.

Thank you,
Roy Bynum

----- Original Message -----
From: THALER,PAT (A-Roseville,ex1) <pat_thaler@xxxxxxxxxxx>
To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; THALER,PAT (A-Roseville,ex1) <pat_thaler@xxxxxxxxxxx>; Rick Walker
<walker@xxxxxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Monday, May 01, 2000 7:05 PM
Subject: RE: 850 nm solutions

> Roy,
> This is a frustrating discussion. You seem intent on twisting what is said
> and implying evil actions. I did not say different groups developed Hari and
> XAUI. What I said is that the Infiniband TA did not develop Hari. I should
> know, I've been there from the beginning and in the Future IO before that.
> Over my career, I've seen a number of times when separate groups applied
> existing technologies to the same or similar problems and came up with
> similar solutions. For instance, there were about 4 proposals for 10BASE-T
> developed independently by different companies that when examined were
> almost identical. It wasn't because we co-developed them. It was because
> taking as a departure point what we had learned about twisted-pair cable
> as an industry and applying that to how to run Manchester code over it,
> a certain direction was fairly attractive and 4 out of 6 companies
> investigating
> it came up with very similar solutions. There were minor differences such as
> the
> choice of where to put the equalizer, but mostly it was the same solution.
> That is the source of much of the "commonality" to which you refer.
> "Hari" was developed with Ethernet in Fibre Channel in mind (to the best of
> my
> understanding; I did not work in that group). But Hari as a name really
> didn't fit into the names 802.3 has used for interfaces. Therefore, a
> proposal
> based on the Hari work suggests "XAUI" as a name that does fit in with
> traditional Ethernet interface names.
> I have no idea what you are talking about when you talk about different
> groups with the same people. Your statement about voting blocks is totally
> unjustified and offensive.
> Sincerely,
> Pat Thaler