[802.3_NGECDC] 10BASE-T1S Differentiated Services CFI

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

I was looking through the deck posted at https://www.ieee802.org/3/ad_hoc/ngrates/public/calls/26_0609/802-3_CFI_Differentiated_Services_10BaseT1S_CFI-v7e_wo.pdf

trying to understand what the scope of the proposed study group would be, particularly in light of the comments of Peter Jones.

I believe the presentation does a good job laying out a need, and showing simulation results for a possible solution at the physical layer. Where I am foggy after reading it is just how (and from/to what) criticality of traffic, availability of media, and any necessary control information might be conveyed. How the proposed functionality might interact with 802.1 or other non-802.3 layer functionality isn't clear to me, and that boundary seems key to defining the scope of any proposed study group and ultimately project. I would like to see that boundary at least mentioned in the deck (or mentioned more prominently if I missed it).

The CFI call states (at the end) "This is a call for interest to initiate a Study Group to explore the market requirements for an interoperable solution and to develop a PAR and CSD for PLCA Multidrop Latency, Jitter, and Scalability Enhancements."

This suggests that the scope of any proposed PAR would be all internal to the PLCA RS. It mentions "mixed criticality traffic" but does not mention anything about communications with the PLCA RS, which would seem to be important. Somewhere the availability of the medium, and the criticality of traffic would need to be communicated, and this is where functionality outside of 802.3 may come into play.

In the deck I see plenty of mentions of the PLCA RS and 10BASE-T1S, which could lead one to believe this is purely a physical layer project. However, I also see mentions of priorities of traffic, which make me think that some primitives above the physical layer and perhaps to a client (but not the client itself) might be in scope. In private conversations with others, I hear that such primitives and definition (perhaps similar to what Peter Jones has suggested) may be essential components of the solution. If the Study Group were to be purely focused on the PLCA RS, I would be concerned such elements might be considered out of scope.

Having at least the primitive interface in scope would seem to be essential to success - otherwise we are limited to a model where any traffic or service differentiation is limited to identifying it with the MAC the traffic came from (similar to clause 99). Further, I would expect higher layers would need to know at least the state of the RS cycle in order to control latency and jitter. I'm missing the mention of what seem essential interfaces in the proposed CFI deck. it would be nice to have a short discussion indicating whether or not such interfaces were in scope. It would be helpful to see a diagram or a short discussion of different ways the priorities might be sorted and different options for interfacing with higher layers, should that be desired in the future. I believe that the primitives that Peter is expounding may be a useful construct - there may be others as well.

Further, understanding what primitives might be used also helps us understand the relationship of this project to any potential 802.1 project (concurrent or in the future).

I also want to get clarity - from the CFI statement, this appears to be a proposal for a "PAR study group" - to draft a PAR & CSD responses.

Exploration of a problem should be focused on writing that PAR & CSDs. The NEA industry connections activity can be (and has been) used for broader exploration of problems. In the deck I see the statement: "We need to study the latency, jitter and scalability related concerns to get a deeper understanding of the issues that enables us to define scope and objectives of a subsequent project." - I think this unintentionally removes clarity that we may be ready to write a PAR. We don't need to know the technical specs to be hit - but we need to know the function well enough to know what the scope of a project (and it's feasibility/distinct identity/etc) would be. I think that relates to the issue of primitives and where the effort fits in the architecture.

So, in closing - (as an individual), I'd like to see the following in the deck:

if interfaces to non-802.3 functions (primitives, interfaces to clients, etc) to communicate and control mixed protocol traffic are indeed considered in scope of the project, some discussion of that point in the CFI deck would be useful to avoid future arguments on scope. (and to perhaps help understand where the authors think 802.3 ends and others, e.g., 802.1 begin)

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

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