Minutes for DetNet Interim 2024/01 (virtual)

WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet

Datatracker: https://datatracker.ietf.org/group/detnet/about/

Tuesday, February 6, 2024

13:00 - 15:00 (UTC)
https://www.timeanddate.com/worldclock/fixedtime.html?msg=DetNet+Interim&iso=20240206T13&p1=1440&ah=2

Materials:
https://datatracker.ietf.org/meeting/interim-2024-detnet-01/session/detnet

Note taking:
https://notes.ietf.org/notes-ietf-interim-2024-detnet-01-detnet?edit
Meetecho:
https://meetings.conf.meetecho.com/interim/?group=f2fb81ce-1c4a-418c-8621-b05fa6686ef3

Chat: https://zulip.ietf.org/#narrow/stream/detnet
Session ICS:
https://datatracker.ietf.org/meeting/interim-2024-detnet-01/sessions/detnet.ics

YouTube: https://www.youtube.com/watch?v=GI3VsgQpI7M

Slot Start Time (UTC) Duration Information

#1 13:00 10 min Title: Intro

Presenter: Chairs

No questions from the attendees. Agenda bashed.

#2 13:10 50 min Title: Some Taxonomy Considerations

Presenter: David Black

David Black (DB) presents the slides
(https://datatracker.ietf.org/meeting/interim-2024-detnet-01/materials/slides-interim-2024-detnet-01-sessa-2-taxonomy-considerations-00)
summarizing the progress of previous discussions and goals of the
taxonomy discussion.

János Farkas (JF): Evaluation should also include evaluation against the
scaling requirements.

Shaofu Peng (SP): better to consider multiple solutions. Consider time
based vs delay based.

Antoine Fressancourt (AF): during last IETF meeting it was agreed to
have a common set of use cases against which the solutions could be
evaluated. Is it the intention to categorize solutions or do a
performance evaluation even if they belong to different categories?

JF: we are contributions-driven, and no contributions on use cases
received. Agrees it would be good to have groupings, but groupings alone
unlikely to be sufficient.

Jinoo Joung (JJ): taxonomy draft to be presented today does not have the
applicability part, but it can have that in the future. This can be
discussed during the meeting.

SP: initial discussion on the mailing list on common topologies. We have
some thoughts on this and can present when available.

DB: interesting to have the common topologies.

JJ: for some use cases the topologies might be simple, but in others it
can be complex. Bearing that in mind, not sure there is a common
topology that is useful for every use case.
DB: agrees.

Lou Berger (LB): prefers not to merge topology (queueing use cases) and
taxonomy documents.

#3 14:00 50 min Title: Dataplane Enhancement Taxonomy

Presenter: Jinoo Joung

Draft: https://datatracker.ietf.org/doc/draft-joung-detnet-taxonomy-dataplane/00

JJ presents
https://datatracker.ietf.org/meeting/interim-2024-detnet-01/materials/slides-interim-2024-detnet-01-sessa-3-dataplane-enhancement-taxonomy-00.pdf.

Four broad categories of proposed mechanisms:

1. CQF variants (e.g., TCQF, CSQF)
2. FQ (Fair Queueing) variants (e.g., C-SCORE)
3. TAS variants (e.g., TQF)
4. Deadline (EDF - Earliest Deadline First) variants.

Yizhou Li (YL) on slide 5: there is some information included in some
IEEE standard. IS this paper considering this?

SP: (missed his comment)

Norman Finn (NF): CBS is not part of ATS. I would not put anything at
higher priority than ATS (at the final selection, you wouldn't have any
higher priority that is not detnet traffic).

DB on slide 6: s/Meets the criteria/has the property

NF (on slide 8): as presented you can have an inference on the latency
bound. But in practice a bin can be filling and consume at the same
time. The per-hope delay can be less than the cycle.

JJ: ECQF not described in the draft, but brought to the presentation for
completenes. Work to be done to add it including the discussion.

NF (on slide 10): bursts are buffered at the edge, so there are no
bursts at the body of the ECQF network.

NF (on slide 12): withouth some kind of clock sync e2e, there is no such
thing as one way delay.
JJ: every solution requires some level of sync.

NF (on slides 15): disagrees that ATS and ECQF are class level
solutions.

YL (on slides 13 and 15): it looks that the class level is priority
based TS, cascaded after traditional ATS, so two things rather than one.

JJ agrees after some discussion that ECQF is not class-level.

NF: do we have the same assumption about zero-congestion loss? is that a
criteria?
DB: detnet assumes zero-congestion loss.

NF: is buffer space requirements a consideration you are interested in?

NF: non-conserving algorithms can have smaller buffer requirements.

JF: Is buffer-space a new taxonomy? or just bind it with
work-conserving? Linked with another question: is the group happy with
this first shot of taxonomy?

JJ: As it was pointed out by Quan on the list: latency is only one
aspect, jitter (latency variation) and buffer size are futhre aspects,
which should be considered in the taxonomy.

JJ: In-time mode and on-time mode have different properties

YL: how do we want to use this draft? we can consider the taxonomy the
bigger dimension to categorize solution groups. Within each of the
groups the could be smaller dimensions to improve.

NF: one item not seen is computation required to create a new
reservation (strictly data plane, related to scaling).

NF: state to add a flow can be something to be considered in the
taxonomy (related to scaling).

JF: implementation complexity should not be part of the taxonomy, but
the point from NF about complexity when adding a flow should be.

NF: heard 2 different things from JF and DB. Taxonomy is great to help
identifying to understand the different solutions and to compare them.
Buffering falls out of work conservativeness. Whether need to touch each
node is just an endineering thing. But JF says that the taxonomy might
help to decide/select solutions. Does not like doing charts assigning
points for selection, if we were going to do so, then moe things should
be considered.

JF: does not want to have such a chart either. Trying to figure out how
to wotk with all the many types of solutions that there exist.

DB: good initial top-down taxonomy, providing visibility into which ones
are similar to each other. Taxonomy should not limit us on what
algorithm to standardize.

JJ: Standardizing an algorithm from each of the 4 broad categories could
be a good approach.

Summary from discussion

• Four broad categories of proposed mechanisms:
  1. C-SCORE (as an example of FQ (Fair Queueing) variants)
  2. EDF (Earliest Deadline First) variants
  3. TAS (Time Aware Shaper) variants (e.g., TQF)
  4. CQF (Cyclic Queueing and Forwariding) variants (e.g., TCQF,
     CSQF)

DB: Taxonomy helps us the define different classes of algorithms but
does not help to decide whether an algorithm is suitable to standardize.

JJ: Based on categories, one can choose which solutions to proceed with.
Select one soltuoin ind each category could be a good start.

JF: Current taxonomy is a good starting point and foundation for
categorization discussion.

#4 14:50 10 min Wrap up and Next steps

JF: highlight that we are contribution-driven. Futher contributions are
encouraged, joint or individual. Also (queueing centric) use cases,
e.g., specific topolgy and flows. Thanks for the discussion.

DB: thank you very much JJ for the draft and the presentation, enabling
having a deep technical discussion today.

JJ: thanks to all the contributors of the draft.

Next steps: Chinese new year coming and then not much time before next
IETF F2F meeting. Mailing list is the primary forum for discussion. Next
virtual meeting before the July meeting is to be discussed during IETF
119.

JJ: Will update taxonomy draft for IETF 119 in Brisbane.

14:55 Adjourn