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

[János Farkas <[e-mail]>]

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 <[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