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
