Re: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
> Sent: vendredi 19 octobre 2018 22:06
> To: Joel M. Halpern <[e-mail]>
> Cc: [e-mail]; [e-mail]; DetNet WG
> <[e-mail]>; [e-mail]
> 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