Last Call Review of draft-ietf-detnet-architecture-08
review-ietf-detnet-architecture-08-rtgdir-lc-rogge-2018-10-15-00

(Posting to RTG-DIR on behalf of Henning.)

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