Markdown Version | Session Recording

Session Date/Time: 03 Oct 2023 12:00

DETNET

Summary

The DETNET Working Group met for an open working session focusing on queuing and scheduling mechanisms. The primary discussions revolved around proposed updates to the draft-ietf-detnet-scaling-requirements document, particularly regarding high bandwidth utilization, jitter tolerance, and the impact of recent Raw (Reliable and Available Wireless) efforts being folded into DETNET. Participants also discussed the evaluation framework for proposed mechanisms, emphasizing the need for explicit mathematical expressions for latency bounds. A concrete end-to-end latency calculation example was presented to foster common understanding, but it was decided that further detailed discussion on the mailing list would be more productive. The Raw architecture draft was announced to be ready for Working Group Last Call.

Key Discussion Points

• draft-ietf-detnet-scaling-requirements Updates:
  • Proposed changes to Section 3.1.3 (mechanisms not requiring strict time synchronization), 3.4 (scalable to large number of flows and tolerate high utilization), 3.6 (clarifying "DETNET flows"), 3.7 (latency/jitter in complex scenarios, sync control loops), and 3.8 (non-periodic, lower latency requirements, support for multiple mechanisms).
  • Section 3.4 (Tolerate High Utilization): Discussion centered on clarifying that "tolerate high utilization" refers to the ability to guarantee latency even with high utilization by DETNET traffic, and not solely on improving utilization (e.g., through guard band reduction). The importance of considering bursts in addition to bandwidth was highlighted. Turles suggested focusing on DETNET traffic utilization and considering bursts.
  • Section 3.7 (Complex/Large Hops): The concept of routing calculation/resource scheduling being "tractable and implementable" was suggested over "linear relationship is expected." Jinu questioned the current explanation for why jitter bound should ideally not be a function of hop number, requesting more concrete reasoning.
  • Impact of Raw Integration: The integration of Raw efforts into DETNET prompted discussion about introducing a new evaluation criterion: "tolerate variable link latency/jitter" (proposed as 3.2.1). Pascal noted that wireless links (and other physical links like power line networking) exhibit such variability due to retransmissions, reflections, or physical changes, and that it's crucial for DETNET mechanisms to account for this bounded variability.
  • Section 3.8 (Multiple Mechanisms/Flow Types): The wording "lower latency requirements" for non-periodic flows was suggested to be clarified as "less tight" or "looser" requirements compared to hard latency limits.
• Evaluation Framework for Mechanisms:
  • A complete and agreed-upon evaluation template for new mechanisms is desired, specifically to adequately distinguish between existing TSN mechanisms and new DETNET proposals.
  • The addition of "tolerate variable link latency/jitter" (3.2.1) was seen as a crucial distinguisher given the Raw integration, even if it "moves the goalposts" slightly.
  • A sense of those present indicated that the new text concerning tight jitter and sync control loops in Section 3.8 might be better integrated under existing Requirement 7 (or a sub-bullet like 3.7.1).
• Latency Calculation Example:
  • Turles presented an example of a flow across 10 routers, competing with 100 other DETNET flows at each hop, to demonstrate worst-case end-to-end latency. The example aimed to highlight differences in how various mechanisms would calculate the latency bound and the challenge of simple summation of interference.
  • Jinu reiterated the need for all solution authors to provide explicit mathematical expressions for latency bounds to facilitate common understanding and fruitful discussion. It was agreed that this detailed discussion would continue on the mailing list.
• draft-ietf-detnet-raw-architecture Status: Pascal informed the group that version 14 of the Raw architecture draft has been published, addressing terminology changes, and is considered ready for Working Group Last Call.

Decisions and Action Items

• AI: Authors of draft-ietf-detnet-scaling-requirements (Pang and co-authors) to revise the text for Section 3.4 to focus on tolerating high utilization by DETNET traffic, considering bursts, and clarifying the distinction between guaranteeing latency and improving utilization. Pang (Quan) will provide example text on the mailing list.
• AI: Jinu to propose text for Section 3.7 regarding more concrete reasoning for the jitter bound's relationship with hop number.
• AI: Turles and Pascal to collaborate on and propose initial text for the new requirement 3.2.1 (tolerate variable link latency/jitter) on the mailing list, potentially using a GitHub issue.
• AI: Jinu and others are encouraged to propose revisions to the text from Pang's slides concerning tight jitter and sync control loops, suggesting how it might be integrated under Requirement 7 (e.g., as 3.7.1).
• AI: Authors of draft-ietf-detnet-scaling-requirements are encouraged to facilitate the use of GitHub issues for small text changes, pointing people to it via the mailing list.
• AI: All authors of proposed DETNET queuing and scheduling mechanisms are requested to provide explicit mathematical expressions for their mechanisms' latency bounds.
• AI: Turles and Jinu to continue the detailed discussion on the end-to-end latency calculation example via the DETNET mailing list.

Next Steps

• Continue discussions on the mailing list for updates to draft-ietf-detnet-scaling-requirements.
• The chairs will aim to schedule a discussion in Prague regarding a Working Group Last Call for draft-ietf-detnet-scaling-requirements.
• Solution authors are expected to update their evaluation slides (or provide input) against a revised template that incorporates new evaluation criteria, such as the proposed 3.2.1.
• The chairs will work to prepare a proposal for the next meeting on how to begin expressing preferences or making recommendations among the different DETNET queuing and scheduling mechanisms being considered.
• The draft-ietf-detnet-raw-architecture is anticipated to move to Working Group Last Call.