Subject: [Detnet] Last Call Review for ietf-detnet architecture

From: Henning Rogge <[email-masked]>
Date: Wed, 10 Oct 2018 15:13:58 +0200

Hi,

I was asked to do a last-call review for the detnet architecture 08
draft... sorry for the delay.

I think the draft provides a good overview what detnet wants to do.
When read in order, some chapters seem to skip a few points that get
included in later chapters (in a different context), but I think this
should be easy to fix.

Here are some comments to the draft that came to my mind during reading it:

Detnet Relay Node (Page 5)

can be bridge (which should be layer2), but Detnet operates on IP layer?

Congestion Protection (Page 8)

Does Detnet differenciate between limited network capabilities because
of media access and datarate? In some networks you might hit a "packet
per time" limit before you hit the "byte per time" limit, which is
mostly solved by aggregating multiple packets.

Explicit Routes (Page 8)

Does this mean DetNet normally uses a "frozen" state of a route, e.g.
a snapshot of a routing protocol? What happens if the route does not
apply anymore (maybe this is out-of-scope for DetNet)?

Sufficient buffer (Page 10)

"Sufficient buffer" also can give you a higher amount of latency. If
for whatever reason a packet arrives "too late", it might be better to
drop it to recover the realtime behavior of the following packets
(assuming more allocated bandwidth than necessary). This is explained
in page 15 (3.3.2. Fault Mitigation) I think.

Extra Buffering for different-length paths (Page 13)

This sounds like another point where additional latency might appear.

Reduction of available bandwidth for non-DetNet packets (Page 15)

... and increased latency.
(Mixing DetNet and non-DetNet packets sounds quite difficult if you
want to keep all guarantees of DetNet)

DetNet data plane protocol stack (Page 18)

How does this diagram mesh with the standard stack layers? Are IP/MAC
all "lower Layers" ?

DetNet adaptation to data plane (Page 19)

Figure 4 reads like the combination of UDP and IP (with static routes
set) would be okay for DetNet under certain circumstances... no
"hop-by-hop" userspace (DetNet)-processing required?

Synchronous DetNet (Page 24)

I feel that the most important advantage of this would be the
collision-free usage of the shared links between the DetNet nodes,
which helps to keep the Latency to a lower limit.

Henning Rogge

---

From: János Farkas <[email-masked]>
Date: Fri, 19 Oct 2018 21:19:45 +0200

Hi Henning,

Thank you very much for your review!

Please find below in-line responses and how we will update the draft to 
resolve your comments.

Best regards,
Janos

> can be bridge (which should be layer2), but Detnet operates on IP layer?
bridge is removed based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01790.html

> apply anymore (maybe this is out-of-scope for DetNet)?
These issues are solved by explicit routing techniques.
For instance, explicit routes are used with PREOF. If one of the routes 
go down, then the other one remains. The broken route is then 
changed/updated by explicit routing techniques, e.g., by a central 
network controller.
DetNet only refers to explicit routing techniques specified by other 
IETF WGs, DetNet does not specify explicit routing details; it is out of 
scope for DetNet.

> in page 15 (3.3.2. Fault Mitigation) I think.

The next paragraph in 3.2.1.1 explains that the buffers have to be 
adequately designed, which keeps under control the delay and jitter that 
can be caused by buffering:

"Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow."

> This sounds like another point where additional latency might appear.
It is additional latency, but it is deterministic latency.

> want to keep all guarantees of DetNet)
Correct.
Updates will be made to clarify along last call comments:
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html

> How does this diagram mesh with the standard stack layers? Are IP/MAC
Updates will be made to clarify along last call comments:
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html

> "hop-by-hop" userspace (DetNet)-processing required?
The data plane forwarding avoids user space processing.
The details are in the data plane documents:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-mpls/
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/

> which helps to keep the Latency to a lower limit.
Yes, if synchronization is available, then more can be done, e.g., 
time-based scheduling techniques can be used.