Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)

Lou Berger <lberger@labn.net> Thu, 10 September 2020 17:15 UTC

Return-Path: <lberger@labn.net>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C43A0E58 for <detnet@ietfa.amsl.com>; Thu, 10 Sep 2020 10:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 41FllNhMxPTo for <detnet@ietfa.amsl.com>; Thu, 10 Sep 2020 10:15:36 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 AB54D3A0E1C for <detnet@ietf.org>; Thu, 10 Sep 2020 10:15:36 -0700 (PDT)
Received: from CMGW (unknown [10.9.0.13]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 5F95A1E08F2 for <detnet@ietf.org>; Thu, 10 Sep 2020 11:15:31 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id GQAVkg0j3UY3DGQAVkD0pw; Thu, 10 Sep 2020 11:15:31 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.2 cv=K/NSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=reM5J-MqmosA:10 a=Vy_oeq2dmq0A:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=y75HceRYlxQPT5Bp-dgA:9 a=YjVpHElgmxALxuIH:21 a=mghPgGed9rH5UbCb:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=l1rpMCqCXRGZwUSuRcM3:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Ukf2ytxZ70I68kWqeOQkMVACzQMP05rYkDdN8Zf/qww=; b=v07SJI0J42Top4UwRpcLLdk9dy GKqHLcz+zuvFAcTLYupKw6L7BZZLPkU6AOWZ7Qht3X02Hp4eN1VWPB9EtapAkwoLW03eqaDKdlmla jsz7lLK9/fjfnt+4gw4oRrVL+;
Received: from [127.0.0.1] (port=15369 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <lberger@labn.net>) id 1kGQAU-003dLG-Vm; Thu, 10 Sep 2020 11:15:31 -0600
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Janos Farkas <Janos.Farkas@ericsson.com>
Cc: "detnet@ietf.org" <detnet@ietf.org>, "stewart.bryant@gmail.com" <stewart.bryant@gmail.com>, "eagros@dolby.com" <eagros@dolby.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-detnet-mpls@ietf.org" <draft-ietf-detnet-mpls@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>
References: <159957776121.26189.12459072134609921207@ietfa.amsl.com> <C67179BF-8ABF-48B7-A577-6DDF547AA56F@gmail.com> <b84c5d2d2d86e094cfec8f94ba9554516d0bb61c.camel@ericsson.com> <1382403d89c99db44e8269d016c6b6e02abed40f.camel@ericsson.com> <AM7PR07MB6994EB4D07FB44F046C55FA4F2260@AM7PR07MB6994.eurprd07.prod.outlook.com> <40f46ac3d56cd44906b35feb066ff9a8226bc891.camel@ericsson.com> <AM7PR07MB69948CBB26584E80199DE4DFF2270@AM7PR07MB6994.eurprd07.prod.outlook.com> <6f8f67998e90bf2c73d0073765f07060c4dbea97.camel@ericsson.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <a006c2e4-6249-3de6-af80-87810140153c@labn.net>
Date: Thu, 10 Sep 2020 13:15:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <6f8f67998e90bf2c73d0073765f07060c4dbea97.camel@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1kGQAU-003dLG-Vm
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:15369
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/fhSqDPp6g42tKcQdjv3FMwxgwwU>
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 17:15:39 -0000

Magnus,

I agree that minimum sized frames are needed as well.  Please see the 
text I proposed in my last message and note that the reference traffic 
specification (RFC2212) includes a minimum policed unit (m), and the 
maximum   datagram size (M).

Lou

On 9/10/2020 11:31 AM, Magnus Westerlund wrote:
> On Thu, 2020-09-10 at 13:26 +0000, Janos Farkas wrote:
>> Hi Magnus,
>>
>> I think we have the very same goal: make DetNet work; avoid any bugs.
>>
>> I may be wrong, but as far as I know, multiple methods could be used for
>> buffer dimensioning, e.g.: bytes, number of packets, time; and if a good job
>> is done, then one can be converted to another.
>>
>> I think we can make DetNet work if the POF buffer size is given in number of
>> packets if we do a good job with the traffic specification.
>> The flow information model draft (
>> https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-10#section-5.5
>> ) provides the following:
>>
>>     TrafficSpecification has the following attributes:
>>
>>     a.  Interval: the period of time in which the traffic specification
>>         is specified.
>>
>>     b.  MaxPacketsPerInterval: the maximum number of packets that the
>>         Ingress will transmit in one Interval.
>>
>>     c.  MaxPayloadSize: the maximum payload size that the Ingress will
>>         transmit.
>>
>>
>> Thus, my interpretation of your point is that the TrafficSpecification is not
>> good enough to make the conversion between time and number of packets.
> Exactly, this specification is good when one like ensure capability can handle
> the traffic by specifying the maxmimum kind of resource the flow will consume.
> But it doesn't work for calculate a bounded delay as by lowering the number of
> packets per second actually sent, the actual latency increases in the POF if it
> is configured only on number of packets. To bound latency based on number of
> packets, in that case you have to enforce that the flow have a minimal packet
> interval.
>
>> My preference is to leave number of packets for POF int the MPLS data plane
>> draft and make it sure that the TrafficSpecification provides all the
>> parameters needed for engineering to convert between number of packets and
>> time.
> So the number of packets is a relevant aspect, but as the dataplane draft states
> it is the combination of time and packets that bounds the POF function.
>
> I have no opinion if the TrafficSpecification is the right place to put this
> configuration boundary. It is really not a traffic flow property, it is more a
> configuration of the network from my perspecitive. And given a bound latency
> requirement from the Detnet flow the POF buffer depth may be different depending
> on what path through the MPLS network one uses.
>
>> Please let us know if we have overlooked anything with regards to the
>> TrafficSpecification and such conversion is not possible. If there is any
>> issue with the TrafficSpecification, then I think we should fix it.
>>
> To be clear i don't want to tell the WG how to do its work. I have noted what I
> consider a serious short comming, one that I think needs to be solved. I am
> happy to discuss it and the proposed way forward.
>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>