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

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
> 
> 
>