Re: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16
"Black, David" <David.Black@dell.com> Tue, 19 June 2018 18:38 UTC
Return-Path: <David.Black@dell.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 64FDB130E08; Tue, 19 Jun 2018 11:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Y5zxJYXi; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=UOeneDP+
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 DuvhO6vIZD5P; Tue, 19 Jun 2018 11:38:29 -0700 (PDT)
Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 C3657130DC2; Tue, 19 Jun 2018 11:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1529433508; x=1560969508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UKMYmgM9s+PdwN/9kf7eRJmEVbp7/ldK4Ye2PVT5LsM=; b=Y5zxJYXib9TG/ZtM2jnoEVkEVqgTbHo3aUQbkzksFlQfGzX1q6fsJTv3 mSLU5jSy05BWZ1inZYhCS12RrwshymBByCMeEo6HWuHEJFGiL3wZKeBg8 tVD140AZTmM6tbOvxATbe6BnoQN2/ls5sx4Quo+UTYkgHS3zNazeGPQUv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2E9AABMTClbmGKa6ERdGgEBAQEBAgEBAQEIAQEBAYJ1gTZ/KAqLc4xSggCUe4E9OwsYCwuBSYIvRgKCbyE0GAECAQEBAQEBAgEBAhABAQEBAQgLCwYpIwyCNSQBDi8cIQgGAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBARcCQwESAhgBAQEEAQEbChMGHw8LAQsEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIMdAYF/AQ6uAjOCeIVPZQMFh0uBCYFVPoQbgxMBAYFiBYMrgiSHNCGRTAMEAgKQTIQAhU+CL4oThxkCBAIEBQIUgUGCC3BQgkOCL4JHgQeFFIU+b4oIKoEEgRoBAQ
X-IPAS-Result: A2E9AABMTClbmGKa6ERdGgEBAQEBAgEBAQEIAQEBAYJ1gTZ/KAqLc4xSggCUe4E9OwsYCwuBSYIvRgKCbyE0GAECAQEBAQEBAgEBAhABAQEBAQgLCwYpIwyCNSQBDi8cIQgGAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBARcCQwESAhgBAQEEAQEbChMGHw8LAQsEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCIMdAYF/AQ6uAjOCeIVPZQMFh0uBCYFVPoQbgxMBAYFiBYMrgiSHNCGRTAMEAgKQTIQAhU+CL4oThxkCBAIEBQIUgUGCC3BQgkOCL4JHgQeFFIU+b4oIKoEEgRoBAQ
Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 13:38:27 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2018 00:38:27 +0600
Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w5JIcKJ9007238 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 14:38:26 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w5JIcKJ9007238
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1529433506; bh=wQufToRMafnWNv+h3Yazmu4uDCU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UOeneDP+s3G4ffE3UdPIMIJRub185tHI04Q+Y6d9qMbedePeurdeuLnmFBbgnW8N2 gOebdPuIEC7b4Ba1FDm1zRKmWZu0N6k9VJqQYeyfd8EgziqsfpghyZoto9fENA29SI dfe3bA6jvwBmEHKjaPJB3hc9q33p3pn7zb+g21Tk=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w5JIcKJ9007238
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 19 Jun 2018 14:38:11 -0400
Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w5JIcBit021858 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 19 Jun 2018 14:38:12 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0382.000; Tue, 19 Jun 2018 14:38:11 -0400
To: "Grossman, Ethan A." <eagros@dolby.com>, DetNet WG <detnet@ietf.org>
CC: DetNet Chairs <detnet-chairs@ietf.org>
Thread-Topic: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16
Thread-Index: AQHT7RHcTGt/VQ9Sq0+bZHFsONjV6KRBBT8AgCZPUYCAAHtksIAAgT2A///N7fA=
Date: Tue, 19 Jun 2018 18:38:11 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363017FEB8@MX307CL04.corp.emc.com>
References: <30319033-7d4a-20c5-f4a6-35fe638cd08a@labn.net> <CE03DB3D7B45C245BCA0D24327794936301489B2@MX307CL04.corp.emc.com> <BY2PR0601MB1591561432ABF510F7E0429EC4700@BY2PR0601MB1591.namprd06.prod.outlook.com> <CE03DB3D7B45C245BCA0D243277949363017F5EE@MX307CL04.corp.emc.com> <BY2PR0601MB1591BDDF9BC7ABB660F2970EC4700@BY2PR0601MB1591.namprd06.prod.outlook.com>
In-Reply-To: <BY2PR0601MB1591BDDF9BC7ABB660F2970EC4700@BY2PR0601MB1591.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/F8kBXXeQYXxdY1q8UOaFOc-ZWQ0>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 18:38:33 -0000
Looks good to me, Thanks, --David > -----Original Message----- > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > Sent: Tuesday, June 19, 2018 1:37 PM > To: Black, David; DetNet WG > Cc: DetNet Chairs > Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16 > > Thanks David. Here is what I plan for item #1 below: > > Was: Packets sent over DetNet are guaranteed not to be dropped by the > network due to congestion. (Packets may however be dropped for intended > reasons, e.g. per security measures). > > Is: Packets sent over DetNet are guaranteed not to be dropped by the > network due to congestion. However, the network may drop packets for > intended reasons, e.g. per security measures. Also note that this guarantee > applies to the actions of DetNet protocol software, and does not provide any > guarantee against lower level errors such as media errors or checksum > errors. > > Regarding item #2, I understand your comment to mean that the text as > currently published in use cases draft 16 is acceptable as is, i.e. I am not > adding the text from my reply below. > > Ethan. > > -----Original Message----- > From: Black, David [mailto:David.Black@dell.com] > Sent: Tuesday, June 19, 2018 6:59 AM > To: Grossman, Ethan A. <eagros@dolby.com>; DetNet WG > <detnet@ietf.org> > Cc: DetNet Chairs <detnet-chairs@ietf.org>; Black, David > <David.Black@dell.com> > Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16 > > Hi Ethan, > > > 1) David> What about media (e.g., CRC) errors? > > > > DetNet does not have a mechanism to affect the presence or absence of > > media errors, nor does TSN. Such errors are one reason why both TSN > > and DetNet have so much focus on redundant paths as a means to provide > > a given level of reliability of packet delivery. > > Please add a mention of errors to this text to avoid any implication that > delivery is assured/guaranteed in the absence of security restrictions: > > 11.1.6. Guaranteed End-to-End Delivery > > Packets sent over DetNet are guaranteed not to be dropped by the > network due to congestion. (Packets may however be dropped for > intended reasons, e.g. per security measures). > > e.g., per security measures -> e.g., due to checksum errors or security > measures > > > 2) David> Is this just about bandwidth, or a more general notion of > > network resources including capacity for queueing/buffering, even > > though bandwidth may be the most user-visible resource? > > > > The user notion of a specific amount of bandwidth is what is being > > provided by a DetNet network; any underlying network resources are > > implied to be "sufficient" but are otherwise opaque at the DetNet > interface. > > I think this is ok - no text change needed. > > Thanks, --David > > > -----Original Message----- > > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > > Sent: Monday, June 18, 2018 10:33 PM > > To: Black, David; DetNet WG > > Cc: DetNet Chairs > > Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16 > > > > Hi David, WG, > > Here is my understanding of the answers to your questions - others > > please chime in if I miss something here. If I don't hear any comment > > on this by the end of this week I will add some statement in the use > > cases drafts to clarify each of these points based on the explanations > > below. Obviously if there is comment I will integrate that instead. > > > > 1) David> What about media (e.g., CRC) errors? > > > > DetNet does not have a mechanism to affect the presence or absence of > > media errors, nor does TSN. Such errors are one reason why both TSN > > and DetNet have so much focus on redundant paths as a means to provide > > a given level of reliability of packet delivery. > > > > 2) David> Is this just about bandwidth, or a more general notion of > > network resources including capacity for queueing/buffering, even > > though bandwidth may be the most user-visible resource? > > > > The user notion of a specific amount of bandwidth is what is being > > provided by a DetNet network; any underlying network resources are > > implied to be "sufficient" but are otherwise opaque at the DetNet > interface. > > > > Best, > > Ethan. > > P.S. These are the only LC comments on the Use Cases draft that I know > > of (apart from Lou's Shepherd Review comments) - if you sent some > > other comments and are waiting for a reply, please re-send them. > > > > ---------------------------------------------------------------------- > > - > > -----Original Message----- > > From: Black, David [mailto:David.Black@dell.com] > > Sent: Friday, May 25, 2018 2:36 PM > > To: Lou Berger <lberger@labn.net>; DetNet WG <detnet@ietf.org> > > Cc: DetNet Chairs <detnet-chairs@ietf.org> > > Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16 > > > > Looking at Section 11 (which is starting to tease out common > > requirements) from a Transport (Area) viewpoint, I have a couple of > questions: > > > > 11.1.6. Guaranteed End-to-End Delivery > > > > Packets sent over DetNet are guaranteed not to be dropped by the > > network due to congestion. (Packets may however be dropped for > > intended reasons, e.g. per security measures). > > > > David> What about media (e.g., CRC) errors? > > > > 11.1.9. Unused Reserved BW to be Available to Best Effort Traffic > > > > If bandwidth reservations are made for a stream but the associated > > bandwidth is not used at any point in time, that bandwidth is made > > available on the network for best-effort traffic. If the owner of > > the reserved stream then starts transmitting again, the bandwidth is > > no longer available for best-effort traffic, on a moment-to-moment > > basis. Note that such "temporarily available" bandwidth is not > > available for time-sensitive traffic, which must have its own > > reservation. > > > > David> Is this just about bandwidth, or a more general notion of > > David> network > > resources including capacity for queueing/buffering, even though > > bandwidth may be the most user-visible resource? > > > > Thanks, --David > > > > > -----Original Message----- > > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou > > > Berger > > > Sent: Wednesday, May 16, 2018 8:31 AM > > > To: DetNet WG > > > Cc: DetNet Chairs > > > Subject: [Detnet] WG Last Call: draft-ietf-detnet-use-cases-16 > > > > > > All, > > > > > > This starts a two-week working group last call for > > > draft-ietf-detnet-use-cases-16 > > > > > > The working group last call ends on May 30. > > > Please send your comments to the detnet mailing list. > > > > > > Positive comments, e.g., "I've reviewed this document and believe it > > > is ready for publication", are welcome! > > > This is useful and important, even from authors. > > > > > > Thank you, > > > DetNet Chairs > > > > > > _______________________________________________ > > > detnet mailing list > > > detnet@ietf.org > > > https://www.ietf.org/mailman/listinfo/detnet
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Grossman, Ethan A.
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Grossman, Ethan A.
- [Detnet] WG Last Call: draft-ietf-detnet-use-case… Lou Berger
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Grossman, Ethan A.
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Xavier Vilajosana
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Prof. Diego Dujovne
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-use-… Lou Berger