Please add notes inline with the appropriate slot below.
Only discussion need be captured, not material on slides.
Also please feel free to add your name here as a
Note Takers: Eve Schooler, Lou Berger, Janos Farkas
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
Datatracker: https://datatracker.ietf.org/group/detnet/about/
15:30-17:00 AEST (05:30-7:00 UTC)
Room: M4 -- https://datatracker.ietf.org/meeting/119/floor-plan?room=m4
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20240318T053000&p1=47
Materials: https://datatracker.ietf.org/meeting/119/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-119-detnet#both
Meetecho: https://meetings.conf.meetecho.com/ietf119/?session=32018
Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=32018
Video stream: https://meetings.conf.meetecho.com/ietf119/?session=32018
Audio stream: https://mp3.conf.meetecho.com/ietf119/32018.m3u
Chat: https://zulip.ietf.org/#narrow/stream/detnet
ICS: https://datatracker.ietf.org/meeting/119/sessions/detnet.ics
YouTube: https://www.youtube.com/watch?v=pZoySNf7EJA
Presenter: Chairs
Janos Farkas: Updated link for the liaison link:
https://datatracker.ietf.org/liaison/1885/
Xuesong Geng: Controller Plane Framework authors seeking WGLC. Authors
will summarize to list. Also YANG model draft due for an updated
progress report.
Lou Berger: Planned process change: for every WG document, status report
at every IETF solicited going forward.
Toerless Eckert: This places more work at the same time as the ID
cut-off.
Lou Berger: If you are requesting a slot, there is no additional work at
the ID cut-off; simply request to present at the meeting.
Draft: https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/17
Presenter: Pascal Thubert Janos Farkas
Lou Berger: looking at the doc and getting ready for the next last call,
can see other inconsistencies that are NOT due to the updates. Notably
in the definitions. A lot of repeat text from outside the doc from
multiple sources and not necessary consistent. Will need to clean this
up too, perhaps even by removing the paraphrasing and just reference the
source.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-raw-industrial-req/00
Presenter: Carlos Jesus Bernardos Cano
Janos Farkas: remove technologies from the draft and focus on the
requirements.
Carlos Jesus Bernardos Cano: agree with that comment, as the document
should be technology-agnostic. Feedback solicited!
Draft:
https://datatracker.ietf.org/doc/draft-varga-detnet-mobile-latency-analysis/00
Presenter: Balazs Varga
From chat: Lou Berger: There is a related draft that will be presented
in TEAS.
Shaofu Peng: Do you think the transport network between gNB and the UPF
should also be indicated as DetNet, because now we are taking as a whole
virtual DetNet router?
Balazs: I think that concept is not bad. This is something we can work
with because that will make easier the control plane communication with
the mobile system. If you would like to segment the mobile system one by
one and add deterministic capabilities, I think that would be really
hard work to do.
Toerless Eckert: Probably measuring latency as part of a best-effort
configuration of the network? Probably not having reserved capacity in
the network just for the DetNet packets?
Balazs Varga: Not really. In the draft there are many parameters of the
radio network that can be tuned, even on a per session basis, in order
to provide better characteristics for DetNet flows. You can configure
much better the radio network. If you are just using best-effort
optimized for mobile broadband, that is not something you'd expect for
DetNet. That might be enough for some DetNet traffic, depending on your
latency bounds. If you have a periodic control loop running every
100msec, easy to achieve. However, as you have tighter control loops (in
your application), you will have more challenges.
Toerless Eckert: Worst-case impact of the other competing traffic would
be beneficial to understand.
Balazs Varga: QoS architecture of the mobile network is described in the
draft. You can protect your DetNet flows from the impact of other
traffic. Let's make it a next step discussion. Further details may be
added.
Toerless Eckert: Would like to be able to compare Wifi and 5G.
Balazs Varga: Exactly why URLLC functionalities were defined in Rel-16.
Janos Farkas: Regarding Shaofu's question and the use of DetNet in 5G
system inside, which was part of the original DetNet use cases. DetNet
in that case is a building block for the 5G system as described in
https://www.rfc-editor.org/rfc/rfc8578.html#section-6. Balazs was
actually talking about using DetNet as an overlay. These are two
different cases that can be combined.
Draft: https://datatracker.ietf.org/doc/draft-huang-detnet-rdi/01
Presenter: Li Zhang
Greg Mirsky: This work does not seem specific for Detnet. You introduce
these values and they will show up in all BFD. You suggest to use BFD as
a transport for notifications. But if we imagine two-way active
measurement protocol to measure performance metrics like delay and
packet loss. The notification here intended from the remote BFD peer to
the head-end of the BFD session, but that is only to characterize the
measurements going between these two nodes. But if we use two-way active
measurement protocol this head-end will know whether the threshold is
being crossed because of the nature of the two-way active measurement
protocl. It seems that it is not much of the benefit. Yes, I agree if
using one-way protocol measurement methods, perhaps on-path telemetry,
or in situ OAM, yes there is some benefit.
Greg Mirsky: But in environments such as DetNet, where we expect service
degradation will come before loss of path continuity, then BFD messages
will be more relaxed compared to their performance measurements. Service
degradation will be constituted before we will lose three control
packets in a row. Because of that, it seems that it might be more useful
to look at more generic cases.
Greg Mirsky: Want to point to the work going on in IPPM working group,
for Multi-SLO environments. When we have SLA, in DetNet we use several
precision availability metrics. Crossing threshold limits for the
metrics makes the DetNet service unavailable. In this work being cleared
for publication, we use network slices as an example. Agree that DetNet
could be another useful example, and the multi-SLO environment and
precision metrics is very much applicable. Also can point to the work on
extending PAM in IPv6.
Greg Mirsky: I think there is a need to do notifications. BFD may not be
the right mechanism. A more generic mechanism may be a better approach.
Will benefit DetNet as well as other applications that share multi-SLO
environments.
Draft:
https://datatracker.ietf.org/doc/draft-tan-detnet-cap-discovery/01
Presenter: Li Zhang
Greg Mirsky: You might look at not using ICMPv6 for the extension of the
discovery of the functionality. There is a different mechanism
recommended in the 6MAN WG. See the RFC4620,
https://www.rfc-editor.org/rfc/rfc4620.html, for node capabilities
discovery.
Lou Berger: Who is the consumer of the information of the notifications
you are passing?
Li Zhang: the DetNet Ping initiator.
Lou Berger: Capabilities adverizement. Generally if talking about
in-network control plane using it, we've generally done that in routing
to advertize capabilities in the network. Otherwise done in YANG.
Max Smith: The flow label field does not seem to be appropriate here.
Draft:
https://datatracker.ietf.org/doc/draft-eckert-6man-qos-exthdr-discuss/00/
Presenter: Toerless Eckert
Antoine Fressancourt: Regarding Headers and the finish time for packets,
does it make sense to put it in the header vs putting it in the control
channel?
Toerless Eckert: This is calculated in the hop-by-hop option. The other
option was end-to-end and this is an interesting question. Minimize the
control plane operation; we eliminate the need of putting in state for
each flow at the egress node.
Antoine Fressancourt: Regarding e2e presented during the interim
meeting, QoS contracts end-to-end. You raised the question if RSVP was
suitable for carrying the contract in the packet.
Toerless Eckert: Rely on admission control as with segment routing
solutions.
Greg Mirsky: What is the use of the sequence number in the DetNet
forwarding sublayer?
Toerless Eckert: In a large scale network, put in IPv6 destiniation
option extension header, only process in the destination. What
functional difference is there out of declaring such an IPv6 transport
header vs IPv6 extension header?
Greg Mirsky: Who needs it in IPv6?
Toerless Eckert: Highly resilient multicast community, they all want to
have it in the network.
Greg Mirsky: Why not put in the application?
Toerless Eckert: If you want to do a merge in a network device, prefer
not to have to figure out another signaling mechanism. We do have the
seqno in MPLS.
Greg Mirsky: No, we have in the DetNet controller.
Greg Mirsky: Next, you suggest the timestamp will be in microseconds. I
encourage considering nanoseconds as a unit instead. When you propose
compensating for the control plane in the data plane, it overloads the
data plane. I prefer that you use provisioning instead, because it saves
precious resources in the data plane.
Janos Farkas: Let's take to the ML.
Janos Farkas: Two comments. First, honestly I do not like approaching
other WGs until the DetNet WG has made its own recommendation, i.e., an
adopted document.
Toerless Eckert: Would like for us to avoid serialization, which causes
delay.
Jano Farkas: Second, this proposal is like writing a blank check for
header usage.
Toerless Eckert: Can we make this applicable to a registration-based
extension header.
Lou Berger: The last few minutes of discussion shows that we don't as
yet have agreement on the approach. Getting information of what is
viable or not from 6MAN would be useful, but let's ask for it in a
general form. Bring 6MAN feedback back to the working group.
09:30 - 11:30 AEST (23:30 - 01:30 UTC)
Room: M3 -- https://datatracker.ietf.org/meeting/119/floor-plan?room=m3
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20240320T233000&p1=47
Materials: https://datatracker.ietf.org/meeting/119/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-119-detnet#both
Meetecho: https://meetings.conf.meetecho.com/ietf119/?session=32017
Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=32017
Video stream: https://meetings.conf.meetecho.com/ietf119/?session=32017
Audio stream: https://mp3.conf.meetecho.com/ietf119/32017.m3u
Chat: https://zulip.ietf.org/#narrow/stream/detnet
ICS: https://datatracker.ietf.org/meeting/119/sessions/detnet.ics
YouTube: https://www.youtube.com/watch?v=mNTkzTCYvKo
Presenter: Chairs
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-scaling-requirements-05
Presenter: Peng Liu
No Comments
Draft:
https://datatracker.ietf.org/doc/draft-joung-detnet-taxonomy-dataplane/01
Presenter: Jinoo Joung
From chat: Antoine Fressancourt
I would appreciate the Bounded Queue Delay (BQD) solution we presented
in an interim last year to be listed in the solutions. We are still
participating in interims.
https://datatracker.ietf.org/doc/draft-aft-detnet-bound-delay-queue/
From chat: David Black
It would also be helpful to fit BQD into the frameworks on the slides
that go beyond the -01 draft (e.g., slide 11 of the current
presentation).
From chat: Jinoo Joung
BQD will be included in the future version of the taxonomy.
Shaofu Peng: On slide 11, does admission control for rate based
solutions need to manage the buffer space?
Jinoo Joung: If the relaying node routers or switches have limited
amounts of buffer, then it definitely has to be considered. In reality
the buffer space is quite abundant in most cases so we don't care about
the buffers when we consider admission decisions. But Yes, buffer size
also needs to be considered.
Toerless Eckert: Interesting to look at buffer space, and may want to
revisit. If we look at the lower end of the forwarding plane chips and
high speeds. Two classes, ones with a lot of buffer meant to be used for
routers, and ones with a lot less buffer meant for switches. For
example, if you look at Metropolitan networks, many of them try to get
away with just the low buffer, whether or not that is too low for what
we are trying to achieve is an interesting question for these two
different types of devices with different size buffers.
Jinoo Joung: Remember that in all solutions currently being proposed for
DetNet services, they have very low end-to-end latency bounds. In order
to meet those bounds, the buffer size itself should not be very large.
These are the tradeoffs.
Toerless Eckert: Whatever we propose, we need to allow for low end
devices that have small buffer size. Applicability statements needed.
Jinoo Joung: Good points. Maybe we should characterize the buffer
requirements of each solution.
Toerless Eckert: Might also be useful to add the older algorithms like
ATS. Perhaps also mention older solutions, e.g., ones based on RFC2212.
Even if we don't consider them because they are not scalabe, have them
for comparison.
Jinoo Joung: Very good idea.
Quan Xiong: Concern about the latency and loss tolerance specification,
end-to-end as well as per-hop bounds.
Jinoo Joung: Good question. Personally, I think many of the solutions
being proposed don't have explicit expression for end-to-end latency
bound. However, we can roughly figure out what are the per-hop behavior
characteristics. No strict mathematical proof that each solution fits
into these categories. One exception is perhaps the C-SCORE or FQ.
Quan Xiong: Suggest clarification for more categories under latency and
jitter performance, as shown in slides.
Jinoo Joung: Will try my best to include jitter performance.
Dan Bogdanovich: Going back to the buffer, when you get down to Silicon,
some Silicon has fixed buffer and fixed table sizes, but because have
finite resources always a key tradeoff between the two. Fewer flows? Or
using fewer buffers?
Jinoo Joung: DetNet solutions usually cannot maintain the flow state,
thus suspect the flow table or other table type of information should
not be very large. Balance the two aspects.
Balazs Varga: I have a high level comment regarding how
wireless-friendly these functions are. It could be an important aspect
for mixed (wired, wireless) environments as highlighted during the
Monday session.
Jinoo Joung: Agreed. So far the focus has been concentrated on wired
scenarios. Wireless in the future.
Some participation (20%), not a huge number.
Result: A good percentage of participants think this is a good
foundation, as long as we get consensus on the list.
Lou Berger: Service ordering is confusing as a term. Avoid ordering.
Some of the other terms are not as tightly defined, e.g., tight and
loose latency.
Expect to see this polled for adoption on the list. To the one person
who said no, please let us know why during the adoption poll.
Abdussalam Baryum: I objected to the terminology document since it
doesn't cover use cases. If we can focus on Slide 9, make it a more
detailed reference.
Jinoo Joung: The reference topology will be needed. Cannot say that
there will be only one or two. Maybe including wireless as well. The
focus of the taxonomy draft is not the use cases; we will reference
existing use cases drafts.
Toerless Eckert: A ring topology can be scaled up or down. And a ring is
real-world.
Jinoo Joung: Ring will be considered.
Lou Berger: Although the taxonomy document is not about use cases, in
terms of having some reference topologies, multiple topologies sounds
like a great idea. Question: WG doc first, then proceed with topologies?
Or other way around? Co-authors and co-chairs agree on the former. Means
that the WG works on the topologies and anyone can provide inputs, not
just the authors.
Antoine: Would value input on topologies from operators.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding-09
Presenter: Shaofu Peng
No comments.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism-06
Presenter: Shaofu Peng
No comments.
Draft:
https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/02
Presenter: Jinoo Joung
(time mark 10:59) Shafou Peng: Can we provide common topolgy to show
benefits of C-SCORE?
Jinoo Joung: Different solutions are suitable for different topologies
and scale.
Shaofu Peng: A concern is latency. Another concern is multiple
priorities (class levels)?
Jinoo Joung: Latency bound can be adjusted by service rate of the flow.
Lou Berger: Perhaps add reference topologies to illustrate scale in the
taxonomy drafts.
From chat: Antoine Fressancourt
Regarding topologies, DEFO has some examples
https://sites.uclouvain.be/defo/
Abdussalam Baryum: Topologies would be good.
Draft:
https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/00
Presenter: Yeoncheol Ryoo
Toerless Eckert: Couple of points.
Assuming with FIFO that you can explicitly say what the nominal
departure time is? Giving that as the control parameter to the FIFO?
Yeoncheol Ryoo: When a packet arrives, we calculate the minimum and
departure time (according to the node delay upper and lower bound). Then
according to the nominal departure time, the queueing in FIFO queue
(slide 5). This is the arranged ordering is using ordering time and
packet departure is at the minimum departure time.
Toerless Eckert: High-speed implementations are just coming as written
up in a paper from CMU (showing a scalable algorithm), another paper
last year. Still the point missing is that the FIFO control parameter
can be an actual timestamp. Currently the control parameter is a
priority, so cannot continuously increment it. There is one more level
of FPGA complexity to get working before FIFO can move into the
industry. As far as this mechanism is concerned, it is similar to LGF we
worked on a few years back, referenced in the GLBF document
(https://datatracker.ietf.org/doc/html/draft-eckert-detnet-glbf-02). The
flexibility of the mechanism is so large that it is hard to describe an
actual calculus. As a result, we moved to a simpler damper using the ATS
calculus, which can be implemented.
Peng Liu:
Regarding Point 3 of the Capability analysis on Slide 9. Reminder that
the higher link speed will influence the time control and buffer set.
Didn't see an explanation in this section with a reasonable analysis
yet. Please enhance this section to capture the points behind it.
Shaofu Peng: Two questions. First one, the node delay with low bound and
the node delay with upper bound should be stored on each node for the
flow.
Are these parameters for the flow carried in the packet?
Yeoncheol Ryoo: We assume carried in the packet, configured at the node.
Shaofu Peng: Second question, the document describes the node delay of
upper bound is related with the packet that are already existing in the
queue, want to know if there are any mathematical equations to compute
the packet amount?
Yeoncheol Ryoo: Did you say we need to add the mathematical equations?
Shaofu Peng: Yes to calculate the packet delay upper bound.
Draft:
https://datatracker.ietf.org/doc/draft-xiong-detnet-flow-aggregation/00
Presenter: Quan Xiong
Xuesong Geng: Two questions about the necessity of this work: