John,
In general, I was trying to parse your
comments (which summarized some of the others’ comments).... only to find
you parsing mine right back… very amusing :)
Regarding your questions:
Am I proposing aggregating 10G MACs? I
am looking for a solution which might avoid development of all new silicon, so
at some level I guess the answer is YES but I don’t think I have a clear
or viable conception of how precisely to do so. NOTE: This is different
from the CFI slides because you insisted that for clarity we only show one MAC even
though we’d discussed that other alternatives were permitted. I
agree that we’d have to make it different than LAG and this might be
accomplished in the PHY through some kind of striping mechanism. Personally,
I’m more interesting in working out the issues of the PHY and PMD.
Question: If the MAC is to be a Single
Chip (per your comment about the CFI) and the PHY/PMD will at least for datacom
economics need to be a single package, then what is to be scalable and how will
that be beneficial?
Regarding proposing a failover objective.
This only would be applicable & necessary if some form of scalable / variable
aggregation of lanes is supported then this would likely come for free (if the
implementation sensed which lanes were working rather than just being told that
the port supports 40G vs 80G vs 100G, etc in the negotiation). It only
seems appropriate to present on this topic in the future after we settled on
the nature and bounds of the scalability issue.
Regarding proposing a new rate
objective. Yes, I think 80G should be considered as the rate to be
supported (instead of 100G); not as a minimum but as the actual rate. The
actual PHY would be 8x10.3125G. Yes, it is heresy… but at one point
so was suggesting that the Earth revolved around the Sun. :)
Regarding pros & cons of a scalable
solution:
This may need to be broken into scalability
of lane rate & scalability of number of lanes. Here are some general
CONS which are admittedly inter-related…
CONS –
- Will
create an “Arms race” in incremental improvement in rate &
number of lanes and create fragmentation in market unit volumes which will
negatively impact investment & margins.
- Will
add complexity to the specification, add the need for features such as
failover/auto-negotiation, and difficulty to multi-vendor interoperability
testing.
- Will
lack a distinct identity (trying to create one standard for 40G –
100G – 160G)
- Will
impede multi-vendor internetworking and favor single vendor network
solutions due to the economics of wasted capacity on the most expensive
ports in a switch.
- Will
create a standard which is not standard. Not only might we
have different optical flavors such as 850nm vs 1550nm (etc.) but we will
multiply this by various rate options such as 40G, 100G, etc. And (while
not the IEEE’s problem) let’s not forget that there may end up
being multiple physical form factors (MSAs). The PHY/PMD vendors
already have too many implementations at 10G and now we are considering
adding a new variable which the PHY/PMD vendors will be asked to
implement. There are fewer companies making PHY/PMDs than there
would be “standards”. It would end up be more uniform if
the industry abandon the IEEE and just formed MSAs to address the PHY/PMD.
We don’t want this study group to cause that to happen.
From: John DAmbrosia
[mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, August 15, 2006
10:53 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] HSSG MAC &
PHY Options
Roger,
Please see comments below-
John
From: Roger Merel
[mailto:roger@xxxxxxxxxxx]
Sent: Tuesday, August 15, 2006
9:54 AM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] HSSG MAC &
PHY Options
I agree that John’s email outlines the
basic options for the MAC; however, I have some questions.
If the Option (B) MAC isn’t 10G
based, then obviously the development of a new MAC is required. However,
even if the MAC is 10G based, would there still be any changes required necessitating a
new 10G MAC design?
JD > I am not sure what you mean by
this. The 802.3 MAC specification is bit serial and speed agnostic.
I understand the modifications for speed to be fairly straightforward.
Are you proposing aggregating 10G MACs? This is different than what we
discussed in the CFI, which always showed a single MAC. The Physical
Layer Aggregation we have been discussing is below the MAC. You seem to
be suggesting aggregating above the MAC, which I understand to be essentially
LAG. Can you provide further clarification?
Does Option (A) preclude the use of
multiple 10G MACs working together? (I think not, but I’d like
others’ thoughts.)
Does Option (A) preclude including
features which allow for less than all of the HSSG “lanes” working?
(I think not, but I’d like others’ thoughts.)
Does Option (A) require that the MAC is
implemented in a single chip (whereas Option (B) does not)? (I think not, but
I’d like others’ thoughts.)
JD > First see above regarding
discussion of MACs. The two options listed were the options I had seen
discussed on the reflector for MAC rate. It looks to me like you are
suggesting adding a failover objective. Is this correct? Are you
considering doing a presentation on this potential objective for the September
Interim?
There definitely is a sense of justified
pride by the long time members regarding the fact that (unlike Fiber Channel),
each new step in Ethernet was a large step which avoided lots of small
increments which still required significant product re-development /
inefficient investment.
I am concerned that the soft-scaling being
considered here will mean:
(1) Different System Vendors will choose
different scale factors and won’t actually be able to talk to each other
as efficiently as they talk to their own boxes. E.g. is Vendor A
implements 40G and Vendor B implements 100G… they would talk to each
other at 40G but this creates a disincentive to cross vendor boundaries since
there is an expensive 100G port being under utilized at 40G.
(2) We have taken the progress for certain
steps of the out of the standards process, but allowed for Vendors to make the
small incremental steps (e.g. multiple factors of 2x)… a Vendor starting
with a 40G implementation can go to 80G then 160G. Since 100G will
undoubtedly be hard just as 1G and 10G were hard, we have created an incentive
for some to take the easier step now especially if it fits better into their
existing system capacity. Thus we will share the same fate as Fiber
Channel in terms of cycle of investment.
Does Option (A) have to operate at exactly
the traditionally 10x? Is 80G out of the question? It’s less
than 1dB difference, is a 2^n factor making certain issues easier, and would
allow for coinciding with SONET/SDH speeds more often in the future.
JD > As mentioned, I only included
those options I had seen on the reflector. Are you suggesting that 80G
should be added as a candidate for the MAC rate? Or are you suggesting
that we replace the 100G rate with a minimum data rate of 80G? Please
clarify.
While this conversation thread is focused
on the MAC, it seems to have neglected to consider that vendors will have to make
PHY/PMDs that work with these MAC options. When people have voice support
for Option (B) are they also suggesting that they support a Scalable PHY/PMD?
I can understand why the MAC should be
scalable and how that can save development costs / investment; however, making
a Scalable PHY/PMD would seem to me to mean increased PHY/PMD development
costs, lots of different “flavors” of PHYs to be developed, not
volume behind any single “flavor”, and worse unit
economics…likely worse than linear scaling…e.g. worse than 10x$$
for 10xBW.
Does Option (B) for the MAC preclude a
single fixed PHY/PMD implementation? (I think not, but I’d like
others’ thoughts.)
Is a Scalable PHY/PMD desirable? (I think
not, but I’d like others’ thoughts.)
I certainly want to re-use 10G MACs, if
possible, to improve the economics for 10G and reduce the new investment
required for HSSG. There are likely some silicon or system vendors
working on Quad 10G MACs, etc. Using a Scalable MAC approach will allow
that density improvement to be utilized for HSSG as well.
However, I think it would be a huge
mistake (particularly for the short distance / datacenter / enterprise
applications) to believe that allowing freedom in the scaling value of N would
somehow make the PHY/PMD situation better. It would not be good for
PHY/PMD developers, nor for customer interoperability / multi-vendor
internetworking. We certainly have a responsibility to consider economic
dynamics that will be created the by features of the standard we choose to
implement.
JD > My sense is that we will see
strong opinions on both sides of a scaleable solution. I encourage
individuals to start discussing this on the reflector as soon as possible, as
well as bring presentations forward to the September that look at the pro’s
/ cons of both the fixed and scaleable solutions.
-Roger
From: Belopolsky,
Yakov [mailto:ybelopolsky@xxxxxxxxxxx]
Sent: Tuesday, August 15, 2006
7:16 AM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] MAC Data Rate
of Operation Objective
Thank you for a very succinct summary of the two proposals.
Without repeating any arguments, I am strongly in
favor of a scalable approach - proposal B
(which should continue another tradition - a tradition
of successful implementation)
Best
Regards,
Yakov Belopolsky
Manager, Research & Development
Bel Stewart Connector
ybelopolsky@xxxxxxxxxxx
Tel. 717-227-7837
FAX 717-235-3231
-----Original Message-----
From: John DAmbrosia
[mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2006 5:20
PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: [HSSG] MAC Data Rate of
Operation Objective
All,
In regards to proposed MAC data rates, I have seen two basic
proposals
Proposal A) 100 Gb/s
Proposal B) Scalable Solution
Proposal A supports the traditional 10x increase in
speed.
Proposal B, as presently discussed, is unbounded. (The
following are only my observations of statements made on the reflector by
others) The lowest limit proposed was a 4x10 approach for 40 Gb/s.
No upper limits have been proposed. It has been suggested that this
approach should use existing PMDs, but there have been also been comments
regarding use of 10G, 25G, and 40G lambdas, but that carriers would want to leverage
their existing DWDM layer, which mean baudrate in the 9.95-12.5 Gig. Consuming
wavelengths has been brought up as a possible concern. It was also suggested
that the greatest bandwidth demands are on VSR links < 50m and that the
longer reach (>10km) may be able to live with 4x10G. (Data in support
of these observations that could be used to guide the creation of objectives
would be welcome.)
An objective for Proposal A could be similar to what was
done for 10 GbE- Support a speed of 100.000 Gb/s at the MAC/PLS service
interface.
For Proposal B, given its current unbounded nature and
multiple discussion points, I am not sure what would be proposed. I am
looking to the advocates of this proposal to provide some verbiage to the
reflector for discussion. Using the objective above as a basis: Support a
speed greater than 10.000 Gb/s at the MAC/PLS service interface, would create
too broad an objective.
Also for both proposals what are people's thoughts on an
objective that would specify an optional Media Independent Interface (MII)?
John