IETF Deterministic Networking (detnet) - Open Working Meeting
Time: April 11, 2023 - 8p-10p (US Eastern Time Zone)
Zoom info: https://Dell.zoom.us/j/91506535175?pwd=MTJZUzFBTUJLcmVLTzNhT05zQUJsZz09
DO NOT USE IETF WebEx for this meeting!!
Organizer: DetNet WG detnet-chairs@ietf.org, David Black (tech advisor)
Reminder - this is an open working meeting to facilitate progress on the enhanced DetNet data plane. The initial focus is on queueing/scheduling mechanisms in DetNet nodes. No final decisions will be made in this meeting - the working group mailing list is the decision forum/venue.
(0) Quick intro (including Note Well slide), agenda bashing
(1) Process-oriented topics - requirements, draft contents, evaluation, etc.
Time: 30 minutes, could be longer
Discussion could include:
(2) In-depth presentations of two queueing/scheduling mechanisms
Time: 40-45 minutes each.
Could postpone one of these presentations if item (1) discussion takes longer.
Presentations expected to be ready for these two drafts (~30 mins of presentation + Q&A):
There will be opportunities in future open working meetings for additional in-depth presentations.
Lou Berger (WG chair)
David Black (Organizer, Tech advisor)
Don Fedyk
Toerless Eckert
Lin Han
Yuji Tochio
Jeong-dong Ryoo
Jinoo Joung (KR)
Peng Liu (CMCC)
Quan Xiong
Shaofu Peng
Taesik (ETRI)
Tianji
Xuesong Geng
Yizhou Li
Teoncheol Ryoo
Zongpeng du (CMCC)
(0) Quick intro (including Note Well slide), agenda bashing
Note Well slide shown: note-well_april_2023.pptx
Agenda bashing: None
(1) Process-oriented topics - requirements, draft contents, evaluation, etc
Discussion about evaluation criteria and impact (or not) of discussing evaluation critera beyond existing requirements draft.
David: Maybe each draft wants to come up with their own top 5 (where solution thinks it performs well/best).
TBD (Toerless): revise evaluation criteria draft, moving out TCQF evaluation into TCQF draft to start making evaluation criteria become more neutral - but very important for every proposal to think of their own critera as well!
Yizhou: can/do we have normative language for queuing mechanism ? IEEE does it, i do not see having it currently in IETF draft.
David: Should be fine to point to an IEEE documented algorithms.
David: Focus on scheduling mechanism, then assuming that there is going to be a mechanism, consider how the required signaling elements will be encoded. But separation is primarily meant to be to focus initial work.
David: We have way more encoding proposal options than actual scheduling/queuing mechanisms. So in my opinion more important now to focus/refine/compare those scheduling/queuing mechanisms separately from their encoding options. Whether/how to finally standardise the overall solution with scheduling and encoding (single / multiple documents) is still open.
DiffServ: RFC2474 (data plane encoding), RFC2475 (Architecture)
Yizhou: forwarding plane dependencies to the routing mechanism, e.g.: SRv6/SRH.
David: I suggest documenting applicability to different data-planes, such as SR(-MPLS/v6).
Toerless: All mechanisms proposed should be able to be made work with all steering mechanisms the IETF has specified (e.g.: SR-MPLS, SRv6/SHR, BIER, "MSR6"), but those mechanisms raise the questions how to combine headers for DetNet dta-plane with this steering data-plane. David: lets get to that point after understanding the scheduling mechansisms.
Xuesong: concern on the boundary between TSN standard and Detnet queueing standard (to be). I tried to explain that CQF is a stable TSN standard and can be used as a well-known reference. What TCQF/Cycle ID CQF proposed is to meet detnet scaling requirement document and to enhance the published CQF. So that should not be an issue. At the same time, it is a good thing IMO that its base reference CQF is a published TSN standard. This reminds me that it would be good to include stable reference to existing paper/standard and illustrate the enhacements added to meet the scaling requirement in the solution drafts.
David: Suggest test run of IEEE mechanisms against our requirements draft / evaluation criteria to show how they do not solve our large scale detnet requirements.
Peng Liu: Other proposal have no IEEE reference. David: This is fine (not to have a reference).
David: Would like to make sure requirements draft is stable so proposals can be checked against it. Would be great to have it stable by early May.
(2) In-depth presentations (only had time for ADN draft courtesy of level of interest and resulting discussion, will provide time for second one at next open working group meeting)
FAIR and PFAR are extensions of ATS that allow it to scale somewhat better, but all with pro/cons. Focus of draft is C-SCORE.
Toerless ? Actual proposal is primarily for C-SCORE (for large scale DetNets): Answer: mostly yes.
Toerless: jitter control mechanism is more general, can be separated from C-SCORE. Need clock drift/frequency synchronization to make this work (not simple in PTP hardware). Alternative to that synchronization is to use packet metadata to accumulate propagation delay for each hop (not simple to implement, although some analogy to PTP framework). Doesn't cover link jitter well (wireless links with retransmission are a serious example), would need to pick up link variability as part of that.
David: This is one of a class of techniques that trade variable jitter for fixed additional latency.