Hi Pascal,
Thank you for your comment!
There was another comment pointing out that the text I suggested is
misleading.
Instead, I suggest the following update:
OLD:
In general, a trivial priority-based queuing scheme will give better
average latency to a data flow than DetNet, but of course, the worst-
case latency can be essentially unbounded.
NEW:
In general, a trivial priority-based queuing scheme will give better
average latency to a data flow than DetNet; however, it may not be
a suitable option for DetNet because of its worst-case latency.
I think it addresses both Joel's and Pascal's concern. I hope it is
clear this way.
Thank you!
Best regards,
Janos
On 10/22/2018 2:32 PM, Pascal Thubert (pthubert) wrote:
Hello János
I's change reasonably to strictly.
The whole point of bounded in detnet is that it is not a vague boundary but a hard, guaranteed one, regardless of any other activity in the network.
All the best,
Pascal
-----Original Message-----
From: János Farkas <janos.farkas@xxxxxxxxxxxx>
Sent: vendredi 19 octobre 2018 22:06
To: Joel M. Halpern <jmh@xxxxxxxxxxxxxxx>
Cc: gen-art@xxxxxxxx; draft-ietf-detnet-architecture.all@xxxxxxxx; DetNet WG
<detnet@xxxxxxxx>; ietf@xxxxxxxx
Subject: Re: Genart last call review of draft-ietf-detnet-architecture-08
Joel,
Please see in-line.
On 10/19/2018 9:17 PM, Joel M. Halpern wrote:
Thank you Janos. Two clarifications under retained text, with the
rest elided.
Yours,
Joel
On 10/19/18 3:10 PM, János Farkas wrote:
...
On 9/22/2018 2:59 AM, Joel Halpern wrote:
...
Minor issues:
Section 3.1 states that worst case delay for priority queueing
is
unbounded. That does not match my understanding. I know that
DelayBound
DSCP behavior tightly (although, I think, not as tightly as
Detnet) limits
both the worst case delay and the delay variation.
Strict priority is not good enough for DetNet. A high priority packet
may need to wait until the transmission of a lower priority packet is
finished at an outbound port, which can cause too much uncertainties
in the network.
I understand that strict priority queueing is viewed as insufficient.
I wasn;t arguing about that. I was arguing with the use of the word
"unbounded". As far as I can tell, with suitable priority queueing
the worst case delay is bounded, simply not well enough bounded.
We can make the sentence clearer:
OLD:
In general, a trivial priority-based queuing scheme will give better average
latency to a data flow than DetNet, but of course, the worst- case latency can
be essentially unbounded.
NEW:
In general, a trivial priority-based queuing scheme will give better average
latency to a data flow than DetNet; however, it may be that the worst-case
latency cannot be reasonably bounded for DetNet.
...
In section 4.1.2, I realized that the Detnet Transit node
terminology had
mildly confused me. The text says "DetNet enabled nodes are
interconnected
via transit nodes (e.g., LSRs) which support DetNet, but are
not DetNet
service aware." Reading this, and the definitions in section
2.1, it
appears that a Detnet Transit node is a node that is providing
transport
behavior that detnet needs, but is not actually modified for
detnet.
Based on last call comments:
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html,
the phrase "DetNet enabled nodes" is removed from the document and it
has been made clear what type of DetNet node is meant:
The text is updated to:
A "Deterministic Network" will be composed of DetNet enabled end
systems, DetNet edge nodes, DetNet relay nodes and collectively
deliver DetNet services. DetNet relay and edge nodes are
interconnected via DetNet transit nodes (e.g., LSRs) which
support
DetNet, but are not DetNet service aware.
Any chance you could simply say "transit nodes" instead of "DetNet
transit nodes? As far as I can tell, they are existing nodes that
were designed and implemented (and even configured) potentially before
DetNet was even defined?
...
It has been pointed out during last call (https://www.ietf.org/mail-
archive/web/detnet/current/msg01791.html), to be specific on what node
type is meant; and be consistent with terminology and definitions. DetNet
transit node is a term defined by this document.
So, it seems better to have DetNet transit node.
Thank you!
Best regards,
Janos
