Re: [Detnet] Comments on Section 3.7 of scaling requirements draft

["Black, David" <[e-mail]>]

Hi Peng and Kiran,

Thank you both for the quick reviews.

Peng is correct about the intent of that “best case” sentence (thanks!), specifically that a linear relationship is the best case (e.g., by comparison to a quadratic or exponential relationship).  He even provided the key word that (in 20/20 hindsight) was missing from that sentence, “bounded”, viz.:

   In the
   best case, the added queuing mechanism latency for DetNet QoS is bounded by a
   fixed constant per hop maximum value so that the resulting end-to-end
   latency bounds are a linear function of the number of hops in addition
   to the inherent forwarding latency of the links and routers (and/or switches)
   involved.
This sentence was not intended to pick up the “dead time” topic from the old text – that “dead time” topic a fine example of changes that need to be made to CQF for scalability, but that topic doesn’t seem to fit well with the new proposed text.

I also like Kiran’s rewrite of the first part of the second paragraph of the new proposed text – it’s a clear improvement (thanks!).

I’ll integrate both changes, make some other minor edits and send a revised (v2) version of that proposed text shortly.

Thanks, --David

From: Peng Liu <[e-mail]>
Sent: Wednesday, October 25, 2023 3:30 AM
To: Black, David; kiran.ietf
Cc: detnet
Subject: Re: Re: [Detnet] Comments on Section 3.7 of scaling requirements draft


[EXTERNAL EMAIL]
Hi David,

Thank you very much for providing the text, it is clear now.

Hi Kiran,

[km] Why is the best case not minimum value?
I think the 'best case' is for the 'linear' relationship, the 'maximum value' describes the bounded latency in each hop.

[km] DetNet QoS requires resource allocation in advance (e.g., of link bandwidth and node buffer resources), as discussed in section 3.2.1 of [RFC8655]. The complexity of resource allocation process may range
from linear (e.g. in allocating resources for each hop via a path-based resource reservation protocol such as RSVP) to potentially
It also looks good.

Regards,
Peng
________________________________
[e-mail]<mailto:[e-mail]>

From: Kiran Makhijani<mailto:[e-mail]>
Date: 2023-10-25 08:14
To: Peng Liu<mailto:[e-mail]>; Black, David<mailto:david.black=[e-mail]>
CC: Black, David<mailto:[e-mail]>; detnet<mailto:[e-mail]>
Subject: Re: [Detnet] Comments on Section 3.7 of scaling requirements draft
Thanks David,

The new text is quite clear and well written. In particular your
proposed sentence in 2nd paragraph: “The resource allocation
complexity does not directly affect achievable…” is very nicely
drafted. I have a question (in first paragraph) and a suggestion (in
IInd para) inline as [km].


On October 24, 2023 at 3:34:37 PM, Black, David
(david.black=[e-mail]<mailto:david.black=[e-mail]>
(mailto:david.black=[e-mail])) wrote:

>
> Hi Peng and WG members,
>
>
>
>
>
> > Please see if you can help to refine the text, thanks!!
>
>
>
>
>
> One of the reasons that I volunteered to work on this is that I suspected that a more significant rewrite (well beyond refinement) could be appropriate to capture the concepts. That’s what I wound up doing – I propose replacing the second paragraph of section 3.7 with 2.5 paragraphs (and … no … I don’t get paid by the word ). I did not change the first paragraph of Section 3.7, so it’s included here for context:
>
>
>
>
>
> NO CHANGE:
>
>
>
>
>
> 3.7. Be Scalable to a Large Number of Hops with Complex Topology
>
>
>
>
>
> Scaling networks often results in situations where an end-to-end flow
>
>
> involves a large number of hops, e.g., 15 or more. The network
>
>
> topology can also be complex, including star, ring, mesh, and their
>
>
> combinations, and can possibly be hierarchical. It is required to
>
>
> support networks with such various types of topologies and large hop
>
>
> Counts.
>
>
>
>
>
> OLD
>
>
> Normally, bounded latency and jitter is a constant of application, so
>
>
> for the queuing mechanisms, keeping them with the variety of hops is
>
>
> required in scaling detnet. The queuing mechanisms should be
>
>
> enhanced, for instance, adjust the cycle time in [IEEE802.1Qch] to
>
>
> meet the end to end latency while considering the feasibility with
>
>
> the dead time. The performance of a queuing mechanism can be
>
>
> evaluated based on the E2E latency bound, the E2E jitter bound, and
>
>
> the execution time required for resource scheduling, which might be
>
>
> constant, or linear functions, or exponential functions in terms of
>
>
> number of flows or network diameter.
>
>
> NEW
>
>
> Delivering DetNet Quality of Service (QoS) in such large and complex
>
>
> networks requires end-to-end bounds on both latency and jitter, as
>
>
> discussed in section 3.1 of [RFC8655]. Achievable end-to-end latency
>
>
> bounds necessarily depend on the number of hops for a flow. In the
>
>
> best case, the added queuing mechanism latency for DetNet QoS is a
>
>
> fixed constant per hop maximum value so that the resulting end-to-end
>
[km] Why is the best case not minimum value? If the best case means a
clear DetNet path with
no queueing overhead on any of the hops, then a packet will incur just
the 'minimum necessary processing time' on each hop.
What have I missed? Is it that you wanted to replace 'dead time’?

>
> latency bounds are a linear function of the number of hops in addition
>
>
> to the inherent forwarding latency of the links and routers (and/or switches)
>
>
> involved. In contrast, it is possible to achieve fixed constant end-to-end
>
>
> jitter bounds that are independent of the number of hops. Such fixed
>
>
> constant jitter bounds are strongly preferable to jitter bounds that
>
>
> increase with an increasing number of hops.
>
>
>
>
>
> Advance resource allocation (e.g., of link bandwidth and node buffer
>
>
> resources) is also required to deliver DetNet QoS of service, as
>
>
> discussed in section 3.2.1 of [RFC8655]. The complexity of that
>
>
> resource allocation ranges from linear in number of hops (e.g., via a
>
>
> path-based resource reservation protocol such as RSVP) to potentially
>
>
[km] maybe the above text could be simplified even further (because a.
'Advance resource allocation…QoS of service’ and b. 'linear in number
of hops’ did not parse easily for me.

DetNet QoS requires resource allocation in advance (e.g., of link
bandwidth and node buffer resources), as discussed in section 3.2.1 of
[RFC8655]. The complexity of resource allocation process may range
from linear (e.g. in allocating resources for each hop via a
path-based resource reservation protocol such as RSVP) to potentially

Thanks, Kiran

> exponential (e.g., if solving a complex graph optimization problem is
>
>
> required). This resource allocation complexity does not directly affect
>
>
> achievable end-to-end latency and jitter bounds, but it does surface
>
>
> in other areas such as the amount of computation and elapsed time
>
>
> required to admit a new flow to a DetNet network without disrupting
>
>
> the DetNet QoS being provided to already admitted flows.
>
>
>
>
>
> Different queuing mechanisms exhibit different properties across
>
>
> achievable end-to-end jitter bounds, achievable end-to-end latency
>
>
> bounds and complexity. All three of these areas are considerations
>
>
> in evaluation and selection of scalable DetNet queuing mechanisms.
>
>
> END
>
>
>
>
>
> This rewrite did not capture the contents of following sentence in the original (OLD) text, which did not seem to fit here, perhaps there’s another better location for it in the draft?:
>
>
>
>
>
> The queuing mechanisms should be
>
>
> enhanced, for instance, adjust the cycle time in [IEEE802.1Qch] to
>
>
> meet the end to end latency while considering the feasibility with
>
>
> the dead time.
>
>
>
>
>
> The above rewrite is all suggested text – comments and revisions are welcome.
>
>
>
>
>
> Thanks, --David
>
>
>
>
>
>
> From: Peng Liu
> Sent: Tuesday, October 24, 2023 9:35 AM
> To: Black, David; jjoung
> Cc: detnet
> Subject: Comments on Section 3.7 of scaling requirements draft
>
>
>
>
>
>
>
> [EXTERNAL EMAIL]
>
>
>
> Hi David, Jinoo,
>
>
>
>
>
>
>
> As discussed, we may need to refine the Section 3.7, here is the text of v04 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-04 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-04__;!!LpKI!hZ1_9jzFCtnMvzqwrB7hySWeF28Rx8BSzLHdSGLBWMe8DIcTZX8xuIi9eqzJxue4-16VoiE7dbHiy4W14W4crUeZ$> [datatracker.ietf.org] (https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-detnet-scaling-requirements-04__;!!LpKI!gTHAVTfSeWjqs27oKrWjnhk4ESDN2tvLiL1GDXwqmPox-rrbaLGfxjgDjcqLrQaq-Gmr9rjWqzsxO24Id1hu9qk8$) (the changes from v03 are in red):
>
>
>
>
>
>
>
> //Req 7. Be Scalable to a Large Number of Hops with Complex Topology
>
>
>
> Scaling networks often results in situations where an end-to-end flow involves a large number of hops, e.g., 15 or more. The network topology can also be complex, including star, ring, mesh, and their combinations, and can possibly be hierarchical. It is required to support networks with such various types of topologies and large hop counts.
>
>
>
> Normally, bounded latency and jitter is a constant of application, so for the queuing mechanisms, keeping them with the variety of hops is required in scaling detnet. The queuing mechanisms should be enhanced, for instance, adjust the cycle time in [IEEE802.1Qch [doi.org] (https://urldefense.com/v3/__https:/doi.org/10.1109/IEEESTD.2017.7961303__;!!LpKI!gTHAVTfSeWjqs27oKrWjnhk4ESDN2tvLiL1GDXwqmPox-rrbaLGfxjgDjcqLrQaq-Gmr9rjWqzsxO24Id0wbV_KP$)] to meet the end to end latency while considering the feasibility with the dead time. The performance of a queuing mechanism can be evaluated based on the E2E latency bound, the E2E jitter bound, and the execution time required for resource scheduling, which might be constant, or linear functions, or exponential functions in terms of number of flows or network diameter.//
>
>
>
>
>
>
>
> Here are the text proposed before, which may help to explain more for this section while need the modification.
>
>
>
> As Jinoo's comments, we may prevent to use 'unacceptable' and better to 'recommend' the baseline criterion.
>
>
>
>
>
>
>
> //Req 7. Be Scalable to a Large Number of Hops with Complex Topology
>
>
>
> Normally, bounded latency and jitter is a constant of application regardless of the number of hops. So keeping them with the variety of hops is required in scaling detnet, especially for the lower end-to-end latency bound. The queueing mechanisms should meet the following points:
>
>
> For the latency, it is acceptable when the relationship between upper bound of end-to-end delay and hop number is linear, but is unacceptable when the relationship is exponential. Considering the diversity of queuing mechanisms in the future, the case of relationship between linear and exponential needs more evaluation.
> For the jitter, it should support tight jitter/sync-control loops, so it is acceptable when the end-to-end jitter is independent of hop number, otherwise it is unacceptable.
> For the routing calculation and the resources scheduling, the linear relationship is also expected but is not be limited because it will be more complex when considering the preformance of the control plane implementation, the flow aggregation to coordinate massive flows.
> There might be more proposed queuing mechanisms that can't be evaluated directly according to the methods above, the specific evaluation methods are out of scope of this document.//
>
>
>
>
>
> Please see if you can help to refine the text, thanks!!
>
>
>
>
>
>
>
> Regards,
>
>
>
> Peng
>
>
>
>
> [e-mail]<mailto:[e-mail]> (mailto:[e-mail])
>
>
>
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/detnet [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/detnet__;!!LpKI!hZ1_9jzFCtnMvzqwrB7hySWeF28Rx8BSzLHdSGLBWMe8DIcTZX8xuIi9eqzJxue4-16VoiE7dbHiy4W14eytryAS$>