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,
 
I am planning to make a presentation that will explain
the behavior, benefits, and shortcomings of 802.3ad
Clause 43 Link Aggregation.
 
Lest any one think that I am an anti-LAG bigot, let
me dispel that notion up front. I was one of the early
proponents of LAG, and I still think that it is a useful
and important part of IEEE Std 802.3.  In situations
where an aggregated link is carrying the aggregated 
traffic of many conversations (or flows, or whatever you 
would like to call them) simultaneously, LAG performs 
well.
 
With LAG, the packets associated with a given conversation
will all be transmitted on a single link, in order to
preserve temporal ordering. The throughput of some
upper layer protocols can be seriously degraded if
packets arrive out of order. While it is possible to
reorder packets at a receiver, this requires a) large
receive buffers, b) inspection of the packets deep into
the header (which may be precluded if the packets are
encrypted, as Geoff points out), and c) quite a bit of time. 
For this reason, the LAG "distributor" is specifically 
constrained to ensure that all packets associated with 
a given conversation are transmitted in order on the same 
link.  See 43.2.1 (f):
 
  Frame ordering must be maintained for certain sequences 
  of frame exchanges between MAC Clients (known as conversations, 
  see 1.4). The Distributor ensures that all frames of a given 
  conversation are passed to a single port. For any given port, 
  the Collector is required to pass frames to the MAC Client
  in the order that they are received from that port. The 
  Collector is otherwise free to select frames received from 
  the aggregated ports in any order. Since there are no means 
  for frames to be mis-ordered on a single link, this guarantees 
  that frame ordering is maintained for any conversation. 
 
Thus, since all of the packets from a given conversation must
be transmitted on a single link, LAG only provides an increase
in bandwidth if there are multiple conversations being carried
across an aggregated link simultaneously. However, there are 
many situations where an aggregated link is not simultaneously 
carrying the packets from multiple conversations. A good example
of this would be a large file transfer.  If you were trying to
copy a large file from a server using FTP (for example) then all
of the packets associated with that file transfer would be
considered part of the same conversation. In this case, the file
transfer speed would be limited to no more than the speed of an
individual link in an aggregation.

Even when an aggregated link is carrying multiple conversations,
the packet transmissions associated with the conversations must
be simultaneous for LAG to provide a throughput gain. One could
argue that inter-exchange links carry such traffic, and this is
in fact one of the applications where LAG does provide increased
throughput. None-the-less, the throughput gain is almost never
a linear increase.

So, while LAG is a good thing and has enjoyed some success, it
does not truly behave like a higher speed pipe. Some have suggested
the idea (although not on this reflector) that we could add a
sequence number to each packet, so that a receiver could easily
perform the reordering. This is inadvisable for several reasons.
First, it would require a change to the MAC frame format. Second,
reordering on a packet basis will involve the large buffers and 
long latencies that I mentioned above. Third, it would probably 
instigate a major controversy with our brethren in 802.1. All
three of these points are show stoppers as far as I am concerned.

This has led me and several others to investigate the concept of
Aggregation at the Physical Layer (or APL, as John has dubbed it).
With APL, packets can be broken up into small chunks and distributed
across an arbitrary number of physical links, and then reassembled
at the receiver. Because the chunks are much smaller than a maximum
sized packet, the buffer requirements and latency through the receiver
are much smaller. Also, the chunks (or fragments, or words, or 
whatever you would like to call them) can be of more or less fixed 
size, and distributed evenly across the physical links. This will
ensure that the throughput of the APL link increases linearly as
the number of links is increased.

There are other benefits of APL, as several people have already
pointed out. The biggest benefit that I can think of is that
we can reuse the Physical layer specifications and technology
and interfaces from 10 Gigabit Ethernet. To my thinking, this 
will provide the shortest path to standardization, deployment, 
and widespread adoption. I do not want to discourage work on higher 
serial speeds, but I sincerely hope that we give serious consideration 
to the concept of APL, and that this work goes forward as a standards
development project in IEEE 802.3.

Howard Frazier
Broadcom Corporation
________________________________

From: DAWE,PIERS [mailto:piers.dawe@AVAGOTECH.COM] 
Sent: Thursday, August 24, 2006 10:35 AM
To: STDS-802-3-HSSG@listserv.ieee.org
Subject: Re: [HSSG] re LAGs just have an unfortunate statistical problem
designed in...


(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.
 
What exactly is the problem with encryption?  Is the whole stream
encrypted so the frame boundaries are not visible?  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.
 
"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?
 
Piers

	-----Original Message-----
	From: Geoff Thompson [mailto:gthompso@nortel.com]
	Sent: 24 August 2006 17:07
	To: DAWE,PIERS
	Cc: STDS-802-3-HSSG@listserv.ieee.org
	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 algorithms were proprietary 
	*	Distribution efficiency was considered to be a vendor
value-add 
	*	It was not an interoperability issue 
	*	It was going to violate layering 
	*	It turns out that, as the market developed, that things
didn't work out. 

	The proprietary mechanisms generally had to: 

	*	Buffer the entire frame 
	*	Look inside the payload of the frame 

	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@INFINERA.COM]
		> Sent: 23 August 2006 23:58
		> To: STDS-802-3-HSSG@listserv.ieee.org
		> 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@infinera.com
		> WWW :  http://www.infinera.com
<http://www.infinera.com/> 
		>  
		> 
		> _____________________________
		>  
		> 
		> -----Original Message-----
		> From: Geoff Thompson [mailto:gthompso@NORTEL.COM] 
		> Sent: Wednesday, August 23, 2006 2:57 PM
		> To: STDS-802-3-HSSG@listserv.ieee.org
		> 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@COLUMBUSADVISORS.COM]
		> > > Sent: 23 August 2006 19:10
		> > > To: STDS-802-3-HSSG@listserv.ieee.org
		> > > 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@avagotech.com]
		> > > Sent: Wednesday, August 23, 2006 2:04 PM
		> > > To: mabraham@COLUMBUSADVISORS.COM; 
		> STDS-802-3-HSSG@listserv.ieee.org
		> > > 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@COLUMBUSADVISORS.COM]
		> > > Sent: Tuesday, August 22, 2006 5:00 PM
		> > > To: STDS-802-3-HSSG@listserv.ieee.org
		> > > 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@infinera.com>
		> > > Date: Wed, 23 Aug 2006 00:01:45
		> > > To:<mabraham@COLUMBUSADVISORS.COM>,
		> > > <STDS-802-3-HSSG@listserv.ieee.org>
		> > > 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@infinera.com
		> > >
		> > > WWW :  http://www.infinera.com
<http://www.infinera.com/> 
		> > >
		> > >
		> > >
		> > >
		> > >
		> > > _____________________________
		> > >
		> > >
		> > >
		> > >
		> > >
		> > > -----Original Message-----
		> > >  From: Menachem Abraham
[mailto:mabraham@COLUMBUSADVISORS.COM]
		> > >  Sent: Tuesday, August 22, 2006 5:00 PM
		> > >  To: STDS-802-3-HSSG@listserv.ieee.org
		> > >  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@nortel.com>
		> > >
		> > > Date: Tue, 22 Aug 2006 16:09:11
		> > >
		> > > To:mabraham@columbusadvisors.com
		> > >
		> > > Cc:STDS-802-3-HSSG@listserv.ieee.org
		> > >
		> > > 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@SPRINT.NET:
		> > > <mailto:adudek@SPRINT.NET> ]
		> > >
		> > >  Sent: Tuesday, August 22, 2006 12:50 PM
		> > >
		> > >  To: STDS-802-3-HSSG@listserv.ieee.org
		> > >
		> > >  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@sprint.net
		> > >
		> > >
		> > >
		> > >
		> > >
		> > >  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@INFINERA.COM:
		> > > <mailto:dperkins@INFINERA.COM> ]
		> > >
		> > >  >       Sent: Tuesday, August 22, 2006 1:24 AM
		> > >
		> > >  >       To: STDS-802-3-HSSG@listserv.ieee.org
		> > >
		> > >  >       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@infinera.com
		> > >
		> > >  >
		> > >
		> > >  >       WWW :  http://www.infinera.com
<http://www.infinera.com/> : 
		> <http://www.infinera.com/>
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >       _____________________________
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >
		> > >
______________________________________________________________
		> > > _____________
		> > > _
		> > >
		> > >
________________________________________________________
		> > >
		> > >  >       From: John DAmbrosia
		> [mailto:jdambrosia@FORCE10NETWORKS.COM:
		> > > <mailto:jdambrosia@FORCE10NETWORKS.COM> ]
		> > >
		> > >  >       Sent: Monday, August 21, 2006 9:38 PM
		> > >
		> > >  >       To: STDS-802-3-HSSG@listserv.ieee.org
		> > >
		> > >  >       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
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >  >
		> > >
		> > >
		>