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

Re: [802.3_DWDM] sluyski_cw_01_200416 proposed edits



Eric,

 

Thanks for your responses. I think these are valuable suggestions. I don’t think I can address all of your points, but I’ll give it go here, we can discuss further tomorrow and hopefully beyond when there are a few stakes in the ground (or targets) to shoot at.

 

From: Eric Maniloff [mailto:eric.maniloff.ieee@xxxxxxxxx]
Sent: Wednesday, April 22, 2020 8:58 PM
To: STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DWDM] sluyski_cw_01_200416 proposed edits

 

Hi Mike,

 

Thanks for preparing this, I think it’s useful to get the discussion started. I’ve reviewed and had some colleagues look at it as well. I have a number of concerns/suggestions that will hopefully be constructive for the discussion..

 

On p7 I think it’s worth pointing out the penalty target. It’s not necessary, but since OIF allocates 0.5dB combined penalty to Interchannel Xtalk and CD, this is a useful number to keep in mind.

 

Agree. The OIF position was to associate a penalty with each individual impairment. In my review of the IEEE methodology however the penalty is lumped as a path penalty and it’s sometimes hard to distinguish. One point to note though is that the penalty due to inter-channel crosstalk when operating on 75GHz grid is significantly higher than when operating on 100GHz grid, considering the baud rate is ~60Gbaud. This proposal focuses on the most critical parameters  and generally accepts that the OIF did a reasonable job of defining the others.

 

On p8, you have a definition from OIF - it’s worth adding an explicit statement: Interchannel Crosstalk can not in & of itself determine the OSNR penalty. There’s a concern that this isn’t clear in what follows, and the actual penalty is tied to one Rx implementation. 

 

This is absolutely true, and is the reason that the overall path penalty is proposed as a TBD. For operation on 75GHz, the adjacent channel signal power spilling into the primary channel is a major concern. The filtering proposal (see Winston’s proposal), combined with limitations on the Maximum Spectral Excursion propose to constrain the overall penalty contribution due to inter-channel xtalk to 1.0 dB.  This sets up the filtering requirement on the Black link. Note that we would still need to confirm this, but it puts a stake in the ground for further analysis.

 

The other concern here is that if we have a Crosstalk spec, it’s impossible to determine if it will be met by a link design without knowledge of the Tx spectrum. Since Interchannel Crosstalk from a link can not be calculated without defining the transmit spectrum, one should be defined. Based on what follows, we recommend using a RRC with a 0.4 roll-off as a reference spectrum for this calculation – subject to change when specs are adopted.

 

The proposal attempts to limit the TX maximum/minimum  spectral excursion ( a TX Mask). IEEE has not in the past use a continuous function (e.g. RRC shaped signal with roll-off of 0.4) as the mask limit. This proposal, however, provides insight and guidance at how the fixed points were arrived at. Indeed the maximum spectral excursion is based on a digitally shaped spectrum (RRC of 0.4).  I’m open to defining the mask as a continuous function, but points in a table is the IEEE precedent.  This is why we chose both a -3dB reference point and a -10dB reference point. 

 

P9

 

Add CD, PMD in penalty.  We’re wondering if this should also add a filter penalty? This says "include" so doesn't necessarily preclude these. However the full list should be included.

 

How to calculate the link penalty as a combination of impairments is a challenging issue.

 

Agree filter penalty may be an additional component of the overall path penalty. This hasn’t been fully determined. That’s why path penalty is still TBD.

 

P10

 

It’s unclear to me if measurement tolerances should be included here. Worth discussing.

 

Agree. However, the ability to measure and isolate bad behavior is really a debug and fault isolation exercise. A spec should include clear definitions on test methodology. That is somewhat beyond the scope of this recommendation other than referencing existing definitions from OIF and ITU-T.

 

P11-12

 

Should a spec be placed on the transfer function of the filters? Right now there is only a ripple spec. This should be discussed along with the reference spectrum.

 

Agree. We debated whether the black link should be defined as a transfer function using an ideal stimulus or step function, or whether it can be defined by constraining the TX to a well defined mask. We chose the latter based on precedent at ITU-T, OIF, and IEEE. My personal opinion of this is that it doesn’t sufficiently decouple the design/development  individual datapath constituents sufficiently. 

 

I don’t want to speak to Winston’s presentation, but I think he is assuming a well defined TX spectrum (within minimum/maximum limits) such that the Black Link filter response can be designed to meet a maximum inter-channel xtalk penalty. Again, other penalties need to be considered. But inter-channel crosstalk seems to be the major impairment.

 

The data is provided for a particular receiver. Details of crosstalk spectrum are important here. 

 

OIF defines an 0.5dB penalty for -8dB Xtalk + CD penalty for their 100GHz spaced spec.

 

Yes. Well defined penalty for specific impairments. IEEE and ITU-T, however,  lump the penalties differently. I will say that all penalties do not add linearly. Summing the penalties defined by OIF may be overkill. In the spirit of broad adoption IEEE blended approach is less constraining to Transceiver vendors.

 

P15

 

Recommend removing 3dB point. 

 

Agree. This was primarily for reference.

 

The -10dB data likely constrains the Tx Spectrum to an RRC spectrum with an 0.4 roll-off. 

 

Agree, personally I would prefer a continuous mask, but -10dB seems sufficient unless you are a rogue hacker trying nefariously to break the spec.

 

Filtering and Xtalk penalties should be included in selecting the maximum RRC spectrum. Is it worthwhile to base the specs on a particular spectrum such as RRC? This would seem to be useful for interop and to allow a single point to define the Tx spectrum.

 

Not disagreeing. Open to modifying the mask or the , but the single -10dB point currently defined fall on the line of a RRC shaped spectrum of 0.4, and is in-line with current IEEE mask definitions. I’d be more than happy to make continuous function.

 

P16

 

This is been modified since the first version of the presentation to change it to a baseband spec. This is a useful correction.

 

The spec that was in the last version of the presentation was removed. The previous spec was consistent with the OIF minimum excess BW. Since 802.3cw is moving to a tighter spacing, we may want to tighten the spec allowing a sharper roll-off.

 

This was discussed in our small group. There was confusion on this parameter on whether it included laser frequency offset or not. At the OIF this was originally intended to provide a minimum amount of excess bandwidth for Clock recovery. The mask corner was set at ~ -9dB at 32GHz, and no laser frequency offset is assumed. The minimum mask prevented someone from rolling off the signal by more than RRC 0.125.  In this proposal it is converted to a minimum TX spectral mask. This spec was converted to a TBD since it is expected to be subject for reconsideration in at the OIF in a future maintenance draft. Ciena was the primary contributor to establish this spec at the OIF.

 

P17-18

 

Tx Specs:

 

Missing Specs from OIF are a concern. My preference would have been to start with the full list of specs, and then remove those that we consider unnessary. 

 

Open to add specifications as necessary, however for this proposal we tried to minimally align to existing practice and precedent at the IEEE. (see Strasser contribution on TX, Black Link and RX parameter tables). This proposal roughly aligns with that proposal but takes 1 step further to populate the table with what we consider well-grounded values.  We also believe having a target to shoot at is better than having a nebulous unit of measure.

 

Laser Frequency Noise

Tx Clock Phase Noise (13.1.213)

 

These two are a major deviation from OIF. 

 

OOB OSNR (13.1.231) – maybe not necessary to include.

 

I/Q Instantaneous offset  -20 dB is included in OIF IA (13.1.270a)

                              Is the Max I/Q Offset (-26dB) included equivalent to DC I/Q Offset  in OIF IA (13.1.270a)?

 

A number of parameters have been omitted that I believe are intended to be included in EVM, but this is not stated:

                              Mean I/Q Amplitude Imbalance

                              I/Q Phase Imbalance

                              I/Q Skew

 

Agree the above are useful and painstakingly arrived at in the OIF. I think we first need to determine if they are necessary given the methodology of determining the overall link budget in IEEE.

 

We should clarify the specs that we are including in EVM, so we have something to point to when people are looking  for them.

 

Agree. I think the expectation is that EVM replaces many of the discrete parameters currently define by the OIF TX.

 

P19:

 

Spec for 50krad/s SOP Tolerance does not call out measurement conditions. OIF defined it @ max PDL/PMD relative to the same impairments at a 1krad/s rate.

 

Should add PDL to path penalty, unless the intention is to allocate a separate penalty for this.

 

Ripple should specify BW. We should discuss how to specify filter in the context of a black link.

 

Open for refinement.

 

P20:  Rx should specify 20ppm

 

After reviewing this I feel like we need to take some time to address some of these issues before adopting a baseline.

 

I think there is a lot of work still to be done, but I’ll reiterate, my experience is that that putting a stake in the ground is the best way to spur  a reaction and a discussion. Not sure I would have received this email otherwiseJ.  I appreciate and value your feedback and I hope you will consider accepting  these well-grounded parameters for baseline. I think if nothing else I have jump started the discussion. I don’t consider anything to be final until we all stop participating.

 

Regards,

 

Eric

 

On Tue, Apr 21, 2020 at 6:27 PM John D'Ambrosia <jdambrosia@xxxxxxxxx> wrote:

Mike,

I appreciate your efforts at driving this proposal forward, and will allow it in that interest.

However, please note any further changes that are more than editorial or adding participants will be subject to the approval of the Task Force before hearing.

 

All – please take the time between now and Thursday’s meeting to review and send comments / questions to the reflector, hopefully tomorrow.  As we all know our calls are limited 2 hours, so getting discussions happening prior to the call is key.

 

And I will remind everyone that in my role as chair:

  • The operation of the TF has to be balanced between democratic procedures that reflect the desires of the TF members and the TF Chair's responsibility to produce a draft standard, recommended practice, or guideline in a reasonable amount of time for review and approval by the WG. Robert's Rules of Order shall be used in combination with these operating rules to achieve this balance.

 

Please keep this in mind as we meet on Thursday.

 

Regards

 

John D’Ambrosia

Chair, IEEE P802.3cw Task Force

 

 

 

  

 

From: MICHAEL SLUYSKI <msluyski@xxxxxxxxxxx>
Sent: Tuesday, April 21, 2020 4:10 PM
To: STDS-802-3-DWDM@xxxxxxxxxxxxxxxxx
Subject: [802.3_DWDM] sluyski_cw_01_200416 proposed edits

 

Dear Colleagues,

 

 

 

I wanted to share a minor update to the baseline proposal that is posted on the .3cw  website Slide .  I will be asking John to allow this update before I present on Thursday.  A group of us have been working together for a few months to ensure we are able to make progress in the .3cw Task Force.  John posted this last week and I’m looking forward to getting wider feedback.  I would appreciate if anyone has any comments or feedback on the proposal that we could start a discussion on the reflector or send to me directly. 

 

 

 

And if anyone is interested in being included as a supporter let me know.

 

 

 

 

Mike A. Sluyski

 

System Consulting Engineer (SCE)

 

office 978.254.2773 | email:   msluyski@xxxxxxxxxxxxxx

 

3 Mill and Main Place #400, Maynard, MA 01754

 

 

 


To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1


To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1


To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1


To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1