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

[Mohammadpour Ehsan <[e-mail]>]

Dear Juergen,

Please see my comments below in red.


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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.epfl.ch%2Fehsan.mohammadpour%3Flang%3Den&data=02%7C01%7Cjuergen.jues.schmitt%40siemens.com%7C0b5ea704081d47df88a108d786fe8f08%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637126300187454466&sdata=5InUYgBBetl%2FOnLc3D8vbJ5xIszvQ6uFI0xR3k1JVjw%3D&reserved=0>


On 8 Jan 2020, at 13:30, [e-mail]<mailto:[e-mail]> wrote:

Thank you very much for your explanations.
Please see my responses in green below.

Greetings


Von: Mohammadpour Ehsan <[e-mail]<mailto:[e-mail]>>
Gesendet: Sonntag, 22. Dezember 2019 17:47
An: Schmitt, Juergen (DI CS SD EH FA 3) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [Detnet] Comments on draft-ietf-detnet-bounded-latency-01

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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.epfl.ch%2Fehsan.mohammadpour%3Flang%3Den&data=02%7C01%7Cjuergen.jues.schmitt%40siemens.com%7C0b5ea704081d47df88a108d786fe8f08%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637126300187454466&sdata=5InUYgBBetl%2FOnLc3D8vbJ5xIszvQ6uFI0xR3k1JVjw%3D&reserved=0>


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

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

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

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.



Juergen: Thank you for the explanation. Now with this new sentence I can understand this paragraph much better.



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.

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


Juergen: I fully understand the model you describe here. But I’m still not happy with “but yield poorer latency and buffer space guarantees”. My suggestion : “but attained latency and  buffer space guarantees are less tight then when that same …”



Ehsan: Thanks for the suggestion. I think that makes the text clearer.






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.

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

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.




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?

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.

Juergen:  Thanks for explaining your decision to choose this combination. For me personally a sentence which makes clear that this combination is only an example at the beginning of this paragraph would help a lot.
As a side note: To my knowledge ATS is discussed by the majority of people implicitly combined with SP. So your choice to combine it with CBS is a little bit exotic to me. Nevertheless it is a completely valid and possible combination from a TSN point of view.




Ehsan: We will modify the text to avoid any confusion.



- What makes it special opposed to only use ATS?

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.


Juergen: Sorry. I was not exact enough. The correct question should be:
- What makes it special opposed to simply use ATS combined with SP (which is in my head the default)?


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



Ehsan:
I would like to raise your attention about this fact that when we use any type of schedulers, like CBS, DRR, SP, etc. we have to deal with known issues called burstiness cascade and cyclic dependency inside a network (with loops) that makes the computation of delay and buffer size bounds too difficult; the issues that can be addressed by reshaping the flows at each network node using ATS. Therefore, the use of ATS is independent of the type of schedulers.

Now, among the possible combination of ATS, we selected the one with CBS, as it is typically used in TSN documents (e.g. look at page 190 of http://www.ieee802.org/1/files/private/q-edition-drafts/2019%20edition/802-1Q-2019-edition-d0-1.pdf, that put some preferences over using of CBS if supported, or section 34.6 of the same document). Of course, one can use other possible schedulers with ATS, like DRR or SP.




Greetings,
Juergen


_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/detnet<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdetnet&data=02%7C01%7Cjuergen.jues.schmitt%40siemens.com%7C0b5ea704081d47df88a108d786fe8f08%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637126300187464420&sdata=Q70YUbx0%2BzgmJ5gpftf15G9aikdFMh4K3h74bM2o0lc%3D&reserved=0>


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>