IETF Logo Mail Archive

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

John Grant <j@ninetiles.com> Wed, 19 December 2018 14:12 UTC

Return-Path: <j@ninetiles.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 CBBB712867A for <detnet@ietfa.amsl.com>; Wed, 19 Dec 2018 06:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 eaPgVm4W3RiE for <detnet@ietfa.amsl.com>; Wed, 19 Dec 2018 06:12:15 -0800 (PST)
Received: from know-smtprelay-omc-6.server.virginmedia.net (know-smtprelay-omc-6.server.virginmedia.net [80.0.253.70]) (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 BEC2E1200B3 for <detnet@ietf.org>; Wed, 19 Dec 2018 06:12:14 -0800 (PST)
Received: from [192.168.1.37] ([79.64.220.62]) by cmsmtp with ESMTPA id Zca3gwB0MBbWYZca3g6Edr; Wed, 19 Dec 2018 14:12:12 +0000
X-Originating-IP: [79.64.220.62]
X-Authenticated-User: john.s.grant@ntlworld.com
X-Spam: 0
X-Authority: v=2.3 cv=Z7TC4kZA c=1 sm=1 tr=0 a=/z0XdV0zd6JNGfriKbvufg==:117 a=/z0XdV0zd6JNGfriKbvufg==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=le6d79QuAAAA:8 a=_DC7OUD3A6tW0mH8YYwA:9 a=szf4JMlDjtsJt4Ko:21 a=TDr02KccyfzlixKR:21 a=pILNOxqGKmIA:10 a=UqCG9HQmAAAA:8 a=1PPSAmhThdHwY5Zv1XwA:9 a=EXTtKaJy4sKETQ1U:21 a=XCpXENLN_ZobvB1f:21 a=BHGngQkmD7r4pzOb:21 a=_W_S_7VecoQA:10 a=QbAMNLWdp4a7deKPGBBn:22
To: detnet@ietf.org
References: <CY1PR0601MB1408FD124CDE12A8B4980100C4A30@CY1PR0601MB1408.namprd06.prod.outlook.com> <b6817ea0-869a-75e6-218f-c478f485e1d8@ericsson.com> <DM6PR06MB5659B678012FDCA7001247DFC4BD0@DM6PR06MB5659.namprd06.prod.outlook.com>
From: John Grant <j@ninetiles.com>
Message-ID: <4bea41e6-18c9-91a2-8152-27cd7636bfaf@ninetiles.com>
Date: Wed, 19 Dec 2018 14:12:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <DM6PR06MB5659B678012FDCA7001247DFC4BD0@DM6PR06MB5659.namprd06.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------1AF18C3A544EA92AE72AC55E"
Content-Language: en-GB
X-CMAE-Envelope: MS4wfJFQtBPogDrX2y1MwGMhBlzp2rM+VOipsgx/Lc6d4LpJBaOdIACtksvBHtHoacGtAL2Z1pA5zamigEnJr3alzOXSxLdOFSBTF7wvcsYeCU2VV+Tv0+yo AcdW+yBc1Y89urhZJyOrjWmp4VVBpdlJqX+52aOPPnxBRXZaHPW8itxk
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/J0cspYau-KsV41flHOfJn0zP_Cg>
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 14:12:18 -0000

On 18/12/2018 19:31, 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?
>
It looks to me as if it's assumed that forward error correction will be 
needed. If you know you won't lose two consecutive packets, you can 
design the FEC around that assumption. On the other hand, if the network 
can reserve enough resource to ensure that level of service, you'd think 
it could manage to arrange that you don't lose any, except in very rare 
circumstances such as equipment malfunction. If the idea is to allow for 
interference on a radio link, I don't see how you can ensure that no 
burst of interference is long enough to affect two consecutive packets.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

v2.23.0 | Report a Bug | By Email