Re: [802.3_NGAUTO] potential objectives change

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

All – we already have adopted objectives for the study group, see http://www.ieee802.org/3/NGAUTO/NGAUTO_OBJ_01a_0117.pdf

Included in those objectives are ‘support optional auto-negotiation’ – so we don’t need an autonegotiation objective.

We also have ‘support optional Energy Efficient Ethernet’ which would provide at least one way to deal with asymmetric traffic.

We don’t need to add every feature in the objectives, and generally it isn’t great practice to put more detail in the objectives. I strongly suggest we keep our objectives focused on those that we need.

As such, I am a little concerned about the proposed objective: “Do not preclude power efficient solutions for use cases with asymmetric data rates. “

I have nothing against asymmetric data rates, but am having great difficulty understanding what we are trying to accomplish with this objective. As a PHY project, we can always support asymmetric data rates at the MAC. It seems that this either requires more work, and possibly technical decisions suited for the task force, or it is unnecessary.

Other than that, I support the objectives proposed in Stefan’s contribution.

-george

George A. Zimmerman, Ph.D.

President & Principal Consultant

CME Consulting, Inc.

Experts in PHYsical Layer Communications

1-310-920-3860

george@xxxxxxxxxxxxxxxxxxxx

From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Monday, February 06, 2017 12:15 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGAUTO] potential objectives change

Dongok,

if the group decides to adopt 3 speeds I guess some kind of extension to the existing 1pair autoneg would also be part of the work.

Regards,

Stefan

Von: 김동옥 책임연구원
Gesendet: Freitag, 3. Februar 2017 07:48
An: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_NGAUTO] potential objectives change

Dear

My question is not proper or not at this group.

For Separating the 3 speed, do you consider ‘speed check algorithm also’ like ‘ auto negotiation’.

Best regards

Dongok kim

From: Brett McClellan [mailto:bmc@xxxxxxxxxxx]
Sent: Thursday, February 02, 2017 6:09 AM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGAUTO] potential objectives change

George,

I believe the wording should be “up to at least 15m” instead of “for at least 15m”.

Or something similar to indicate that lengths less than the maximum are also supported.

I do support the approach of separating the 3 speed and link objectives as you showed.

Regards,

Brett

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 01, 2017 11:20 AM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGAUTO] potential objectives change

Stefan –

Thanks for the detailed contribution today (and thanks also to Helge, Olaf & Kirsten – it was a REALLY good discussion in my opinion). There are 2 separate issues I have with the objectives you’ve put to the reflector.

First, it is really important to try to separate different thoughts on the objectives. There is no penalty for having more objectives. It may make things easier.

Second, (and maybe more importantly, because the other is more about wording), are some thoughts on the asymmetric rate issue.

On the first issue – separating technical points in objectives:

Operation at different Ethernet rates end up having different requirements, and hence different objectives. Each speed has a different MAC interface (at least in rate – even when they are both based on XGMII.) It is safest to have them as separate objectives. It’s not such a big deal in the “MAC data rate” objective, but it is at the PHY and link segment level.

Separation makes it easier to get the important objectives passed, because when you combine things, you may bring in things that are more controversial. This is why I prefer separating them here even at the MAC level – 2.5Gb/s and 10Gb/s have had strong support, but we might have difficulty with the 5Gb/s objective (personally, I would like to see a 5 Gb/s objective as well):

· Support a data rate of 10 Gb/s at the MAC/PLS service interface (ALREADY ADOPTED)

· Support a data rate of 5 Gb/s at the MAC/PLS service interface (to adopt)

· Support a data rate of 2.5 Gb/s at the MAC/PLS service interface (to adopt)

If we have clear consensus we want 5Gb/s as well, then go ahead and combine to be:

· Support MAC data rates of 2.5 Gb/s, 5 Gb/s, and 10 Gb/s

(this follows the model of 802.3bz and 802.3cb).

More importantly, on the “Define a PHY and links segment” objectives, having them as separate objectives automatically gives you what you want with by making which rates get built into a part optional. Ethernet considers each rate as a separate PHY, not as a multi-rate PHY, and uses autoneg to link the rates. Inherently this means that building a PHY which only does 2.5Gb/s (and not 5 and 10) or does 5 Gb/s (and not 2.5 and 10), or a 2.5G/5G PHY (which can do both rates and autonegotiates (or a 2.5/5/10, or any other combination) is the implementers’ option. This way you get your “optional 5 Gbps” for free, in the normal Ethernet way. The market decides where the volume is, what is most cost efficient, etc. Standards compliance is done on a per-speed basis.

Also, the way you’d written it, I think there’s a problem. The 2.5Gb/s and the 5Gb/s would have to use the same link segment, and I suspect you didn’t mean that. For example, if 5Gb/s can only run on shielded medium, but 2.5Gb/s could otherwise use UTP, the objective would say we’d have to specify a shielded, wider-bandwidth link segment for both. For this reason, other similar PHY projects with multiple rates have separated their PHY/link segment objectives by speed. See the 802.3bz (2.5G/5GBASE-T project) for an example, at http://www.ieee802.org/3/bz/ngeabt_objectives_802.3WG_approved_0315.pdf , or the 802.3cb (2.5G/5G backplane project) at http://ieee802.org/3/cb/8023cb_Objectives-Rev_0316a.pdf Both of these call out two separate PHY / link segment objectives.

Therefore, I strongly prefer having the PHY/Link segment objectives spelled out as below: (note, I also fixed the typo Natalie mentioned “using for at least 15m” should be just “for at least 15m”

· Define the performance characteristics of an automotive link segment and a PHY to support 2.5 Gb/s point -to-point operation over this link segment supporting up to four (two?) inline connectors for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax).

· Define the performance characteristics of an automotive link segment and a PHY to support 5 Gb/s point -to-point operation over this link segment supporting up to four (two?) inline connectors for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax).

· Define the performance characteristics of an automotive link segment and a PHY to support 10 Gb/s point -to-point operation over this link segment supporting up to four (two?) inline connectors for at least 15m on at least one type of shielded automotive cabling (e.g. STQ, STP, SPP, Coax or Twinax).

Now, on to the important one: “Do not preclude power efficient asymmetric bandwidth solutions for application.”

Usually, application-level objectives are above our pay-grade. We are an 802.3 PHY project and therefore work below the 802.3 MAC (therefore we are Layer 1 on the OSI stack). However, it is interesting you mentioned this as a “do not preclude”. I can’t think of anything a PHY project can do which would preclude asymmetric applications. Some reflector discussion on this would be useful.

On the wording, the term “bandwidth” is problematic. Since this is a PHY project, bandwidth can either mean frequencies used (asymmetric spectra) or it can mean rates offered. For example, an asymmetric EEE solution, which shut down the opposite direction when not in use, could achieve great power savings, but would use the same transmit spectrum in each direction when operating. I think you might mean something more like the following:

· Do not preclude power efficient solutions for use cases with asymmetric data rates.

Again, thanks for your detailed contribution today and for the follow up work.

-george

From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Wednesday, February 01, 2017 9:34 AM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGAUTO] potential objectives change

Hello all,

started wordsmithing the objectives after the discussion. I let this proposed objectives circulate on the reflector while I will enjoy a glass of “after work wine”:

I try to include the asymmetric bandwidth need only on application layer, but keep options open by delete the “only”.

I added 2,5Gb/s as mandatory on the MAC/PLS, while the 5Gb/s are optional.

I added the 5Gb/s on both PHY objectives as an optional speed.

With this the Task Force is open to drop the 5Gb/s if it turns out to be useless or not doable…

This also clarifies which points need to be started working in the TaskForce first.

· Support full duplex operation. [delete the word “only”]

· Do not preclude power efficient asymmetric bandwidth solutions for application.

· Support data rates of 10 Gb/s and 2,5Gb/s and optional 5Gbps at the MAC/PLS service interface.

· Define the performance characteristics of an automotive link segment and a PHY to support 2.5 Gb/s and optional 5Gb/s point -to-point operation over this link segment supporting up to four (two?) inline connectors using for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax).

· Define the performance characteristics of an automotive link segment and a PHY to support 10 Gb/s point -to-point operation over this link segment supporting up to four (two?) inline connectors using for at least 15m on at least one type of shielded automotive cabling (e.g. STQ, STP, SPP, Coax or Twinax).

· Support operation in automotive environments (e.g., EMC, temperature).

Waiting to see the comments on this proposals tomorrow J

Regards

Stefan

Von: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Gesendet: Dienstag, 31. Januar 2017 16:16
An: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Betreff: [802.3_NGAUTO] potential objectives change

Hello Georg, Hello all,

in principal I agree with your proposed change. Whatever we develop should work under automotive conditions.

However I see the objectives as a “bucket” and therefore before we agree on this single change, we should look at the other objectives too.

There are other objectives stating 10Gbps as well and we may need to put together speed grades and cabling options individually.

As I will show in my slides on the call tomorrow, other objectives need to be re-considered as well:

· “Support a data rate of 10 Gb/s at the MAC/PLS service interface” change to “Support a data rate of 10/5/2,5 Gb/s at the MAC/PLS service interface”

· Define appropriate cabling options to be considered for each intended speed grade.

For now this is just the short listing of further objectives I would like to consider to change as well, the details and arguments will be presented tomorrow.

Gruß/Regards,

Stefan Buntz

Mercedes-Benz Cars Development, Daimler AG

Group Research & Advanced Engineering

Safeguarding Hard & Software

HPC: U059 – Dep.: RD/FEQ

Phone: +49 731 505-2089

Mobil: +49 176 30 90 51 44

Fax: +49 711 305 216 45 95

E-Mail: stefan.buntz@xxxxxxxxxxx

Address for visitors:

Buildung 10

Room 3.2.022

Wilhelm-Runge-Str. 11

D-89081 Ulm

Germany

Von: NATALIE WIENCKOWSKI [mailto:NWIENCKOWSKI@xxxxxxx]
Gesendet: Dienstag, 31. Januar 2017 15:44
An: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_NGAUTO] potential objectives change

George,

I would prefer not to change this until we have another objective approved which includes 10 Gbps and a cabling type as we need 10 Gbps.

Thanks,

Natalie Wienckowski

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, January 30, 2017 6:31 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGAUTO] potential objectives change

I was considering our objectives, and the expansion to include generalization on speeds and media types, and looking at what we had adopted that was specific.

The 10Gbps rate for the MAC is necessary (and we’ll have to add new rates for any additional speeds), but the “operation in automotive environments” objective could be made generic.

To make matters worse, right now it reflects a media choice that we don’t have a PHY or link segment objective for – “single pair shielded balanced copper cabling”. We have discussed the generalization to using coax or twinax, and even optical PHYs – these would need their own “automotive environments” objectives, making the objectives clunky, and having this objective spell out more than it needs to.

As a result, I think it would be better if we collapse the objective to refer only to the environment, and leave the media types and rates to their own objectives – each needing to operate in an automotive environment.

So, I would seek feedback on the following objective change:

Change from:

· Support operation at 10Gb/s in automotive environments (e.g., EMC, temperature) over single pair shielded balanced copper cabling.

To: