Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M

János Farkas <janos.farkas@ericsson.com> Wed, 19 December 2018 16:58 UTC

Return-Path: <Janos.Farkas@ericsson.com>
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 9181F130E71 for <detnet@ietfa.amsl.com>; Wed, 19 Dec 2018 08:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham 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 TbvnbwnuEDHm for <detnet@ietfa.amsl.com>; Wed, 19 Dec 2018 08:58:02 -0800 (PST)
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 DA233130E62 for <detnet@ietf.org>; Wed, 19 Dec 2018 08:58:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1545238680; x=1547830680; 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=HaAxJSgrrKQ+QumpVIsQn2SCj+eeKsIRV+8UnRQGQRo=; b=aBSlKQwGzSNswOzOoSxljFXM0N5R/e15NfTZooDt8GZKBb0smN5N2nVuvfwPYZq7 ccNMOUZpQPcFPlaeo5/fIzYVMrKys2Vy1i+W+YggmeTwUU78GexLCH81nnEvno6J k83hQ3expciIs3P0ssxb1QcOLSFgeIOHdqhyGb+ISvk=;
X-AuditID: c1b4fb3a-14fff7000000672c-5d-5c1a789766b5
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.8C.26412.7987A1C5; Wed, 19 Dec 2018 17:58:00 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB504.ericsson.se (153.88.183.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 19 Dec 2018 17:57:59 +0100
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 19 Dec 2018 17:57:59 +0100
Received: from [131.160.183.54] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 19 Dec 2018 17:57:58 +0100
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Grossman, Ethan A." <eagros@dolby.com>
CC: "jouni@gmail.com" <jouni@gmail.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, "detnet@ietf.org" <detnet@ietf.org>, Balázs Varga A <balazs.a.varga@ericsson.com>, "Maik Seewald (maseewal)" <maseewal@cisco.com>
References: <CY1PR0601MB1408FD124CDE12A8B4980100C4A30@CY1PR0601MB1408.namprd06.prod.outlook.com> <b6817ea0-869a-75e6-218f-c478f485e1d8@ericsson.com> <DM6PR06MB5659B678012FDCA7001247DFC4BD0@DM6PR06MB5659.namprd06.prod.outlook.com> <b018e8d7-7499-89bb-4f89-70a6640b8bde@ericsson.com> <ffa69772d1ef41538401e5e38e42e08e@XCH-RCD-001.cisco.com>
From: János Farkas <janos.farkas@ericsson.com>
Message-ID: <9fe3ec20-5623-acc6-46a3-22215beca7cb@ericsson.com>
Date: Wed, 19 Dec 2018 17:57:58 +0100
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: <ffa69772d1ef41538401e5e38e42e08e@XCH-RCD-001.cisco.com>
Content-Type: multipart/alternative; boundary="------------1C2A653ABC069A635FB61B93"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2J7qe6MCqkYgyvTGC1+f5rNYtH3eDu7 xbe/j5ksLi/cw24xY8o7RosjG86yOrB5TPm9kdVj38QjLB47Z91l91iy5CdTAEsUl01Kak5m WWqRvl0CV8arfddYCuYsZ6y4tf4sUwNjZ3UXIyeHhICJxIqGFvYuRi4OIYEjjBK7P+1ihnC+ MUpMX/+ZHc75/vM4VOYoo8S3ngZmkH5hgRyJ5ccmg9kiAvES/RvuMoEUMQu8Y5S4/WUiVMct Jon+o5dYQarYBOwl7l7aANbBC2T/WnKQDcRmEVCVeHLyFViNqECsxKcri6FqBCVOznzC0sXI wcEp4Crx7SonSJhZIEzizKuvrBC2uMStJ/OZQGwhATWJ9w13GCcwCs1C0j0LScssJC2zgKYy A13xYGsZRFheonnrbGYIW1/i+p37rMjiCxjZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIE xtrBLb+tdjAefO54iFGAg1GJh/dcvlSMEGtiWXFl7iFGCQ5mJRHeGyZAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rx/hARjhATSE0tSs1NTC1KLYLJMHJxSDYya/fYzb0148E6+NPhd6srVqbuq Vr4/bD6z5b/RpD83PRfobH9ZNy9w9Z/FdjWRmo9qt3SHx7vF16izfJ96ir9c1GSuL9vPfB9j B/Gbxi+u33/33/vW8/Ov3L+K7H1wcwfr82/xax3EclOmy/oGHJzBksrZfmNqu2nbm2J180M7 7QJmK9b1bhBXYinOSDTUYi4qTgQAfOO5FLECAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/hLu-bV2Kx-urMAdazLyxRmf79Ug>
Subject: Re: [Detnet] Resolving the remaining Use Cases Draft Comments - Cellular Radio and Industrial M2M
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: Wed, 19 Dec 2018 16:58:17 -0000

Well, I'd not enter MTBF discussion at this stage.

It is just example in the brackets. What about skipping numbers to get:

"Low packet loss (e.g., limited number of consecutive packets)"

?

The special aspect brought in really is the aspect of consecutive packets.

Regards,
Janos

On 12/19/2018 5:50 PM, Pascal Thubert (pthubert) wrote:
>
> Hello János
>
> I agree to change the sentence. Zero is not reasonable in the real 
> world, even in wired space : ) What about
>
>
> "Low packet loss (e.g.,  one in a million, one in a billion, min time 
> between losses, min packets between losses, strictly bounded number of 
> consecutive losses)"
>
> Maybe that’s too many examples but when you look up the (old) art of 
> “reliability “ you end up with terms such as MTBF…
>
> All the best
>
> Pascal
>
> *From:*detnet <detnet-bounces@ietf.org> *On Behalf Of *János Farkas
> *Sent:* mercredi 19 décembre 2018 17:13
> *To:* Grossman, Ethan A. <eagros@dolby.com>
> *Cc:* jouni@gmail.com; Suresh Krishnan <suresh.krishnan@gmail.com>; 
> detnet@ietf.org; Balázs Varga A <balazs.a.varga@ericsson.com>; Maik 
> Seewald (maseewal) <maseewal@cisco.com>
> *Subject:* Re: [Detnet] Resolving the remaining Use Cases Draft 
> Comments - Cellular Radio and Industrial M2M
>
> I just tried to resolve the concern around burstless.
>
> Actually, the numbers may not be right.
>
> Checking IEC/IEEE 60802 contributions
> https://1.ieee802.org/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation/
>
> Use Cases: 
> http://www.ieee802.org/1/files/public/docs2018/60802-industrial-use-cases-0918-v13.pdf
> and traffic type characterization: 
> http://www.ieee802.org/1/files/public/docs2018/60802-ademaj-traffic-type-characterization-1118-v01.pdf
> indicate that the most stringent requirement is zero loss.
> The next one is how many consecutive packets may be lost
> There are more relaxed cases.
>
> This section is: 7.4.  Industrial M2M Asks
>
> Maybe we should focus on the stringent cases.
>
> What about updating the bullet to:
>
> "Low packet loss (e.g., zero, limited number of consecutive packets)"
>
> ?
>
> Regards,
> Janos
>
> On 12/18/2018 8:31 PM, Grossman, Ethan A. wrote:
>
>     Thanks Janos,
>
>     Doesn’t 0.1-1% sound like an awful lot of packet loss?
>
>     Do I understand correctly that you mean:
>
>     "Low packet loss (0.1-1 % of packets can be lost, but only a
>     bounded number of consecutive packets can be lost)"
>
>     I guess I still don’t exactly understand the intent, can you
>     please clarify?
>     Thanks, and sorry for being dense here.
>
>     Ethan.
>
>     *From:*János Farkas <janos.farkas@ericsson.com>
>     <mailto:janos.farkas@ericsson.com>
>     *Sent:* Tuesday, December 18, 2018 8:21 AM
>     *To:* Grossman, Ethan A. <eagros@dolby.com> <mailto:eagros@dolby.com>
>     *Cc:* jouni@gmail.com <mailto:jouni@gmail.com>; Maik Seewald
>     (maseewal) <maseewal@cisco.com> <mailto:maseewal@cisco.com>;
>     Balázs Varga A <balazs.a.varga@ericsson.com>
>     <mailto:balazs.a.varga@ericsson.com>; detnet@ietf.org
>     <mailto:detnet@ietf.org>; Suresh Krishnan
>     <suresh.krishnan@gmail.com> <mailto:suresh.krishnan@gmail.com>
>     *Subject:* Re: Resolving the remaining Use Cases Draft Comments -
>     Cellular Radio and Industrial M2M
>
>     Hi Ethan,
>
>     Maybe it is not a god phrase, but the intention with the phrase
>     that the loss should be burstless was that consecutive packets
>     should not be lost.
>     Perhaps the maximum consecutive loss tolerance parameter describes
>     it better in
>     https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dflow-2Dinformation-2Dmodel-2D02&d=DwMD-g&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=0W0EQyafQ7HdKxGYDUDOn91m44yUJHQre2QdC0Pq5rI&s=xtlwetwJuYWGjTBmpNfLC8CvvhDk4x1YkRjNDTE0rws&e=>.
>     It is the "maximum    number of consecutive packets whose loss can
>     be tolerated"
>
>     Maybe updating the bullet in the use cases draft to:
>
>     "Low packet loss (0.1-1 %, limited number of consecutive packets)"
>
>     ?
>
>     Regards,
>     Janos
>
>     On 12/16/2018 6:03 AM, Grossman, Ethan A. wrote:
>
>         *_Balazs, Janos: _*
>
>         * Section 7.4
>
>         What does burstless mean (especially in the context of low
>         packet loss)?
>