Re: 850 nm solutions
Here is my involvement, as a participant in the InfiniBand effort I
know we always strive for building block commonality and re-use. When
Pat tried to clarify that, she got entangled in PHY conspiracy
theories.
I hope this clarification does not get me entangled as well.
Ariel
> From: "Roy Bynum" <rabynum@xxxxxxxxxxxxxx>
> To: "Ariel Hendel" <Ariel.Hendel@xxxxxxxxxxx>, <pat_thaler@xxxxxxxxxxx>, <stds-802-3-hssg@xxxxxxxx>
> Subject: Re: 850 nm solutions
> Date: Fri, 5 May 2000 08:59:00 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
>
> 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
> > >
> > >
> > >
> >
>