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

János Farkas <janos.farkas@ericsson.com> Fri, 19 October 2018 20:05 UTC

Return-Path: <Janos.Farkas@ericsson.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E50130E01 for <gen-art@ietfa.amsl.com>; Fri, 19 Oct 2018 13:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.364
X-Spam-Level:
X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCeGUi0jc_XZ for <gen-art@ietfa.amsl.com>; Fri, 19 Oct 2018 13:05:50 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581EB130E9D for <gen-art@ietf.org>; Fri, 19 Oct 2018 13:05:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539979545; x=1542571545; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ro4grRJ8HCKnzBcxJR30vvpaAZjNa7nYrWBd23AhsTI=; b=Wn3aC2u4D4Wh34PHxd32kWiBhCk/t5Bn2tRhzIw+IV9ZhSqocCb1N4nRWVRuLXln DQWO5Mqaoc1Lelsz89ZGejeHsNeQ/gndWQ7eL6bNZIuDEooEqTeBgXYwArgFwx3J CIz2kWTsjPvjCp33F5UkvfH+nTZJRWC5dqEU1l4jI3A=;
X-AuditID: c1b4fb3a-604d59e0000012ff-7f-5bca39195e92
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.96.04863.9193ACB5; Fri, 19 Oct 2018 22:05:45 +0200 (CEST)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 22:05:32 +0200
Received: from [100.94.32.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 22:05:31 +0200
To: "Joel M. Halpern" <jmh@joelhalpern.com>
CC: gen-art@ietf.org, draft-ietf-detnet-architecture.all@ietf.org, DetNet WG <detnet@ietf.org>, ietf@ietf.org
References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> <a773d59b-92e0-8acc-348c-b79b3b6048a6@ericsson.com> <ce26f203-2429-1eaf-4b5e-c81c2b76bed4@joelhalpern.com>
From: János Farkas <janos.farkas@ericsson.com>
Message-ID: <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com>
Date: Fri, 19 Oct 2018 22:05:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <ce26f203-2429-1eaf-4b5e-c81c2b76bed4@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2J7ua6k5alog7Uz2Cx+f5rNYrFv1iYW i6uvPrNYPNs4n8Xi46k3TA6sHkuW/GTyODflO2MAUxSXTUpqTmZZapG+XQJXxqLfp9kLvklV NLX6NjBeEe1i5OSQEDCReNyzjaWLkYtDSOAoo8Tybx/YIJxvjBI/Np2Ecg4zStw4tIIVpEVY wFPi7eZJYLaIgLbE/iUfmLoYOTiYBUolzn0Wgqhfxyixbk8LM0gNm4C9xN1LG8BsXiD7/aUm sF4WAVWJU2uOsoPYogKxEp+uLIaqEZQ4OfMJC4jNKeAs0bu7ASzOLGAhMXP+eUYIW16ieets qLi4xK0n85lAbCEBNYlPbx+yT2AUmoVk1Cwk7bOQtM9C0r6AkWUVo2hxanFxbrqRkV5qUWZy cXF+nl5easkmRmD4H9zy22oH48HnjocYBTgYlXh413CfihZiTSwrrsw9xCjBwawkwqtYejJa iDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWUkEB6YklqdmpqQWoRTJaJg1OqgXH20/KfQjLH rt7cxiLxUmZHoMDDnuenQy8s87c32SJ/PuhZZXCZSVxVzaFFtSsM+eOYH66f/JW5QPz5IucL 24vOnLrO0c722kvUW17x+r7JZhM75m36fXT2JE4Nhp1fK/85LBbekzmXa7746o3PjIWuv54e nCyscr0sWfwoa6Yod6qV637G/ENKLMUZiYZazEXFiQDeAIWYewIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/AuQP4s6BPHt5mT-nA0jqPFBlqVw>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2018 20:05:51 -0000

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