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

Re: [HSSG] 40G MAC Rate Discussion



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<de-lurk>

Please forgive a few questions from a lurker new to this process....

Shimon Muller wrote:
> > Thank you for the clarification, John.
> >
> > On that point, as someone who started the 40Gb discussion back in
> > January, I would like to make it clear in no uncertain terms what our
> > motivations were and still are: in no way do we intend to impede or
> > slow down the development and/or the adoption of 100Gb Ethernet.
> >
> > We believe that doing a standard for 100Gb is important but not enough,
> > for the following reasons:
> > - The 40Gb speed will enable us to get the most out of our servers
> > until 100Gb becomes technically and economically viable for server
> > connectivity. We believe that there is a 5-year window of opportunity
> > for this market.

Just out of curiosity, what is the difference between running a 40G
interface at wire speed and running a 100G interface at 40G?  Note that
the first round of 10G interfaces were bus-limited to 8G (well,
7.mumble) by the PCI-X bus, and this did not appear to damage early
adoption.

> > - The two speeds should be addressing two distinct markets. This can be
> > accomplished by defining the PMDs based on reach, with 40Gb defined for
> > short-reach datacenter connectivity only.

It seems to me that if the market for 40G were limited in this way, it
would increase the cost of both 40G and 100G since the economy of scale
for both would be diluted (less 100G in data centers, no 40G in carrier
networks)....thoughts?

> > - 40Gb connectivity at the server will require a faster aggregation speed
> > even in the datacenter. This will increase the market potential for 100Gb.

Given that it is currently difficult for servers to make effective use
of 10Gbps host interfaces (one often has to devote an entire high-speed
host CPU to network I/O, though TOE cards are getting better), I would
expect that 10G aggregation would fill the same role for providing
demand for 100G uplink ports.  It seems to me that 10G host interfaces
have seen limited market penetration, and have quite a ways to go yet.
 Is there data that says otherwise?  (note that vandoorn_01_0307.pdf
states that 10G host interfaces are being adopted slowly due to cost
concerns....it seems likely that the cost barrier for 40G will be
significantly higher, unless there is data to suggest otherwise).

> > - Unless the 100Gb effort starts today, the technology will not be ready
> > when we need it for servers in 2015. I am sure your heard me say this
> > at the last meeting, and I meant it.
> > - The development of a 40Gb standard will be highly leveraged: either
> > from the work that was done in other standards bodies, or from the
> > work that needs to be done for 100Gb anyway. Therefore, 40Gb should
> > in no way slow down the 100Gb effort.

See below...

> >
> > What has been puzzling to me in this debate ever since it started is:
> > how can 40Gb server connectivity in the datacenter hurt those of you who
> > believe that 100Gb is the right speed for aggregation links in service
> > provider networks? I am certainly at a point where I understand and
> > respect the needs of your market. All I am asking in return is the same.

I'm coming at this from a customer perspective, not from the
perspective of someone who has to develop the hardware.  However, it
seems to me that dilution of development resources has the potential to
cause problems.  One thing that might mitigate this is to separate the
two efforts so that there are clear areas of focus for development for
particular markets.

It appears that there is broad consensus supporting the need for 100G
(my organization certainly needs 100G by 2010).  If it can be shown
that there is also broad consensus supporting the need for 40G for
datacenter applications, then spinning off a 40G datacenter effort
seems like a productive way to go.  That way neither effort would
impede the other from a development perspective, and each could satisfy
the needs of its market.

Thanks for reading...

<lurk>

		--eli


> >
> > Any comments that will help me understand and address the above concerns
> > would be very much appreciated.
> >
> > Regards,
> >
> > Shimon.
> >
> >
> >
> > John DAmbrosia wrote On 03/30/07 19:48,:
> >
>> >> All,
>> >>
>> >> From discussions I have had, I sense that there may be some confusion
>> >> regarding the proposal for adding a 40Gb/s MAC rate objecitve. 40 Gb/s
>> >> has been proposed as an additional MAC rate, not as a replacement for
>> >> the current objective of 100 Gb/s.
>> >>
>> >> The presentations given have focused on the needs of servers / end
>> >> stations:
>> >>
>> >> http://grouper.ieee.org/groups/802/3/hssg/public/jan07/muller_01_0107.pdf
>> >>
>> >> http://grouper.ieee.org/groups/802/3/hssg/public/mar07/frazier_01_0307.pdf
>> >>
>> >>
>> >> http://grouper.ieee.org/groups/802/3/hssg/public/mar07/vandoorn_01_0307.pdf
>> >>
>> >>
>> >> I encourage all to review the above presentations, and use the
>> >> reflector to further discuss them and / or the proposed objective.
>> >> This will help to assist the SG in preparing for the April Interim, as
>> >> well as making decisions regarding the project’s objectives.
>> >>
>> >> Best Regards,
>> >>
>> >> John D’Ambrosia
>> >>
>> >> ------------------------------------------------------------------------
>> >>
>> >> *From:* John DAmbrosia [mailto:jdambrosia@FORCE10NETWORKS.COM]
>> >> *Sent:* Monday, March 26, 2007 5:11 PM
>> >> *To:* STDS-802-3-HSSG@listserv.ieee.org
>> >> *Subject:* [HSSG] 40G MAC Rate Discussion
>> >>
>> >> 

- --
Eli Dart                                         Office: (510) 486-5629
ESnet Network Engineering Group                  Fax:    (510) 486-6712
Lawrence Berkeley National Laboratory
PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGEpWoLTFEeF+CsrMRAvP0AJ4qaFKaEzBL1UV6cFgz+SWN8J0liQCggklH
CSRNfwApAiOgkKJOA3cHzJ8=
=eZV2
-----END PGP SIGNATURE-----