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

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

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.
  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.
  3. PLCA provides a bounded maximum latency (e.g., number of nodes * MTU) for transmissions even when running at very high utilization.
  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.
  5. 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.
  6. 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?
  7. 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.

 

 

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.
  2. I think that per node, per class is a lot more complex and requires us to go down a “MAC Merge” like approach.

 

 

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