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

Re: [802.3_NGECDC] Comments on 10BASE-T1S differentiated services slide deck

Hi Peter,

Please see my responses in your 10/17 email below.

Also, please allow for the following clarification: A key point of feedback during our NEA presentation was that we are getting into the solution space prematurely. I believe this feedback makes sense. Some of your comments are responding to the technical approach outlined in the deck (the ‘how’). I will be glad to respond to those. Please note that for the upcoming plenary our intention (in line with the feedback received during NEA) is to focus more on the 'what' and the 'why ' (to some degree described on slides 10 to 13).

 

Thanks again, Peter, for this valuable input! It would be great if we can find some time to talk in person during the Plenary.

 

Regards,

Markus


On Tue, Oct 28, 2025 at 11:27 AM Peter Jones (petejone) <petejone@xxxxxxxxx> wrote:

Markus,

 

Thanks for the response.

 

We are all going to be busy in Bangkok. To prepare for discussions in Bangkok, I’d appreciate some responses to the detailed points before we get there.

 

Regards,

Peter

_______________________________________________________________

Peter Jones               Distinguished Engineer,

                          Cisco Networking Hardware

                          Chair, Ethernet Alliance

Mobile:                   +1 408 315 8024

Email:                    petejone@xxxxxxxxx

Web:                      https://about.me/petergjones

Webex:                    https://cisco.webex.com/meet/petejone

Book a call:              Book time with Peter

_______________________________________________________________

 

From: Markus Jochim <markus.jochim.802@xxxxxxxxx>
Sent: Saturday, October 25, 2025 9:26 AM
To: STDS-802-3-NGECDC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGECDC] Comments on 10BASE-T1S differentiated services slide deck

 

Thank you Peter!
Yong and I will make sure to consider this valuable feedback when revising the consensus deck in preparation for a CFI.

We are btw. not planning for a CFI in November and instead will use the Nov. plenary to talk with various experts (discuss the need, socialize the idea for low latency support in 10Base, collecting input).

 

Looking forward to talking with you in Bangkok!

 

Thanks,

Markus

 

On Fri, Oct 17, 2025 at 9:00 PM Peter Jones (petejone) <00000b5d1d72f221-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Warning – long detailed email.

 

Folks,

 

I’m sorry that I missed the meeting on this topic, but I was vacationing in Denmark at the time.

 

I have several comments on the Consensus Building for 10BASE-T1S Differentiated Services (v1) presentation that I would like to offer:

  1. I’m sympathetic to the problem described on slides 11/12/13. I think of this as running mixed traffic types on shared media when the stations have significantly different expectations/requirements of the network performance.

    MJ: Yes, that is a good way to think about it. It will need to be discussed whether it is sufficient to assume different stations connected to the shared media to have different latency requirements, or if one would need to assume that single stations may have different types of traffic that have different latency requirements. See last bullet point on slide 10.   

  2. We need to be VERY careful with the term “Differentiated Services”. People will very reasonably assume that this is trying to deliver DiffServ(https://en.wikipedia.org/wiki/Differentiated_services) on the shared media and I think that’s beyond our scope.

    MJ: Noted. I think in a broader sense the term fits, but if a causes confusion, then we can work around it/avoid using it.

  3. PLCA provides a bounded maximum latency (e.g., number of nodes * MTU) for transmissions even when running at very high utilization.

    MJ: I agree. We acknowledge this on slides 9 and 10.

  4. PLCA normally treats all nodes equally but does provide some ability to allow specific nodes to send more than one packet when it’s their turn (PLCA burst mode – see 148.4.4.1 PLCA Control state diagram). Burst mode allows adjustment of the bandwidth allocation but using it increases worst case latency.

    MJ: I agree with your observation regarding burst mode and with the conclusion that it increases worst case latency. Even if we were to assume that there is only one node N with low latency traffic on a link and if we assume you would allow only node N to burst, then
    1. N may be able to send multiple frames in single cycle and can thereby reduce latency for such frames.
    2. a frame F that becomes available at N the moment N finished transmission and the TO went to node N+1 would still have to wait for a full cycle, which can be long, if all other nodes leverage their TO and transmit.

  1. Slide 14 “Differentiated Services Concept (1/4)” proposes to have nodes configured to deliberately skip TOs in some cycles, e.g., “only use TOs in every Nth cycle”. I think this is simpler than having nodes with multiple PLCA nodeIds as mentioned in slide 7).
    1. As I understand slide 14, different types of nodes (e.g., medium latency, best effort) deliberately skip TO’s to reduce the worst case latency for the higher class nodes.
    2. It may be worth using a “node transmit probability” approach, e.g., best effort nodes only transmit on 25% of their TOs, rather than specifically control which cycles a given node can transmit on.
    3. I think the “node transmit probability” approach would also address the maximum number of nodes transmission per cycle.
    4. I “think” this is a tractable problem that could implemented mostly with changes to the exit conditions from WAIT_TO in PLCA Control state diagram.

MJ: For the reasons mentioned above I don’t want to get too deep into the solution space (the how) by exploring alternative approaches, but please allow me to note that transmit probability based approaches would not give us the guaranteed reduced maximum latency we are looking for (as describe on slide 10). Reason being the lack of determinism that results in having no guarantee that there won’t be cycles where all nodes are transmitting.

  1. I’m not sure I understand what is being proposed in Slide 15 “Differentiated Services Concept (2/4)”.
    1. It’s still per node, but what is the benefit of using “(cci + oi) mod mi = 0” as the control to use or skip a TO?

MJ: Purpose was to show how a node (with just two config parameters and a simple formula that can easily be implemented in hardware) can determine in which cycle is does/doesn’t have permission to transmit. There are probably several alternative approaches one could think of. Probably a point for discussion once there is alignment on the “why” and the “what” and we get deeper into the solution space.

  1. Slide 16 “Differentiated Services Concept (3/4)”  wants to provide “differentiation” between nodes and classes of service within nodes.
    1. As a reminder, the IEEE 802 MAC service definition (802.1AC-2016) uses an 8 bit priority field in the Service primitives(14.2).

                       i.   Side note, the priorities are not straight highest to lowest. Highest to lowest is 7,6,5,4,3,2,0,1.

    1. The Ethernet convergence function (802.1AC-2016 13.1) ignores the priority parameter, so the MA_DATA.request primitive (802.3-2022 2.3.1) does not include any indication of packet priority or class.
    2. Once the MA_DATA.request primitive has been invoked, you can’t invoke it again until the first packet is done.
    3. It proposes to have multiple PLCA nodeIds, and multiple transmit queues, per node. I think we could get away with a single nodeId and a scheduler between transmit queues.
    4. I think the closest analogy currently in 802.3 is the MAC Merge sublayer (Clause 99), where two instances of the MAC service are presented to the MAC Client and the MAC Merge sublayer controls which MAC (eMAC or pMAC) has access to the media when they conflict.
    5. MAC Merge relies on co-operation with 802.1Q, see 6.7.2 Frame preemption. This maps priority values (0-7) representing queues to the express(eMAC) or the preemptable(pMAC).
    6. The effect of this is to split the 8 queues per port (see 802.1Q 8.6.6 – 8.6.11) into N queues attached to the eMAC and 8-N queues attached to the pMAC.
    7. The proposal on Slide 15 looks like it could be addressed using a similar approach as MAC Merge. This would require significant investigation, and co-operation with 802.1 to amend 802.1Q appropriately if it went forward.

MJ: A lot of good pointers, observations, and suggestions! On slide 10 we are leaving it open whether the ability to customize/fine tune max latency should be on a per “node basis” (similar to the example shown on slide 15), or on a “per node and per PCP code basis” (similar to the example shown on slide 16). This will be one of the points we intend to collect input on in Bangkok and may determine if this work would require 802.1 collaboration, versus being an 802.3 topic only.

 

Executive summary:

  1. I can see how changes to the PLCA Control subclause could support nodes selectivly ignoring TOs to reduce the worst case delay for other nodes to access the media, aka per node prioritization.

    MJ: I think this sums up it up very well.

  2. I think that per node, per class is a lot more complex and requires us to go down a “MAC Merge” like approach.

    MJ: A good topic to explore deeper during the study phase. Clearly “per node, per class” would drive the need for an interface to MAC Services.

  

Regards,

Peter

_______________________________________________________________

Peter Jones               Distinguished Engineer,

                          Cisco Networking Hardware

                          Chair, Ethernet Alliance

Mobile:                   +1 408 315 8024

Email:                    petejone@xxxxxxxxx

Web:                      https://about.me/petergjones

Webex:                    https://cisco.webex.com/meet/petejone

Book a call:              Book time with Peter

_______________________________________________________________

 

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

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

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