Re: 850 nm solutions
Ariel,
I am not sure what your involvement in this is. It was never my intention to accuse anyone individually on this reflector. If I
gave the impression to Pat, or others, that I was accusing her individually, of collusion in block voting, I do apologize to her
individually. Thank you for pointing out a potential false impression.
Thank you,
Roy Bynum
----- Original Message -----
From: "Ariel Hendel" <Ariel.Hendel@xxxxxxxxxxx>
To: <pat_thaler@xxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>; <rabynum@xxxxxxxxxxxxxx>
Sent: Wednesday, May 03, 2000 12:00 PM
Subject: Re: 850 nm solutions
> Roy,
>
> Your informercial is all nice and good, but where is the apology to Pat
> Thaler for accusing her of collusion and block voting?
>
>
>
> Ariel
>
>
> > From: "Roy Bynum" <rabynum@xxxxxxxxxxxxxx>
> > To: "THALER,PAT (A-Roseville,ex1)" <pat_thaler@xxxxxxxxxxx>, <stds-802-3-hssg@xxxxxxxx>
> > Subject: Re: 850 nm solutions
> > Date: Wed, 3 May 2000 00:27:35 -0500
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
> > X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > X-Listname: stds-802-3-hssg
> > X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> >
> >
> > Pat,
> >
> > 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
> >
> >
> >
>