I like A. Simple, clear… doesn’t leave an end-user wondering what the reach will be.
This also forces the conversation on reach now. If anyone objects to 3m, better speak up!
If there is disagreement on the reach, then C allows for possible repartitioning in TF.
dlc
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, August 21, 2014 2:01 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] FW: [STDS-802-3-25G] 25G CR objective wording
I'd say a, then c, based on simplicity. B is a mouthful, and i don't know what it means to reuse characteristics. Thanks to all, for the discussion, I think things are getting clearer.
Experts in PHYsical Layer Communications
Mark Gustlin <mark.gustlin@xxxxxxxxxx> wrote:
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
|