Subject: [Detnet] WG: Comments on draft-ietf-detnet-bounded-latency-01

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Dec 2019 15:57:27 +0000

Hi all,

I have some questions / comments  related to some text within draft-ietf-detnet-bounded-latency-01.

------------------------------------

I’m not sure what is  meant by:

⇒ “It gives the best possible worst-case behavior.” (Page 5 / Line 3,4)

My assumption here is you wanted to express, that when every requirement of every flow is known upfront  it is possible tailor the network most exactly according to these flows.

What I want to say here is, that I think that words like "best" / "better", "worse" or similar words are not a good fit here. It's all about the requirements of the flows and how many of these flows are you able to serve within such a network. Some depend on minimal latency, some on minimal jitter and other require a maximum of availability.

If my assumption is true, I suggest a sentence according the lines of the

following:

--> "Here it is possible to tailor the network most exactly according the requirements of the flows."

------------------------------------

The same holds true for:

⇒ "Other queuing methods  (e.g. the credit-based shaper defined in [IEEE8021Q] section 8.6.8.2) can be used for dynamic flow creation, but yield poorer latency and  buffer space guarantees than when that same queuing method is used for static flow creation (Section 3.1.1)." (Last sentence of Page 5)

Is the intention here to say, that someone who wants to be able to establish flows in a simple and dynamic way has to do some kind of over provision to get the desired flexibility (regarding bandwidth, latency, buffer space ...).

This is true. But in my view this doesn't make it "poorer". It's just the price to pay for flexibility combined with a simple controller plane.

------------------------------------

Within the text, beginning with page 12, the term "max_packet_length" is used multiple times. I suggest to use the term "max_burst_size". This would leave it open to use multiple frames as one burst.

------------------------------------

While I read the section "Credit-Based Shaper with Asynchronous Traffic Shaping" two questions arised:

-  Why is there such a focus on exactly this combination on features selected out of the many possibilities TSN provides?

- What makes it special opposed to only use ATS?

Thank you all for your great work so far on all this papers within DetNet.

Greetings,

Juergen

---

From: Mohammadpour Ehsan <[email-masked]>
Date: Sun, 22 Dec 2019 16:46:51 +0000

Dear Juergen,

Thanks for your email. I tried to address your comments below.

Best,
Ehsan

--
Ehsan Mohammadpour
PhD Candidate at Swiss Federal Institute of Technology (EPFL)
EDIC PhD student Representative
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne
https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en>

On 10 Dec 2019, at 16:57, [email-masked]<mailto:[email-masked]> wrote:

Hi all,

I have some questions / comments  related to some text within draft-ietf-detnet-bounded-latency-01..

I agree that the sentence is not well expressing what we really mean; however, I feel like that there is a misunderstanding regarding the draft. The goal of the draft is to compute bounds on the delay and buffer size (which is written in the abstract), so that there is a guaranty for the delay and zero loss due to buffer overflow. This means that in this draft we are not targeting to address minimal latency, or other QoS requirement of DetNet flows (except maybe we want to add the jitter bound at some point). What I would like to propose is to replace the sentence with the following bolded sentence:

In this calculation, all of the DetNet flows are known before the
calculation commences.  This problem is of interest to relatively
static networks, or static parts of larger networks. It provides

bounds on delay and buffer size.  The calculations can be extended
to provide global optimizations, such as altering the path of one
DetNet flow in order to make resources available to another DetNet
flow with tighter constraints.

The same holds true for:

------------------------------------
The idea here is to say that in some applications we may have addition/removal flows from the network; this is what we call the dynamic flow creation. In this case, we put fixed resource capacity (reserved for detnet purpose) for each node, e.g., maximum burst and rate. We compute the delay and buffer bound using these capacity parameters. The admission is done based on the remaining capacity. The bounds are “poorer" in comparison with static one, as when we compute the bounds based on the fixed resource capacity (normally more than being used) and not how much the resource is used. This is the penalty we pay for being dynamic. In the case of static problem, we have set of flows with their TSPEC, and then the computation is done based on the existing flows (burst is some of the bursts of the flows).

Using “max_burst_size” does not conflict with “using multiple frames as one burst”. In the provided formula, we accounted for the shaping effect of the input link, i.e., "c t + L_max”. Even the previous node is intended to send multiple frames as burst, the line is transmitting frame-by-frame one after each other with the line rate. Using network calculus, the calculation gives the provided formula in the draft.

The section is an example among all possible configuration of TSN. The idea of this section is using ATS in combination with a scheduling algorithm. Instead of CBS, one can use DRR, SP, or other scheduling mechanisms. The intension here is we once do the complete calculation for one of the mechanisms; CBS is one of the main scheduling algorithms used in the context of TSN; so, we decided to select the combination of ATS with CBS.

I don't know what you mean by only using ATS. At the any you may have different priority classes and the corresponding flows should be behaved in different ways to meet their QoS requirement, e.g., we cannot combine flows of BE with TSN SR-A. What I understand of ATS is that is comes with a scheduling module (CBS, DRR, SP, …). Then as long as we can abstract each class with a service curve (Network calculus book, Jean-Yves Le Boudec and Patrick Thiran), we are able to compute bounds on delay and buffer size.

Greetings,
Juergen

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet