Minutes for 0324: Use of Tick in List Execute state machine (802.1Q)

Standard: IEEE Std 802.1Q-2018 Clause: 8.6.9.4.16 Draft with fix: Submitted: 2021-05-06
Show Request Show Preformatted Request
Date Meeting Text Status
2021-06-01 Jun 2021 Concall The request as briefly reviewed and it was agreed to requestor to attend the next maintenance call to further explain the request. Technical experts review
2021-06-08 8 Jun 2021 Concall The requestor reviewed the parts of 802.1Q that highlight the issue. The main concern is with the Note that follows the text describing the implementation of the Tick boolean variable. The non-normative note references the TickGranularity managed object which is intended to provide the actual granularity of the Tick clock in units of 1/10 of ns. However, the Tick variable is intended to run on 1ns intervals and the state machine current depends on this specification, so having a TickGranularity other than 1ns creates a problem for the operation of the state machine. Simply deleting the Note is not a sufficient resolution to the issue. There was some discussion about when this text was introduced in Qbv and a reference to comment #15 of Qbv/d2.1 was provided: https://www.ieee802.org/1/files/private/bv-drafts/d2/802-1Qbv-D2-1-dis.pdf. It was also suggested that the following previous contribution could be useful, though no discussion on this contribution occurred and is provided for reference: https://www.ieee802.org/1/files/public/docs2014/bv-admin-parameters-tony-jeffree-1214.pdf. It was agreed that a couple of approaches could be considered here and that further discussion of the options will be needed. One approach is for the internal implementation to adjust the gate controls in accordance with the internal delays caused by clock inaccuracy or different granularity. Another approach is for the implementation to punt this to the management station that creates the schedules and have that station consider a different Tick granularity in a schedule unique for the device. In either case, it would be helpful for the implementation to provide some more information about the accuracy of the clock or delays in responding to Tick events. Further discussion is required at a future meeting and it was suggested to revisit the initial motivation for the current text, use a whiteboard to capture the discussion and to eventually provide specific text for 802.1Q to clarify the solution. Technical experts review
2021-09-24 20 Sep 2021 Interim The group prefers to discuss the item in TSN with a contribution to facility the discussion. The requestor agreed. One solution to consider is to remove the Tick handling from this state machine and create a separate timer state machine the only counts down to zero, at whatever tick granularity it operates at, but reaches zero at the requested amount of ns. The exit condition would be changed to the signal when the timer state machine reached zero. Another approach could be to decrement exit timer by Tick. Currently exit timer is set to timer interval. Alternatively we could change the definition of Tick. It would be preferred to not change the meaning of the managed objects (MIB/YANG) Technical experts review
2022-01-04 17 Jan 2022 Interim The current plan of action remains relevant. In addition, the editor of 802.1Q-Rev suggested defining '=' in the list state machine to indicate the timer is within the resolution window to trigger the action. This change can be reviewed in a future version of 802.1Q-Rev. Technical experts review
2022-03-11 8 Mar 2022 Plenary No change was made to the latest version of Q-Rev, lacking a technical proposal. A proposed solution needs to be discussed in a future maintenance meeting. The window for inclusion in Q-Rev has been missed and a future vehicle will need to be determined, after a solution has been reviewed. Technical experts review
2022-05-13 10 May 2022 Interim No change Technical experts review
2022-07-12 12 Jul 2022 Plenary Agreed to schedule a Maintenance TG call after the July 2022 Plenary to specifically address and resolve the issue. The TG chair agreed to obtain commitments from stakeholders and schedule the meeting. Technical experts review
2022-08-10 9 Aug 2022 Concall Continued agreement that the definition of Tick as a Boolean variable that is asserted True every ns is neither sufficient nor accurate enough for today's implementations. The leading proposal is to replace ExitTimer with a new variable ExitTicks that operates in the units of TimeGranularity for the DELAY loop in the list execute state machine (Fig 8-20). The Tick variable would then be updated to remove the description of the 1 ns interval. In order to deal with frequency variations in real implementations, the equality tests "==" should be changed to ">=" or "<=" where appropriate. A review of other timer comparisons should be performed to determine if the equality test could be replaced (e.g. Figure 8-19). There was discussion about adding a management variable and PICs entries that define the amount of frequency deviation an implementation may have. The bounds on this frequency deviation should be discussed with the experts in TSN working on the various profiles. The following list of items were described as next steps: 1. Change ExitTimer to ExitTick in the FSM diagrams 2. Remove 1 nanoseconds resuolution from the (nominal!) definition of Tick, allow lower resolutions. 3. Consider changing the transition in Figure 8-19 from "==" to ">=" 4. Change exitTimer semantics to be the less than or equal time exitTicks 5. Introduce management parameter for the frequency deviation bound requirement on Tick 6. Discuss in TSN and the 802.1 TSN profile experts: Is a frequency deviation bound requirement on Tick (e.g., ppm), and if yes, what it should be. 7. Check consistentcy throughout document Technical experts review

Back