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

[János Farkas <[e-mail]>]

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


On 10/10/2018 3:13 PM, Henning Rogge wrote:
> 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?
bridge is removed based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01790.html

>
> 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)?
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.

>
> 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.

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."

>
> Extra Buffering for different-length paths (Page 13)
>
> This sounds like another point where additional latency might appear.
It is additional latency, but it is deterministic latency.

>
> 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)
Correct.
Updates will be made to clarify along last call comments:
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html

>
> DetNet data plane protocol stack (Page 18)
>
> How does this diagram mesh with the standard stack layers? Are IP/MAC
> all "lower Layers" ?
>
Updates will be made to clarify along last call comments:
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html

> 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?
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/

>
> 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.
Yes, if synchronization is available, then more can be done, e.g., 
time-based scheduling techniques can be used.

>
> Henning Rogge