| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Yong – thanks for the presentation today. I wanted to capture some of my thoughts on the objectives proposed. We talked about most of them today, but I had prepared this email last week to try to help you
out, and forgot to send it. Getting the thoughts written down may be useful. Like you said, the ‘motherhood and apple pie’ objectives may not be as motherhood and apple pie… we should probably leave these for later – especially as most of these are “don’t break the existing standard”
kinds of things. “Preserve PLCA fair and equal access method” – needs more specificity. ‘fair and equal’ seems out of alignment with the aim of the project which is to give some traffic priority. Suggest we spend some time
as a task force defining what we mean by this beyond “Backward compatible with clause 148 PLCA defined in 802.3-2022”. This could mean that having a non-E-PLCA node on the mixing segment means all nodes revert to ‘classic’ PLCA. We should discuss. Preserve optional PLCA node ID allocation method – after discussion, I think you mean – “Preserve compatibility with D-PLCA defined in Clause 148 of 802.3da-2026” – need to think on the wording. Preserve optional Time Synchronization Interface (TSSI) – I think you mean “Support operation with optional Time Synchronization Interface (TSSI)”. (this seems like one we want to have E-PLCA still support
TSSI) Support interoperability with CSMA/CD – this one I think you clarified as possibly “Compatible with non-PLCA-enabled nodes on the same mixing segment” – note this will be at some reduced performance. We discussed
and you have suggested dropping this. I suggest if some disagree, we should continue discussing whether there is consensus on this as an objective. Support interoperability with Clause 147 multidrop – suggest modify to Support operation with Clause 147 10BASE-T1S multidrop and Clause 188 10BASE-T1M PHYs. On the other ones, I think we need to talk more on these, but the first two seem to overlap. Not quite sure what is meant…. • Specify methods to improve access latency and latency variability per node. • Specify methods to improve access latency and latency variability by frame’s class of service per node. First of all, it would seem that this has to always be by a frame’s class of service – even if there is only one class of service on a given data source – so I don’t understand the difference. If that’s right, then the class of service is never a “per node” thing – shouldn’t this just be: Specify methods to improve access latency and latency variability by frame’s class of service. And maybe it is “Specify at least one method to improve…”? On the last one you have, “Specify PLCA selection service client to be used by upper layer” – I think we specify the client INTERFACE. Like the LPI client, we don’t specify the internals of the client, just
its interface – how it signals PLCA. 802.1 may specify the client protocol itself… and who uses it the client is up to other specs than 802.3. So, suggest “Specify a PLCA selection service client interface” George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 |