Re: [STDS-802-3-25G] 25G CR objective wording
I agree with Mark. Option A.
Mike Dudek
QLogic Corporation
Director Signal Integrity
26650 Aliso Viejo Parkway
Aliso Viejo CA 92656
949 389 6269 - office.
Mike.Dudek@xxxxxxxxxx
-----Original Message-----
From: Mark Gustlin [mailto:mark.gustlin@xxxxxxxxxx]
Sent: Thursday, August 21, 2014 1:41 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-25G] FW: [STDS-802-3-25G] 25G CR objective wording
I vote for A. I think simplicity is good.
Mark
> > -----Original Message-----
> > From: Mellitz, Richard [mailto:richard.mellitz@xxxxxxxxx]
> > Sent: Thursday, August 21, 2014 1:26 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
> > Subject: Re: [STDS-802-3-25G] 25G CR objective wording
> >
> > I cast my vote for C.
> > ... Rich
> >
> >
> > Sent from my iPhone
> >
> > On Aug 21, 2014, at 3:58 PM, "Mark Nowell (mnowell)"
> > <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx>> wrote:
> >
> > Thanks Vineet,
> >
> > I see we are trying to balance simplicity of the language of the
> > objective, clarity on what the task force will do, and enabling the
> > task force to not be unable from exploring what it may want to do.
> >
> > The things I believe I'm hearing are definite "musts" are a reach
> > of at least 3m and the re-use of the existing transceivers designed
> > for 802.3bj implementations. I also believe we have interest to not
> > preclude the Task Force to be able to explore host board and cable
> > loss budget allocations (but not the overall loss budget!).
> >
> > So I'm proposing a series of objectives for the twin-ax objective
> > which I believe all essentially say the same thing. But with a
> > different balance point between simplicity of language and
> > clarity/preciseness. I'd appreciate feedback on the these:
> >
> > A) Define a single lane 25 Gb/s PHY for operation over links consistent with
> > copper twin axial cables, with lengths up to at least 3m (same language as
> > 802.3bj - with a different reach #)
> >
> > B) Define a single lane 25 Gb/s PHY for operation over links
> > consistent with copper twin axial cables, with lengths up to at
> > least 3m that re-uses the host board silicon transmitter and
> > receiver
> characteristics specified in IEEE Std
> > 802.3bj-2014 Annex 92A (adding reference to the receiver and
> transmitter
> > specs - I know they are defined in Clause 93, bust Annex 92A
> > references them and this provides consistency with twin-ax clauses)
> >
> > C) Define a single-lane 25 Gb/s PHY for operation over copper
> > twin-axial cables consistent with the overall channel budget
> > specified in IEEE Std
> > 802.3bj-2014 Clause 92
> >
> > I personally lean to simplicity, so would choose A, then B, then C
> >
> > Feedback?
> >
> > Regards...Mark
> >
> > On 8/20/14, 9:05 PM, "Vineet Salunke (vineets)"
> > <vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx>> wrote:
> >
> > Team ...
> >
> > Thanks to David and Matt for providing some clarity here.
> >
> >
> > 1) We want to constrain the total loss budget (or end to end channel) or
> to
> > be compatible with 100G CR4 transceivers.
> >
> > 2) We want to allow task force the opportunity to re-partition the loss
> > budget between host and cable, to meet the market needs.
> >
> > Some examples we have heard - avoid use of FEC, allow for larger
> > host loss, target for 3m cables (not 5m).
> >
> > Are there any strong objections to Steve's suggestion of keeping it
> > simple and high level ?
> >
> > * Define a single lane 25 Gb/s PHY for operation over links consistent
> with
> > copper twinaxial cables, with lengths up to at least 3m.
> >
> > --vineet
> >
> > From: Matt Brown (APM) [mailto:mbrown@xxxxxxx]
> > Sent: Wednesday, August 20, 2014 5:11 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Hi Steve,
> >
> > The intent of the posted proposed objective is to indicate that the
> > 25G Ethernet copper cable PHY is not to start from a blank slate,
> > but rather is constrained to permit end users and suppliers to
> > leverage technology developed for 100GBASE-CR4, e.g., transceivers.
> >
> > The expressed concern with the posted proposed objective is that it
> > might be interpreted to be too restrictive and may not allow any
> > non-obvious deviations; e.g., must use the host loss budget as
> > specified in 802.3bj. As an example, Vineet's presentation yesterday
> > proposed an additional host configuration restricted to around half
> > the 802.3bj host budget with cable lengths up to 3 m that might
> > allow no FEC or lower latency FEC (e.g., Clause
> > 74) and meet BER/MTTFPA targets.
> >
> > The intent is to find words that will not be interpreted as being
> > that restrictive. Chris's suggested wording is intended to clarify
> > that the channel specifications referred to in the objective are the
> > end to end
> > (TP0 to TP5) parameters, not necessarily the partitioning of the
> > budget. This would constrain the end to end channel to be compatible
> > with 100GBASE-CR4 transceiver technology but would permit
> > repartitioning of the channel budget between transceivers amongst
> > other
> trade-offs.
> >
> > Matt Brown
> > AppliedMicro
> > mbrown@xxxxxxx<mailto:mbrown@xxxxxxxx>
> > 613 254 6728 office
> > 613 852 6728 cell
> >
> > From: Trowbridge, Stephen J (Steve)
> > [mailto:steve.trowbridge@ALCATEL-
> > LUCENT.COM<mailto:steve.trowbridge@xxxxxxxxxxxxxxxxxx>]
> > Sent: Wednesday, August 20, 2014 6:22 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Hi David,
> > Certainly fine to have that discussion to prepare for the task
> > force, but no need to put any constraining details in the objective.
> > If you think you might want to change stuff in this way, and a
> > shorter reach meets the market need, you could back the objective
> > off to "at least 3m" or "at least 4m" and leave yourself that
> > flexibility. Even if you later decide to just copy what bj did, the bj solution meets "at least 3m"
> and "at least 4m".
> > Regards,
> > Steve
> >
> > From: Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx]
> > Sent: Wednesday, August 20, 2014 4:11 PM
> > To: Trowbridge, Stephen J (Steve); STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-25G@xxxxxxxxxxxxxxxxx>
> > Subject: RE: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Steve - we have been discussing repartitioning the end-to-end budget
> > for CR... Maybe reduce the cable length & give some back to the host
> > PCB channel segment... so if we are going to put a reach objective
> > in for CR we need to finish that debate first. The other
> > suggestions for CR objective wording kept things vague enough that
> > we could work the
> partition later.
> >
> >
> >
> > From: Trowbridge, Stephen J (Steve)
> > [mailto:steve.trowbridge@ALCATEL- LUCENT.COM]
> > Sent: Wednesday, August 20, 2014 3:02 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Hi all,
> > I think you guys are getting into the weeds here considering that
> > this is the Study Group phase. I believe that the objectives can be
> > much higher level than you are proposing and you can trust the task
> > force to do the right thing, because this isn't a waterfall thing
> > where you are creating a set of objectives and throwing them over
> > the fence to a totally disjoint group of engineers who you don't
> > trust to do the right thing unless you tie their hands: the task
> > force will be YOU, and if you
> can't trust yourself, who can you trust?
> >
> > The only reason the later iteration of the P802.3bj objectives got
> > into channel details was that they were trying to generate distinct
> > identity for doing two backplane PHYs, otherwise they could just
> > have left it as "up to 1m over a backplane".
> >
> > Assuming you are intending to specify a single backplane PHY rather
> > than having KR and KP variants, I think you could leave it as:
> >
> > * Define a single lane 25 Gb/s PHY for operation over links consistent
> with
> > copper traces (as specified by P802.3bj) with lengths up to at least 1m.
> >
> > * Define a single lane 25 Gb/s PHY for links consistent with copper
> > twinaxial cables with lengths up to at least 5m.
> > Regards,
> > Steve
> >
> > From: Vineet Salunke (vineets) [mailto:vineets@xxxxxxxxx]
> > Sent: Wednesday, August 20, 2014 12:18 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Matt,
> >
> > I agree, staying with CR4 specs would be best, but I am trying to
> > understand the need for larger host loss.
> >
> > The main volume would be "SFP" ports used on both switch and server,
> > so we should optimize for that.
> > QSFP switch ports will not be able to use the larger loss, but can
> > still provide 4x25G CR breakout.
> >
> > --vineet
> >
> > From: Matt Brown (APM) [mailto:mbrown@xxxxxxx]
> > Sent: Wednesday, August 20, 2014 10:43 AM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Hi Vineet,
> >
> > I think it makes a lot of sense to retain the 802.3bj host loss. The
> > case in point would be a switch with 4x25G connectors that may be
> > used for either a signal 100G Ethernet port (100GBASE-CR4 per
> > 802.3bj) or four 25G Ethernet ports (25GBASE-CR per new 25G project).
> >
> > Matt Brown
> > AppliedMicro
> > mbrown@xxxxxxx<mailto:mbrown@xxxxxxxx>
> > 613 254 6728 office
> > 613 852 6728 cell
> >
> > From: Vineet Salunke (vineets)
> > [mailto:vineets@xxxxxxxxx<mailto:vineets@xxxxxxxxx>]
> > Sent: Wednesday, August 20, 2014 12:08 PM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Chris,
> >
> > We heard on the call yesterday, at least 3 demands that do not
> > exactly match Clause 92.
> >
> > * Need to reduce the host loss on the server side, to reduce total loss
> and
> > avoid use of FEC.
> >
> > * Need to further optimize around 3m cables for above.
> >
> > * And I also heard need to allow larger host loss for the TOR switch side
> > (when using RS-FEC).
> >
> > So can we avoid the direct reference to Clause 92 specifications ?
> >
> > --vineet
> >
> > From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-
> > request@xxxxxxxx]
> > Sent: Wednesday, August 20, 2014 8:57 AM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Rich,
> >
> > Hopefully this addresses both you and George.
> >
> > Given the intent is to operate over channels consistent with the
> > channel
> > (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause92.
> >
> > *Define a single-lane 25Gb/s PHY for operation over channels
> > consistent with the channel specified in IEEEStd802.3bj-2014
> > Clause92 (Fig 92-2 - TP0-TP5) Regards, Chris DiMinico
> >
> >
> > -----Original Message-----
> > From: Mellitz, Richard
> > <richard.mellitz@xxxxxxxxx<mailto:richard.mellitz@xxxxxxxxx>>
> > To: STDS-802-3-25G <STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-
> 802-
> > 3-25G@xxxxxxxxxxxxxxxxx>>
> > Sent: Wed, Aug 20, 2014 11:49 am
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder Both suggestions allude to a
> > specific host/module budget which I believe needs to re-evaluated in
> > task
> force.
> > Perhaps:
> >
> > Define a single-lane 25Gb/s PHY for operation over copper twin-axial
> > cables, host channels, and module channels consistent with channels
> > (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause93
> >
> > This sort of reinforces a single silicon solution.
> >
> > From: George Zimmerman
> >
> [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:george@C
> > MECONSULTING.ONMICROSOFT.COM?>]
> > Sent: Wednesday, August 20, 2014 10:33 AM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Chris -
> > Clause 92 has a lot of non-channel stuff in it, and the
> > parenthetical insert, while clarifying to those who know clause 92
> > intimately, isn't perhaps as clear as you could be. Pointing to the
> > correct subclause, a figure or a table would be a lot better.
> >
> > The wording itself leads to confusion because it says "over copper
> > twinaxial cables consistent with", but TP0 to TP5 includes more than
> > the twinax cables, as you know. We end up with a couple of choices:
> > 1) Just identify the cables in clause 92, or
> > 2) Say operate over the whole TP0 to TP5 channel in clause 92
> > (I apologize because I have another call which conflicted with
> > yesterday's meeting - I don't have an opinion on whether using the
> > whole channel from
> > TP0 to TP5 is in fact the correct objective, or whether you want to
> > do just the
> > cables) If you just want to do (1) just the cables, the cable
> > assembly is specified in 92.10 (and references elsewhere), I would
> > suggest stating *Define a single-lane 25Gb/s PHY for operation over
> > copper twin-axial cables consistent with cable assemblies specified
> > in
> > IEEEStd802.3bj-2014 Clause92.10
> >
> > And, if you want to do the whole channel, including the PCB, as you
> > stated, from TP0 to TP5, Clause 92.9 clearly specifies this (by
> > referencing other
> > subclauses)
> >
> > *Define a single-lane 25Gb/s PHY for operation over copper
> > twin-axial cables consistent with cable assemblies specified in
> > IEEEStd802.3bj-2014 Clause92.9
> >
> > Note I'm looking at draft 3.2 of the 802.3bj, and don't have the
> > final published version.
> >
> > George Zimmerman
> > Principal, CME Consulting
> > Experts in Advanced PHYsical Communications Technology
> >
> george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxx
> > microsoft.com>
> > 310-920-3860
> >
> > (PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT
> PLEASE
> > USE THIS FOR CME BUSINESS)
> >
> > From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-
> > request@xxxxxxxx]
> > Sent: Wednesday, August 20, 2014 6:14 AM
> > To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-
> > 25G@xxxxxxxxxxxxxxxxx>
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder
> >
> > Colleagues,
> >
> > Based on the discussions of the objective given on slide 9 second
> > bullet in
> >
> http://www.ieee802.org/3/25GSG/public/adhoc/architecture/nowell_08121
> > 4_25GE_adhoc.pdf
> > during the ad-hoc yesterday, I suggest we explicitly identify
> > 802.3bj channel by adding (TP0-TP5).
> >
> > Change from *Define a single-lane 25Gb/s PHY for operation over
> > copper twin-axial cables consistent with channels specified in
> > IEEEStd802.3bj-2014
> > Clause92 To *Define a single-lane 25Gb/s PHY for operation over
> > copper twin-axial cables consistent with channels (TP0-TP5)
> > specified in
> > IEEEStd802.3bj-2014 Clause92
> >
> > Regards,
> >
> > Chris DiMinico
> >
> >
> > -----Original Message-----
> > From: Mark Nowell (mnowell)
> > <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx>>
> > To: STDS-802-3-25G <STDS-802-3-25G@xxxxxxxxxxxxxxxxx<mailto:STDS-
> 802-
> > 3-25G@xxxxxxxxxxxxxxxxx>>
> > Sent: Tue, Aug 19, 2014 6:17 pm
> > Subject: Re: [STDS-802-3-25G] Ad-hoc reminders/updates and Interim
> > Meeting Call for Presentation reminder Sorry everyone - calendar
> > screw up on my side around the re-arranged architecture ad-hoc meeting.
> > Will update soon with improved logistics.
> >
> > Mark
> >
> > On 8/19/14, 5:42 PM, "Mark Nowell (mnowell)"
> > <mnowell@xxxxxxxxx<mailto:mnowell@xxxxxxxxx>> wrote:
> >
> > Dear 25Gb/s Ethernet Study Group Members,
> >
> > A few reminders and updates:
> >
> > 1) Optical Ad-hoc is tomorrow Wed 8/20 @ 9am PST. Dial in details
> > are
> here:
> > http://www.ieee802.org/3/25GSG/public/adhoc/index.html
> >
> > 2) Architecture ad-hoc meeting next week has moved to Wed 8/27 @ (am
> > PST (shifted from Tues). Dial in details are here:
> > http://www.ieee802.org/3/25GSG/public/adhoc/index.html
> >
> > 3) Reminders on Call for presentations and September Meeting planning.
> > Presentation request deadline is Friday Aug 29th. Please see my original
> > email for details on meeting logistics and travel planning (We meet
> > all-day Thurs and Friday).
> > http://www.ieee802.org/3/25GSG/email/msg00004.html
> >
> > As a reminder, the September Study Group meeting has limited meeting
> > time and the presentations will be focused on the Study Group work
> > of building objectives, developing responses to the CSD (5 Criteria) and PAR.
> > Presentations outside of the scope of those priorities will be given
> > time on agenda as possible.
> >
> > Regards...Mark