WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
Datatracker: https://datatracker.ietf.org/group/detnet/about/
13:00-15:00 GMT (13:00-15:00 UTC)
Room: Liffey A --
https://datatracker.ietf.org/meeting/121/floor-plan?room=liffey-a
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20241107T130000&p1=78
Materials: https://datatracker.ietf.org/meeting/121/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-121-detnet?bothch
Meetecho: https://meetings.conf.meetecho.com/ietf121/?session=33377
Onsite tool: https://meetings.conf.meetecho.com/onsite121/?session=33377
Video stream: https://meetings.conf.meetecho.com/ietf121/?session=33377
Audio stream: https://mp3.conf.meetecho.com/ietf121/33377.m3u
Chat: https://zulip.ietf.org/#narrow/stream/detnet
ICS: https://datatracker.ietf.org/meeting/121/session/33377.ics
YouTube: https://www.youtube.com/watch?v=cVglHWHM6CM
Session recording:
https://meetecho-player.ietf.org/playout/?session=IETF121-DETNET-20241107-1300
Presenter: Chairs
Jon Scudder: if we hope to have someone review the last incoming liaison
document, which is large, perhaps we need to actually more actively
solicit a volunteer. Not sure it is important for us to review this
particular document, just an observation.
Toerless Eckert: How many RFCs make sense to steer the industry? We only
need 1 per category, if they don't overlap. But it may not be the best
approach, because these things are so novel - perhaps make use of
experimental and informational to examine the space.
Lou Berger: You can think of the categories as classes of solutions. If
the group decides we need to conduct experiments, we still want to
categorize the solutions. We will discuss more with the taxonomy
document. Tease out from the functional categorization. Bin the
solutions. One solution per category would be optimal. We certainly
would not want to do more than one standards track solution per
category.
Link:
https://datatracker.ietf.org/doc/draft-ietf-detnet-controller-plane-framework/07
Presenter: Xuesong Geng
Xuesong Geng: thanks Kiran for reviewing the document. Three aspects.
Clarifications aspect. A second aspect is where there are places that
are unclear about policies around encryption and policy related
mechanisms about admissions control. Third aspect is around protocol
extensions and other related working groups. For this part, it will be
left as further work for the WG, unless the WG thinks it needs to be
included in this version. Include in the liaison work requested by
Janos.
Pascal Thubert: Things in the RAW architecture may not be reflected in
this document. As a result, we should work more closely.
Xuesong Geng: Carlos has given for RAW, but may not fully cover, so
let's work together. A question to the chairs, do we need to cover RAW
considerations in this document.
Lou Berger: Given that the two documents are going through last call at
the same time, they should align with each other. Not a lot of work.
Likely just a couple paragraphs, maybe a new section, maybe not even be
that much. I've also started my shepherd review of this document, there
are some additional comments that will need to be addressed. We will
need another version, to address comment and ensure the document
alignment.
Janos Farkas: We will not be asking for new work, but rather
harmonization.
Carlos Bernardos: I agree that there should not be any
RAW-specific/separate section.
Lou Berger: Let's look at the text changes needed then decide on updated
sections, sub-sections, etc.
Link: https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/21
Presenter: Pascal Thubert
Lou Berger: is it clear what the proposed changes are?
Pascal Thubert: RCPF and LCPF, the orientation function (part of the
OODA function).
Janos Farkas: Please summarize on the list.
Pascal Thubert: Clarify that this is just a piece of the generic
architecture.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dataplane-taxonomy/02
Presenter: Jinoo Joung
Lou Berger: Note we are talking about categories for which we want to
find solutions. Discussion will be really important to identify the
right categories. Perhaps call them classes of solutions instead.
Janos Farkas: Deliberate distinction between functional characteristics
and categories.
Lou Berger: Listing strengths and weaknesses, as well as recommended
solutions for WG adoptions, both helpful, but I don't believe they
belong in the Taxonomy document. That could be a separate analysis work,
and as a stand-alone document would be very good. But take on the
characterization work in this document.
Rod van Meter: The figures in the draft right now as ascii versions, the
source and destinations are not listed as yet as bidirectional, but
assume they are bidirectional?
Jinoo Joung: I will include that.
Figure 1 (ref topology 1) and 2.
Rod van Meter: The ring topology also needs specificity. Unidirectional
vs bidirectional.
Janos Farkas: Align with the RFC we have on the service information
model.
Quan Xiong: For the 6 functional categories types and each function
characteristic type, if we take al the combinations it is a very large
number of catergories, please clarify.
Lou Berger: Looking at the functional categories by themselves would
result in too many options. We are envisioning a new section (following
4 or 5) perhaps named classes, where we are looking for solutions. We
want the WG to come up with the set where we want to drive standards or
solutions. Then start adopting. They are certainly not functional
characteristics, rather groupings that make sense. We'd like the group
to come up with a collapsed list and add it to this documents. We can
then map specific solutions to the collapsed list.
Lou Berger: Will look forward to the solution analysis, but don't think
it should be in this document.
Jinoo Joung: Instead of 2^6 solutions, combine some of the categories.
Further, only some are feasible. Envisioning around 10 solutions at
most.
Janos Farkas: I am hoping for fewer than the number of functional
characteristics.
Sebastian Robitzsch: About the flow sets, is that what you measured or
is that what you are proposing how you will treat traffic?
Jinoo Joung: It's a set of different flows, three different types of
flows. Combine those different flow types together and make them travel
together through the same paths.
Sebastian Robitzsch: If you have an XR application that has video
haptics, some might be processed elsewhere.
Jinoo Joung: what you suggest is more realistic.
Lou Berger: We have a service model defined in the YANG models, what you
(Sabastian) are suggesting may be outside of what is supported and an
interseting addition. Please have a look at the YANG models, and see if
the use case you are considering is adequately covered.
Draft:
https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/03
Presenter: Jinoo Joung
When you say the latency bound, are you actually meaning the queueing
latency bound?
Jinoo Joung: No, it includes the transmission latency. There are several
types of latency, including transmission, queueing and propagation.
Lou Berger: I don't understand the transmission and propagation being
included.
Jinoo Joung: Because they are more custom.
Shaofu Peng: On slide 5, in the table, the video flow you mentioned that
it exceeded the requirement. How does one calculate this? And, when
calculate the therotical E2E bound latency, if the used service rate is
the aggregate flow rate of individual flow rate?
Jinoo Joung: There are arrival rates and a service rates. The service
rate can be higher than the arrival rate.
Shaofu Peng: So that may be overprovision.
Toerless Eckert: [Will put the question and answer on the list].
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/12
Presenter: Shaofu Peng
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/09
Presenter: Shaofu Peng
No comments.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-policing-jitter-control/01
Presenter: Shaofu Peng
Jinoo Joung: Like to remind you that a very similar approach/solution
has been addressed in the Asynchronous deterministic network framework,
which I have been presenting since 2010. Please try to avoid overlap.
Shaofu Peng: Still some differences.
Jinoo Joung: although there are some differences there is still some
overlap. Let's collaborate to resolve.
Shaofu Peng: Let's do that.
Draft: https://datatracker.ietf.org/doc/draft-liu-detnet-rcqf/00
Presenter: Rubing Liu
No comments.
Draft:
https://datatracker.ietf.org/doc/draft-rc-detnet-data-unit-groups/00
Presenter: Sebastian Robitzsch
Toerless Eckert: The problem is that something IPv6 extension header
needs to go through 6man working group to be standardized. That group
doesn't know about DetNet QoS requirements. One direction that might
make sense, there is an expired draft joint header that makes it easy to
have experimentation with QoS.
Sebastian Robitzsch: Great input. In the end it is header
standardization.
Jinoo Joung: The single DUG has the same priority. Does that priority
become lower and higher at some times?
Seabstian Robitzsch: Depends on the application. It is an interesting
proposal you h ave to say you change the I flag while you're walking
through the DUG packets.
Jinoo Joung: Not sure how the concept matches to the network.
Sebastian Robitzsch: didn't anticipate how the I flag would change
within the flow. Thgouh an application could mis-use.
Lou Berger: In slide 4, which of these things are unique to DetNet?
Sebastian Robitzsch: The PREOF behavior.
Lou Berger: If you are describing a general behavior, then it should be
in the IPv6 group. If they agree on portion, then come back to the group
and we can discuss making PREOF work.
Sebastian Robitzsch: Good point, I'll take this on as well as continue
the work in progress.
Lou Berger: Let's build on the data plane behavior others define as
opposed to defining our own.
Quan Xiong: Slide 2. Concern related to Lou. You mentioned two use
cases, XR and digital Twins. They are not the scope of the DetNet RFC.
Are they new use cases? Perhaps we can discuss the requirements first?
Sebastian Robitzsch: Happy to coordinate and contribute.
Toerless Eckert: It would require an extension to the DetNet
architecture to use other header fields for DetNet flow identification.
Janos Farkas: DetNet can be also used in use cases not in the RFC.
OPEN MIC
Toerless Eckert: Really loved the joint meetings with IEEE TSN in
Bangkok, any thought on having it in Madrid?
Janos Farkas: DetNet is not the only group wanting to jointly meet. But
we are open to proposals and topics that would be good for joint meeting
with TSN.
Toerless Eckert: The other standards bodies were less educated about IP.
Charles Eckel: Re the liaison statement to 3GPP. Should I get that in
process?
Janos Farkas: Yes.
Lou Berger: Thank you Charles for all the support!
Eve Schooler