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
