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

Re: [HSSG] re LAGs just have an unfortunate statistical problem designed in...

Piers-

At 10:34 AM 8/24/2006 , DAWE,PIERS wrote:
(Geoff, you may not want to spend time personally answering all these questions.  This topic still needs a presentation!)
 
For the benefit of everyone who wasn't involved in Clause 43:
 
What load balancing problem?  If a sender (aggregating MAC) has 4 possible paths available, it can distribute packets round-robin wise or according to which path has the lowest queue in its output buffer, or other...  What does this scheme do?  Is some kind of virtual path allocation involved?
 
I would imagine there might be more of a problem at reception; knowing how to reassemble the pieces in the right order.

Nope. the assumption was that you did not need to know the distribution scheme for reception (thus, you did not need to know the balancing scheme for interoperability). It is received are muxed into the single stream in the order received received. If that results in misordered packets from a single stream on the transmit side then that is the fault of the distribution scheme. It is common to look into the packets to identify TCP streams, thus my earlier comment.

 
What exactly is the problem with encryption?  Is the whole stream encrypted so the frame boundaries are not visible? 

Nope, it is that you have to identify streams

If not; what does one need to read the frame for?  If it's got as far as the aggregating MAC, there's only the peer aggregating MAC it can be destined for.

It is to make sure that things don't get mis-ordered. Otherwise there is a potential for short packets to sling-shot around long ones.

 
"Minimum granularity is one frame"
Why is this a problem that is not generic to Ethernet?
If it were a problem at 1G, is it still a problem at 10G or 40G?
Does this relate to the cost-of-buffers conversation recently on this reflector?

None of the above. PHY aggregation lets you balance at a code group or coding level instead of a packet level, Thus it avoids the stick packet stream balancing problems.

Geoff

 
Piers
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
Sent: 24 August 2006 17:07
To: DAWE,PIERS
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] re LAGs just have an unfortunate statistical problem designed in...
Piers-

It is really pretty simple.
We completely punted on addressing the distribution load balancing problem when we developed LAG on the theory that:
The proprietary mechanisms generally had to: Thus owners of VLANs were offended and encrypted traffic was resistant to the peeking.

And, lastly, with LAG your minimum granularity is a complete frame

I hope this helps.

Geoff

At 07:59 AM 8/24/2006 , DAWE,PIERS wrote:
John,

I hope you have someone lined up to give the study group a teach-in on what this problem is, what kinds of traffic it afflicts, what alternatives are out there and how the 802.3 Cl.43 LAG with its statistical problem might be fixed/avoided/substituted for.

Thank you!

Piers

> -----Original Message-----
> From: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx]
> Sent: 23 August 2006 23:58
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reliability or relative reliability objective?
>
>
> Just to add my $.02, do people see 802.3ad LAGs as adding additional
> "configurations" or creating interoperability problems? I see it as
> adding nice scaling capabilities that in fact increase
> volumes and hence
> economies of scale. LAGs just have an unfortunate statistical problem
> designed in...
>
> Drew
> _____________________________
> 
> Drew Perkins
> Chief Technology Officer
> Infinera Corporation
> 1322 Bordeaux Drive
> Sunnyvale, CA  94089
> 
> Phone:  408-572-5308
> Cell:       408-666-1686
> Fax:        408-904-4644
> Email:    dperkins@xxxxxxxxxxxx
> WWW :  http://www.infinera.com
> 
>
> _____________________________
> 
>
> -----Original Message-----
> From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
> Sent: Wednesday, August 23, 2006 2:57 PM
> To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> Subject: Re: [HSSG] Reliability or relative reliability objective?
>
> Not to disagree too strongly with Piers...
>
> But...
> The more configurations we have, the less economy of scale and
> guaranteed
> interoperability we have.
>
> Geoff
>
>
> At 12:17 PM 8/23/2006 , DAWE,PIERS wrote:
> >Also it allows a graceful growth plan, which gives the whole project
> some
> >relevance.
> >
> >If you bought a new HSSG-compliant box with a big MAC, you could buy
> just
> >one XFP to let it talk to your old box with its 10G ports. 
> Later, you
> can
> >buy a wavelength mux and a second and third XFP...  Just like the way
> DWDM
> >networks grow their capacity.  You can buy the second new box before
> the
> >second XFP (use the new smarter lane bonding) or after (use
> 802.3 Cl.43
>
> >link aggregation or a proprietary alternative until you buy
> the second
> box).
> >
> >Now if you knew you had most of 80 Gb/s of traffic on a route today,
> you
> >could find someone who would sell you 8 lasers in a box.  It
> might not
> be
> >cheaper, but it would be more compact, which could make it
> >worthwhile.  (Or relatively worthwhile if the big MAC were expensive
> and
> >you would never have bought it without buying the second box and at
> least
> >several lasers at each end.)
> >
> >I expect that over a portfolio of various sized routes, the
> >pay-as-you-grow approach would be more cost-effective, for most
> networks.
> >
> >This is not to say that purchasing lasers in groups, like 6-packs of
> beer,
> >is bad.  But I think it's a mechanical partitioning choice, not
> something
> >for 802.3 to require.
> >
> >I do not believe a proposed standard that REQUIRES the big
> MAC and the
> >6-pack of lasers could have Broad Market Potential (which I
> define as a
>
> >balance of market size to NRE so that the market would
> support several
> >vendors and several customers, up and down the food chain).  But a
> >proposed standard that allows the really untypical "power users" to
> deploy
> >the big MAC and the 6-pack of lasers, but also offers
> something to the
> >wider market, may.
> >
> >Piers
> >
> > > -----Original Message-----
> > > From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx]
> > > Sent: 23 August 2006 19:10
> > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > > Subject: Re: [HSSG] Reliability or relative reliability objective?
> > >
> > > Jugnu,
> > >
> > > I agree that it has value in this context.
> > >
> > > Thanks,
> > > Menachem
> > >
> > > -----Original Message-----
> > > From: OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
> > > Sent: Wednesday, August 23, 2006 2:04 PM
> > > To: mabraham@xxxxxxxxxxxxxxxxxxxx;
> STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > > Subject: RE: [HSSG] Reliability or relative reliability objective?
> > >
> > > Menachem,
> > >
> > > I think this is a very good reason to have a graceful
> > > degradation mechanism
> > > - i.e., if one channel fails, continue to operate over the
> > > others at reduced
> > > bit rate.  This would come for free in a scalable solution.
> > >
> > > Jugnu
> > >
> > > -----Original Message-----
> > > From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx]
> > > Sent: Tuesday, August 22, 2006 5:00 PM
> > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > > Subject: [HSSG] Reliability or relative reliability objective?
> > >
> > > All,
> > >
> > > Has IEEE 802 set reliability (MTBF) objectives in any of the
> > > past projects?
> > >
> > > The multi-lane approach assumed in HSSG raises some questions
> > > in this regard
> > > when compared to our tradition.
> > >
> > > When we went from 1G to 10G optical interfaces we still had
> > > one laser, one
> > > PIN diode, one transimpedance receiver preamplifier etc etc. These
> > > components moved up in their cutoff frequencies but the
> > > number of components
> > > was in the same order of magnitude and therefore the MTBF and
> > > reliability
> > > was expected to be similar.
> > >
> > > In contrast, going from 10G to 100G by using 10 x 10G
> lanes implies
> a
> > > reduction in reliability by a factor of 10.
> > >
> > > This consideration combined with the cost concern related to
> > > 10 x 10G lane
> > > approach (10 lasers, 10 PIN diodes etc) causes me to think that it
> is
> > > important to keep an open mind regarding the number of lanes
> > > and the speed
> > > of each one of these lanes.
> > >
> > > Thanks,
> > > Menachem
> > > Menachem Abraham
> > > Columbus Advisors
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: "Drew Perkins" <dperkins@xxxxxxxxxxxx>
> > > Date: Wed, 23 Aug 2006 00:01:45
> > > To:<mabraham@xxxxxxxxxxxxxxxxxxxx>,
> > > <STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx>
> > > Subject: RE: [HSSG] Reach Objectives
> > >
> > > Menachem,
> > >
> > >
> > >
> > > I think we need to differentiate between what PMDs we specify
> > > and what other
> > > PMDs we enable. For instance, I don't think it is the IEEE's place
> to
> > > specify an ULH PMD in terms of the optical specifications.
> > > However, this
> > > could be one of the more important applications of a HS
> > > Ethernet. So I think
> > > it would be worthwhile for us to enable vendors to develop it in a
> > > straightforward fashion. Thus I think we should get into some
> > > of the details
> > > that you mention including:
> > >
> > > 1.    PHY layer - what degree of compatibility with
> LAN-PHY, WAN-PHY
> > > (SONET/SDH), and/or G.709 is desired?
> > >
> > > 2.    What amount of differential delay (skew) will be
> > > allowed? What will be
> > > mandated for all conformant implementation?
> > >
> > >
> > >
> > > It is clearly desirable to maintain compatibility with
> today's DWDM
> > > transponders. This is a specific goal of some carriers that are
> > > participating in this process. Carriers would love to have a
> > > PMD option that
> > > leverages the 10G LAN-PHY or WAN-PHY. Of course this will
> > > depend on the
> > > answers to these questions and other decisions we make.
> > >
> > >
> > >
> > > Many (I believe most) DWDM systems on the market now support
> > > the LAN-PHY
> > > natively by simply speeding up the G.709 OUT to run at
> > > ~11Gb/s instead of
> > > 10.7Gb/s rather than by doing some sort of overhead
> compression into
> > > SONET/SDH or the G.709 digital wrapper.
> > >
> > >
> > >
> > > Drew
> > >
> > > _____________________________
> > >
> > >
> > >
> > > Drew Perkins
> > >
> > > Chief Technology Officer
> > >
> > > Infinera Corporation
> > >
> > > 1322 Bordeaux Drive
> > >
> > > Sunnyvale, CA  94089
> > >
> > >
> > >
> > > Phone:  408-572-5308
> > >
> > > Cell:       408-666-1686
> > >
> > > Fax:        408-904-4644
> > >
> > > Email:    dperkins@xxxxxxxxxxxx
> > >
> > > WWW :  http://www.infinera.com
> > >
> > >
> > >
> > >
> > >
> > > _____________________________
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > >  From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx]
> > >  Sent: Tuesday, August 22, 2006 5:00 PM
> > >  To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > >  Subject: Re: [HSSG] Reach Objectives
> > >
> > >
> > >
> > > Geoff,
> > >
> > >
> > >
> > > Thanks for your comments.
> > >
> > >
> > >
> > > I also believe that our efforts should focus on distances no
> > > higher than
> > > 10's of Km (up to and including metro).
> > >
> > >
> > >
> > > If we decide as a group that it is an objective to make it
> > > easy to hook into
> > > LH and ULH transport systems in the installed base, we will
> > > have to study a
> > > number of issues such as:
> > >
> > >
> > >
> > > (A) should we pick a data rate that is matching SONET rates?
> > >
> > > (B) should we design our 802.3 std so that it tolerates a much
> larger
> > > inter-lane differential delay than what would be expected
> in a metro
> > > application of the standard?
> > >
> > > (C) should we assume we never go through existing LH
> > > transponders and just
> > > have to COEXIST on the same fiber, optical amplifiers, dispersion
> > > compensators located in the huts, optical mux demux at both ends
> etc.
> > >
> > > Etc. In this case we would assume a new type of LH tranponder
> > > purpose built
> > > for HSSG applications.
> > >
> > > If this is the case, SONET rate compatibility would not be
> important.
> > >
> > >
> > >
> > >
> > >
> > > Today's 10G LH and ULH system run mostly at OC-192 rates plus
> > > FEC overhead.
> > > Chip vendors were creative and managed to find ways to build
> > > devices that
> > > pack into these solutions the full 10G LAN data rate even
> > > though OC-192 is
> > > less than 10G.
> > >
> > > I think (but I may be wrong) that they use available bandwidth in
> the
> > > management bits available in Digital Wrapper or something
> like that.
> > >
> > > Not clean but seems to work...
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Menachem
> > >
> > > Menachem Abraham
> > >
> > > Columbus Advisors
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > >
> > > From: "Geoff Thompson" <gthompso@xxxxxxxxxx>
> > >
> > > Date: Tue, 22 Aug 2006 16:09:11
> > >
> > > To:mabraham@xxxxxxxxxxxxxxxxxxxx
> > >
> > > Cc:STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > >
> > > Subject: Re: [HSSG] Reach Objectives
> > >
> > >
> > >
> > > Menachem-
> > >
> > >
> > >
> > >  Thanks for your much more specific answer to the question.
> > > I'm afraid that
> > > my earlier answer was handicapped by my ignorance of the
> > > specifics of that
> > > market.
> > >
> > >
> > >
> > >  Based on what you said, I believe the questions for us to
> > > consider or not
> > > are:
> > >
> > >
> > >
> > > a) Will we consider long haul solutions.
> > >
> > > OR
> > >
> > > b) Will we limit ourselves to metro solutions and "transport
> > > end" (i.e.
> > > stuff that hooks into the transport infrastructure) solutions.
> > >
> > > Back in the old days of 10Gig we spent an awful lot of time
> > > discussing the
> > > need for the WAN PHY to address case "b)". I think most of us
> > > didn't get it
> > > then. I would hope that with a different cast of characters
> > > involved in the
> > > discussions that we (or at least I, for one) could come out
> > > with a clear
> > > rationale for what we choose.
> > >
> > >
> > >
> > >  (Just FYI, I believe the crux of the issue came down to
> > > whether or not one
> > > could have a 2 port bridge, as opposed to an
> > > Optical-Electrical-Optical
> > > repeater in a Transport Chassis.)
> > >
> > >
> > >
> > >  None the less, I believe that my proposed answer stands. We
> > > don't need to
> > > tackle this issue in the first set of objectives and projects.
> > >
> > >
> > >
> > >  I do remain interested (old repeater hack that I am) in
> > > looking into an
> > > O-E-O repeater that does not necessarily come all the way
> > > back up to the
> > > level of reassembling the full packet.
> > >
> > >
> > >
> > >  Geoff
> > >
> > >
> > >
> > >  At 01:30 PM 8/22/2006 , Menachem Abraham wrote:
> > >
> > >  All,
> > >
> > >
> > >
> > >  If we decide to include in our reach objectives Long Haul
> > > (e.g. 1000 km
> > > with
> > >
> > >  optical amps placed at 80 Km spacing) and Ultra Long Haul
> > > (e.g. 3000 Km
> > > with
> > >
> > >  optical amps at 80 Km spacing, without Optical-Electrical-Optical
> > >
> > >  regeneration), we need to keep in mind that
> > > modulation/encoding/FEC choices
> > >
> > >  play an important role in how far we can go on an optical
> > > amplifier based
> > >
> > >  line system. Such PMD designs may be too costly for our < 80Km
> > >
> > >  applications/objectives so we may end up with more PMDs.
> > >
> > >
> > >
> > >  While there are some examples of Routers / Switches which
> > > have LH or ULH
> > >
> > >  optical interfaces built in, most systems use Routers / Switches
> with
> > >
> > >  shorter reach interfaces connected to separate Transport
> > > Chassis that house
> > >
> > >  proprietary LH or ULH solutions. As far as I know the LH and
> > > ULH world does
> > >
> > >  not have interoperable standard solutions today in terms of
> > > the signaling
> > > on
> > >
> > >  the fiber.
> > >
> > >
> > >
> > >  My input for our activities in HSSG is to optimize for cost
> > > and not require
> > >
> > >  that one of our PMDs be directly useable as part of a LH or
> > > ULH line system
> > >
> > >  (unless that is doable without incremental cost).
> > >
> > >
> > >
> > >  Having said that, I believe we should debate the need to
> > > address "ease of
> > >
> > >  HSSG data transport" on top of existing and emerging LH and
> > > ULH transport
> > >
> > >  systems. If this debate already happened as part of the 10G
> > > 802.3 standard
> > >
> > >  development and the conclusions apply here, perhaps somebody
> > > can educate
> > >
> > >  those of us who were not involved at that time.
> > >
> > >
> > >
> > >  Thanks,
> > >
> > >  Menachem
> > >
> > >
> > >
> > >
> > >
> > >  -----Original Message-----
> > >
> > >  From: Aaron Dudek [mailto:adudek@xxxxxxxxxx:
> > > <mailto:adudek@xxxxxxxxxx> ]
> > >
> > >  Sent: Tuesday, August 22, 2006 12:50 PM
> > >
> > >  To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > >
> > >  Subject: Re: [HSSG] Reach Objectives
> > >
> > >
> > >
> > >  Geoff,
> > >
> > >  Shouldn't the migration to ULH systems have any impact on
> > > the spacing
> > >
> > >  and hence be taken into consideration? Or is that beyond the
> > > scope for
> > >
> > >  now?
> > >
> > >
> > >
> > >  Aaron Dudek
> > >
> > >  (703) 689-6879
> > >
> > >  Sprintlink Engineering
> > >
> > >  adudek@xxxxxxxxxx
> > >
> > >
> > >
> > >
> > >
> > >  On Tue, 22 Aug 2006, Geoff Thompson wrote:
> > >
> > >
> > >
> > >  > Roger-
> > >
> > >  >
> > >
> > >  > At 03:47 AM 8/22/2006 , Roger Merel wrote:
> > >
> > >  >
> > >
> > >  >       Agree with Drew.  Have a few additional comments on
> > > other reachs:
> > >
> > >  >
> > >
> > >  >       For reach objectives, we should start with customer
> > > based needs
> > > (for
> > >
> > >  broad market potential) and only amend if an
> > >
> > >  >       obvious technical limitation with compelling
> economics can
> t
> > > readily
> > >
> > >  meet the broad customer need.
> > >
> > >  >
> > >
> > >  >       Specifically:
> > >
> > >  >
> > >
> > >  >       - Long Reach probably should be set at 80km rather
> > > than 100km (as
> > >
> > >  this is the common hut-to-hut amplifier spacing
> > >
> > >  >       in telecom)
> > >
> > >  >
> > >
> > >  >       - While 50m does serve a useful portion of the
> > > market (smaller
> > >
> > >  datacenters and/or the size of a large computer
> > >
> > >  >       cluster), it is somewhat constraining as I ve
> been lead to
> > >
> > >  understand that the reach needed in larger datacenters
> > >
> > >  >       is continuing to out-grow the 100m meter definition
> > > but the 100m
> > >
> > >  definition at least serves the customer well.
> > >
> > >  >       Certainly 10G-BaseT worked awfully hard to get
> to 100m (for
> > >
> > >  Datacenter interconnect).
> > >
> > >  >
> > >
> > >  >
> > >
> > >  > I wouldn't attach a lot of creedence to the 10GBASE-T goal for
> 100
> > > meters.
> > >
> > >  It was, I believe, mainly driven by the
> > >
> > >  > traditional distance in horizontal (i.e. wiring closet to
> desktop)
> > >
> > >  distances rather than any thorough examination of data
> > >
> > >  > center requirements.
> > >
> > >  >
> > >
> > >  > Geoff
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       - For both in-building reaches (50m & 300m; or 100m
> > > & 300m), the
> > >
> > >  bigger issue which affects the PMD is the loss
> > >
> > >  >       budget arising from the number of patch panels.  The
> > > shorter /
> > >
> > >  datacenter reach should include a budget for 1
> > >
> > >  >       patch panel.  The longer / enterprise reach should
> > > include a budget
> > >
> > >  for 2 patch panels (one in the datacenter and
> > >
> > >  >       1 in the remote switch closet).
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       From: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx:
> > > <mailto:dperkins@xxxxxxxxxxxx> ]
> > >
> > >  >       Sent: Tuesday, August 22, 2006 1:24 AM
> > >
> > >  >       To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > >
> > >  >       Subject: Re: [HSSG] Reach Objectives
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       John,
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       I suggest dividing Metro into Metro Short Reach at 10 km
> > > (equivalent
> > >
> > >  application to 10GBASE-LR) and Metro
> > >
> > >  >       Intermediate Reach at 40 km (equivalent application
> > > to 10GBASE-ER).
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Drew
> > >
> > >  >
> > >
> > >  >       _____________________________
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Drew Perkins
> > >
> > >  >
> > >
> > >  >       Chief Technology Officer
> > >
> > >  >
> > >
> > >  >       Infinera Corporation
> > >
> > >  >
> > >
> > >  >       1322 Bordeaux Drive
> > >
> > >  >
> > >
> > >  >       Sunnyvale, CA  94089
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Phone:  408-572-5308
> > >
> > >  >
> > >
> > >  >       Cell:       408-666-1686
> > >
> > >  >
> > >
> > >  >       Fax:        408-904-4644
> > >
> > >  >
> > >
> > >  >       Email:    dperkins@xxxxxxxxxxxx
> > >
> > >  >
> > >
> > >  >       WWW :  http://www.infinera.com:
> <http://www.infinera.com/>
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       _____________________________
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >
> > > ______________________________________________________________
> > > _____________
> > > _
> > >
> > >  ________________________________________________________
> > >
> > >  >       From: John DAmbrosia
> [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx:
> > > <mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx> ]
> > >
> > >  >       Sent: Monday, August 21, 2006 9:38 PM
> > >
> > >  >       To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> > >
> > >  >       Subject: [HSSG] Reach Objectives
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       All,
> > >
> > >  >
> > >
> > >  >       We have had some conversation on the reflector
> > > regarding reach
> > >
> > >  objectives.  Summarizing what has been discussed
> > >
> > >  >       on the reflector I see the following
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Reach Objectives
> > >
> > >  >
> > >
> > >  >       Long-Haul   --> 100+ km
> > >
> > >  >
> > >
> > >  >       Metro       --> 10+ km
> > >
> > >  >
> > >
> > >  >       Data Center --> 50m & 300m
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Data Center Reach Segregation
> > >
> > >  >
> > >
> > >  >       Intra-rack
> > >
> > >  >
> > >
> > >  >       Inter-rack
> > >
> > >  >
> > >
> > >  >       Horizontal runs
> > >
> > >  >
> > >
> > >  >       Vertical risers
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Use this data to identify a single low-cost solution
> > > that would
> > >
> > >  address a couple of the reach objectives
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Other Areas
> > >
> > >  >
> > >
> > >  >       During the course of the CFI there were individuals
> > > who wanted
> > >
> > >  Backplane Applications kept in for consideration,
> > >
> > >  >       but I have not heard any further input in this area.
> > >  Are there
> > >
> > >  still individuals who wish to propose Backplane
> > >
> > >  >       as an objective?
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       John
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >
>