Re: [Detnet] draft-kmak-ocn: comment on interface to Detnet relay node

[Kiran Makhijani <[e-mail]>]

Hi Florian,
Thank you for participating in the discussion and bringing comments forward.
Please see inline with [KM].


On August 10, 2023 at 4:09:21 AM, Florian Kauer ([e-mail])
wrote:

Hi all,
as author of that cited comment, let me add some more context for
clarification.
So as brief recap how I understand the draft, it defines extension headers
that specify per-packet (!) real-time requirements (e.g. bounded latency)
that are sent by an industrial 'process controller' to a DetNet relay that
in turn needs to select a matching DetNet flow - out of the already
provisioned ones - to transmit that specific packet.

[KM] That’s spot on.



One of the very fundamental principles of deterministic communication in
general (not only DetNet or TSN) is that before a packet is sent out, you
must be sure that on the whole end-to-end path all resources are available
to process the packet according to its real-time requirements. And in my
opinion, that principle can not be guaranteed if you set up a system
according to the current draft for two reasons:

[KM] I'd just one-thing: this draft represents an endsystem's request
without needing to know the details of network internals. Additional work
to be done by the network (DetNet or another - TSN, wireless, 5G-radio) is
assumed and to be out of the scope for this document. Although, we should
add text to make our assumptions about operational view of end-to-end
mechanics clear.



1. It is impossible to pre-provision a set of DetNet flows that is able to
process packets with completely arbitrary real-time requirements. Lets say
the provisioned DetNet flow with the lowest latency guarantees a delivery
within 5 ms. Then you simply can't properly transmit an individual packet
that specifies a 3 ms latency requirement.

[KM] agree. We dont expect arbitrary latency requirements. They will be
mapped to a pre-provisioned network (connecting endsystem as well as
DetNet). If the document is under-specified, authors should say that
explicitly (and we will).



2. The specified requirements only apply for the path through the DetNet,
but neither for the path from process controller to the DetNet relay node,
nor from the final DetNet relay node to e.g. the actuator (assuming it is
not part of the DetNet itself).

To address the second problem, Kiran suggested in her comment below to
assume a contention-free path outside of the DetNet, but in my opinion that
is an oversimplification that does not exist in reality. Even if you have
set up e.g. a TSN, that also has a bound regarding the amount of traffic
that can be transmitted contention-free as well as a bound on the
achievable latency.

The process controller can't simply generate arbitrary traffic hoping that
it will be processed properly according to its per-packet real-time
requirements. In the end, there is no way around the fact that the
end-to-end (!) communication between two communication partners is somehow
bounded with regard to real-time properties. In the given scenario that
means the 'process controller' needs to be aware which traffic will be
processed properly and which not, either explicitly (by providing the
bounds via controller plane) or implicitly (by configuring its packet
generation appropriately).

And after we made the process controller to generate its traffic according
to the end-to-end properties, I honestly see no advantage in further
specifying per-packet real-time requirements. If the promised end-to-end
properties are e.g. "max 5 ms latency for 100 packets/s of 200 bytes" then
all packets will anyway be delivered after at most 5 ms as long as no more
than 100 packets with 200 bytes are generated per second. We can't get
faster by specifying "but I want to be delivered after 3 ms!" in the
packet. And specifying "10 ms is fine for this packet" also has no real
advantage in my opinion because the resources are anyway reserved for 5 ms
delivery.

Of course, we might have the situation of different kinds of traffic (e.g.
"max 5 ms latency for 100 packets/s of 200 bytes" plus "max 20 ms latency
for 50 packets/s of 3000 bytes") but also that needs to be guaranteed
end-to-end and not only within the DetNet and that means classifying the
traffic at the DetNet relay node is too late!

For me that finally means we should either have logical (!) end-to-end (!)
DetNet flows or TSN streams (tunneled via DetNet).

[KM] That's how even we started this document, but I am not a fan of
tunneling or exposing network internals to applications. It limits
application portability. Especially more troubling for OT experts.
Therefore, we first focus on just endsystem expressibility.


However, a logical end-to-end DetNet flow/TSN stream does not necessarily
imply that all devices are explicitly DetNet or TSN aware! With a single
end-to-end traffic class, the DetNet relay node can simply identify the
flow e.g. by the source/destination address and there is not need for the
process controller to make any further per-packet specifications as
outlined above. And in the case of different traffic classes, it is
sufficient (but in my opinion necessary!) that the process controller
differentiates the different classes by either L2 fields (MAC
addresses/VLAN IDs resulting in logical TSN streams) or L3 fields
(resulting in logical DetNet flows).

[KM] This is the key to discussion. Is it possible to have single traffic
class across different domains ? or is it sufficient? Semantics of
traffic-class will differ across domains. I find this type of configuration
quite static. While it may work in current usecases, I had a more dynamic
system in mind. Our disconnect is with regards to the scope of this work. I
split the problem in 2 parts, a) the expressibility of an endsystem's
requirement and b) the capability of the networks between them. The
document focuses on a) and i think with on going efforts in large-scale
detnets, we can deal with part b) without repeating the work.
For an end-to-end system, we should at least agree on doing things in L3
fields because media could change across domains. I like your choice of
term 'logical DetNet flow'. The only difference now is the use of
traffic-class vs OCN option EH.

Tempted to add a little more here. The ocn-option is not only dealing with
latency but is also epxresing other characteristics with a programmability
mindset (or more dynamic behavior - BUT within the constraints of what
network can offer).
Cheers,
Kiran

In the latter case, the mapping of flow/stream identification to real-time
requirements is either the responsibility of the controller plane or
implicit by setting up the 'process controller' to generate appropriate
traffic. But in any case, this is something to configure network-wide
before a packet is sent and specifying the real-time requirements solely in
the packet itself is too late.

Do you agree with my assessment of the situation or do I overlook something?


Greetings,
Florian


On 10.08.23 08:15, Kiran Makhijani wrote:
> Hi WG,
> I will start a series of discussions on the comments posted earlier.
>
> Pasting comment on section 3.2 for discussion.
> ---
> With your draft, you only have resource allocation within the DetNet but
not between the process controller and the DetNet. And in my opinion that
could easily lead to a situation where the constraints specified by the OCN
extension header of a specific packet just cannot be fulfilled by the
DetNet.
>
> As I understand the current draft, nothing would prevent an application
from just sending thousands of very large packets where the OCN extension
header specifies an upper latency bound of 1 ms.
> ---
> The issue is for the remote DC (where oc-controller will be)  we do not
specify the characteristics of connection between an oc-controller and
DetNet relay node. When I started writing the document, I assumed this
would be a contention-free logical or physical wire connection to keep the
document simple.
>
> The question for the group is whether it is ok to go ahead with this
assumption for the scope of this document?
> Perhaps, a better way to deal with this is to explain on cases by case
basis as in RFC8939 Section 3.
>
> 1. ref. Figure 1. DetNet service aware endsystem: - the interface between
the endsystem and relay node is deterministic.
> 2. ref. Figure 2. non-DetNet-aware IP endsystem: - endsystem to proxy
node provides proprietary means of deterministic behavior.
>
> The benefit of OCN option from oc-controller is to express network
requirements in a common IP-based approach.
>
> Please chime in.
> Kiran
> Detail comments at
>
https://docs.google.com/document/d/15MtFAbKQkrFwTHBiOLl_yYHG9ToqkHyBc5_LI6-Fr98/edit?pli=1
<
https://docs.google.com/document/d/15MtFAbKQkrFwTHBiOLl_yYHG9ToqkHyBc5_LI6-Fr98/edit?pli=1
>
>
>
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet