From nobody Sat Oct 1 07:53:13 2016 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE05112B009; Sat, 1 Oct 2016 07:53:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147533358987.2812.7479925737595316699.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2016 07:53:09 -0700 Archived-At: Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-alt-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 14:53:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking of the IETF. Title : DetNet Data Plane Protocol and Solution Alternatives Authors : Jouni Korhonen János Farkas Gregory Mirsky Pascal Thubert Yan Zhuang Lou Berger Filename : draft-ietf-detnet-dp-alt-00.txt Pages : 51 Date : 2016-09-20 Abstract: This document identifies existing IP and MPLS, and other encapsulations that run over IP and/or MPLS data plane technologies that can be considered as the base line solution for deterministic networking data plane definition. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-alt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-detnet-dp-alt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 3 12:57:20 2016 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 557FE1294FC; Mon, 3 Oct 2016 12:57:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147552463534.29632.12980325347234459180.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 12:57:15 -0700 Archived-At: Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-11.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 19:57:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Use Cases Authors : Ethan Grossman Craig Gunther Pascal Thubert Patrick Wetterwald Jean Raymond Jouni Korhonen Yu Kaneko Subir Das Yiyong Zha Balázs Varga János Farkas Franz-Josef Goetz Juergen Schmitt Xavier Vilajosana Toktam Mahmoodi Spiros Spirou Petra Vizarreta Filename : draft-ietf-detnet-use-cases-11.txt Pages : 79 Date : 2016-10-03 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include wireless for industrial applications, professional audio, electrical utilities, building automation systems, radio/mobile access networks, automotive, and gaming. For each case, this document will identify the application, identify representative solutions used today, and what new uses an IETF DetNet solution may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-cases-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 3 13:15:28 2016 Return-Path: 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 C0CAA12950F for ; Mon, 3 Oct 2016 13:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Sr-Th1bWc_7D for ; Mon, 3 Oct 2016 13:15:25 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 02815129508 for ; Mon, 3 Oct 2016 13:15:24 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u93KB2l6027212 for ; Mon, 3 Oct 2016 13:15:24 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25tbd83j33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 03 Oct 2016 13:15:24 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 13:15:05 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 13:15:05 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-11.txt Thread-Index: AQHSHbBjPQfS6ze6WUOUHycI+aKPj6CXJZRA Date: Mon, 3 Oct 2016 20:15:04 +0000 Message-ID: <7f8ced5dbc9a455084879de5194a36cf@DLB-XCHPW03.dolby.net> References: <147552463534.29632.12980325347234459180.idtracker@ietfa.amsl.com> In-Reply-To: <147552463534.29632.12980325347234459180.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-03_11:, , signatures=0 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-11.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 20:15:27 -0000 SGkgQWxsLA0KDQpEZXROZXQgVXNlIENhc2VzIERyYWZ0IDExIGluY29ycG9yYXRlcyB0aGUgV2lu ZCBGYXJtIHVzZSBjYXNlIHN1Ym1pdHRlZCBieSBYYXZpIFZpbGFqb3NhbmEgZXQgYWwsIGludGVn cmF0ZWQgaW50byB0aGUgVXRpbGl0aWVzIHNlY3Rpb24gKHdpdGggdGhlIGtpbmQgdGVjaG5pY2Fs IG92ZXJzaWdodCBvZiBQYXRyaWNrIFdldHRlcndhbGQpLiBUaGUgc2Vuc2Ugb2YgdGhlIGN1cnJl bnQgdGV4dCBpcyBjbG9zZSB0byB0aGUgb3JpZ2luYWwsIGJ1dCB0aGVyZSBpcyBvbmUgbm90YWJs ZSBjaGFuZ2Ugd2hpY2ggSSBkZXNjcmliZSBiZWxvdy4gVGhhbmtzIGFnYWluIHRvIFhhdmksIFRv a3RhbSBNYWhtb29kaSwgU3Bpcm9zIFNwaXJvdSwgUGV0cmEgVml6YXJyZXRhIGFuZCB0aGUgRXVy b3BlYW4gVW5pb24ncyBIb3Jpem9uIDIwMjAgUmVzZWFyY2ggYW5kIElubm92YXRpb24gUHJvZ3Jh bSdzIFZpcnR1V2luZCBwcm9qZWN0IGZvciB0aGlzIGNvbnRyaWJ1dGlvbi4gDQoNClRoZSBvcmln aW5hbCBkcmFmdCBkZXNjcmliZXMgYSB3aW5kIGZhcm0gYmVpbmcgcmVtb3RlbHkgYWRtaW5pc3Rl cmVkIHZpYSBhbiBJbnRlcm5ldCBjb25uZWN0aW9uLiBUaGlzIGNvbm5lY3Rpb24gaGFzIGxvb3Nl IHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBiZWNhdXNlIGFueSB0aW1lLWNyaXRpY2FsIHdvcmsg aXMgZG9uZSBvbiB0aGUgbG9jYWwgbmV0d29yay4gVGhlIGFzayBmcm9tIHRoZSBkcmFmdCB3YXMg dG8gaW1wcm92ZSB0aGF0IHdvcmtmbG93IGJ5IGltcHJvdmluZyBJbnRlcm5ldCBxdWFsaXR5IG9m IHNlcnZpY2Ugc3VjaCB0aGF0IHNvbWUgdGltZS1jcml0aWNhbCB3b3JrIGNvdWxkIGJlIGRvbmUg b3ZlciB0aGUgSW50ZXJuZXQuIFNpbmNlIHRoZSBvcGVuIEludGVybmV0IGlzIG91dCBvZiBzY29w ZSBmb3IgRGV0TmV0LCBJIGFkYXB0ZWQgdGhpcyB1c2UgY2FzZSB0byB1c2UgYW4gT3BlcmF0b3It QWRtaW5pc3RlcmVkIFdBTiBpbnN0ZWFkLiBUaGVzZSBjaGFuZ2VzIHdlcmUgYXBwcm92ZWQgYnkg WGF2aS4gDQoNCkV0aGFuLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBk ZXRuZXQgW21haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDE2IDEyOjU3 IFBNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogZGV0bmV0QGlldGYub3JnDQpTdWJq ZWN0OiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTEu dHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIG9mIHRoZSBJRVRGLg0KDQogICAgICAg IFRpdGxlICAgICAgICAgICA6IERldGVybWluaXN0aWMgTmV0d29ya2luZyBVc2UgQ2FzZXMNCiAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogRXRoYW4gR3Jvc3NtYW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgQ3JhaWcgR3VudGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBQYXNjYWwg VGh1YmVydA0KICAgICAgICAgICAgICAgICAgICAgICAgICBQYXRyaWNrIFdldHRlcndhbGQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgSmVhbiBSYXltb25kDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEpvdW5pIEtvcmhvbmVuDQogICAgICAgICAgICAgICAgICAgICAgICAgIFl1IEthbmVr bw0KICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJpciBEYXMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgWWl5b25nIFpoYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBCYWzDoXpzIFZh cmdhDQogICAgICAgICAgICAgICAgICAgICAgICAgIErDoW5vcyBGYXJrYXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgRnJhbnotSm9zZWYgR29ldHoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgSnVlcmdlbiBTY2htaXR0DQogICAgICAgICAgICAgICAgICAgICAgICAgIFhhdmllciBWaWxh am9zYW5hDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRva3RhbSBNYWhtb29kaQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICBTcGlyb3MgU3Bpcm91DQogICAgICAgICAgICAgICAgICAgICAg ICAgIFBldHJhIFZpemFycmV0YQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZGV0bmV0 LXVzZS1jYXNlcy0xMS50eHQNCglQYWdlcyAgICAgICAgICAgOiA3OQ0KCURhdGUgICAgICAgICAg ICA6IDIwMTYtMTAtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IGRvY3VtZW50cyByZXF1 aXJlbWVudHMgaW4gc2V2ZXJhbCBkaXZlcnNlIGluZHVzdHJpZXMgdG8NCiAgIGVzdGFibGlzaCBt dWx0aS1ob3AgcGF0aHMgZm9yIGNoYXJhY3Rlcml6ZWQgZmxvd3Mgd2l0aCBkZXRlcm1pbmlzdGlj DQogICBwcm9wZXJ0aWVzLiAgSW4gdGhpcyBjb250ZXh0IGRldGVybWluaXN0aWMgaW1wbGllcyB0 aGF0IHN0cmVhbXMgY2FuDQogICBiZSBlc3RhYmxpc2hlZCB3aGljaCBwcm92aWRlIGd1YXJhbnRl ZWQgYmFuZHdpZHRoIGFuZCBsYXRlbmN5IHdoaWNoDQogICBjYW4gYmUgZXN0YWJsaXNoZWQgZnJv bSBlaXRoZXIgYSBMYXllciAyIG9yIExheWVyIDMgKElQKSBpbnRlcmZhY2UsDQogICBhbmQgd2hp Y2ggY2FuIGNvLWV4aXN0IG9uIGFuIElQIG5ldHdvcmsgd2l0aCBiZXN0LWVmZm9ydCB0cmFmZmlj Lg0KDQogICBBZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBpbmNsdWRlIG9wdGlvbmFsIHJlZHVuZGFu dCBwYXRocywgdmVyeSBoaWdoDQogICByZWxpYWJpbGl0eSBwYXRocywgdGltZSBzeW5jaHJvbml6 YXRpb24sIGFuZCBjbG9jayBkaXN0cmlidXRpb24uDQoNCiAgIEluZHVzdHJpZXMgY29uc2lkZXJl ZCBpbmNsdWRlIHdpcmVsZXNzIGZvciBpbmR1c3RyaWFsIGFwcGxpY2F0aW9ucywNCiAgIHByb2Zl c3Npb25hbCBhdWRpbywgZWxlY3RyaWNhbCB1dGlsaXRpZXMsIGJ1aWxkaW5nIGF1dG9tYXRpb24N CiAgIHN5c3RlbXMsIHJhZGlvL21vYmlsZSBhY2Nlc3MgbmV0d29ya3MsIGF1dG9tb3RpdmUsIGFu ZCBnYW1pbmcuDQoNCiAgIEZvciBlYWNoIGNhc2UsIHRoaXMgZG9jdW1lbnQgd2lsbCBpZGVudGlm eSB0aGUgYXBwbGljYXRpb24sIGlkZW50aWZ5DQogICByZXByZXNlbnRhdGl2ZSBzb2x1dGlvbnMg dXNlZCB0b2RheSwgYW5kIHdoYXQgbmV3IHVzZXMgYW4gSUVURiBEZXROZXQNCiAgIHNvbHV0aW9u IG1heSBlbmFibGUuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWRldG5ldC11c2UtY2FzZXMvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0 LXVzZS1jYXNlcy0xMQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1k ZXRuZXQtdXNlLWNhc2VzLTExDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGV0bmV0IG1haWxpbmcgbGlzdA0KZGV0 bmV0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5l dA0K From nobody Wed Oct 5 16:09:54 2016 Return-Path: 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 6B5821294D6 for ; Wed, 5 Oct 2016 16:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 6xb9zZOps4ls for ; Wed, 5 Oct 2016 16:09:52 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 0BBB01294D2 for ; Wed, 5 Oct 2016 16:09:52 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u95N9h0K020425 for ; Wed, 5 Oct 2016 16:09:51 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25uy8h5t7x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Oct 2016 16:09:51 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Oct 2016 16:09:28 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Wed, 5 Oct 2016 16:09:28 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements - How to express app time accuracy and reliability needs? Thread-Index: AdIfSZ9RlRHX+JyBRHenm9cDBBOMdg== Date: Wed, 5 Oct 2016 23:09:28 +0000 Message-ID: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_8620772c4ff1410ca6281384696a791bDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-05_06:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:09:53 -0000 --_000_8620772c4ff1410ca6281384696a791bDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, As of our IETF 96 meeting there were still a couple of Use Case Statements = that I would like clarity on. Here's the first, remaining to follow in sepa= rate emails. Question: How will an application express its time accuracy and reliability needs? Is= that within scope of DetNet? Discussion: In AVB/TSN when an application (talker) attempts to make a stream reservati= on it must state how much bandwidth that stream reservation requires. Presu= mably in a LAN this is sufficient since a LAN presumably has consistent tim= e accuracy and reliability metrics. For DetNet, in which we support interconnected DetNet networks and have wid= ely varying requirements for timing accuracy and reliability depending on t= he use case, it appears to me that we need to allow an application to provi= de this kind of information to the network, and a way for the network to ei= ther agree or decline to provide the requested service (analogous to AVB/TS= N accepting or declining a stream reservation based on the bandwidth reques= ted). We have had some discussion about this (see below) but nothing near consens= us. Other thoughts from anyone? Ethan. -------------------------------- Discussion, oldest item first: Ethan Grossman wrote: Timekeeping - the only explicit DetNet Ask for this is in the use cas= es is in M2M as "Precise time synchronization accuracy (1us)" and I think t= he intent (as in other use cases) is that the DetNet Ask is for a way to sp= ecify the required accuracy, not how to achieve that accuracy. Norm Finn wrote: Timekeeping is an essential part of many, probably most, of the appli= cations that also find DetNet useful. That having been said, so is protect= ion against EMI and electrical power saving. Let's concentrate DetNet on re= liable, on-time delivery of packets. I'm not even sure that "a way to spec= ify the required accuracy" need be in scope. Rodney Cummings wrote: I rarely disagree with Norm, but on this point I'll have to quibble a= bit. I agree that we don't need DetNet to specify how time sync is accompl= ished. There are plenty of IEEE 1588 techniques (and similar) for that purp= ose. I also agree that we should concentrate on reliable, on-time delivery= of packets (i.e. worst-case latency). If I don't know how accurate my time sync is, then how do I know when= a packet is delivered on time? If I don't know the reliability of my time = sync, how can I reliably measure that packet delivery? Almost all (if not 100%) of DetNet use cases require time sync at the= end systems to some degree of accuracy. I agree that we don't need to addr= ess the implementation of that time sync, but the application requirements = are needed for time sync (including reliability) just as much as for packet= delivery. -------------------------------- --_000_8620772c4ff1410ca6281384696a791bDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
 
As of our IETF 96 meeting there were still a couple of Use Case Statem= ents that I would like clarity on. Here’s the first, remaining to fol= low in separate emails.
 
Question:
How will an application express its time accuracy and reliability need= s? Is that within scope of DetNet?
 
Discussion:
In AVB/TSN when an application (talker) attempts to make a stream rese= rvation it must state how much bandwidth that stream reservation requires. = Presumably in a LAN this is sufficient since a LAN presumably has consisten= t time accuracy and reliability metrics.
 
For DetNet, in which we support interconnected DetNet networks and hav= e widely varying requirements for timing accuracy and reliability depending= on the use case, it appears to me that we need to allow an application to = provide this kind of information to the network, and a way for the network to either agree or decline to pro= vide the requested service (analogous to AVB/TSN accepting or declining a s= tream reservation based on the bandwidth requested).
 
We have had some discussion about this (see below) but nothing near co= nsensus. Other thoughts from anyone?
Ethan.
 
--------------------------------
Discussion, oldest item first:
 
Ethan Grossman wrote:   
Timekeeping - the only explicit DetNet As= k for this is in the use cases is in M2M as “Precise time synchroniza= tion accuracy (1us)” and I think the intent (as in other use cases) i= s that the DetNet Ask is for a way to specify the required accuracy, not how to achieve that accuracy.
 
Norm Finn wrote:
Timekeeping is an essential part of many,= probably most, of the applications that also find DetNet useful.  Tha= t having been said, so is protection against EMI and electrical power savin= g. Let’s concentrate DetNet on reliable, on-time delivery of packets.  I’m not even sure that “a wa= y to specify the required accuracy” need be in scope.
 
Rodney Cummings wrote:
I rarely disagree with Norm, but on this = point I'll have to quibble a bit.
I agree that we don't need DetNet to spec= ify how time sync is accomplished. There are plenty of IEEE 1588 techniques= (and similar) for that purpose.
I also agree that we should concentrate o= n reliable, on-time delivery of packets (i.e. worst-case latency).
If I don't know how accurate my time sync= is, then how do I know when a packet is delivered on time? If I don't know= the reliability of my time sync, how can I reliably measure that packet de= livery?
Almost all (if not 100%) of DetNet use ca= ses require time sync at the end systems to some degree of accuracy. I agre= e that we don't need to address the implementation of that time sync, but t= he application requirements are needed for time sync (including reliability) just as much as for packet delivery.<= /div>
--------------------------------
 
 --_000_8620772c4ff1410ca6281384696a791bDLBXCHPW03dolbynet_-- From nobody Wed Oct 5 16:25:54 2016 Return-Path: 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 86D5C1294D2 for ; Wed, 5 Oct 2016 16:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 rpoJQIsQOeb3 for ; Wed, 5 Oct 2016 16:25:51 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 5C46D129454 for ; Wed, 5 Oct 2016 16:25:51 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u95NOdVa030819 for ; Wed, 5 Oct 2016 16:25:51 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25uy8h5u5f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Oct 2016 16:25:51 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Oct 2016 16:25:28 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Wed, 5 Oct 2016 16:25:28 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements - Latency matching Thread-Index: AdIfXd/Gq1HxYlFESUmAufZ2/y8alw== Date: Wed, 5 Oct 2016 23:25:27 +0000 Message-ID: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_99768945c86b4c799b3bfdf0eb8f95a7DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-05_06:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:25:52 -0000 --_000_99768945c86b4c799b3bfdf0eb8f95a7DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Latency matching - single- or bi-directional. The Utilities use case needs = this, but is this something we need to address in DetNet? Discussion (oldest first): Ethan Grossman wrote: This came up because at least one use case mentioned a need for multiple ou= tgoing paths (or the send and return paths) to have matched latencies. I su= ppose one way to do this is to specify a latency which is the minimum, and = the add delay to the other path(s) to match it - but does this happen at th= e DetNet level or is it something the application layer would do? Pascal Thubert wrote: This seems related to the in-order packets delivery item. A tight latency = control can be useful to maintain that order. But doesn't this imply Time t= riggered operations? We could also add that feature of voluntary latency addition, probably asso= ciated to jitter elimination. --------------------------------------------------------- --_000_99768945c86b4c799b3bfdf0eb8f95a7DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Latency matching – single- or bi-directional. The Utilities use = case needs this, but is this something we need to address in DetNet?
 
Discussion (oldest first):
 
Ethan Grossman wrote:
This came up because at least one use case mentioned a need for multip= le outgoing paths (or the send and return paths) to have matched latencies.= I suppose one way to do this is to specify a latency which is the minimum,= and the add delay to the other path(s) to match it – but does this happen at the DetNet level or is = it something the application layer would do?
 
Pascal Thubert wrote:
This seems related to the in-order packets del= ivery item. A tight latency control can be useful to maintain that order. = But doesn’t this imply Time triggered operations?
We could also add that feature of voluntary la= tency addition, probably associated to jitter elimination.
---------------------------------------------------------
 
 
 
 --_000_99768945c86b4c799b3bfdf0eb8f95a7DLBXCHPW03dolbynet_-- From nobody Wed Oct 5 18:31:06 2016 Return-Path: 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 18EC112944C for ; Wed, 5 Oct 2016 18:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.295 X-Spam-Level: X-Spam-Status: No, score=-7.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 yyqvStNLCQPG for ; Wed, 5 Oct 2016 18:31:03 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB75129438 for ; Wed, 5 Oct 2016 18:31:03 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 6E0F11200CB; Wed, 5 Oct 2016 18:31:00 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 6E0F11200CB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1475717460; bh=hbdyTjwzjiFv1N8joEfzh1R9QrsNAxLQRqKrcsyu8Rc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=fGyuDxs+cJzcSihzzFf4uXhKBettcVcHaQ4lSUm4Sa64+ip4xUEX/bLaOdQRfgWIr zPk6gDlr6wxjOEfJh7wMMSGA7LDFQ5z4qkzWvZgz462RnHHnxjipfZRs0TRGO5HoVj zEx2X0SMRkWRpMa6rj4Qfo3QV0UtXt4ni1xJiQ0U= Content-Type: multipart/alternative; boundary="Apple-Mail=_AED569E1-3381-467C-8785-692C35B8A326" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: nfinn In-Reply-To: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> Date: Wed, 5 Oct 2016 18:30:59 -0700 Message-Id: <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> References: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." X-Mailer: Apple Mail (2.3124) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 6E0F11200CB.AE7F2 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.099, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 01:31:05 -0000 --Apple-Mail=_AED569E1-3381-467C-8785-692C35B8A326 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Interesting question. It seems more useful to me to make sure that the time protocols are able = to report, along with the time, the accuracy provided. The application = can then decide whether that is sufficient. The accuracy reported will = likely consist of several parameters (frequency accuracy, absolute = accuracy, etc.). Different time protocols may have different parameters = for accuracy. The application might worried about one or the other of = those parameters. It might operate in different modes, depending on the = accuracy provided. I don=E2=80=99t see the value in moving the decision = point anywhere else. With DetNet, one can imagine a bandwidth reservation crossing a boundary = between two different master clock domains. My inclination would be to = disallow that, at least for now. Given an application that runs for = long enough, any frequency difference between source and sink will = eventually cause starvation or overflow. All that said, let=E2=80=99s suppose that you have a solid use case that = is expected to *try* to run across clock domain boundaries, and we want = to prevent that when it won=E2=80=99t work. This could be solved by an = application-level protocol that exchanges clock domain information. = This could be solved by configuring the network controller to disallow = domain crossings. This could be handled by parameters in the = reservation protocol, as you suggest, so that the controller can allow = some reservations but not others. I=E2=80=99ll leave it to timing = experts to pick some number of appropriate parameters. One last consideration =E2=80=94 Are you sure that all applications that = have these timing requirements also require bandwidth reservations? = I=E2=80=99m not sure of that. And, if not, a protocol separate from the = bandwidth reservation might be indicated. =E2=80=94 Norm > On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. = wrote: >=20 > Hi Folks, > =20 > As of our IETF 96 meeting there were still a couple of Use Case = Statements that I would like clarity on. Here=E2=80=99s the first, = remaining to follow in separate emails.=20 > =20 > Question:=20 > How will an application express its time accuracy and reliability = needs? Is that within scope of DetNet?=20 > =20 > Discussion: > In AVB/TSN when an application (talker) attempts to make a stream = reservation it must state how much bandwidth that stream reservation = requires. Presumably in a LAN this is sufficient since a LAN presumably = has consistent time accuracy and reliability metrics.=20 > =20 > For DetNet, in which we support interconnected DetNet networks and = have widely varying requirements for timing accuracy and reliability = depending on the use case, it appears to me that we need to allow an = application to provide this kind of information to the network, and a = way for the network to either agree or decline to provide the requested = service (analogous to AVB/TSN accepting or declining a stream = reservation based on the bandwidth requested).=20 > =20 > We have had some discussion about this (see below) but nothing near = consensus. Other thoughts from anyone?=20 > Ethan. > =20 > -------------------------------- > Discussion, oldest item first: > =20 > Ethan Grossman wrote: =20 > Timekeeping - the only explicit DetNet Ask for this is in the use = cases is in M2M as =E2=80=9CPrecise time synchronization accuracy = (1us)=E2=80=9D and I think the intent (as in other use cases) is that = the DetNet Ask is for a way to specify the required accuracy, not how to = achieve that accuracy.=20 > =20 > Norm Finn wrote:=20 > Timekeeping is an essential part of many, probably most, of the = applications that also find DetNet useful. That having been said, so is = protection against EMI and electrical power saving. Let=E2=80=99s = concentrate DetNet on reliable, on-time delivery of packets. I=E2=80=99m = not even sure that =E2=80=9Ca way to specify the required accuracy=E2=80=9D= need be in scope. > =20 > Rodney Cummings wrote:=20 > I rarely disagree with Norm, but on this point I'll have to quibble a = bit. > I agree that we don't need DetNet to specify how time sync is = accomplished. There are plenty of IEEE 1588 techniques (and similar) for = that purpose. > I also agree that we should concentrate on reliable, on-time delivery = of packets (i.e. worst-case latency). > If I don't know how accurate my time sync is, then how do I know when = a packet is delivered on time? If I don't know the reliability of my = time sync, how can I reliably measure that packet delivery? > Almost all (if not 100%) of DetNet use cases require time sync at the = end systems to some degree of accuracy. I agree that we don't need to = address the implementation of that time sync, but the application = requirements are needed for time sync (including reliability) just as = much as for packet delivery. > -------------------------------- > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_AED569E1-3381-467C-8785-692C35B8A326 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Interesting question.

It seems more useful to me to make sure that the time = protocols are able to report, along with the time, the accuracy = provided.  The application can then decide whether that is = sufficient.  The accuracy reported will likely consist of several = parameters (frequency accuracy, absolute accuracy, etc.). =  Different time protocols may have different parameters for = accuracy.  The application might worried about one or the other of = those parameters.  It might operate in different modes, depending = on the accuracy provided.  I don=E2=80=99t see the value in moving = the decision point anywhere else.

With DetNet, one can imagine a = bandwidth reservation crossing a boundary between two different master = clock domains.  My inclination would be to disallow that, at least = for now.  Given an application that runs for long enough, any = frequency difference between source and sink will eventually cause = starvation or overflow.

All that said, let=E2=80=99s suppose that you have a solid = use case that is expected to *try* to run across clock domain = boundaries, and we want to prevent that when it won=E2=80=99t work. =  This could be solved by an application-level protocol that = exchanges clock domain information.  This could be solved by = configuring the network controller to disallow domain crossings. =  This could be handled by parameters in the reservation protocol, = as you suggest, so that the controller can allow some reservations but = not others.  I=E2=80=99ll leave it to timing experts to pick some = number of appropriate parameters.

One last consideration =E2=80=94 Are = you sure that all applications that have these timing requirements also = require bandwidth reservations?  I=E2=80=99m not sure of that. =  And, if not, a protocol separate from the bandwidth reservation = might be indicated.

=E2=80=94 Norm

On = Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. <eagros@dolby.com> = wrote:

Hi Folks,
 
As of our IETF 96 meeting there = were still a couple of Use Case Statements that I would like clarity on. = Here=E2=80=99s the first, remaining to follow in separate emails. 
 
Question: 
How = will an application express its time accuracy and reliability needs? Is = that within scope of DetNet? 
 
Discussion:
In= AVB/TSN when an application (talker) attempts to make a stream = reservation it must state how much bandwidth that stream reservation = requires. Presumably in a LAN this is sufficient since a LAN presumably = has consistent time accuracy and reliability metrics. 
 
For DetNet, in which we support = interconnected DetNet networks and have widely varying requirements for = timing accuracy and reliability depending on the use case, it appears to = me that we need to allow an application to provide this kind of = information to the network, and a way for the network to either agree or = decline to provide the requested service (analogous to AVB/TSN accepting = or declining a stream reservation based on the bandwidth = requested). 
 
We have had some discussion about = this (see below) but nothing near consensus. Other thoughts from = anyone? 
Ethan.
 
--------------------------------
Discussion, oldest item first:
 
Ethan Grossman = wrote:    
Timekeeping - the only explicit = DetNet Ask for this is in the use cases is in M2M as =E2=80=9CPrecise = time synchronization accuracy (1us)=E2=80=9D and I think the intent (as = in other use cases) is that the DetNet Ask is for a way to specify the = required accuracy, not how to achieve that accuracy. 
 
Norm Finn wrote: 
Timekeeping is an essential = part of many, probably most, of the applications that also find DetNet = useful.  That having been said, so is protection against EMI and = electrical power saving. Let=E2=80=99s concentrate DetNet on reliable, = on-time delivery of packets.  I=E2=80=99m not even sure that =E2=80=9C= a way to specify the required accuracy=E2=80=9D need be in = scope.
 
Rodney Cummings wrote: 
I rarely disagree with Norm, = but on this point I'll have to quibble a bit.
I agree that we don't need = DetNet to specify how time sync is accomplished. There are plenty of = IEEE 1588 techniques (and similar) for that purpose.
I also agree that we should = concentrate on reliable, on-time delivery of packets (i.e. worst-case = latency).
If I don't = know how accurate my time sync is, then how do I know when a packet is = delivered on time? If I don't know the reliability of my time sync, how = can I reliably measure that packet delivery?
Almost all (if not 100%) of = DetNet use cases require time sync at the end systems to some degree of = accuracy. I agree that we don't need to address the implementation of = that time sync, but the application requirements are needed for time = sync (including reliability) just as much as for packet = delivery.
--------------------------------
 
_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_AED569E1-3381-467C-8785-692C35B8A326-- From nobody Wed Oct 5 18:43:58 2016 Return-Path: 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 8329D129438 for ; Wed, 5 Oct 2016 18:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.295 X-Spam-Level: X-Spam-Status: No, score=-7.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 FqUO72dK0vo8 for ; Wed, 5 Oct 2016 18:43:55 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id A43E6129435 for ; Wed, 5 Oct 2016 18:43:55 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 05716120259; Wed, 5 Oct 2016 18:43:53 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 05716120259 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1475718234; bh=KHd+MTj6mD1NfrUCpWknvhbC2ZExYtFOtsq/pIcgVEo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=PdRhGFEPeLT0SriXNnzlh2YAqrGEI2Gmex6CfPQOv5tu/g6nzpaOl1gr72w+fFkI6 qJGld0xAoXlKTLziUFStsxp4ygO2McZvp6RfCXUu+ljK1usZSs7lBOKnTj4fyxDVL2 kEfhVE8DRoXSkpcGL8k8vsIc1NQleGb7Dk/CUZ/w= Content-Type: multipart/alternative; boundary="Apple-Mail=_96F0F195-FD58-4DD8-96D9-8337AE90F657" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: nfinn In-Reply-To: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> Date: Wed, 5 Oct 2016 18:43:53 -0700 Message-Id: <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> References: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." X-Mailer: Apple Mail (2.3124) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 05716120259.ACD13 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.099, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 01:43:57 -0000 --Apple-Mail=_96F0F195-FD58-4DD8-96D9-8337AE90F657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The architecture draft still mentions both minimum and maximum latency = as specifiable. In some sense, that solves the problem. The issue, of = course, is picking the minimum and maximum numbers. Perhaps there is = some way to provide clues to the app so it can pick suitable numbers. Bit, as I think about it, bi-directional latency equality is not at all = trivial to maintain. The existing TSN standards report latency, instead = of satisfying a requirement for latency. The imagined use (by me, = anyway) of a max latency parameter is to allow the network to change = topology, or reroute a stream, or add higher-priority flows, and still = guarantee the max latency is met. If, by bidirectional latency = matching, you mean, =E2=80=9Cmake both slow if one is slow, and = vice-versa,=E2=80=9D I don=E2=80=99t know how to do that. If you mean = =E2=80=9Cmeet min and max latency specifications for the flow=E2=80=9D, = then were on the right track, already. =E2=80=94 Norm > On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. = wrote: >=20 > Statement: > Latency matching =E2=80=93 single- or bi-directional. The Utilities = use case needs this, but is this something we need to address in DetNet?=20= > =20 > Discussion (oldest first): > =20 > Ethan Grossman wrote:=20 > This came up because at least one use case mentioned a need for = multiple outgoing paths (or the send and return paths) to have matched = latencies. I suppose one way to do this is to specify a latency which is = the minimum, and the add delay to the other path(s) to match it =E2=80=93 = but does this happen at the DetNet level or is it something the = application layer would do?=20 > =20 > Pascal Thubert wrote:=20 > This seems related to the in-order packets delivery item. A tight = latency control can be useful to maintain that order. But doesn=E2=80=99t = this imply Time triggered operations?=20 > We could also add that feature of voluntary latency addition, probably = associated to jitter elimination. > --------------------------------------------------------- > =20 > =20 > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_96F0F195-FD58-4DD8-96D9-8337AE90F657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The architecture draft still mentions both minimum and = maximum latency as specifiable.  In some sense, that solves the = problem.  The issue, of course, is picking the minimum and maximum = numbers.  Perhaps there is some way to provide clues to the app so = it can pick suitable numbers.

Bit, as I think about it, bi-directional latency equality is = not at all trivial to maintain.  The existing TSN standards report = latency, instead of satisfying a requirement for latency.  The = imagined use (by me, anyway) of a max latency parameter is to allow the = network to change topology, or reroute a stream, or add higher-priority = flows, and still guarantee the max latency is met.  If, by = bidirectional latency matching, you mean, =E2=80=9Cmake both slow if one = is slow, and vice-versa,=E2=80=9D I don=E2=80=99t know how to do that. =  If you mean =E2=80=9Cmeet min and max latency specifications for = the flow=E2=80=9D, then were on the right track, already.

=E2=80=94 = Norm

On Oct 5, 2016, at 4:25 PM, Grossman, Ethan = A. <eagros@dolby.com> wrote:

Statement:
Latency matching =E2=80=93 = single- or bi-directional. The Utilities use case needs this, but is = this something we need to address in DetNet? 
 
Discussion (oldest = first):
 
Ethan Grossman = wrote: 
This came up because at least one use case mentioned a need = for multiple outgoing paths (or the send and return paths) to have = matched latencies. I suppose one way to do this is to specify a latency = which is the minimum, and the add delay to the other path(s) to match it = =E2=80=93 but does this happen at the DetNet level or is it something = the application layer would do? 
 
Pascal Thubert wrote: 
This seems related to the in-order packets = delivery item. A tight latency control can be useful to maintain that = order. But doesn=E2=80=99t this imply Time triggered operations? 
We could also add that = feature of voluntary latency addition, probably associated to jitter = elimination.
---------------------------------------------------------
=
 
 
 
_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_96F0F195-FD58-4DD8-96D9-8337AE90F657-- From nobody Thu Oct 6 03:06:29 2016 Return-Path: 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 63F4A129549 for ; Thu, 6 Oct 2016 03:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 8kXnBXOq8aD7 for ; Thu, 6 Oct 2016 03:06:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4CD7E12953F for ; Thu, 6 Oct 2016 03:06:23 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 07DC8B0C4CDB9 for ; Thu, 6 Oct 2016 10:06:19 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u96A6KUR030283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Oct 2016 10:06:21 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u96A5Rfv007815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Oct 2016 12:06:16 +0200 Received: from [172.27.205.158] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Oct 2016 12:05:20 +0200 To: References: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> From: Olivier Marce Message-ID: Date: Thu, 6 Oct 2016 12:05:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 10:06:27 -0000 Hi, I'm in favor of Norm' position: DetNet should concentrate on reliable, on-time delivery of packets. Time accuracy is required for DetNet but out of scope, as many solutions exist and is not only a networking topic. At most, DetNet could provide some reference examples on how providing required time accuracy. Regards Le 06/10/2016 03:30, nfinn a crit : > Interesting question. > > It seems more useful to me to make sure that the time protocols are able > to report, along with the time, the accuracy provided. The application > can then decide whether that is sufficient. The accuracy reported will > likely consist of several parameters (frequency accuracy, absolute > accuracy, etc.). Different time protocols may have different parameters > for accuracy. The application might worried about one or the other of > those parameters. It might operate in different modes, depending on the > accuracy provided. I dont see the value in moving the decision point > anywhere else. > > With DetNet, one can imagine a bandwidth reservation crossing a boundary > between two different master clock domains. My inclination would be to > disallow that, at least for now. Given an application that runs for > long enough, any frequency difference between source and sink will > eventually cause starvation or overflow. > > All that said, lets suppose that you have a solid use case that is > expected to *try* to run across clock domain boundaries, and we want to > prevent that when it wont work. This could be solved by an > application-level protocol that exchanges clock domain information. > This could be solved by configuring the network controller to disallow > domain crossings. This could be handled by parameters in the > reservation protocol, as you suggest, so that the controller can allow > some reservations but not others. Ill leave it to timing experts to > pick some number of appropriate parameters. > > One last consideration Are you sure that all applications that have > these timing requirements also require bandwidth reservations? Im not > sure of that. And, if not, a protocol separate from the bandwidth > reservation might be indicated. > > Norm > >> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. > > wrote: >> >> Hi Folks, >> >> As of our IETF 96 meeting there were still a couple of Use Case >> Statements that I would like clarity on. Heres the first, remaining >> to follow in separate emails. >> >> Question: >> How will an application express its time accuracy and reliability >> needs? Is that within scope of DetNet? >> >> Discussion: >> In AVB/TSN when an application (talker) attempts to make a stream >> reservation it must state how much bandwidth that stream reservation >> requires. Presumably in a LAN this is sufficient since a LAN >> presumably has consistent time accuracy and reliability metrics. >> >> For DetNet, in which we support interconnected DetNet networks and >> have widely varying requirements for timing accuracy and reliability >> depending on the use case, it appears to me that we need to allow an >> application to provide this kind of information to the network, and a >> way for the network to either agree or decline to provide the >> requested service (analogous to AVB/TSN accepting or declining a >> stream reservation based on the bandwidth requested). >> >> We have had some discussion about this (see below) but nothing near >> consensus. Other thoughts from anyone? >> Ethan. >> >> -------------------------------- >> Discussion, oldest item first: >> >> Ethan Grossman wrote: >> Timekeeping - the only explicit DetNet Ask for this is in the use >> cases is in M2M as Precise time synchronization accuracy (1us) and I >> think the intent (as in other use cases) is that the DetNet Ask is for >> a way to specify the required accuracy, not how to achieve that accuracy. >> >> Norm Finn wrote: >> Timekeeping is an essential part of many, probably most, of the >> applications that also find DetNet useful. That having been said, so >> is protection against EMI and electrical power saving. Lets >> concentrate DetNet on reliable, on-time delivery of packets. Im not >> even sure that a way to specify the required accuracy need be in scope. >> >> Rodney Cummings wrote: >> I rarely disagree with Norm, but on this point I'll have to quibble a bit. >> I agree that we don't need DetNet to specify how time sync is >> accomplished. There are plenty of IEEE 1588 techniques (and similar) >> for that purpose. >> I also agree that we should concentrate on reliable, on-time delivery >> of packets (i.e. worst-case latency). >> If I don't know how accurate my time sync is, then how do I know when >> a packet is delivered on time? If I don't know the reliability of my >> time sync, how can I reliably measure that packet delivery? >> Almost all (if not 100%) of DetNet use cases require time sync at the >> end systems to some degree of accuracy. I agree that we don't need to >> address the implementation of that time sync, but the application >> requirements are needed for time sync (including reliability) just as >> much as for packet delivery. >> -------------------------------- >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Olivier Marc Nokia Bell Labs France "we need to guard against increased levels of reporting and other requirements that distract you from doing what you really need to be doing." Rajeev Suri, Nokia CEO, April 2016 From nobody Thu Oct 6 03:16:36 2016 Return-Path: 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 3FE3C129597 for ; Thu, 6 Oct 2016 03:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 1MKi47I9PWWu for ; Thu, 6 Oct 2016 03:16:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 79A45129590 for ; Thu, 6 Oct 2016 03:16:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 964D338871243 for ; Thu, 6 Oct 2016 10:16:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u96AGUob013668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Oct 2016 10:16:30 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u96AGCo5008945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Oct 2016 12:16:29 +0200 Received: from [172.27.205.158] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Oct 2016 12:16:10 +0200 To: References: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> From: Olivier Marce Message-ID: <87f5bd9e-ebe9-3b91-8cca-49614452a3e7@nokia.com> Date: Thu, 6 Oct 2016 12:16:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 10:16:34 -0000 Hi, I have the feeling that expressing min latency in addition to max latency is a loose way to express jitter control. There is a tradeoff between latency/jitter constraints and protection/paths redundancies: one could not expect having the same latency and jitter for one single path, than for multiple concurrent paths. As such jitter should be dependent of level of protections i.e. more paths, higher acceptable jitter. I do not see (yet) any reason for having similar latency on send and return paths. Regards Le 06/10/2016 03:43, nfinn a crit : > The architecture draft still mentions both minimum and maximum latency > as specifiable. In some sense, that solves the problem. The issue, of > course, is picking the minimum and maximum numbers. Perhaps there is > some way to provide clues to the app so it can pick suitable numbers. > > Bit, as I think about it, bi-directional latency equality is not at all > trivial to maintain. The existing TSN standards report latency, instead > of satisfying a requirement for latency. The imagined use (by me, > anyway) of a max latency parameter is to allow the network to change > topology, or reroute a stream, or add higher-priority flows, and still > guarantee the max latency is met. If, by bidirectional latency > matching, you mean, make both slow if one is slow, and vice-versa, I > dont know how to do that. If you mean meet min and max latency > specifications for the flow, then were on the right track, already. > > Norm > >> On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. > > wrote: >> >> Statement: >> Latency matching single- or bi-directional. The Utilities use case >> needs this, but is this something we need to address in DetNet? >> >> Discussion (oldest first): >> >> Ethan Grossman wrote: >> This came up because at least one use case mentioned a need for >> multiple outgoing paths (or the send and return paths) to have matched >> latencies. I suppose one way to do this is to specify a latency which >> is the minimum, and the add delay to the other path(s) to match it >> but does this happen at the DetNet level or is it something the >> application layer would do? >> >> Pascal Thubert wrote: >> This seems related to the in-order packets delivery item. A tight >> latency control can be useful to maintain that order. But doesnt this >> imply Time triggered operations? >> We could also add that feature of voluntary latency addition, probably >> associated to jitter elimination. >> --------------------------------------------------------- >> >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Olivier Marc Nokia Bell Labs France "we need to guard against increased levels of reporting and other requirements that distract you from doing what you really need to be doing." Rajeev Suri, Nokia CEO, April 2016 From nobody Thu Oct 6 08:55:54 2016 Return-Path: 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 A81681296E8 for ; Thu, 6 Oct 2016 08:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L4ZTVMR0ZwYS for ; Thu, 6 Oct 2016 08:55:50 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD1812956C for ; Thu, 6 Oct 2016 08:55:50 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id b186so21864070vkb.1 for ; Thu, 06 Oct 2016 08:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gp7b/oS1Sx68b6Ult6Lm1YZyNrxyglob4YcqkBdHo1c=; b=w4xRIKuY+WwPO5WftzSkqU8AYijNknxnxP4Ue87diDjsQ98GP0D1VR9dwm+mn3/BrA rfOG2yDj/Awagt5rl4mrgeKs1IzZvQf91rogdOkRU1kQR8nenKlgA6YqssaXz17XYtQu Se9e1BSGbTApY38jECUfGfwkX+4Zgu3dhiaSJQyIIaKnglVKZXdfl6MUiAtOW6jCDWcl 9HzsmqUq9UgjDcFkDj3aLy7B+fVfeyEO6vHZlhMVyti07iigRZv2vY+ADoN3S7WHJq6N CQa9VAH3cE7/vL7mq8L3mVxYqBhpyrQ1FY9076xg29dzDCb/5tga1WSIelmwcMWUSE/6 b3uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gp7b/oS1Sx68b6Ult6Lm1YZyNrxyglob4YcqkBdHo1c=; b=MmZGXpM2ddrT6qGUXHppr5wbut9Jd/7TBTRRJWHrjQtheFgEl90RhC0FdO/gKv7tp4 mTIDP7iRsvub7VufhG0DH6Rea4fgFxDPYJf29rwFBIG36+eROrxHzx3CURbuWA4l7iL8 TqHdR0MujVD/SO68Fb5vhEnc4JrHd83twsaGYDg1lKpYk1ctS0NbOXCotN/LyRlkriT3 fXw/pdFzKbNjwrV18Ju50iPmcZO5AN4bMqxBwIGwM4gdaY1wwPWqB1NKBFPVSkgcBrdA 42B9IamcqbP7ftz+jXGDrxWu9qO6YQuVdO5B+NE5587tBRPxutmPpm30OdgMbOIH8yT4 q2bg== X-Gm-Message-State: AA6/9RlVGWUYHMkY2cz0U2/DMBs93gdgWd1pwe3lgyQnbG67a84EKvesJ30D8Eh9IxmWoA== X-Received: by 10.31.157.201 with SMTP id g192mr11373931vke.85.1475769349055; Thu, 06 Oct 2016 08:55:49 -0700 (PDT) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com. [209.85.213.50]) by smtp.gmail.com with ESMTPSA id n71sm4537433vke.23.2016.10.06.08.55.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Oct 2016 08:55:48 -0700 (PDT) Received: by mail-vk0-f50.google.com with SMTP id z126so21938642vkd.0 for ; Thu, 06 Oct 2016 08:55:48 -0700 (PDT) X-Received: by 10.31.137.140 with SMTP id l134mr11577951vkd.90.1475769348426; Thu, 06 Oct 2016 08:55:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.228 with HTTP; Thu, 6 Oct 2016 08:55:48 -0700 (PDT) In-Reply-To: <87f5bd9e-ebe9-3b91-8cca-49614452a3e7@nokia.com> References: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> <87f5bd9e-ebe9-3b91-8cca-49614452a3e7@nokia.com> From: Gordon Bechtel Date: Thu, 6 Oct 2016 09:55:48 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Olivier Marce Content-Type: multipart/alternative; boundary=001a11459402c8a7c5053e34531e Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 15:55:53 -0000 --001a11459402c8a7c5053e34531e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seems to me that the question of latency metrics can be resolved in the same way Norm suggested for timing and bandwidth: Let the network *report* on what it is capable of (with whatever metrics this group feels makes sense) and let the application *decide* how best to use (or not use) the network. In the particular case of matched latencies, the network should report the latency metrics for each direction of the flow, and the application can decide if this is sufficient. Some applications need symmetric latencies (it sounds like the utility applications do) and some don't. But the network doesn't know that. Only the application does. Gordy On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce wrote: > Hi, > I have the feeling that expressing min latency in addition to max latency > is a loose way to express jitter control. > There is a tradeoff between latency/jitter constraints and > protection/paths redundancies: one could not expect having the same laten= cy > and jitter for one single path, than for multiple concurrent paths. > As such jitter should be dependent of level of protections i.e. more > paths, higher acceptable jitter. > > I do not see (yet) any reason for having similar latency on send and > return paths. > > Regards > > Le 06/10/2016 =C3=A0 03:43, nfinn a =C3=A9crit : > >> The architecture draft still mentions both minimum and maximum latency >> as specifiable. In some sense, that solves the problem. The issue, of >> course, is picking the minimum and maximum numbers. Perhaps there is >> some way to provide clues to the app so it can pick suitable numbers. >> >> Bit, as I think about it, bi-directional latency equality is not at all >> trivial to maintain. The existing TSN standards report latency, instead >> of satisfying a requirement for latency. The imagined use (by me, >> anyway) of a max latency parameter is to allow the network to change >> topology, or reroute a stream, or add higher-priority flows, and still >> guarantee the max latency is met. If, by bidirectional latency >> matching, you mean, =E2=80=9Cmake both slow if one is slow, and vice-ver= sa,=E2=80=9D I >> don=E2=80=99t know how to do that. If you mean =E2=80=9Cmeet min and ma= x latency >> specifications for the flow=E2=80=9D, then were on the right track, alre= ady. >> >> =E2=80=94 Norm >> >> On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. >> > wrote: >>> >>> Statement: >>> Latency matching =E2=80=93 single- or bi-directional. The Utilities use= case >>> needs this, but is this something we need to address in DetNet? >>> >>> Discussion (oldest first): >>> >>> Ethan Grossman wrote: >>> This came up because at least one use case mentioned a need for >>> multiple outgoing paths (or the send and return paths) to have matched >>> latencies. I suppose one way to do this is to specify a latency which >>> is the minimum, and the add delay to the other path(s) to match it =E2= =80=93 >>> but does this happen at the DetNet level or is it something the >>> application layer would do? >>> >>> Pascal Thubert wrote: >>> This seems related to the in-order packets delivery item. A tight >>> latency control can be useful to maintain that order. But doesn=E2=80= =99t this >>> imply Time triggered operations? >>> We could also add that feature of voluntary latency addition, probably >>> associated to jitter elimination. >>> --------------------------------------------------------- >>> >>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> >> > -- > Olivier Marc=C3=A9 > Nokia Bell Labs France > "we need to guard against increased levels of reporting and other > requirements that distract you from doing what you really need to be > doing." Rajeev Suri, Nokia CEO, April 2016 > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a11459402c8a7c5053e34531e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems to me that the question of latency metrics can be re= solved in the same way Norm suggested for timing and bandwidth: Let the net= work report on what it is capable of (with whatever metrics t= his group feels makes sense) and let the application decide h= ow best to use (or not use) the network.

In the particul= ar case of matched latencies, the network should report the latency metrics= for each direction of the flow, and the application can decide if this is = sufficient.=C2=A0 Some applications need symmetric latencies (it sounds lik= e the utility applications do) and some don't.=C2=A0 But the network do= esn't know that.=C2=A0 Only the application does.

<= div>Gordy

On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce <Olivier.Marce@nok= ia.com> wrote:
Hi,
I have the feeling that expressing min latency in addition to max latency i= s a loose way to express jitter control.
There is a tradeoff between latency/jitter constraints and protection/paths= redundancies: one could not expect having the same latency and jitter for = one single path, than for multiple concurrent paths.
As such jitter should be dependent of level of protections i.e. more paths,= higher acceptable jitter.

I do not see (yet) any reason for having similar latency on send and return= paths.

Regards

Le 06/10/2016 =C3=A0 03:43, nfinn a =C3=A9crit :
The architecture draft still mentions both minimum and maximum latency
as specifiable.=C2=A0 In some sense, that solves the problem.=C2=A0 The iss= ue, of
course, is picking the minimum and maximum numbers.=C2=A0 Perhaps there is<= br> some way to provide clues to the app so it can pick suitable numbers.

Bit, as I think about it, bi-directional latency equality is not at all
trivial to maintain.=C2=A0 The existing TSN standards report latency, inste= ad
of satisfying a requirement for latency.=C2=A0 The imagined use (by me,
anyway) of a max latency parameter is to allow the network to change
topology, or reroute a stream, or add higher-priority flows, and still
guarantee the max latency is met.=C2=A0 If, by bidirectional latency
matching, you mean, =E2=80=9Cmake both slow if one is slow, and vice-versa,= =E2=80=9D I
don=E2=80=99t know how to do that.=C2=A0 If you mean =E2=80=9Cmeet min and = max latency
specifications for the flow=E2=80=9D, then were on the right track, already= .

=E2=80=94 Norm

On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. <eagros@dolby.com
 <mailto:eagros@dol= by.com>> wrote:

Statement:
Latency matching =E2=80=93 single- or bi-directional. The Utilities use cas= e
needs this, but is this something we need to address in DetNet?

Discussion (oldest first):

Ethan Grossman wrote:
This came up because at least one use case mentioned a need for
multiple outgoing paths (or the send and return paths) to have matched
latencies. I suppose one way to do this is to specify a latency which
is the minimum, and the add delay to the other path(s) to match it =E2=80= =93
but does this happen at the DetNet level or is it something the
application layer would do?

Pascal Thubert wrote:
This seems related to the in-order packets delivery item. A tight
latency control can be useful to maintain that order. But doesn=E2=80=99t t= his
imply Time triggered operations?
We could also add that feature of voluntary latency addition, probably
associated to jitter elimination.
---------------------------------------------------------



_______________________________________________
detnet mailing list
detnet@ietf.org= <mailto:detnet= @ietf.org>
https://www.ietf.org/mailman/listinfo/detnet



_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet

--
Olivier Marc=C3=A9
Nokia Bell Labs France
"we need to guard against increased levels of reporting and other
requirements that distract you from doing what you really need to be doing.= " Rajeev Suri, Nokia CEO, April 2016


_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet

--001a11459402c8a7c5053e34531e-- From nobody Fri Oct 7 10:42:46 2016 Return-Path: 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 3B997129674 for ; Fri, 7 Oct 2016 10:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 dJx9L--X9mQ5 for ; Fri, 7 Oct 2016 10:42:43 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 C843F129493 for ; Fri, 7 Oct 2016 10:42:43 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u97HeAG3022799 for ; Fri, 7 Oct 2016 10:42:43 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25wjfxu6pj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 07 Oct 2016 10:42:43 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 10:42:17 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 10:42:17 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYw== Date: Fri, 7 Oct 2016 17:42:16 +0000 Message-ID: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: multipart/alternative; boundary="_000_857af1285c294744ae69f939e2a991cfDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0 Archived-At: Subject: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:42:45 -0000 --_000_857af1285c294744ae69f939e2a991cfDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, I did a brief "DetNet Status" presentation to the AVnu Alliance Technical W= orking Group, which is an industry group that promotes AVB/TSN. The attenda= nce at this particular meeting was mostly Pro Audio people, and their main = line of questioning was "What is the plan for incrementally migrating users= from where they are today to increasingly improved network performance, wh= ich would eventually culminate in "full DetNet"?" Another way to put it mi= ght be "Can we leverage the work of DetNet to improve networking capabiliti= es between now and when DetNet is implemented on most routers?" As far as I know, we don't have a plan to roll out a "migration path" with = intermediate performance levels, using today's protocols, perhaps with "min= or" changes to support DetNet. We are designing an architecture and protoco= l extensions that will do the job, leveraging existing protocols to the ex= tent possible, but it is an end goal, not a roadmap. Having said that, do we have any other more helpful reply to this line of q= uestioning? Thanks, Ethan. --_000_857af1285c294744ae69f939e2a991cfDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
 
I did a brief “DetNet Status” presentation to the AVnu All= iance Technical Working Group, which is an industry group that promotes AVB= /TSN. The attendance at this particular meeting was mostly Pro Audio people= , and their main line of questioning was “What is the plan for incrementally migrating users from where they are today to = increasingly improved network performance, which would eventually culminate= in “full DetNet”?”  Another way to put it might be = “Can we leverage the work of DetNet to improve networking capabilities between now and when DetNet is implemented on most routers?= 221; 
 
As far as I know, we don’t have a plan to roll out a “migr= ation path” with intermediate performance levels, using today’s= protocols, perhaps with “minor” changes to support DetNet. We = are designing an architecture and protocol extensions that will do the job, leveraging existing  protocols to the extent possible, but it is = an end goal, not a roadmap.
 
Having said that, do we have any other more helpful reply to this line= of questioning?
 
Thanks,
Ethan.
 
 --_000_857af1285c294744ae69f939e2a991cfDLBXCHPW03dolbynet_-- From nobody Fri Oct 7 11:23:00 2016 Return-Path: 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 91E5B12944A for ; Fri, 7 Oct 2016 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.onmicrosoft.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 vTET6SRoEAhH for ; Fri, 7 Oct 2016 11:22:57 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0127.outbound.protection.outlook.com [104.47.34.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E911E128B44 for ; Fri, 7 Oct 2016 11:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PynBGbs9MvyZ5LA/e7/dmoQnD7RViye1twzpnvcb8yc=; b=S7tgMhgVhLPOXReiRazufNbpde08kQrItVDzbr2b27bsjHvpbHHcFFCBf5iA1q63hZtSixxOX22hFaiqaZuMXXEOu2JmOnatpYUNMGSLtEOzHiJXUW/lIswrL7BD1GfXiy/7Ap9A2nQrSzFnMfzXZjxyVfyQq0MyPcdgAzH91EA= Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB422.namprd04.prod.outlook.com (10.141.58.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Fri, 7 Oct 2016 18:22:54 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.229]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.229]) with mapi id 15.01.0639.015; Fri, 7 Oct 2016 18:22:57 +0000 From: Rodney Cummings To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyng Date: Fri, 7 Oct 2016 18:22:57 +0000 Message-ID: References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> In-Reply-To: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.189] x-ms-office365-filtering-correlation-id: cdf5f03a-ee6b-44c7-632c-08d3eedef68d x-microsoft-exchange-diagnostics: 1; BN1PR04MB422; 6:grvzqdV/Uh8SNxEA+KU74TR4usAdX+DEcGdCpgqV3nRHvR3vvHIjBidUDPo7270u+5kF1mxPAz7BxoE/+n0a7F+zQsBZDxnc1wp5V02A5xAz3N5Rr85A+xx8ATaXQ4jwi6Lurg0MR2dk7ZNW5KVm9vpPYVFhOlFTovT79i2zrr/3Rchh+y6p7aKotX/YYO4zzmUwehS4bDo6Wo7ao2FsGxVb6TtBVkHTv4IVEhwbxZookLHrNoU4XmHVxLnmOBxKpppPzn3nH0tF8s26QXQe95YGGjApD9bMQAThoOrb5ks=; 5:ARonfkH+w9Opl0KmaT2lLzsxmR00aeAt+bWwge94BvsyN/4PUphPKVLSv3OF/BW+poZM4fVg9mrmxaQ07gBtIvOZB+Q/WuMSLpi2OyIxjRnHtHYexWXRAnPRFMC72MY202fIHxJqpoNLR/V1r4MjXw==; 24:dgk+5dc1fkrtK9rulwpJoFsbPqAfntktkLDBHzHI/bnkZYmF973ga/GDWgFCfXsFQMts8143XXcZCwZDsAoaCC41iqf/hPISPd3XHVDYPGQ=; 7:XdOVbM4u8ODVm28mk0hHeNTWd5xB3rg6IDmT2kuGpNXv6NfsZ/JsX+NuaVYJ1SdvragBoDLee57RuYUXufzys/lqhjzoXoqlRq32g4jW0sL6QytQlNrQRLIbggekMVcSX72XqSUtRip3oV2Ps+pXt+ZfyL4SYi/D/UA9HQiNT49QwV3LeS1HkV9Uo4ycDEmYc5eJkAzOb/weKdX7omA6TvGweDS1t+SU0/+YVYkrHURMIWy2YbfY6gY+YY6goXL3I3DzEsPG0AG4GonAljj5HpbhUB8xrpbLO+mvN9pm3aQCuK0udxS6cW/VNwFKd6q2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB422; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR04MB422; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB422; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(81166006)(122556002)(50986999)(81156014)(19580405001)(19580395003)(54356999)(3280700002)(99286002)(9686002)(8936002)(92566002)(3660700001)(5660300001)(106356001)(101416001)(105586002)(33656002)(76576001)(8676002)(76176999)(10400500002)(66066001)(74316002)(2900100001)(189998001)(2906002)(305945005)(6116002)(7696004)(102836003)(5001770100001)(107886002)(586003)(86362001)(87936001)(7736002)(68736007)(7846002)(97736004)(3846002)(5002640100001)(2950100002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB422; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 18:22:57.3943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB422 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:22:59 -0000 Great topic, I'm not completely clear on what it would mean for a router to support DetN= et, but let's assume it means that the router: 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify flows = of DetNet data. 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide DetNet= guarantees for that data (e.g. max latency). 3. Provides YANG management for #1 and #2. All of this could be done today using vendor-specific YANG modules, with ce= ntralized network management software from that vendor. That's not ideal of= course, but it is useful. How would a user application (protocol from draft-ietf-detnet-use-cases) us= e this? I would argue that the user applications should use the "API" specified in = 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/3 = details and the data-plane encoding. The user simply identifies the flows f= rom the host perspective (e.g. UDP header fields), and requests a maximum l= atency. The API is used between the user's application and the centralized = network management software. The API specifies YANG, so it can be implement= ed as a RESTful API or similar. AVnu Alliance's goal is to certify conformance to standards (i.e. multiple = vendors). Can AVnu Alliance certify the vendor-specific router implementation? No Can AVnu Alliance certify the 802.1Qcc API between the user application and= the vendor-specific network manager? Yes As time goes on and DetNet standards are published, can AVnu Alliance certi= fication do deeper into the routers? Yes That's one hypothetical intermediate plan. Rodney From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Friday, October 7, 2016 12:42 PM To: detnet@ietf.org Subject: [Detnet] DetNet - Migration path Hi Folks, =A0 I did a brief "DetNet Status" presentation to the AVnu Alliance Technical W= orking Group, which is an industry group that promotes AVB/TSN. The attenda= nce at this particular meeting was mostly Pro Audio people, and their main = line of questioning was "What is the plan for incrementally migrating users= from where they are today to increasingly improved network performance, wh= ich would eventually culminate in "full DetNet"?"=A0 Another way to put it = might be "Can we leverage the work of DetNet to improve networking capabili= ties between now and when DetNet is implemented on most routers?"=A0=20 =A0 As far as I know, we don't have a plan to roll out a "migration path" with = intermediate performance levels, using today's protocols, perhaps with "min= or" changes to support DetNet. We are designing an architecture and protoco= l extensions that will do the job, leveraging existing=A0 protocols to the = extent possible, but it is an end goal, not a roadmap.=20 =A0 Having said that, do we have any other more helpful reply to this line of q= uestioning?=20 =A0 Thanks, Ethan. =A0 From nobody Fri Oct 7 12:11:51 2016 Return-Path: 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 0C6CE129429 for ; Fri, 7 Oct 2016 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.294 X-Spam-Level: X-Spam-Status: No, score=-7.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 VICMYQBoZ2HG for ; Fri, 7 Oct 2016 12:11:45 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 46579120726 for ; Fri, 7 Oct 2016 12:11:45 -0700 (PDT) Received: from [192.168.1.108] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 01EBA120056; Fri, 7 Oct 2016 12:11:41 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 01EBA120056 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1475867503; bh=nKwzhZ0tWSe7k3VXPd+54kBw/drxzu0+jxuRDzN7rZk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Hp0JhSaYczl9A+l2v0YZPXKc501D0vmOch1nG9Lr2WUJDkNVkB+tBY2J+Ukc6tcG5 bGH86/zRpPYpjUNT5pg5DJrP+wi9YfN/Zz1XJrn3v/BP446Sd5Qep5g3f61jaP2n3j cpWxyjT5ijcHDWtSV2lBA6Pki3+HFd0K7rVikw5E= Content-Type: multipart/alternative; boundary=Apple-Mail-963E9042-2924-4C28-90FC-F78704A3DBB8 Mime-Version: 1.0 (1.0) From: Norman Finn X-Mailer: iPhone Mail (14A456) In-Reply-To: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> Date: Fri, 7 Oct 2016 12:11:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 01EBA120056.A3C55 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.098, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, MIME_QP_LONG_LINE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:11:50 -0000 --Apple-Mail-963E9042-2924-4C28-90FC-F78704A3DBB8 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable IMO, Ethan, the current work on P802.1Qcc and the brand-new PAR for Link Reg= istration Protocol are exactly the sort of next steps that AVnu is looking f= or. -- Norm > On Oct 7, 2016, at 10:42, Grossman, Ethan A. wrote: >=20 > Hi Folks, > =20 > I did a brief =93DetNet Status=94 presentation to the AVnu Alliance Techni= cal Working Group, which is an industry group that promotes AVB/TSN. The att= endance at this particular meeting was mostly Pro Audio people, and their ma= in line of questioning was =93What is the plan for incrementally migrating u= sers from where they are today to increasingly improved network performance,= which would eventually culminate in =93full DetNet=94?=94 Another way to p= ut it might be =93Can we leverage the work of DetNet to improve networking c= apabilities between now and when DetNet is implemented on most routers?=94=20= > =20 > As far as I know, we don=92t have a plan to roll out a =93migration path=94= with intermediate performance levels, using today=92s protocols, perhaps wi= th =93minor=94 changes to support DetNet. We are designing an architecture a= nd protocol extensions that will do the job, leveraging existing protocols t= o the extent possible, but it is an end goal, not a roadmap. > =20 > Having said that, do we have any other more helpful reply to this line of q= uestioning? > =20 > Thanks, > Ethan. > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --Apple-Mail-963E9042-2924-4C28-90FC-F78704A3DBB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
IMO, Ethan, the current wor= k on P802.1Qcc and the brand-new PAR for Link Registration Protocol are exac= tly the sort of next steps that AVnu is looking for.

-- Norm

On Oct 7, 2016, at 10:42, Grossman, Ethan A. <eagros@dolby.com> wrote:

=
Hi Folks,
 
I did a brief =E2=80=9CDetNet Status=E2=80=9D presentation to the AVnu A= lliance Technical Working Group, which is an industry group that promotes AV= B/TSN. The attendance at this particular meeting was mostly Pro Audio people= , and their main line of questioning was =E2=80=9CWhat is the plan for incrementally migrating users from where they are today to i= ncreasingly improved network performance, which would eventually culminate i= n =E2=80=9Cfull DetNet=E2=80=9D?=E2=80=9D  Another way to put it might b= e =E2=80=9CCan we leverage the work of DetNet to improve networking capabilities between now and when DetNet is implemented on most routers?=E2=80= =9D 
 
As far as I know, we don=E2=80=99t have a plan to roll out a =E2=80=9Cm= igration path=E2=80=9D with intermediate performance levels, using today=E2=80= =99s protocols, perhaps with =E2=80=9Cminor=E2=80=9D changes to support DetN= et. We are designing an architecture and protocol extensions that will do th= e job, leveraging existing  protocols to the extent possible, but it is a= n end goal, not a roadmap.
 
Having said that, do we have any other more helpful reply to this line o= f questioning?
 
Thanks,
Ethan.
 
____________________= ___________________________
detnet mailing list
detnet@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/detnet">https://www.ietf.org= /mailman/listinfo/detnet
= --Apple-Mail-963E9042-2924-4C28-90FC-F78704A3DBB8-- From nobody Fri Oct 7 13:13:56 2016 Return-Path: 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 10E1C129708 for ; Fri, 7 Oct 2016 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 q8_kNk3UPNK7 for ; Fri, 7 Oct 2016 13:13:53 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 90D7C129587 for ; Fri, 7 Oct 2016 13:13:53 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u97KA629025279 for ; Fri, 7 Oct 2016 13:13:53 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25wjfxubxc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 07 Oct 2016 13:13:53 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 13:13:27 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 13:13:26 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Security Review Thread-Index: AdIg1UITR2QEeogET/23bai5Z4zLUg== Date: Fri, 7 Oct 2016 20:13:26 +0000 Message-ID: <10f52d4c6629445cae87f49f9ebb7a36@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: multipart/alternative; boundary="_000_10f52d4c6629445cae87f49f9ebb7a36DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Security Review X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:13:55 -0000 --_000_10f52d4c6629445cae87f49f9ebb7a36DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Security is of paramount importance for most if not all of the networks des= cribed in the DetNet use cases. I gather that DetNet itself doesn't have a = lot of explicit security aspects, however since security in such networks n= eeds to be considered from the start as opposed to later, do we have someon= e among us who is our "security guru" who is keeping an eye on our developm= ent to make sure we don't miss a trick anywhere? One way or another, I woul= d like to be confident that we have this totally covered. Thanks, Ethan. --_000_10f52d4c6629445cae87f49f9ebb7a36DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
Security is of paramount importance for most if not all of the network= s described in the DetNet use cases. I gather that DetNet itself doesn̵= 7;t have a lot of explicit security aspects, however since security in such= networks needs to be considered from the start as opposed to later, do we have someone among us who is our ̶= 0;security guru” who is keeping an eye on our development to make sur= e we don’t miss a trick anywhere? One way or another, I would like to= be confident that we have this totally covered.
Thanks,
Ethan.
 
 --_000_10f52d4c6629445cae87f49f9ebb7a36DLBXCHPW03dolbynet_-- From nobody Fri Oct 7 13:21:38 2016 Return-Path: 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 3BB0412966C for ; Fri, 7 Oct 2016 13:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 kNvJHVqzdkjY for ; Fri, 7 Oct 2016 13:21:35 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 92ABB129410 for ; Fri, 7 Oct 2016 13:21:35 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u97KK6Fk031540; Fri, 7 Oct 2016 13:21:35 -0700 Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25wjfxuc6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Oct 2016 13:21:35 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 13:21:08 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 13:21:08 -0700 From: "Grossman, Ethan A." To: Rodney Cummings , "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyngAATYncA= Date: Fri, 7 Oct 2016 20:21:08 +0000 Message-ID: <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:21:37 -0000 Thanks Rodney. On a peripherally related note, one thing you mention below = about 802.1Qcc is "the user ... requests a maximum latency". In another cur= rent DetNet discussion there is the distinction between the user requesting= a specific latency (presumably implying a reply from the network saying wh= ether it was available or not) vs only being able to query the network abou= t its latency performance. I thought we were converging on the latter model= , but now I'm not as clear. Am I missing something here?=20 Thanks, Ethan.=20 -----Original Message----- From: Rodney Cummings [mailto:rodney.cummings@ni.com]=20 Sent: Friday, October 07, 2016 11:23 AM To: Grossman, Ethan A.; detnet@ietf.org Subject: RE: DetNet - Migration path Great topic, I'm not completely clear on what it would mean for a router to support DetN= et, but let's assume it means that the router: 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify flows = of DetNet data. 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide DetNet= guarantees for that data (e.g. max latency). 3. Provides YANG management for #1 and #2. All of this could be done today using vendor-specific YANG modules, with ce= ntralized network management software from that vendor. That's not ideal of= course, but it is useful. How would a user application (protocol from draft-ietf-detnet-use-cases) us= e this? I would argue that the user applications should use the "API" specified in = 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/3 = details and the data-plane encoding. The user simply identifies the flows f= rom the host perspective (e.g. UDP header fields), and requests a maximum l= atency. The API is used between the user's application and the centralized = network management software. The API specifies YANG, so it can be implement= ed as a RESTful API or similar. AVnu Alliance's goal is to certify conformance to standards (i.e. multiple = vendors). Can AVnu Alliance certify the vendor-specific router implementation? No Can= AVnu Alliance certify the 802.1Qcc API between the user application and th= e vendor-specific network manager? Yes As time goes on and DetNet standards= are published, can AVnu Alliance certification do deeper into the routers?= Yes That's one hypothetical intermediate plan. Rodney From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Friday, October 7, 2016 12:42 PM To: detnet@ietf.org Subject: [Detnet] DetNet - Migration path Hi Folks, =A0 I did a brief "DetNet Status" presentation to the AVnu Alliance Technical W= orking Group, which is an industry group that promotes AVB/TSN. The attenda= nce at this particular meeting was mostly Pro Audio people, and their main = line of questioning was "What is the plan for incrementally migrating users= from where they are today to increasingly improved network performance, wh= ich would eventually culminate in "full DetNet"?"=A0 Another way to put it = might be "Can we leverage the work of DetNet to improve networking capabili= ties between now and when DetNet is implemented on most routers?"=A0=20 =A0 As far as I know, we don't have a plan to roll out a "migration path" with = intermediate performance levels, using today's protocols, perhaps with "min= or" changes to support DetNet. We are designing an architecture and protoco= l extensions that will do the job, leveraging existing=A0 protocols to the = extent possible, but it is an end goal, not a roadmap.=20 =A0 Having said that, do we have any other more helpful reply to this line of q= uestioning?=20 =A0 Thanks, Ethan. =A0 From nobody Mon Oct 10 23:05:29 2016 Return-Path: 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 ABB971297CA for ; Mon, 10 Oct 2016 23:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.295 X-Spam-Level: X-Spam-Status: No, score=-7.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 uzVytmiFoMjd for ; Mon, 10 Oct 2016 23:05:25 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF45129620 for ; Mon, 10 Oct 2016 23:05:25 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 6BC2712010B; Mon, 10 Oct 2016 23:05:17 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 6BC2712010B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1476165919; bh=uKR5fGQWN3RzYuiaZMCII2BWqMn1G7x0aSvmdVGbNN8=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date: In-Reply-To:Cc:To:References; b=VLUm8+sqLXFlzvWHU2Ofr+/ew4/m36QMUG+MT93R9l7QftYdX1onFst/T4uTqWlzl LIwb1NbkEElOkfrClFS6U3QTDu2oUVv5sVAq2o6a/3S0i95+nQJ8sldUoNdXBGL0As DStL30ust981VIAWMv0/7YrSog+qC9SOuZgcX/jE= From: nfinn Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CC3DA4E8-7032-48FD-BED1-0B59D404E392" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 10 Oct 2016 23:05:16 -0700 In-Reply-To: <10f52d4c6629445cae87f49f9ebb7a36@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." References: <10f52d4c6629445cae87f49f9ebb7a36@DLB-XCHPW03.dolby.net> X-Mailer: Apple Mail (2.3226) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 6BC2712010B.AB605 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.099, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Security Review X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 06:05:26 -0000 --Apple-Mail=_CC3DA4E8-7032-48FD-BED1-0B59D404E392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You are a regular fountain of good questions lately, Ethan! There are people in NTP/TICTOC looking at time security. Not much else that I know about. =E2=80=94 Norm > On Oct 7, 2016, at 1:13 PM, Grossman, Ethan A. = wrote: >=20 > Hi Folks, > Security is of paramount importance for most if not all of the = networks described in the DetNet use cases. I gather that DetNet itself = doesn=E2=80=99t have a lot of explicit security aspects, however since = security in such networks needs to be considered from the start as = opposed to later, do we have someone among us who is our =E2=80=9Csecurity= guru=E2=80=9D who is keeping an eye on our development to make sure we = don=E2=80=99t miss a trick anywhere? One way or another, I would like to = be confident that we have this totally covered. > Thanks, > Ethan. > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_CC3DA4E8-7032-48FD-BED1-0B59D404E392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You are a regular fountain of good questions lately, = Ethan!

There are = people in NTP/TICTOC looking at time security.

Not much else that I know = about.

=E2=80=94= Norm

On Oct 7, 2016, at 1:13 PM, = Grossman, Ethan A. <eagros@dolby.com> wrote:

Hi = Folks,
Security is of paramount importance for most = if not all of the networks described in the DetNet use cases. I gather = that DetNet itself doesn=E2=80=99t have a lot of explicit security = aspects, however since security in such networks needs to be considered = from the start as opposed to later, do we have someone among us who is = our =E2=80=9Csecurity guru=E2=80=9D who is keeping an eye on our = development to make sure we don=E2=80=99t miss a trick anywhere? One way = or another, I would like to be confident that we have this totally = covered.
Thanks,
Ethan.
 
_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_CC3DA4E8-7032-48FD-BED1-0B59D404E392-- From nobody Tue Oct 11 04:09:38 2016 Return-Path: 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 E00421294E5 for ; Tue, 11 Oct 2016 04:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DI2JBpN05cIR for ; Tue, 11 Oct 2016 04:09:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E641294D4 for ; Tue, 11 Oct 2016 04:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8271; q=dns/txt; s=iport; t=1476184173; x=1477393773; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=FFUw+F4hHa5zCQ1gJbklNJAnamQtWYaRncaCZEyj1nQ=; b=DLeYikw3GGUpnncD7c7RT+slvd6oM63+i9QWTsn0k1gomjWm+z6dULHY eFxs0nef8ytKhkVCRVYAsu/GUP7ZBAjhRH/fBWKe84P8fdVSc+IvLxDD/ +EN4mbCriS1wWlf04o5VlUycMGj97ol+t05IJqC4e4/D+amSZ/Fr4itdf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAQCpx/xX/4QNJK1cDgwBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMHNQEBAQEBHVd8B40slwOPIIUUggsbAQqFMEoCgX84FAECAQEBAQE?= =?us-ascii?q?BAV4nhGEBAQEEAQEBawsSAQgRAwECKC4LFAkIAQEEDgWIUA7CXgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhj2EVYRnhT8FjniFMIVaAY98j3WMeYN+AR42TYQlO3K?= =?us-ascii?q?HIoEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,329,1473120000"; d="scan'208,217";a="158482174" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Oct 2016 11:09:32 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u9BB9VJs027778 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Oct 2016 11:09:32 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 07:09:31 -0400 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1210.000; Tue, 11 Oct 2016 07:09:31 -0400 From: "Maik Seewald (maseewal)" To: nfinn , "Grossman, Ethan A." Thread-Topic: [Detnet] DetNet Security Review Thread-Index: AdIg1UITR2QEeogET/23bai5Z4zLUgC0bTEAAA7QfoA= Date: Tue, 11 Oct 2016 11:09:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.56.235.91] Content-Type: multipart/alternative; boundary="_000_D422942B5635Bmaseewalciscocom_" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Security Review X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:09:37 -0000 --_000_D422942B5635Bmaseewalciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In parallel, IEEE 1588 has a sub working group defining security (in terms = of profiles/prongs) for the 1588 protocol. For time-sensitive networking, security for critical services (such as time= ) is essential, especially in WAN use cases... Regards, Maik From: Norm Finn > Date: Dienstag, 11. Oktober 2016 08:05 To: "Grossman, Ethan A." > Cc: "detnet@ietf.org" > Subject: Re: [Detnet] DetNet Security Review You are a regular fountain of good questions lately, Ethan! There are people in NTP/TICTOC looking at time security. Not much else that I know about. - Norm On Oct 7, 2016, at 1:13 PM, Grossman, Ethan A. > wrote: Hi Folks, Security is of paramount importance for most if not all of the networks des= cribed in the DetNet use cases. I gather that DetNet itself doesn't have a = lot of explicit security aspects, however since security in such networks n= eeds to be considered from the start as opposed to later, do we have someon= e among us who is our "security guru" who is keeping an eye on our developm= ent to make sure we don't miss a trick anywhere? One way or another, I woul= d like to be confident that we have this totally covered. Thanks, Ethan. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_D422942B5635Bmaseewalciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3F178CAA5C7B174E81FE3C9BEE686FEE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
In parallel, IEEE 1588 has a sub working group defining security (in t= erms of profiles/prongs) for the 1588 protocol.
For time-sensitive networking, security for critical services (such as= time) is essential, especially in WAN use cases…
Regards, Maik 

From: Norm Finn <nfinn@alumni.caltech.edu>
Date: Dienstag, 11. Oktober 2016 08= :05
To: "Grossman, Ethan A." = <eagros@dolby.com>
Cc: "detnet@ietf.org" <= detnet@ietf.org>
Subject: Re: [Detnet] DetNet Securi= ty Review

You are a regular fountain of good questions lately, Ethan!

There are people in NTP/TICTOC looking at time security.

Not much else that I know about.

— Norm

On Oct 7, 2016, at 1:13 PM, Grossman, Ethan A. <eagros@dolby.com> wrote:
Hi Folks,
Security is of paramount importance for most if not all of = the networks described in the DetNet use cases. I gather that DetNet itself= doesn’t have a lot of explicit security aspects, however since secur= ity in such networks needs to be considered from the start as opposed to later, do we have someone among us who is our= “security guru” who is keeping an eye on our development to ma= ke sure we don’t miss a trick anywhere? One way or another, I would l= ike to be confident that we have this totally covered.
Thanks,
Ethan.
 
= _______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

--_000_D422942B5635Bmaseewalciscocom_-- From nobody Tue Oct 11 04:29:27 2016 Return-Path: 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 3C8921294F5 for ; Tue, 11 Oct 2016 04:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 c_94fuVBRvgJ for ; Tue, 11 Oct 2016 04:29:24 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03B41294F1 for ; Tue, 11 Oct 2016 04:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6868; q=dns/txt; s=iport; t=1476185362; x=1477394962; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=a7evuxgcOeAFiJwbslH88iAs0Tn0c6m9baoHpFLYQeo=; b=LOMtUgjBhNR3EIZezXcbaPTzfns83de+bOF0FgrLddsiZ9SPYP1ZHHzz W7evm1EtGy9AhDb6L2FsSmyOi9pCORO8eJjcDhC/HMf9Ni25Hs8GNk32x WczDCa9Pu4lIhdPSqsfzDyF3R9Uqoqq67p8xHFiS3QNd4WXVtYnKeUFXX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQCqy/xX/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAeNLJcDlDSCCxsLhTBKAoF/OBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RhAQEBBAEBAWgDFwQCAQgRBAEBAScHJwsUCQgBAQQBEggTiDUOwmEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYY9hFWELYV5BYg8hjyLCgGPdY98jHmDfgEeNk2?= =?us-ascii?q?CcRwZgTpyhyKBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,329,1473120000"; d="scan'208";a="332430504" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Oct 2016 11:29:21 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9BBTLsr031059 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Oct 2016 11:29:21 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 06:29:20 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 11 Oct 2016 06:29:21 -0500 From: "Pascal Thubert (pthubert)" To: Olivier Marce , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? Thread-Index: AdIfSZ9RlRHX+JyBRHenm9cDBBOMdgAUZQWAABH2gIAA87/bIA== Date: Tue, 11 Oct 2016 11:29:05 +0000 Deferred-Delivery: Tue, 11 Oct 2016 11:28:32 +0000 Message-ID: <2c9cfd1f09b84ad4808871c9bcaf540b@XCH-RCD-001.cisco.com> References: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:29:26 -0000 This is my understanding too, Olivier.=20 Also, time-related work is done elsewhere, whether one thinks of IETF or ou= tside the IETF. We do not want to be taken in the middle of that storm. Best can do is probably state requirements, but for all I know we are using= time as an information provided by external means, as opposed to managing = it. Cheers, Pascal -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Olivier Marce Sent: jeudi 6 octobre 2016 12:05 To: detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time = accuracy and reliability needs? Hi, I'm in favor of Norm' position: DetNet should concentrate on reliable, on-= time delivery of packets. Time accuracy is required for DetNet but out of s= cope, as many solutions exist and is not only a networking topic. At most, DetNet could provide some reference examples on how providing requ= ired time accuracy. Regards Le 06/10/2016 =E0 03:30, nfinn a =E9crit : > Interesting question. > > It seems more useful to me to make sure that the time protocols are=20 > able to report, along with the time, the accuracy provided. The=20 > application can then decide whether that is sufficient. The accuracy=20 > reported will likely consist of several parameters (frequency=20 > accuracy, absolute accuracy, etc.). Different time protocols may have=20 > different parameters for accuracy. The application might worried=20 > about one or the other of those parameters. It might operate in=20 > different modes, depending on the accuracy provided. I don't see the=20 > value in moving the decision point anywhere else. > > With DetNet, one can imagine a bandwidth reservation crossing a=20 > boundary between two different master clock domains. My inclination=20 > would be to disallow that, at least for now. Given an application=20 > that runs for long enough, any frequency difference between source and=20 > sink will eventually cause starvation or overflow. > > All that said, let's suppose that you have a solid use case that is=20 > expected to *try* to run across clock domain boundaries, and we want=20 > to prevent that when it won't work. This could be solved by an=20 > application-level protocol that exchanges clock domain information. > This could be solved by configuring the network controller to=20 > disallow domain crossings. This could be handled by parameters in the=20 > reservation protocol, as you suggest, so that the controller can allow=20 > some reservations but not others. I'll leave it to timing experts to=20 > pick some number of appropriate parameters. > > One last consideration - Are you sure that all applications that have=20 > these timing requirements also require bandwidth reservations? I'm=20 > not sure of that. And, if not, a protocol separate from the bandwidth=20 > reservation might be indicated. > > - Norm > >> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. > > wrote: >> >> Hi Folks, >> >> As of our IETF 96 meeting there were still a couple of Use Case=20 >> Statements that I would like clarity on. Here's the first, remaining=20 >> to follow in separate emails. >> >> Question: >> How will an application express its time accuracy and reliability=20 >> needs? Is that within scope of DetNet? >> >> Discussion: >> In AVB/TSN when an application (talker) attempts to make a stream=20 >> reservation it must state how much bandwidth that stream reservation=20 >> requires. Presumably in a LAN this is sufficient since a LAN=20 >> presumably has consistent time accuracy and reliability metrics. >> >> For DetNet, in which we support interconnected DetNet networks and=20 >> have widely varying requirements for timing accuracy and reliability=20 >> depending on the use case, it appears to me that we need to allow an=20 >> application to provide this kind of information to the network, and a=20 >> way for the network to either agree or decline to provide the=20 >> requested service (analogous to AVB/TSN accepting or declining a=20 >> stream reservation based on the bandwidth requested). >> >> We have had some discussion about this (see below) but nothing near=20 >> consensus. Other thoughts from anyone? >> Ethan. >> >> -------------------------------- >> Discussion, oldest item first: >> >> Ethan Grossman wrote: >> Timekeeping - the only explicit DetNet Ask for this is in the use=20 >> cases is in M2M as "Precise time synchronization accuracy (1us)" and=20 >> I think the intent (as in other use cases) is that the DetNet Ask is=20 >> for a way to specify the required accuracy, not how to achieve that accu= racy. >> >> Norm Finn wrote: >> Timekeeping is an essential part of many, probably most, of the=20 >> applications that also find DetNet useful. That having been said, so=20 >> is protection against EMI and electrical power saving. Let's=20 >> concentrate DetNet on reliable, on-time delivery of packets. I'm not=20 >> even sure that "a way to specify the required accuracy" need be in scope= . >> >> Rodney Cummings wrote: >> I rarely disagree with Norm, but on this point I'll have to quibble a bi= t. >> I agree that we don't need DetNet to specify how time sync is=20 >> accomplished. There are plenty of IEEE 1588 techniques (and similar)=20 >> for that purpose. >> I also agree that we should concentrate on reliable, on-time delivery=20 >> of packets (i.e. worst-case latency). >> If I don't know how accurate my time sync is, then how do I know when=20 >> a packet is delivered on time? If I don't know the reliability of my=20 >> time sync, how can I reliably measure that packet delivery? >> Almost all (if not 100%) of DetNet use cases require time sync at the=20 >> end systems to some degree of accuracy. I agree that we don't need to=20 >> address the implementation of that time sync, but the application=20 >> requirements are needed for time sync (including reliability) just as=20 >> much as for packet delivery. >> -------------------------------- >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Olivier Marc=E9 Nokia Bell Labs France "we need to guard against increased levels of reporting and other requireme= nts that distract you from doing what you really need to be doing." Rajeev = Suri, Nokia CEO, April 2016 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 11 05:54:07 2016 Return-Path: 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 ACBCC1293FF for ; Tue, 11 Oct 2016 05:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.onmicrosoft.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 Y3O7ghZRY_4Q for ; Tue, 11 Oct 2016 05:54:04 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B4E129480 for ; Tue, 11 Oct 2016 05:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dr8va2tQsHxMaNLVgYmweQhAvMd/BsEn2qadzEBXU0E=; b=Kb7ZB/iR/LalcaAEp8BopmnqWgy0593IDsqdc6l3MW+mlKdEbnCh6a4DfwVWdUEB+w5iNicV8Z54gmhE7naXEbClpcDj5NvuIe/OMFu2LnnYw0p2EqgG7DsOEXooWfJa+PmzkQRoCIwooyM9vofPjPv4u53TGs5SLG8m3oe746E= Received: from CO1PR04MB425.namprd04.prod.outlook.com (10.141.74.27) by CO1PR04MB426.namprd04.prod.outlook.com (10.141.74.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 11 Oct 2016 12:54:03 +0000 Received: from CO1PR04MB425.namprd04.prod.outlook.com ([169.254.16.119]) by CO1PR04MB425.namprd04.prod.outlook.com ([169.254.16.119]) with mapi id 15.01.0639.017; Tue, 11 Oct 2016 12:54:02 +0000 From: Rodney Cummings To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyngAATYncAAuLx1AA== Date: Tue, 11 Oct 2016 12:54:02 +0000 Message-ID: References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> In-Reply-To: <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [74.220.238.132] x-ms-office365-filtering-correlation-id: 4112b383-255e-4c77-1a6e-08d3f1d5ad0d x-microsoft-exchange-diagnostics: 1; CO1PR04MB426; 6:g4DURYK9wkeXeAZ/Ek3kG3/hVQ+NyLJhjqJVgjHuRGncuUhlAFDKo3d7ki0b2rie29UBYEjVuA+wNaqmHND+WyzU+jK4cKyRRHHe/aSaxQsX5O5aOA75ySSEb5pg+JZIm6SwS3deb74CQkrt3zMtEcwAZBIokmnZNRYsUjiGOPHOiBWRUzE0a5ldZI4Gyn/3HZCXT6fk+GzW/cPE9zLRLonrxbl8VpNBB1bb4gB+euRFx/kh1+vmq/Gj+B3oimVAHIRAbegXRcktXY5vYkNUlOYfKmTkgk9upeWSPbHnhio=; 5:gIj+KxnTeSzlXfGyvi0luHYB2LVw741OmcqIz7TS7Nihrxj0biIVjA76hjneee8z7X7LMrxbPXiys1t+X6mPDCnDiB4tOSe8+nutJFD7dhBx7e5jl5ubODe6r66an5AdVAYaCAxfq2816dj0iLhtHA==; 24:4mQ2MYBLnqebSMuxCBocIjA090C32KEyWrHOIlNtfGPVKApq9ri3KCYdWqYU2UXVmmvnZqeNJ9ampC1wrddkcnWqNurJlT854cqy5kbirkA=; 7:HmyUq2SMO5zj/h80d/5QizPXEAi/rf6t3eUFovRjragyBXVe2/mUsmCQuhotsdJXeUPGxVrbY6thau50NQ10qvKR+iyEg700KEPBNbfZfaGzzfPgDI5BmrqhbSXsKdYOy6oSw6oaIYiJHG93Zzj7+NOlUnZ6cMQmkjdnqgfRKpDzcS8bQt4GUTfzZFkpD+fEy65T/0+5zy9gxVHav2ZRzrfYLzT4F96GH1Nr4CHh5mSWp63iM+xQm8+ngA64Vlg5GbLq7eHHqBPHRxpxeLtZR2e9DDaQClaNw7rDy/bU6wpdsAar2Sd/yjrPO9jGGpqg1X2zGlu4X5/mNCJF2KKlyA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR04MB426; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(145744241990776); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CO1PR04MB426; BCL:0; PCL:0; RULEID:; SRVR:CO1PR04MB426; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(92566002)(5001770100001)(87936001)(8936002)(7696004)(86362001)(2501003)(97736004)(5660300001)(10400500002)(102836003)(107886002)(9686002)(2906002)(8676002)(81156014)(3846002)(6116002)(3280700002)(3660700001)(586003)(99286002)(2950100002)(68736007)(81166006)(106356001)(105586002)(76176999)(33656002)(74316002)(7736002)(7846002)(189998001)(5002640100001)(101416001)(19580405001)(305945005)(19580395003)(50986999)(76576001)(54356999)(2900100001)(122556002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR04MB426; H:CO1PR04MB425.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 12:54:02.1317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR04MB426 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 12:54:06 -0000 Thanks Ethan, The current draft of 802.1Qcc has both for each flow (stream): - AccumulatedLatency: This is provided from network to user, and it represe= nts the currently configured maximum latency. - MaxLatency: This is provided from user to network as the maximum latency = that the application requires. If AccumulatedLatency exceeds this value, th= e network reports failure (flow not configured). The assumption was that the network configuration may need to adapt to chan= ging physical hardware and/or the requirements of new flows, and therefore = AccumulatedLatency isn't always stable. Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), but= that was removed due to concerns that it would require significant bufferi= ng. Application representatives (e.g. automotive, industrial) did not make = strong arguments to keep MinLatency. Rodney > -----Original Message----- > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > Sent: Friday, October 7, 2016 3:21 PM > To: Rodney Cummings ; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Thanks Rodney. On a peripherally related note, one thing you mention belo= w > about 802.1Qcc is "the user ... requests a maximum latency". In another > current DetNet discussion there is the distinction between the user > requesting a specific latency (presumably implying a reply from the > network saying whether it was available or not) vs only being able to > query the network about its latency performance. I thought we were > converging on the latter model, but now I'm not as clear. Am I missing > something here? > Thanks, > Ethan. >=20 > -----Original Message----- > From: Rodney Cummings [mailto:rodney.cummings@ni.com] > Sent: Friday, October 07, 2016 11:23 AM > To: Grossman, Ethan A.; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Great topic, >=20 > I'm not completely clear on what it would mean for a router to support > DetNet, but let's assume it means that the router: > 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify flow= s > of DetNet data. > 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide > DetNet guarantees for that data (e.g. max latency). > 3. Provides YANG management for #1 and #2. >=20 > All of this could be done today using vendor-specific YANG modules, with > centralized network management software from that vendor. That's not idea= l > of course, but it is useful. >=20 > How would a user application (protocol from draft-ietf-detnet-use-cases) > use this? >=20 > I would argue that the user applications should use the "API" specified i= n > 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/= 3 > details and the data-plane encoding. The user simply identifies the flows > from the host perspective (e.g. UDP header fields), and requests a maximu= m > latency. The API is used between the user's application and the > centralized network management software. The API specifies YANG, so it ca= n > be implemented as a RESTful API or similar. >=20 > AVnu Alliance's goal is to certify conformance to standards (i.e. multipl= e > vendors). >=20 > Can AVnu Alliance certify the vendor-specific router implementation? No > Can AVnu Alliance certify the 802.1Qcc API between the user application > and the vendor-specific network manager? Yes As time goes on and DetNet > standards are published, can AVnu Alliance certification do deeper into > the routers? Yes >=20 > That's one hypothetical intermediate plan. >=20 > Rodney >=20 > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Etha= n > A. > Sent: Friday, October 7, 2016 12:42 PM > To: detnet@ietf.org > Subject: [Detnet] DetNet - Migration path >=20 > Hi Folks, >=20 > I did a brief "DetNet Status" presentation to the AVnu Alliance Technical > Working Group, which is an industry group that promotes AVB/TSN. The > attendance at this particular meeting was mostly Pro Audio people, and > their main line of questioning was "What is the plan for incrementally > migrating users from where they are today to increasingly improved networ= k > performance, which would eventually culminate in "full DetNet"?"=A0 Anoth= er > way to put it might be "Can we leverage the work of DetNet to improve > networking capabilities between now and when DetNet is implemented on mos= t > routers?" >=20 > As far as I know, we don't have a plan to roll out a "migration path" wit= h > intermediate performance levels, using today's protocols, perhaps with > "minor" changes to support DetNet. We are designing an architecture and > protocol extensions that will do the job, leveraging existing=A0 protocol= s > to the extent possible, but it is an end goal, not a roadmap. >=20 > Having said that, do we have any other more helpful reply to this line of > questioning? >=20 > Thanks, > Ethan. >=20 From nobody Tue Oct 11 15:11:11 2016 Return-Path: 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 885F91293D9 for ; Tue, 11 Oct 2016 15:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 M1ZOi6s4Qmnm for ; Tue, 11 Oct 2016 15:11:07 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 B483E1293EC for ; Tue, 11 Oct 2016 15:11:07 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9BMB7Ke016806; Tue, 11 Oct 2016 15:11:07 -0700 Received: from dlb-xchpw03.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 2615c6gbxk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Oct 2016 15:11:07 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 15:10:33 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Tue, 11 Oct 2016 15:10:33 -0700 From: "Grossman, Ethan A." To: Rodney Cummings , "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyngAATYncAAuLx1AAATkD7w Date: Tue, 11 Oct 2016 22:10:33 +0000 Message-ID: <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-11_10:, , signatures=0 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:11:09 -0000 Thanks Rodney. Since a DetNet network must provide bounded latency and jitt= er, once the network promises an AccumulatedLatency value to a flow, doesn'= t it have to maintain that value at least for the duration of the flow? We = haven't discussed much about the consistency over time of such things as la= tency and jitter, but I assumed they would be within some given bound over = time, right? Or is it an enduring property of the given network? Isn't that= in effect a MinLatency value?=20 Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Rodney Cummings Sent: Tuesday, October 11, 2016 5:54 AM To: Grossman, Ethan A.; detnet@ietf.org Subject: Re: [Detnet] DetNet - Migration path Thanks Ethan, The current draft of 802.1Qcc has both for each flow (stream): - AccumulatedLatency: This is provided from network to user, and it represe= nts the currently configured maximum latency. - MaxLatency: This is provided from user to network as the maximum latency = that the application requires. If AccumulatedLatency exceeds this value, th= e network reports failure (flow not configured). The assumption was that the network configuration may need to adapt to chan= ging physical hardware and/or the requirements of new flows, and therefore = AccumulatedLatency isn't always stable. Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), but= that was removed due to concerns that it would require significant bufferi= ng. Application representatives (e.g. automotive, industrial) did not make = strong arguments to keep MinLatency. Rodney > -----Original Message----- > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > Sent: Friday, October 7, 2016 3:21 PM > To: Rodney Cummings ; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Thanks Rodney. On a peripherally related note, one thing you mention=20 > below about 802.1Qcc is "the user ... requests a maximum latency". In=20 > another current DetNet discussion there is the distinction between the=20 > user requesting a specific latency (presumably implying a reply from=20 > the network saying whether it was available or not) vs only being able=20 > to query the network about its latency performance. I thought we were=20 > converging on the latter model, but now I'm not as clear. Am I missing=20 > something here? > Thanks, > Ethan. >=20 > -----Original Message----- > From: Rodney Cummings [mailto:rodney.cummings@ni.com] > Sent: Friday, October 07, 2016 11:23 AM > To: Grossman, Ethan A.; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Great topic, >=20 > I'm not completely clear on what it would mean for a router to support=20 > DetNet, but let's assume it means that the router: > 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify=20 > flows of DetNet data. > 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide=20 > DetNet guarantees for that data (e.g. max latency). > 3. Provides YANG management for #1 and #2. >=20 > All of this could be done today using vendor-specific YANG modules,=20 > with centralized network management software from that vendor. That's=20 > not ideal of course, but it is useful. >=20 > How would a user application (protocol from=20 > draft-ietf-detnet-use-cases) use this? >=20 > I would argue that the user applications should use the "API"=20 > specified in 802.1Qcc clause 46 (currently in draft). That API is=20 > agnostic of layer 2/3 details and the data-plane encoding. The user=20 > simply identifies the flows from the host perspective (e.g. UDP header=20 > fields), and requests a maximum latency. The API is used between the=20 > user's application and the centralized network management software.=20 > The API specifies YANG, so it can be implemented as a RESTful API or simi= lar. >=20 > AVnu Alliance's goal is to certify conformance to standards (i.e.=20 > multiple vendors). >=20 > Can AVnu Alliance certify the vendor-specific router implementation?=20 > No Can AVnu Alliance certify the 802.1Qcc API between the user=20 > application and the vendor-specific network manager? Yes As time goes=20 > on and DetNet standards are published, can AVnu Alliance certification=20 > do deeper into the routers? Yes >=20 > That's one hypothetical intermediate plan. >=20 > Rodney >=20 > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman,=20 > Ethan A. > Sent: Friday, October 7, 2016 12:42 PM > To: detnet@ietf.org > Subject: [Detnet] DetNet - Migration path >=20 > Hi Folks, >=20 > I did a brief "DetNet Status" presentation to the AVnu Alliance=20 > Technical Working Group, which is an industry group that promotes=20 > AVB/TSN. The attendance at this particular meeting was mostly Pro=20 > Audio people, and their main line of questioning was "What is the plan=20 > for incrementally migrating users from where they are today to=20 > increasingly improved network performance, which would eventually=20 > culminate in "full DetNet"?"=A0 Another way to put it might be "Can we=20 > leverage the work of DetNet to improve networking capabilities between=20 > now and when DetNet is implemented on most routers?" >=20 > As far as I know, we don't have a plan to roll out a "migration path"=20 > with intermediate performance levels, using today's protocols, perhaps=20 > with "minor" changes to support DetNet. We are designing an=20 > architecture and protocol extensions that will do the job, leveraging=20 > existing=A0 protocols to the extent possible, but it is an end goal, not = a roadmap. >=20 > Having said that, do we have any other more helpful reply to this line=20 > of questioning? >=20 > Thanks, > Ethan. >=20 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 11 17:02:09 2016 Return-Path: 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 7207F1296AD for ; Tue, 11 Oct 2016 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.296 X-Spam-Level: X-Spam-Status: No, score=-7.296 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_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 EurkMSJyuEfx for ; Tue, 11 Oct 2016 17:02:05 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5613A1296AC for ; Tue, 11 Oct 2016 17:02:05 -0700 (PDT) Received: from [192.168.1.108] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 1AE5E12004E; Tue, 11 Oct 2016 17:02:03 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 1AE5E12004E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1476230523; bh=ZOc8MVJEeHDVegQN7X/zglXE2dpWnYuhu92T/rwozw4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F2tktW3XQLpgo7QNZnNzpNlqGmZ04lR9cWAlZL6nn6132jjYkW+n+kT4iT3szk0IJ OPez+GChStjESkv72E/S2FYa44wG3q6wzGFhCXEUzWpV1HD/Qp3d5MTqLJ+4agmxA6 SswhbAyaM2NV5eoai1gWjfrMv815UR9gYCcgEL2w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Norman Finn X-Mailer: iPhone Mail (14A456) In-Reply-To: <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> Date: Tue, 11 Oct 2016 17:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 1AE5E12004E.A2899 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.1, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: Rodney Cummings , "detnet@ietf.org" Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 00:02:07 -0000 That is, I believe, the current status of 802.1Qat. Going forward, some of u= s would prefer AccumulatedLatency to be advisory, and it would change if the= network must change it, but never to exceed MaxLatency. Rodney may have something to add to that about .1Qcc. -- Norm > On Oct 11, 2016, at 15:10, Grossman, Ethan A. wrote: >=20 > Thanks Rodney. Since a DetNet network must provide bounded latency and jit= ter, once the network promises an AccumulatedLatency value to a flow, doesn'= t it have to maintain that value at least for the duration of the flow? We h= aven't discussed much about the consistency over time of such things as late= ncy and jitter, but I assumed they would be within some given bound over tim= e, right? Or is it an enduring property of the given network? Isn't that in e= ffect a MinLatency value?=20 > Ethan. >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Rodney Cummings= > Sent: Tuesday, October 11, 2016 5:54 AM > To: Grossman, Ethan A.; detnet@ietf.org > Subject: Re: [Detnet] DetNet - Migration path >=20 > Thanks Ethan, >=20 > The current draft of 802.1Qcc has both for each flow (stream): >=20 > - AccumulatedLatency: This is provided from network to user, and it repres= ents the currently configured maximum latency. >=20 > - MaxLatency: This is provided from user to network as the maximum latency= that the application requires. If AccumulatedLatency exceeds this value, th= e network reports failure (flow not configured). >=20 > The assumption was that the network configuration may need to adapt to cha= nging physical hardware and/or the requirements of new flows, and therefore A= ccumulatedLatency isn't always stable. >=20 > Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), bu= t that was removed due to concerns that it would require significant bufferi= ng. Application representatives (e.g. automotive, industrial) did not make s= trong arguments to keep MinLatency. >=20 > Rodney >> -----Original Message----- >> From: Grossman, Ethan A. [mailto:eagros@dolby.com] >> Sent: Friday, October 7, 2016 3:21 PM >> To: Rodney Cummings ; detnet@ietf.org >> Subject: RE: DetNet - Migration path >>=20 >> Thanks Rodney. On a peripherally related note, one thing you mention=20 >> below about 802.1Qcc is "the user ... requests a maximum latency". In=20 >> another current DetNet discussion there is the distinction between the=20= >> user requesting a specific latency (presumably implying a reply from=20 >> the network saying whether it was available or not) vs only being able=20= >> to query the network about its latency performance. I thought we were=20 >> converging on the latter model, but now I'm not as clear. Am I missing=20= >> something here? >> Thanks, >> Ethan. >>=20 >> -----Original Message----- >> From: Rodney Cummings [mailto:rodney.cummings@ni.com] >> Sent: Friday, October 07, 2016 11:23 AM >> To: Grossman, Ethan A.; detnet@ietf.org >> Subject: RE: DetNet - Migration path >>=20 >> Great topic, >>=20 >> I'm not completely clear on what it would mean for a router to support=20= >> DetNet, but let's assume it means that the router: >> 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify=20 >> flows of DetNet data. >> 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide=20 >> DetNet guarantees for that data (e.g. max latency). >> 3. Provides YANG management for #1 and #2. >>=20 >> All of this could be done today using vendor-specific YANG modules,=20 >> with centralized network management software from that vendor. That's=20 >> not ideal of course, but it is useful. >>=20 >> How would a user application (protocol from=20 >> draft-ietf-detnet-use-cases) use this? >>=20 >> I would argue that the user applications should use the "API"=20 >> specified in 802.1Qcc clause 46 (currently in draft). That API is=20 >> agnostic of layer 2/3 details and the data-plane encoding. The user=20 >> simply identifies the flows from the host perspective (e.g. UDP header=20= >> fields), and requests a maximum latency. The API is used between the=20 >> user's application and the centralized network management software.=20 >> The API specifies YANG, so it can be implemented as a RESTful API or simi= lar. >>=20 >> AVnu Alliance's goal is to certify conformance to standards (i.e.=20 >> multiple vendors). >>=20 >> Can AVnu Alliance certify the vendor-specific router implementation?=20 >> No Can AVnu Alliance certify the 802.1Qcc API between the user=20 >> application and the vendor-specific network manager? Yes As time goes=20 >> on and DetNet standards are published, can AVnu Alliance certification=20= >> do deeper into the routers? Yes >>=20 >> That's one hypothetical intermediate plan. >>=20 >> Rodney >>=20 >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman,=20 >> Ethan A. >> Sent: Friday, October 7, 2016 12:42 PM >> To: detnet@ietf.org >> Subject: [Detnet] DetNet - Migration path >>=20 >> Hi Folks, >>=20 >> I did a brief "DetNet Status" presentation to the AVnu Alliance=20 >> Technical Working Group, which is an industry group that promotes=20 >> AVB/TSN. The attendance at this particular meeting was mostly Pro=20 >> Audio people, and their main line of questioning was "What is the plan=20= >> for incrementally migrating users from where they are today to=20 >> increasingly improved network performance, which would eventually=20 >> culminate in "full DetNet"?" Another way to put it might be "Can we=20 >> leverage the work of DetNet to improve networking capabilities between=20= >> now and when DetNet is implemented on most routers?" >>=20 >> As far as I know, we don't have a plan to roll out a "migration path"=20 >> with intermediate performance levels, using today's protocols, perhaps=20= >> with "minor" changes to support DetNet. We are designing an=20 >> architecture and protocol extensions that will do the job, leveraging=20 >> existing protocols to the extent possible, but it is an end goal, not a r= oadmap. >>=20 >> Having said that, do we have any other more helpful reply to this line=20= >> of questioning? >>=20 >> Thanks, >> Ethan. >>=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 11 17:44:19 2016 Return-Path: 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 E4F31129457 for ; Tue, 11 Oct 2016 17:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.715 X-Spam-Level: X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ETLBm3Docw1B for ; Tue, 11 Oct 2016 17:44:13 -0700 (PDT) Received: from nm33-vm5.bullet.mail.bf1.yahoo.com (nm33-vm5.bullet.mail.bf1.yahoo.com [72.30.239.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F104A129405 for ; Tue, 11 Oct 2016 17:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476233052; bh=qnMtX5seviE+S1YyiGq7YUWwjPR06mLJIq1KL/XRwdY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=J5l85uK1/otGFBRSb/95PrYzYiIcu1dV5ZnPx7EFecVsWIQfRthJqUWEZMpzi0sAntcJHfAgFMBfl2/D1buu90vY/hnjr5QVqgH0ynZvyYYpzqftH75uH9FqDAmpE2+mHSqNLZtSXKPMngh0aVOz4hWl2DBx3ukSF2D7DP2UoJUjheRLEshGADEIg5ad9hTnv0H7JhXfKvZLIzSps4etHUeIFZL6OlAXQQ3zY1ZvZiTeZD/exaUO2Ws8RZXuCnw+oE5/BLXqeW/VeVSoVNiwPgLOczw6WNnFe+tayLsFVF+HrzIfVkmzgaBYLHDb0rvUEZvHDJCe5rzFN1MtTa2dhw== Received: from [66.196.81.171] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 12 Oct 2016 00:44:12 -0000 Received: from [98.139.212.251] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 12 Oct 2016 00:44:12 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 12 Oct 2016 00:44:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 14664.56614.bm@omp1060.mail.bf1.yahoo.com X-YMail-OSG: pJVev6QVM1m.FbqJGpCRTSKqGnZAsK1MtEnrkRLtBV9fVrvq4He_Sr_WzeZCZOY mrathiJ6ZZsFazp2vtuATcDZX4vcd4bHr9J79J9pEK8zhyEcYrY92uNp0zmhGWIWBojuIqC0M2fG dfDhcz_W46qcAvNZjzpZrpCHJzkyHMzX6AKc44LzVuL5q6A2psdN7KL06NoPJq2xvvWMVaNwjjs2 jRp8V.vBuMFfqI8zFmtL49CehztgNd_fevMIv5LyK1DxaoCGymS6T6Euy_g4KHCT3oGPiBChtihk tTwOeM4Gh9ZlAspr2IuTCMT2pEJMnFS4rKuHopZWfgNbW.OVGaipvVUxYcG02eykd36YDw_dCabH JHcXrGs9pO0bkJA.xj0WPqiaT.mh_ccrz35_ZBSuu7dPXHHbQ_fO0Yp73Gnpg9C8W31ltzwLtHv9 SzrUKJBMQpZJx9nJTQEGX.jHbQdjfMEb1DFXO_qezoF3uG7ydWUmA7F9CNf6JUYWVEKKe387vHAX P0wgl6nR_hA1mQ9vwkgsfTy9jkjgVXjwC8_iVQXAvJ_AmIgEbjI7wKPxv0MirLIgsDaAEMH.mq3W jzfVDuwFsxt.yeta_SMbhZ_uJkdEnDLAymu7kZS8vMRociw9KYWrtv_o- Received: from jws106129.mail.bf1.yahoo.com by sendmailws141.mail.bf1.yahoo.com; Wed, 12 Oct 2016 00:44:11 +0000; 1476233051.561 Date: Wed, 12 Oct 2016 00:44:11 +0000 (UTC) From: Craig Gunther To: "Grossman, Ethan A." , Rodney Cummings , "detnet@ietf.org" Message-ID: <1762842.2277903.1476233051182@mail.yahoo.com> In-Reply-To: <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2277902_623944230.1476233051172" Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Craig Gunther List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 00:44:16 -0000 ------=_Part_2277902_623944230.1476233051172 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ethan, You have two options here.=C2=A0 Option 1: If you specify a MaxLatency (newly added in Qcc) then the network= is free to reroute your stream as needed in order to make room for other s= treams that might be competing for bandwidth on a particular link, as long = as the new path's latency does not exceed the MaxLatency. =C2=A0See slides = 3,4,5 of this presentation for a potential reason why you might want to do = this:=C2=A0http://www.ieee802.org/1/files/public/docs2014/cc-cgunther-accep= table-latency-0314-v01.pdf. Please note that the presentation refers to Acc= eptableLatency, which has been named MaxLatency in Qcc. Option 2: If you do not specify a MaxLatency then the AccumulatedLatency wo= rks as it always has; which is to not allow the AccumulatedLatency to excee= d the reported value when the reservation was first created. - Craig From: "Grossman, Ethan A." To: Rodney Cummings ; "detnet@ietf.org" =20 Sent: Tuesday, October 11, 2016 4:10 PM Subject: Re: [Detnet] DetNet - Migration path =20 Thanks Rodney. Since a DetNet network must provide bounded latency and jitt= er, once the network promises an AccumulatedLatency value to a flow, doesn'= t it have to maintain that value at least for the duration of the flow? We = haven't discussed much about the consistency over time of such things as la= tency and jitter, but I assumed they would be within some given bound over = time, right? Or is it an enduring property of the given network? Isn't that= in effect a MinLatency value?=20 Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Rodney Cummings Sent: Tuesday, October 11, 2016 5:54 AM To: Grossman, Ethan A.; detnet@ietf.org Subject: Re: [Detnet] DetNet - Migration path Thanks Ethan, The current draft of 802.1Qcc has both for each flow (stream): - AccumulatedLatency: This is provided from network to user, and it represe= nts the currently configured maximum latency. - MaxLatency: This is provided from user to network as the maximum latency = that the application requires. If AccumulatedLatency exceeds this value, th= e network reports failure (flow not configured). The assumption was that the network configuration may need to adapt to chan= ging physical hardware and/or the requirements of new flows, and therefore = AccumulatedLatency isn't always stable. Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), but= that was removed due to concerns that it would require significant bufferi= ng. Application representatives (e.g. automotive, industrial) did not make = strong arguments to keep MinLatency. Rodney > -----Original Message----- > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > Sent: Friday, October 7, 2016 3:21 PM > To: Rodney Cummings ; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Thanks Rodney. On a peripherally related note, one thing you mention=20 > below about 802.1Qcc is "the user ... requests a maximum latency". In=20 > another current DetNet discussion there is the distinction between the=20 > user requesting a specific latency (presumably implying a reply from=20 > the network saying whether it was available or not) vs only being able=20 > to query the network about its latency performance. I thought we were=20 > converging on the latter model, but now I'm not as clear. Am I missing=20 > something here? > Thanks, > Ethan. >=20 > -----Original Message----- > From: Rodney Cummings [mailto:rodney.cummings@ni.com] > Sent: Friday, October 07, 2016 11:23 AM > To: Grossman, Ethan A.; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Great topic, >=20 > I'm not completely clear on what it would mean for a router to support=20 > DetNet, but let's assume it means that the router: > 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify=20 > flows of DetNet data. > 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide=20 > DetNet guarantees for that data (e.g. max latency). > 3. Provides YANG management for #1 and #2. >=20 > All of this could be done today using vendor-specific YANG modules,=20 > with centralized network management software from that vendor. That's=20 > not ideal of course, but it is useful. >=20 > How would a user application (protocol from=20 > draft-ietf-detnet-use-cases) use this? >=20 > I would argue that the user applications should use the "API"=20 > specified in 802.1Qcc clause 46 (currently in draft). That API is=20 > agnostic of layer 2/3 details and the data-plane encoding. The user=20 > simply identifies the flows from the host perspective (e.g. UDP header=20 > fields), and requests a maximum latency. The API is used between the=20 > user's application and the centralized network management software.=20 > The API specifies YANG, so it can be implemented as a RESTful API or simi= lar. >=20 > AVnu Alliance's goal is to certify conformance to standards (i.e.=20 > multiple vendors). >=20 > Can AVnu Alliance certify the vendor-specific router implementation?=20 > No Can AVnu Alliance certify the 802.1Qcc API between the user=20 > application and the vendor-specific network manager? Yes As time goes=20 > on and DetNet standards are published, can AVnu Alliance certification=20 > do deeper into the routers? Yes >=20 > That's one hypothetical intermediate plan. >=20 > Rodney >=20 > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman,=20 > Ethan A. > Sent: Friday, October 7, 2016 12:42 PM > To: detnet@ietf.org > Subject: [Detnet] DetNet - Migration path >=20 > Hi Folks, >=20 > I did a brief "DetNet Status" presentation to the AVnu Alliance=20 > Technical Working Group, which is an industry group that promotes=20 > AVB/TSN. The attendance at this particular meeting was mostly Pro=20 > Audio people, and their main line of questioning was "What is the plan=20 > for incrementally migrating users from where they are today to=20 > increasingly improved network performance, which would eventually=20 > culminate in "full DetNet"?"=C2=A0 Another way to put it might be "Can we= =20 > leverage the work of DetNet to improve networking capabilities between=20 > now and when DetNet is implemented on most routers?" >=20 > As far as I know, we don't have a plan to roll out a "migration path"=20 > with intermediate performance levels, using today's protocols, perhaps=20 > with "minor" changes to support DetNet. We are designing an=20 > architecture and protocol extensions that will do the job, leveraging=20 > existing=C2=A0 protocols to the extent possible, but it is an end goal, n= ot a roadmap. >=20 > Having said that, do we have any other more helpful reply to this line=20 > of questioning? >=20 > Thanks, > Ethan. >=20 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet =20 ------=_Part_2277902_623944230.1476233051172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ethan,

You hav= e two options here. 


Option 2: If you do not specify a MaxLatency then= the AccumulatedLatency works as it always has; which is to not allow the A= ccumulatedLatency to exceed the reported value when the reservation was fir= st created.

- Craig


From: "Grossman, Ethan A." <eagros@dolby.com>
To: Rodney Cummings <rodney.cummings@ni.= com>; "detnet@ietf.org" <detnet@ietf.org>
Sent: Tuesday, October 11, 2016 4:10 PM
<= b>Subject: Re: [Detnet] DetNe= t - Migration path

Thanks Rodney. Since a DetNet networ= k must provide bounded latency and jitter, once the network promises an Acc= umulatedLatency value to a flow, doesn't it have to maintain that value at = least for the duration of the flow? We haven't discussed much about the con= sistency over time of such things as latency and jitter, but I assumed they= would be within some given bound over time, right? Or is it an enduring pr= operty of the given network? Isn't that in effect a MinLatency value?
Ethan.

-----Original Mes= sage-----
From: detnet [mailto:detnet-bounces@ietf.org] On B= ehalf Of Rodney Cummings
Sent: Tuesday, October 11, 2016 = 5:54 AM
To: Grossman, Ethan A.; detnet@ietf.org
Subject: Re= : [Detnet] DetNet - Migration path

Tha= nks Ethan,

The current draft of 802.1Q= cc has both for each flow (stream):

- = AccumulatedLatency: This is provided from network to user, and it represent= s the currently configured maximum latency.

- MaxLatency: This is provided from user to network as the maximum la= tency that the application requires. If AccumulatedLatency exceeds this val= ue, the network reports failure (flow not configured).
The assumption was that the network configuration may need= to adapt to changing physical hardware and/or the requirements of new flow= s, and therefore AccumulatedLatency isn't always stable.
=
Early drafts of 802.1Qcc had a MinLatency requirement (f= or low jitter), but that was removed due to concerns that it would require = significant buffering. Application representatives (e.g. automotive, indust= rial) did not make strong arguments to keep MinLatency.
<= br clear=3D"none">Rodney
> -----Original Message-----<= br clear=3D"none">> From: Grossman, Ethan A. [mailto:eagros@= dolby.com]
> Sent: Friday, October 7, 2016 3:21 PM=
> To: Rodney Cummings <r= odney.cummings@ni.com>; detnet@ietf.org
> Subject: RE: DetNet - Migration path
>
> Thanks Rodney. On a peripherally related note, one thing = you mention
> below about 802.1Qcc is "the user ... r= equests a maximum latency". In
> another current DetN= et discussion there is the distinction between the
> = user requesting a specific latency (presumably implying a reply from
> the network saying whether it was available or not) vs on= ly being able
> to query the network about its latenc= y performance. I thought we were
> converging on the = latter model, but now I'm not as clear. Am I missing
>= ; something here?
> Thanks,
> Eth= an.
>
> -----Original Message---= --
> From: Rodney Cummings [mailto:rodney.cummings@ni.com]
> Sent: Friday, Octob= er 07, 2016 11:23 AM
> To: Grossman, Ethan A.; detnet@ietf.org
> Subject: RE: DetNet - Migrati= on path
>
> Great topic,
>
> I'm not completely clear on what it= would mean for a router to support
> DetNet, but let= 's assume it means that the router:
> 1. Uses one of t= he solutions from draft-dt-detnet-dp-alt to identify
>= ; flows of DetNet data.
> 2. Uses queuing/shaping/sche= duling techniques from 802.1Q to provide
> DetNet gua= rantees for that data (e.g. max latency).
> 3. Provide= s YANG management for #1 and #2.
>
= > All of this could be done today using vendor-specific YANG modules, > with centralized network management software from tha= t vendor. That's
> not ideal of course, but it is use= ful.
>
> How would a user applic= ation (protocol from
> draft-ietf-detnet-use-cases) u= se this?
>
> I would argue that = the user applications should use the "API"
> specifie= d in 802.1Qcc clause 46 (currently in draft). That API is
> agnostic of layer 2/3 details and the data-plane encoding. The user =
> simply identifies the flows from the host perspecti= ve (e.g. UDP header
> fields), and requests a maximum= latency. The API is used between the
> user's applic= ation and the centralized network management software.
&= gt; The API specifies YANG, so it can be implemented as a RESTful API or si= milar.
>
> AVnu Alliance's goal = is to certify conformance to standards (i.e.
> multip= le vendors).
>
> Can AVnu Allian= ce certify the vendor-specific router implementation?
&g= t; No Can AVnu Alliance certify the 802.1Qcc API between the user
> application and the vendor-specific network manager? Yes As = time goes
> on and DetNet standards are published, ca= n AVnu Alliance certification
> do deeper into the ro= uters? Yes
>
> That's one hypoth= etical intermediate plan.
>
> Ro= dney
>
> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman,=
> Ethan A.
> Sent: Friday, Octo= ber 7, 2016 12:42 PM
> To: detnet@ietf.org=
> Subject: [Detnet] DetNet - Migration path
>
> Hi Folks,
> =
> I did a brief "DetNet Status" presentation to the A= Vnu Alliance
> Technical Working Group, which is an i= ndustry group that promotes
> AVB/TSN. The attendance= at this particular meeting was mostly Pro
> Audio pe= ople, and their main line of questioning was "What is the plan
> for incrementally migrating users from where they are today to =
> increasingly improved network performance, which wo= uld eventually
> culminate in "full DetNet"?"  A= nother way to put it might be "Can we
> leverage the = work of DetNet to improve networking capabilities between
> now and when DetNet is implemented on most routers?"
>
> As far as I know, we don't have a plan to r= oll out a "migration path"
> with intermediate perfor= mance levels, using today's protocols, perhaps
> with= "minor" changes to support DetNet. We are designing an
= > architecture and protocol extensions that will do the job, leveraging =
> existing  protocols to the extent possible, bu= t it is an end goal, not a roadmap.
>
> Having said that, do we have any other more helpful reply to this l= ine
> of questioning?
>
> Thanks,
> Ethan.
>= ;

___________________________________= ____________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet


___________________________________= ____________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet


------=_Part_2277902_623944230.1476233051172-- From nobody Wed Oct 12 05:25:33 2016 Return-Path: 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 68EBE1294AC for ; Wed, 12 Oct 2016 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.onmicrosoft.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 RrnyAyU-9u_o for ; Wed, 12 Oct 2016 05:25:29 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B60D129473 for ; Wed, 12 Oct 2016 05:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KEeo5yY4ChcjwiXbKz6jhYgm03+d2lmTq6HYSSq3faY=; b=fx5+j7wM+MQjVAFhUpK8pCPZMC9U/4yZmOiNdKk+cFA6aAIKczPCaQuRvwrRKVat2PoagVptk/d+eVuz9Mma30tLl8F8w25CLWyKfwwOp8gkubegLpNaSNt7uXvGoFIdBvKxCBwlS0CZ4TET4knfHbigq8SyxS2SiqK+VFu5inc= Received: from CO1PR04MB425.namprd04.prod.outlook.com (10.141.74.27) by CO1PR04MB426.namprd04.prod.outlook.com (10.141.74.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Wed, 12 Oct 2016 12:25:25 +0000 Received: from CO1PR04MB425.namprd04.prod.outlook.com ([169.254.16.119]) by CO1PR04MB425.namprd04.prod.outlook.com ([169.254.16.119]) with mapi id 15.01.0639.017; Wed, 12 Oct 2016 12:25:25 +0000 From: Rodney Cummings To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: DetNet - Migration path Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyngAATYncAAuLx1AAATkD7wAB6uQoA= Date: Wed, 12 Oct 2016 12:25:25 +0000 Message-ID: References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net> <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> In-Reply-To: <88ff17378af64f6eaf7c0348f1c71b58@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [74.220.238.132] x-ms-office365-filtering-correlation-id: 0a9d0a81-724f-4f5a-ef23-08d3f29ad814 x-microsoft-exchange-diagnostics: 1; CO1PR04MB426; 6:KGV61VX8wqvjjvJTZGEbJPAKOhX5FQNStbRbg79bCPIOjokxHMyqldRFexZXDQOWLJaKJH1vOukC+HH2GosXYlyAN034MzdlPTarCQ3M364rBLG1bJ4KqkUhWG2oU559k6rsG779rVJzdwfXC7ZzyMbQ34eF1f6OwOBXL+ldWvBG6wXOA+kq6keUHfLY6jYh0M5NjhFVGtUa2gkmH45On6uTglb8Ux+dluTjk1k2KSJSCK4eSoiST+sZvkXG2pAHASTSZrCEMy4Gi+rQXal4abP3NseuzwVDXAQCnb3Dj18=; 5:QjQXgCtpMJxRHgo1RC0ncTypYOOI71bpLeh+eRCBv9Jtvbm0gpd8hsqcAt1GoWaWsum3nlId8UtYbcJ1MJZ4hYyLPrE4ustIuTXGKvPRcWWzdm9xzlBjLnQXvkDaW6vPa0C6aMwhcWvaveHvxDCAcA==; 24:P668nEtwQaVWFXLTVB6bloy3M32y2neDMsFwOYRkMOafO7+YHhtQE0J66rjOdbWhYp+uEimDV3BMGKZ0pbUftBjR3crPNdmiq2aGfeRZ7lE=; 7:RkCPbte5egmn5OqCtBfMDJssB606VvGfRLgmLyBlYWrZE/Jw5djlKcw19OPorb38idF7DBcHOII7cf4H4RQqtzm+s6TJ04XuV/J7cPPTMU9tSFyKMCdaTCa5ppYt27OW1k6Pgj9/pcbYQCN8Pos7i00LoeHGGilQb0kvs1fOQ6u4KydGN3he58IbsgKit6IVU8v/XHUYz4kxygRnx1FdklJfcVFAV4b4eses6TU4amycPCi+VROXH2+sERKr4IfLeDlTdnxqlkODD4vT+xnPmKXymZcEDg4dbxc3JfTUto5ILkocJzFql7chmTp+MBENToUhDhwaCjSfayjVpIdL3Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR04MB426; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(145744241990776); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CO1PR04MB426; BCL:0; PCL:0; RULEID:; SRVR:CO1PR04MB426; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(105586002)(99286002)(93886004)(87936001)(92566002)(5001770100001)(8936002)(102836003)(107886002)(5660300001)(10400500002)(7696004)(97736004)(86362001)(9686002)(2906002)(81156014)(2501003)(3846002)(586003)(6116002)(3660700001)(8676002)(81166006)(3280700002)(106356001)(68736007)(2950100002)(74316002)(76176999)(33656002)(7846002)(189998001)(5002640100001)(11100500001)(101416001)(19580405001)(305945005)(7736002)(50986999)(76576001)(54356999)(15975445007)(19580395003)(2900100001)(66066001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR04MB426; H:CO1PR04MB425.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 12:25:25.2037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR04MB426 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 12:25:32 -0000 No problem Ethan, In 802.1Qcc, MaxLatency is the bounded latency over time. It might be uncom= mon for AccumulatedLatency to increase while the flow is in use, but the as= sumption is that it is possible. > -----Original Message----- > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > Sent: Tuesday, October 11, 2016 5:11 PM > To: Rodney Cummings ; detnet@ietf.org > Subject: RE: DetNet - Migration path >=20 > Thanks Rodney. Since a DetNet network must provide bounded latency and > jitter, once the network promises an AccumulatedLatency value to a flow, > doesn't it have to maintain that value at least for the duration of the > flow? We haven't discussed much about the consistency over time of such > things as latency and jitter, but I assumed they would be within some > given bound over time, right? Or is it an enduring property of the given > network? Isn't that in effect a MinLatency value? > Ethan. >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Rodney Cumming= s > Sent: Tuesday, October 11, 2016 5:54 AM > To: Grossman, Ethan A.; detnet@ietf.org > Subject: Re: [Detnet] DetNet - Migration path >=20 > Thanks Ethan, >=20 > The current draft of 802.1Qcc has both for each flow (stream): >=20 > - AccumulatedLatency: This is provided from network to user, and it > represents the currently configured maximum latency. >=20 > - MaxLatency: This is provided from user to network as the maximum latenc= y > that the application requires. If AccumulatedLatency exceeds this value, > the network reports failure (flow not configured). >=20 > The assumption was that the network configuration may need to adapt to > changing physical hardware and/or the requirements of new flows, and > therefore AccumulatedLatency isn't always stable. >=20 > Early drafts of 802.1Qcc had a MinLatency requirement (for low jitter), > but that was removed due to concerns that it would require significant > buffering. Application representatives (e.g. automotive, industrial) did > not make strong arguments to keep MinLatency. >=20 > Rodney > > -----Original Message----- > > From: Grossman, Ethan A. [mailto:eagros@dolby.com] > > Sent: Friday, October 7, 2016 3:21 PM > > To: Rodney Cummings ; detnet@ietf.org > > Subject: RE: DetNet - Migration path > > > > Thanks Rodney. On a peripherally related note, one thing you mention > > below about 802.1Qcc is "the user ... requests a maximum latency". In > > another current DetNet discussion there is the distinction between the > > user requesting a specific latency (presumably implying a reply from > > the network saying whether it was available or not) vs only being able > > to query the network about its latency performance. I thought we were > > converging on the latter model, but now I'm not as clear. Am I missing > > something here? > > Thanks, > > Ethan. > > > > -----Original Message----- > > From: Rodney Cummings [mailto:rodney.cummings@ni.com] > > Sent: Friday, October 07, 2016 11:23 AM > > To: Grossman, Ethan A.; detnet@ietf.org > > Subject: RE: DetNet - Migration path > > > > Great topic, > > > > I'm not completely clear on what it would mean for a router to support > > DetNet, but let's assume it means that the router: > > 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify > > flows of DetNet data. > > 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide > > DetNet guarantees for that data (e.g. max latency). > > 3. Provides YANG management for #1 and #2. > > > > All of this could be done today using vendor-specific YANG modules, > > with centralized network management software from that vendor. That's > > not ideal of course, but it is useful. > > > > How would a user application (protocol from > > draft-ietf-detnet-use-cases) use this? > > > > I would argue that the user applications should use the "API" > > specified in 802.1Qcc clause 46 (currently in draft). That API is > > agnostic of layer 2/3 details and the data-plane encoding. The user > > simply identifies the flows from the host perspective (e.g. UDP header > > fields), and requests a maximum latency. The API is used between the > > user's application and the centralized network management software. > > The API specifies YANG, so it can be implemented as a RESTful API or > similar. > > > > AVnu Alliance's goal is to certify conformance to standards (i.e. > > multiple vendors). > > > > Can AVnu Alliance certify the vendor-specific router implementation? > > No Can AVnu Alliance certify the 802.1Qcc API between the user > > application and the vendor-specific network manager? Yes As time goes > > on and DetNet standards are published, can AVnu Alliance certification > > do deeper into the routers? Yes > > > > That's one hypothetical intermediate plan. > > > > Rodney > > > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, > > Ethan A. > > Sent: Friday, October 7, 2016 12:42 PM > > To: detnet@ietf.org > > Subject: [Detnet] DetNet - Migration path > > > > Hi Folks, > > > > I did a brief "DetNet Status" presentation to the AVnu Alliance > > Technical Working Group, which is an industry group that promotes > > AVB/TSN. The attendance at this particular meeting was mostly Pro > > Audio people, and their main line of questioning was "What is the plan > > for incrementally migrating users from where they are today to > > increasingly improved network performance, which would eventually > > culminate in "full DetNet"?"=A0 Another way to put it might be "Can we > > leverage the work of DetNet to improve networking capabilities between > > now and when DetNet is implemented on most routers?" > > > > As far as I know, we don't have a plan to roll out a "migration path" > > with intermediate performance levels, using today's protocols, perhaps > > with "minor" changes to support DetNet. We are designing an > > architecture and protocol extensions that will do the job, leveraging > > existing=A0 protocols to the extent possible, but it is an end goal, no= t a > roadmap. > > > > Having said that, do we have any other more helpful reply to this line > > of questioning? > > > > Thanks, > > Ethan. > > >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Oct 12 09:12:08 2016 Return-Path: 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 DF31C129595 for ; Wed, 12 Oct 2016 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jM-6Ac2KO-5o for ; Wed, 12 Oct 2016 09:12:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DA0129580 for ; Wed, 12 Oct 2016 09:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11418; q=dns/txt; s=iport; t=1476288725; x=1477498325; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CmtIHQJC8VKpUyxB+jZaM/nxMa8cpJGEEoROKhjDVRU=; b=IBNdWU56/PERIAWTM9LVua6R5l6U6GP4zShX2UwgdiH6Td0CPgRNV2QI 0b+mvp1bqg3sLgbvW6pWCrGdm2nHBQjRo+ZjRAPSK45kUbGQGT2OfPJIj d/anW0MMoBDZzRanAYg5NuZdhwoKfH6UuzVYir7M4OTbuh3j3vzm+kcoP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCAX/5X/49dJa1SChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM8AQEBAQEdV3wHjSyXBZQ0ggwbC4JEgmxKAhqBWzgUAQIBAQEBAQE?= =?us-ascii?q?BXieEYQEBAQQBAQEgEToGEQYBCBEBAwEBAwIjAwIEJQsUAQIGCgQBEhuINQ62U?= =?us-ascii?q?o0DAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBB4U2gX0IglCEHz+CbSyCLwWaAgG?= =?us-ascii?q?PfI91jHmDfgEeNk6CcxyBU3KHZIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,336,1473120000"; d="scan'208";a="333363618" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2016 16:12:03 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u9CGC3GA007351 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Oct 2016 16:12:03 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Oct 2016 12:12:02 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1210.000; Wed, 12 Oct 2016 12:12:02 -0400 From: "Patrick Wetterwald (pwetterw)" To: Rodney Cummings , "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet - Migration path Thread-Index: AQHSJKNehjCePJ4uTnmkqpgisHkSYw== Date: Wed, 12 Oct 2016 16:12:02 +0000 Message-ID: <54D1F577-0AA5-4062-AF96-DA74D6CEDE00@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.11] Content-Type: text/plain; charset="utf-8" Content-ID: <9C909A6629378A40853B4FCCDA394E88@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 16:12:07 -0000 RGVhciBhbGwsDQoNCknigJltIHRyeWluZyB0byBjYXRjaCB1cCB3aXRoIHRoZSBkaWZmZXJlbnQg bWFpbHMgZXhjaGFuZ2VkIGluIHRoZSBsYXN0IDE1IGRheXMgb3Igc28gYW5kIEkgbWF5IGhhdmUg bWlzc2VkIHNvbWUgaW5mb3JtYXRpb24uDQoNCk15IGJpZyB0cm91YmxlIGlzIG9uIHRoZSB0ZXJt aW5vbG9neS4gTXkgZ3Vlc3MgaXMgdGhhdCB3ZSB3aWxsIGhhdmUgdG8gY29udmVyZ2UgdG8gYSBz aW5nbGUgb25lIGFuZCBwcm9iYWJseSBhbGlnbiB0aGUgZGlmZmVyZW50IFdHIGRvY3VtZW50cyAo aW5jbHVkaW5nIHVzZSBjYXNlKSB3aXRoIHRoaXMgdGVybWlub2xvZ3kuDQpTbyB0ZXJtcyBsaWtl IEFjY3VtdWxhdGVkTGF0ZW5jeSwgbWlubGF0ZW5jeSwgbWF4bGF0ZW5jeSBzaG91bGQgYmUgY2xl YXJseSBkZWZpbmVkIHdpdGhpbiBEZXRuZXQgaWYgd2UgY2hvb3NlIHRvIHVzZSB0aGVtLg0KDQpU aGUgc2Vjb25kIGFzcGVjdCBpcyB0aGF0IEkgc2VlIHNvbWUgZGl2ZXJnaW5nIHBvaW50cyBvZiB2 aWV3IGlmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBBdWRpby92aWRlbyBvciBFbGVjdHJpY2FsL3V0 aWxpdHkgZmllbGQgb3Igb3RoZXIgdXNlIGNhc2VzLg0KU29tZSBleGFtcGxlczogSW4gRWxlY3Ry aWNhbCBhbmQgcHJvYmFibHkgaW5kdXN0cmlhbCB1c2UgY2FzZXMsIHdlIHVzdWFsbHkgdHJ5IHRv IGV4cHJlc3MgZGVsYXksIGppdHRlciByZWxhdGVkIHRvIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdv cmsgYW5kIHRyZWF0IHRoZSBvdmVyYWxsIHRpbWUgYnVkZ2V0IGF0IGEgZGlmZmVyZW50IHN0YWdl LiAgDQogSW5kZXBlbmRlbnRseSBmcm9tIHRoZSBkZWxheSwgdGhlIGppdHRlciBhbmQgc3ltbWV0 cnkgYXJlIHJlYWxseSBpbXBvcnRhbnQgYXMgaXQgY291bGQgbWFrZSBhIGNvbnRyb2wgbG9vcCBv ciB0ZWxlcHJvdGVjdGlvbiB0byBiZWNvbWUgdW5zdGFibGUgb3IgZGl2ZXJnZS4gCQ0KDQpNeSAy IGNlbnRzLA0KDQpQYXRyaWNrDQoNCg0KDQpPbiAxMi8xMC8yMDE2LCAxNDoyNSwgImRldG5ldCBv biBiZWhhbGYgb2YgUm9kbmV5IEN1bW1pbmdzIiA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIHJvZG5leS5jdW1taW5nc0BuaS5jb20+IHdyb3RlOg0KDQogICAgTm8gcHJvYmxl bSBFdGhhbiwNCiAgICANCiAgICBJbiA4MDIuMVFjYywgTWF4TGF0ZW5jeSBpcyB0aGUgYm91bmRl ZCBsYXRlbmN5IG92ZXIgdGltZS4gSXQgbWlnaHQgYmUgdW5jb21tb24gZm9yIEFjY3VtdWxhdGVk TGF0ZW5jeSB0byBpbmNyZWFzZSB3aGlsZSB0aGUgZmxvdyBpcyBpbiB1c2UsIGJ1dCB0aGUgYXNz dW1wdGlvbiBpcyB0aGF0IGl0IGlzIHBvc3NpYmxlLg0KICAgIA0KICAgID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IEdyb3NzbWFuLCBFdGhhbiBBLiBbbWFpbHRvOmVh Z3Jvc0Bkb2xieS5jb21dDQogICAgPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDExLCAyMDE2IDU6 MTEgUE0NCiAgICA+IFRvOiBSb2RuZXkgQ3VtbWluZ3MgPHJvZG5leS5jdW1taW5nc0BuaS5jb20+ OyBkZXRuZXRAaWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IFJFOiBEZXROZXQgLSBNaWdyYXRpb24g cGF0aA0KICAgID4gDQogICAgPiBUaGFua3MgUm9kbmV5LiBTaW5jZSBhIERldE5ldCBuZXR3b3Jr IG11c3QgcHJvdmlkZSBib3VuZGVkIGxhdGVuY3kgYW5kDQogICAgPiBqaXR0ZXIsIG9uY2UgdGhl IG5ldHdvcmsgcHJvbWlzZXMgYW4gQWNjdW11bGF0ZWRMYXRlbmN5IHZhbHVlIHRvIGEgZmxvdywN CiAgICA+IGRvZXNuJ3QgaXQgaGF2ZSB0byBtYWludGFpbiB0aGF0IHZhbHVlIGF0IGxlYXN0IGZv ciB0aGUgZHVyYXRpb24gb2YgdGhlDQogICAgPiBmbG93PyBXZSBoYXZlbid0IGRpc2N1c3NlZCBt dWNoIGFib3V0IHRoZSBjb25zaXN0ZW5jeSBvdmVyIHRpbWUgb2Ygc3VjaA0KICAgID4gdGhpbmdz IGFzIGxhdGVuY3kgYW5kIGppdHRlciwgYnV0IEkgYXNzdW1lZCB0aGV5IHdvdWxkIGJlIHdpdGhp biBzb21lDQogICAgPiBnaXZlbiBib3VuZCBvdmVyIHRpbWUsIHJpZ2h0PyBPciBpcyBpdCBhbiBl bmR1cmluZyBwcm9wZXJ0eSBvZiB0aGUgZ2l2ZW4NCiAgICA+IG5ldHdvcms/IElzbid0IHRoYXQg aW4gZWZmZWN0IGEgTWluTGF0ZW5jeSB2YWx1ZT8NCiAgICA+IEV0aGFuLg0KICAgID4gDQogICAg PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogZGV0bmV0IFttYWlsdG86 ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2RuZXkgQ3VtbWluZ3MNCiAg ICA+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIwMTYgNTo1NCBBTQ0KICAgID4gVG86IEdy b3NzbWFuLCBFdGhhbiBBLjsgZGV0bmV0QGlldGYub3JnDQogICAgPiBTdWJqZWN0OiBSZTogW0Rl dG5ldF0gRGV0TmV0IC0gTWlncmF0aW9uIHBhdGgNCiAgICA+IA0KICAgID4gVGhhbmtzIEV0aGFu LA0KICAgID4gDQogICAgPiBUaGUgY3VycmVudCBkcmFmdCBvZiA4MDIuMVFjYyBoYXMgYm90aCBm b3IgZWFjaCBmbG93IChzdHJlYW0pOg0KICAgID4gDQogICAgPiAtIEFjY3VtdWxhdGVkTGF0ZW5j eTogVGhpcyBpcyBwcm92aWRlZCBmcm9tIG5ldHdvcmsgdG8gdXNlciwgYW5kIGl0DQogICAgPiBy ZXByZXNlbnRzIHRoZSBjdXJyZW50bHkgY29uZmlndXJlZCBtYXhpbXVtIGxhdGVuY3kuDQogICAg PiANCiAgICA+IC0gTWF4TGF0ZW5jeTogVGhpcyBpcyBwcm92aWRlZCBmcm9tIHVzZXIgdG8gbmV0 d29yayBhcyB0aGUgbWF4aW11bSBsYXRlbmN5DQogICAgPiB0aGF0IHRoZSBhcHBsaWNhdGlvbiBy ZXF1aXJlcy4gSWYgQWNjdW11bGF0ZWRMYXRlbmN5IGV4Y2VlZHMgdGhpcyB2YWx1ZSwNCiAgICA+ IHRoZSBuZXR3b3JrIHJlcG9ydHMgZmFpbHVyZSAoZmxvdyBub3QgY29uZmlndXJlZCkuDQogICAg PiANCiAgICA+IFRoZSBhc3N1bXB0aW9uIHdhcyB0aGF0IHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRp b24gbWF5IG5lZWQgdG8gYWRhcHQgdG8NCiAgICA+IGNoYW5naW5nIHBoeXNpY2FsIGhhcmR3YXJl IGFuZC9vciB0aGUgcmVxdWlyZW1lbnRzIG9mIG5ldyBmbG93cywgYW5kDQogICAgPiB0aGVyZWZv cmUgQWNjdW11bGF0ZWRMYXRlbmN5IGlzbid0IGFsd2F5cyBzdGFibGUuDQogICAgPiANCiAgICA+ IEVhcmx5IGRyYWZ0cyBvZiA4MDIuMVFjYyBoYWQgYSBNaW5MYXRlbmN5IHJlcXVpcmVtZW50IChm b3IgbG93IGppdHRlciksDQogICAgPiBidXQgdGhhdCB3YXMgcmVtb3ZlZCBkdWUgdG8gY29uY2Vy bnMgdGhhdCBpdCB3b3VsZCByZXF1aXJlIHNpZ25pZmljYW50DQogICAgPiBidWZmZXJpbmcuIEFw cGxpY2F0aW9uIHJlcHJlc2VudGF0aXZlcyAoZS5nLiBhdXRvbW90aXZlLCBpbmR1c3RyaWFsKSBk aWQNCiAgICA+IG5vdCBtYWtlIHN0cm9uZyBhcmd1bWVudHMgdG8ga2VlcCBNaW5MYXRlbmN5Lg0K ICAgID4gDQogICAgPiBSb2RuZXkNCiAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CiAgICA+ID4gRnJvbTogR3Jvc3NtYW4sIEV0aGFuIEEuIFttYWlsdG86ZWFncm9zQGRvbGJ5LmNv bV0NCiAgICA+ID4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDcsIDIwMTYgMzoyMSBQTQ0KICAgID4g PiBUbzogUm9kbmV5IEN1bW1pbmdzIDxyb2RuZXkuY3VtbWluZ3NAbmkuY29tPjsgZGV0bmV0QGll dGYub3JnDQogICAgPiA+IFN1YmplY3Q6IFJFOiBEZXROZXQgLSBNaWdyYXRpb24gcGF0aA0KICAg ID4gPg0KICAgID4gPiBUaGFua3MgUm9kbmV5LiBPbiBhIHBlcmlwaGVyYWxseSByZWxhdGVkIG5v dGUsIG9uZSB0aGluZyB5b3UgbWVudGlvbg0KICAgID4gPiBiZWxvdyBhYm91dCA4MDIuMVFjYyBp cyAidGhlIHVzZXIgLi4uIHJlcXVlc3RzIGEgbWF4aW11bSBsYXRlbmN5Ii4gSW4NCiAgICA+ID4g YW5vdGhlciBjdXJyZW50IERldE5ldCBkaXNjdXNzaW9uIHRoZXJlIGlzIHRoZSBkaXN0aW5jdGlv biBiZXR3ZWVuIHRoZQ0KICAgID4gPiB1c2VyIHJlcXVlc3RpbmcgYSBzcGVjaWZpYyBsYXRlbmN5 IChwcmVzdW1hYmx5IGltcGx5aW5nIGEgcmVwbHkgZnJvbQ0KICAgID4gPiB0aGUgbmV0d29yayBz YXlpbmcgd2hldGhlciBpdCB3YXMgYXZhaWxhYmxlIG9yIG5vdCkgdnMgb25seSBiZWluZyBhYmxl DQogICAgPiA+IHRvIHF1ZXJ5IHRoZSBuZXR3b3JrIGFib3V0IGl0cyBsYXRlbmN5IHBlcmZvcm1h bmNlLiBJIHRob3VnaHQgd2Ugd2VyZQ0KICAgID4gPiBjb252ZXJnaW5nIG9uIHRoZSBsYXR0ZXIg bW9kZWwsIGJ1dCBub3cgSSdtIG5vdCBhcyBjbGVhci4gQW0gSSBtaXNzaW5nDQogICAgPiA+IHNv bWV0aGluZyBoZXJlPw0KICAgID4gPiBUaGFua3MsDQogICAgPiA+IEV0aGFuLg0KICAgID4gPg0K ICAgID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gPiBGcm9tOiBSb2RuZXkg Q3VtbWluZ3MgW21haWx0bzpyb2RuZXkuY3VtbWluZ3NAbmkuY29tXQ0KICAgID4gPiBTZW50OiBG cmlkYXksIE9jdG9iZXIgMDcsIDIwMTYgMTE6MjMgQU0NCiAgICA+ID4gVG86IEdyb3NzbWFuLCBF dGhhbiBBLjsgZGV0bmV0QGlldGYub3JnDQogICAgPiA+IFN1YmplY3Q6IFJFOiBEZXROZXQgLSBN aWdyYXRpb24gcGF0aA0KICAgID4gPg0KICAgID4gPiBHcmVhdCB0b3BpYywNCiAgICA+ID4NCiAg ICA+ID4gSSdtIG5vdCBjb21wbGV0ZWx5IGNsZWFyIG9uIHdoYXQgaXQgd291bGQgbWVhbiBmb3Ig YSByb3V0ZXIgdG8gc3VwcG9ydA0KICAgID4gPiBEZXROZXQsIGJ1dCBsZXQncyBhc3N1bWUgaXQg bWVhbnMgdGhhdCB0aGUgcm91dGVyOg0KICAgID4gPiAxLiBVc2VzIG9uZSBvZiB0aGUgc29sdXRp b25zIGZyb20gZHJhZnQtZHQtZGV0bmV0LWRwLWFsdCB0byBpZGVudGlmeQ0KICAgID4gPiBmbG93 cyBvZiBEZXROZXQgZGF0YS4NCiAgICA+ID4gMi4gVXNlcyBxdWV1aW5nL3NoYXBpbmcvc2NoZWR1 bGluZyB0ZWNobmlxdWVzIGZyb20gODAyLjFRIHRvIHByb3ZpZGUNCiAgICA+ID4gRGV0TmV0IGd1 YXJhbnRlZXMgZm9yIHRoYXQgZGF0YSAoZS5nLiBtYXggbGF0ZW5jeSkuDQogICAgPiA+IDMuIFBy b3ZpZGVzIFlBTkcgbWFuYWdlbWVudCBmb3IgIzEgYW5kICMyLg0KICAgID4gPg0KICAgID4gPiBB bGwgb2YgdGhpcyBjb3VsZCBiZSBkb25lIHRvZGF5IHVzaW5nIHZlbmRvci1zcGVjaWZpYyBZQU5H IG1vZHVsZXMsDQogICAgPiA+IHdpdGggY2VudHJhbGl6ZWQgbmV0d29yayBtYW5hZ2VtZW50IHNv ZnR3YXJlIGZyb20gdGhhdCB2ZW5kb3IuIFRoYXQncw0KICAgID4gPiBub3QgaWRlYWwgb2YgY291 cnNlLCBidXQgaXQgaXMgdXNlZnVsLg0KICAgID4gPg0KICAgID4gPiBIb3cgd291bGQgYSB1c2Vy IGFwcGxpY2F0aW9uIChwcm90b2NvbCBmcm9tDQogICAgPiA+IGRyYWZ0LWlldGYtZGV0bmV0LXVz ZS1jYXNlcykgdXNlIHRoaXM/DQogICAgPiA+DQogICAgPiA+IEkgd291bGQgYXJndWUgdGhhdCB0 aGUgdXNlciBhcHBsaWNhdGlvbnMgc2hvdWxkIHVzZSB0aGUgIkFQSSINCiAgICA+ID4gc3BlY2lm aWVkIGluIDgwMi4xUWNjIGNsYXVzZSA0NiAoY3VycmVudGx5IGluIGRyYWZ0KS4gVGhhdCBBUEkg aXMNCiAgICA+ID4gYWdub3N0aWMgb2YgbGF5ZXIgMi8zIGRldGFpbHMgYW5kIHRoZSBkYXRhLXBs YW5lIGVuY29kaW5nLiBUaGUgdXNlcg0KICAgID4gPiBzaW1wbHkgaWRlbnRpZmllcyB0aGUgZmxv d3MgZnJvbSB0aGUgaG9zdCBwZXJzcGVjdGl2ZSAoZS5nLiBVRFAgaGVhZGVyDQogICAgPiA+IGZp ZWxkcyksIGFuZCByZXF1ZXN0cyBhIG1heGltdW0gbGF0ZW5jeS4gVGhlIEFQSSBpcyB1c2VkIGJl dHdlZW4gdGhlDQogICAgPiA+IHVzZXIncyBhcHBsaWNhdGlvbiBhbmQgdGhlIGNlbnRyYWxpemVk IG5ldHdvcmsgbWFuYWdlbWVudCBzb2Z0d2FyZS4NCiAgICA+ID4gVGhlIEFQSSBzcGVjaWZpZXMg WUFORywgc28gaXQgY2FuIGJlIGltcGxlbWVudGVkIGFzIGEgUkVTVGZ1bCBBUEkgb3INCiAgICA+ IHNpbWlsYXIuDQogICAgPiA+DQogICAgPiA+IEFWbnUgQWxsaWFuY2UncyBnb2FsIGlzIHRvIGNl cnRpZnkgY29uZm9ybWFuY2UgdG8gc3RhbmRhcmRzIChpLmUuDQogICAgPiA+IG11bHRpcGxlIHZl bmRvcnMpLg0KICAgID4gPg0KICAgID4gPiBDYW4gQVZudSBBbGxpYW5jZSBjZXJ0aWZ5IHRoZSB2 ZW5kb3Itc3BlY2lmaWMgcm91dGVyIGltcGxlbWVudGF0aW9uPw0KICAgID4gPiBObyBDYW4gQVZu dSBBbGxpYW5jZSBjZXJ0aWZ5IHRoZSA4MDIuMVFjYyBBUEkgYmV0d2VlbiB0aGUgdXNlcg0KICAg ID4gPiBhcHBsaWNhdGlvbiBhbmQgdGhlIHZlbmRvci1zcGVjaWZpYyBuZXR3b3JrIG1hbmFnZXI/ IFllcyBBcyB0aW1lIGdvZXMNCiAgICA+ID4gb24gYW5kIERldE5ldCBzdGFuZGFyZHMgYXJlIHB1 Ymxpc2hlZCwgY2FuIEFWbnUgQWxsaWFuY2UgY2VydGlmaWNhdGlvbg0KICAgID4gPiBkbyBkZWVw ZXIgaW50byB0aGUgcm91dGVycz8gWWVzDQogICAgPiA+DQogICAgPiA+IFRoYXQncyBvbmUgaHlw b3RoZXRpY2FsIGludGVybWVkaWF0ZSBwbGFuLg0KICAgID4gPg0KICAgID4gPiBSb2RuZXkNCiAg ICA+ID4NCiAgICA+ID4gRnJvbTogZGV0bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBHcm9zc21hbiwNCiAgICA+ID4gRXRoYW4gQS4NCiAgICA+ID4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDcsIDIwMTYgMTI6NDIgUE0NCiAgICA+ID4gVG86IGRldG5ldEBp ZXRmLm9yZw0KICAgID4gPiBTdWJqZWN0OiBbRGV0bmV0XSBEZXROZXQgLSBNaWdyYXRpb24gcGF0 aA0KICAgID4gPg0KICAgID4gPiBIaSBGb2xrcywNCiAgICA+ID4NCiAgICA+ID4gSSBkaWQgYSBi cmllZiAiRGV0TmV0IFN0YXR1cyIgcHJlc2VudGF0aW9uIHRvIHRoZSBBVm51IEFsbGlhbmNlDQog ICAgPiA+IFRlY2huaWNhbCBXb3JraW5nIEdyb3VwLCB3aGljaCBpcyBhbiBpbmR1c3RyeSBncm91 cCB0aGF0IHByb21vdGVzDQogICAgPiA+IEFWQi9UU04uIFRoZSBhdHRlbmRhbmNlIGF0IHRoaXMg cGFydGljdWxhciBtZWV0aW5nIHdhcyBtb3N0bHkgUHJvDQogICAgPiA+IEF1ZGlvIHBlb3BsZSwg YW5kIHRoZWlyIG1haW4gbGluZSBvZiBxdWVzdGlvbmluZyB3YXMgIldoYXQgaXMgdGhlIHBsYW4N CiAgICA+ID4gZm9yIGluY3JlbWVudGFsbHkgbWlncmF0aW5nIHVzZXJzIGZyb20gd2hlcmUgdGhl eSBhcmUgdG9kYXkgdG8NCiAgICA+ID4gaW5jcmVhc2luZ2x5IGltcHJvdmVkIG5ldHdvcmsgcGVy Zm9ybWFuY2UsIHdoaWNoIHdvdWxkIGV2ZW50dWFsbHkNCiAgICA+ID4gY3VsbWluYXRlIGluICJm dWxsIERldE5ldCI/IiAgQW5vdGhlciB3YXkgdG8gcHV0IGl0IG1pZ2h0IGJlICJDYW4gd2UNCiAg ICA+ID4gbGV2ZXJhZ2UgdGhlIHdvcmsgb2YgRGV0TmV0IHRvIGltcHJvdmUgbmV0d29ya2luZyBj YXBhYmlsaXRpZXMgYmV0d2Vlbg0KICAgID4gPiBub3cgYW5kIHdoZW4gRGV0TmV0IGlzIGltcGxl bWVudGVkIG9uIG1vc3Qgcm91dGVycz8iDQogICAgPiA+DQogICAgPiA+IEFzIGZhciBhcyBJIGtu b3csIHdlIGRvbid0IGhhdmUgYSBwbGFuIHRvIHJvbGwgb3V0IGEgIm1pZ3JhdGlvbiBwYXRoIg0K ICAgID4gPiB3aXRoIGludGVybWVkaWF0ZSBwZXJmb3JtYW5jZSBsZXZlbHMsIHVzaW5nIHRvZGF5 J3MgcHJvdG9jb2xzLCBwZXJoYXBzDQogICAgPiA+IHdpdGggIm1pbm9yIiBjaGFuZ2VzIHRvIHN1 cHBvcnQgRGV0TmV0LiBXZSBhcmUgZGVzaWduaW5nIGFuDQogICAgPiA+IGFyY2hpdGVjdHVyZSBh bmQgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHdpbGwgZG8gdGhlIGpvYiwgbGV2ZXJhZ2luZw0K ICAgID4gPiBleGlzdGluZyAgcHJvdG9jb2xzIHRvIHRoZSBleHRlbnQgcG9zc2libGUsIGJ1dCBp dCBpcyBhbiBlbmQgZ29hbCwgbm90IGENCiAgICA+IHJvYWRtYXAuDQogICAgPiA+DQogICAgPiA+ IEhhdmluZyBzYWlkIHRoYXQsIGRvIHdlIGhhdmUgYW55IG90aGVyIG1vcmUgaGVscGZ1bCByZXBs eSB0byB0aGlzIGxpbmUNCiAgICA+ID4gb2YgcXVlc3Rpb25pbmc/DQogICAgPiA+DQogICAgPiA+ IFRoYW5rcywNCiAgICA+ID4gRXRoYW4uDQogICAgPiA+DQogICAgPiANCiAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBkZXRuZXQgbWFp bGluZyBsaXN0DQogICAgPiBkZXRuZXRAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBkZXRuZXQgbWFpbGluZyBsaXN0DQog ICAgZGV0bmV0QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kZXRuZXQNCiAgICANCg0K From nobody Wed Oct 12 09:54:45 2016 Return-Path: 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 A865A129619 for ; Wed, 12 Oct 2016 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.296 X-Spam-Level: X-Spam-Status: No, score=-7.296 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_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 IOgkdZzG3-cE for ; Wed, 12 Oct 2016 09:54:41 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61B129616 for ; Wed, 12 Oct 2016 09:54:41 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 6247D120084; Wed, 12 Oct 2016 09:54:39 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 6247D120084 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1476291279; bh=8M3DtNoTkZmxIgqJS37iCdsM+wUN5x5UO3oP3XHNJ2A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aWEmD7Fe/qX4gyWI6MNe80Pf1pU/VRYhin9YN960rZBv2Yh1GzfHuQOCLfCTA90Ik x1c3J/DckIvTC2zn0CX3TOyVDkvaBKu2skCZ6nHCZiAGAouJcwMjvlWbYRPTyzMGGU iTXdDBlULu9ZKH1nKEinlWednGkSQ2fvE5pZdVkk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: nfinn In-Reply-To: <54D1F577-0AA5-4062-AF96-DA74D6CEDE00@cisco.com> Date: Wed, 12 Oct 2016 09:54:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54D1F577-0AA5-4062-AF96-DA74D6CEDE00@cisco.com> To: "Patrick Wetterwald (pwetterw)" X-Mailer: Apple Mail (2.3226) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 6247D120084.AE49E X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.1, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: Rodney Cummings , "Grossman, Ethan A." , "detnet@ietf.org" Subject: Re: [Detnet] DetNet - Migration path X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 16:54:44 -0000 Patrick, You can build a real-time network baed on average latency and a = statistical distribution of variation in latency. I will claim that = that is not a target application for DetNet. The reason is that = requires a test the system, tweak the parameters, measure =E2=80=A6 = cycle to get it right. Once right, you must not touch anything. That = can be done, today, with no help from TSN or DetNet, although some = features of TSN (e.g. transmission preemption) may make life easier. IMO, the target for DetNet is applications that use synchronized time. = They have to 1) know the MaxLatency value, so they know the deadline for = transmitting action orders in time to be received before the action is = to be performed; and 2) allocate enough buffer space at the receiver to = accommodate the difference between MaxLatency and MinLatency. Those two = items are required to achieve real-time operations with 0 congestion = loss no matter what the actual latency distribution looks like, and if = those two items are done, then the actual distribution does not matter = at all. Average latency means nothing. Variations from the averages = mean nothing. Max,Latency, and perhaps MinLatency, carry all the = information that needs to be specified. I=E2=80=99m not saying that one model is right or wrong; only that I=E2=80= =99m not trying to solve all the world=E2=80=99s problems, or even all = the world=E2=80=99s real-time problems. I think that it would be best = for DetNet to concentrate on the Min?Max problem, and leave the = average/distribution problem to another effort. =E2=80=94 Norm > On Oct 12, 2016, at 9:12 AM, Patrick Wetterwald (pwetterw) = wrote: >=20 > Dear all, >=20 > I=E2=80=99m trying to catch up with the different mails exchanged in = the last 15 days or so and I may have missed some information. >=20 > My big trouble is on the terminology. My guess is that we will have to = converge to a single one and probably align the different WG documents = (including use case) with this terminology. > So terms like AccumulatedLatency, minlatency, maxlatency should be = clearly defined within Detnet if we choose to use them. >=20 > The second aspect is that I see some diverging points of view if you = are talking about Audio/video or Electrical/utility field or other use = cases. > Some examples: In Electrical and probably industrial use cases, we = usually try to express delay, jitter related to the communication = network and treat the overall time budget at a different stage. =20 > Independently from the delay, the jitter and symmetry are really = important as it could make a control loop or teleprotection to become = unstable or diverge. =09 >=20 > My 2 cents, >=20 > Patrick >=20 >=20 >=20 > On 12/10/2016, 14:25, "detnet on behalf of Rodney Cummings" = wrote: >=20 > No problem Ethan, >=20 > In 802.1Qcc, MaxLatency is the bounded latency over time. It might = be uncommon for AccumulatedLatency to increase while the flow is in use, = but the assumption is that it is possible. >=20 >> -----Original Message----- >> From: Grossman, Ethan A. [mailto:eagros@dolby.com] >> Sent: Tuesday, October 11, 2016 5:11 PM >> To: Rodney Cummings ; detnet@ietf.org >> Subject: RE: DetNet - Migration path >>=20 >> Thanks Rodney. Since a DetNet network must provide bounded latency = and >> jitter, once the network promises an AccumulatedLatency value to a = flow, >> doesn't it have to maintain that value at least for the duration of = the >> flow? We haven't discussed much about the consistency over time of = such >> things as latency and jitter, but I assumed they would be within some >> given bound over time, right? Or is it an enduring property of the = given >> network? Isn't that in effect a MinLatency value? >> Ethan. >>=20 >> -----Original Message----- >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Rodney = Cummings >> Sent: Tuesday, October 11, 2016 5:54 AM >> To: Grossman, Ethan A.; detnet@ietf.org >> Subject: Re: [Detnet] DetNet - Migration path >>=20 >> Thanks Ethan, >>=20 >> The current draft of 802.1Qcc has both for each flow (stream): >>=20 >> - AccumulatedLatency: This is provided from network to user, and it >> represents the currently configured maximum latency. >>=20 >> - MaxLatency: This is provided from user to network as the maximum = latency >> that the application requires. If AccumulatedLatency exceeds this = value, >> the network reports failure (flow not configured). >>=20 >> The assumption was that the network configuration may need to adapt = to >> changing physical hardware and/or the requirements of new flows, and >> therefore AccumulatedLatency isn't always stable. >>=20 >> Early drafts of 802.1Qcc had a MinLatency requirement (for low = jitter), >> but that was removed due to concerns that it would require = significant >> buffering. Application representatives (e.g. automotive, industrial) = did >> not make strong arguments to keep MinLatency. >>=20 >> Rodney >>> -----Original Message----- >>> From: Grossman, Ethan A. [mailto:eagros@dolby.com] >>> Sent: Friday, October 7, 2016 3:21 PM >>> To: Rodney Cummings ; detnet@ietf.org >>> Subject: RE: DetNet - Migration path >>>=20 >>> Thanks Rodney. On a peripherally related note, one thing you mention >>> below about 802.1Qcc is "the user ... requests a maximum latency". = In >>> another current DetNet discussion there is the distinction between = the >>> user requesting a specific latency (presumably implying a reply from >>> the network saying whether it was available or not) vs only being = able >>> to query the network about its latency performance. I thought we = were >>> converging on the latter model, but now I'm not as clear. Am I = missing >>> something here? >>> Thanks, >>> Ethan. >>>=20 >>> -----Original Message----- >>> From: Rodney Cummings [mailto:rodney.cummings@ni.com] >>> Sent: Friday, October 07, 2016 11:23 AM >>> To: Grossman, Ethan A.; detnet@ietf.org >>> Subject: RE: DetNet - Migration path >>>=20 >>> Great topic, >>>=20 >>> I'm not completely clear on what it would mean for a router to = support >>> DetNet, but let's assume it means that the router: >>> 1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify >>> flows of DetNet data. >>> 2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide >>> DetNet guarantees for that data (e.g. max latency). >>> 3. Provides YANG management for #1 and #2. >>>=20 >>> All of this could be done today using vendor-specific YANG modules, >>> with centralized network management software from that vendor. = That's >>> not ideal of course, but it is useful. >>>=20 >>> How would a user application (protocol from >>> draft-ietf-detnet-use-cases) use this? >>>=20 >>> I would argue that the user applications should use the "API" >>> specified in 802.1Qcc clause 46 (currently in draft). That API is >>> agnostic of layer 2/3 details and the data-plane encoding. The user >>> simply identifies the flows from the host perspective (e.g. UDP = header >>> fields), and requests a maximum latency. The API is used between the >>> user's application and the centralized network management software. >>> The API specifies YANG, so it can be implemented as a RESTful API or >> similar. >>>=20 >>> AVnu Alliance's goal is to certify conformance to standards (i.e. >>> multiple vendors). >>>=20 >>> Can AVnu Alliance certify the vendor-specific router implementation? >>> No Can AVnu Alliance certify the 802.1Qcc API between the user >>> application and the vendor-specific network manager? Yes As time = goes >>> on and DetNet standards are published, can AVnu Alliance = certification >>> do deeper into the routers? Yes >>>=20 >>> That's one hypothetical intermediate plan. >>>=20 >>> Rodney >>>=20 >>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, >>> Ethan A. >>> Sent: Friday, October 7, 2016 12:42 PM >>> To: detnet@ietf.org >>> Subject: [Detnet] DetNet - Migration path >>>=20 >>> Hi Folks, >>>=20 >>> I did a brief "DetNet Status" presentation to the AVnu Alliance >>> Technical Working Group, which is an industry group that promotes >>> AVB/TSN. The attendance at this particular meeting was mostly Pro >>> Audio people, and their main line of questioning was "What is the = plan >>> for incrementally migrating users from where they are today to >>> increasingly improved network performance, which would eventually >>> culminate in "full DetNet"?" Another way to put it might be "Can we >>> leverage the work of DetNet to improve networking capabilities = between >>> now and when DetNet is implemented on most routers?" >>>=20 >>> As far as I know, we don't have a plan to roll out a "migration = path" >>> with intermediate performance levels, using today's protocols, = perhaps >>> with "minor" changes to support DetNet. We are designing an >>> architecture and protocol extensions that will do the job, = leveraging >>> existing protocols to the extent possible, but it is an end goal, = not a >> roadmap. >>>=20 >>> Having said that, do we have any other more helpful reply to this = line >>> of questioning? >>>=20 >>> Thanks, >>> Ethan. >>>=20 >>=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 18 22:56:56 2016 Return-Path: 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 B2CF11293D8 for ; Tue, 18 Oct 2016 22:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qw5okvUuZ1GW for ; Tue, 18 Oct 2016 22:56:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C801293F4 for ; Tue, 18 Oct 2016 22:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2432; q=dns/txt; s=iport; t=1476856613; x=1478066213; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WG6zFWLH24+OjUPiJGIQq/yZx1iC6YEKJh4Wga2bbLw=; b=Y4itTD3CRXvf2YCn9MKf/0faZhIXJsKnks3vzQpVCUxKAHCXQ+CzjfCr BCeqLfob44SLaIQ3CFdVeoau1DGMVdlT0Dv7vIT8SnZfICdtLg18HvexZ eRcOzrb2XlDH3Hi20lA6JJSh8yyPbRKv4RfqGPukYx/mtkV61xTVanfgq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQCYCgdY/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR1XfAeNLZcFlDmCCBwLhXoCGoFwOBQBAgEBAQEBAQFiHAu?= =?us-ascii?q?EYQEBAQQBAQEgETgCGwIBCBEBAwEBAwIIGwMCAgIlCxQBAgQBAQUDAgQTCIhKD?= =?us-ascii?q?rZCjQMBAQEBAQEBAQEBAQEBAQEBAQEBARkFgQeFNoRVhBkRAYMgglsFmUFIAYY?= =?us-ascii?q?oiVeBdYRpiSCMfYN/AR42VYMAOoE6coV5gSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,513,1473120000"; d="scan'208";a="161329504" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2016 05:56:53 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9J5uq1U013123 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Oct 2016 05:56:53 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 00:56:52 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 00:56:52 -0500 From: "Pascal Thubert (pthubert)" To: "detnet@ietf.org" Thread-Topic: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes Thread-Index: AQHSKX9JWIHzTRpDtE6f1LqlxXL2dqCvR7uw Date: Wed, 19 Oct 2016 05:56:49 +0000 Deferred-Delivery: Wed, 19 Oct 2016 05:56:32 +0000 Message-ID: References: <147682294801.30835.15229676723560958189.idtracker@ietfa.amsl.com> In-Reply-To: <147682294801.30835.15229676723560958189.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.202.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 05:56:56 -0000 RnJvbTogSUVURi1Bbm5vdW5jZSBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIElFVEYgU2VjcmV0YXJpYXQNClNlbnQ6IG1hcmRpIDE4IG9jdG9icmUg MjAxNiAyMjozNg0KVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QgPGlldGYtYW5ub3VuY2VAaWV0 Zi5vcmc+DQpDYzogbWF0dGhldy5ib2NjaUBub2tpYS5jb207IGRsbmV4QGlldGYub3JnOyBsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbQ0KU3ViamVjdDogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IERM TkVYIC0tIERpc2N1c3Npb24gb2YgcmVsaWFibGUgYW5kIGRldGVybWluaXN0aWMgbGF0ZW5jeSBh dHRyaWJ1dGVzDQoNCg0KQSBuZXcgSUVURiBub24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhh cyBiZWVuIGNyZWF0ZWQuDQoNCkxpc3QgYWRkcmVzczpkbG5leEBpZXRmLm9yZw0KQXJjaGl2ZTog aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1kbG5l eA0KVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rs bmV4DQoNClB1cnBvc2U6IA0KRExORVggaXMgdG8gZGlzY3VzcyB2YXJpb3VzIGxhdGVuY3kgY2hh cmFjdGVyaXN0aWNzIHRoYXQgY2FuIGJlIGV4cG9zZWQgYnkgbmV0d29yayBlbGVtZW50cyBvciBz ZWdtZW50cyBhbmQgdG8gZXhwbG9yZSBpZiB0aGVyZSBhcmUgYW55IGxhdGVuY3kgcmVsYXRlZCBh dHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHV0aWxpemVkIGJ5IHVwcGVyIGxheWVyLiBGb3IgZXhhbXBs ZSwgY291bGQgdGhlcmUgYmUgbGF0ZW5jeSBleHBvc3VyZSB0aGF0IHVwcGVyIGxheWVyIGNhbiB1 dGlsaXplIHRvIHBsYW4gaG93IHRvIGRpc3RyaWJ1dGUgdGhlaXIgY29udGVudCB0byB0aGUgcmln aHQgZWRnZXMgdG8gYWNoaWV2ZSBvcHRpbWFsIHVzZXIgZXhwZXJpZW5jZT8gT3Igc29tZXRoaW5n IHVzZWQgYnkgSW50ZXJhY3RpdmUgQVIgY29udHJvbGxlciB0byBvcHRpbWl6ZSB0aGVpciBzZXJ2 aWNlcz8gSXMgdGhlcmUgYW55IHZhbHVlIGdhaW5lZCBieSB1cHBlciBsYXllciBleHByZXNzaW5n IHRoYXQgdGhleSB3b3VsZCByYXRoZXIgaGF2ZSBmaXhlZCBsYXRlbmN5IHRoYW4gbG9zaW5nIHBh Y2tldHM/DQoNClRoZSBkaXNjdXNzaW9uIGlzIHRvIGFuc3dlciBxdWVzdGlvbnMgbGlrZTogYXJl IHRoZXJlIGFueSBlZmZlY3RpdmUgaW50ZXJhY3Rpb24vY29vcmRpbmF0aW9uIGJldHdlZW4gdXBw ZXIgbGF5ZXIgYW5kIGxvd2VyIGxheWVyIHRvIGFjaGlldmUgbW9yZSBlZmZpY2llbnQgb3B0aW1p emF0aW9uIGZvciBsYXRlbmN5IHNlbnNpdGl2ZSBzZXJ2aWNlcz8NCg0KVGhpcyBkaXNjdXNzaW9u IGdyb3VwIGlzIGFsc28gYSBwbGFjZSB0byBzaG93Y2FzZSB0aGUgc3RhdGUgb2YgdGhlIGFydHMg aW4gbGF0ZW5jeSBvcHRpbWl6ZWQgc3dpdGNoaW5nIGFyY2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNl IGRlc2lnbnMsIGFzIHRoZSBmZWFzaWJpbGl0eSBleGVyY2lzZSBmb3IgYWNoaWV2aW5nIHJlbGlh YmxlIGFuZCBkZXRlcm1pbmlzdGljIGxhdGVuY3kgdGhyb3VnaCBhIG5ldHdvcmsgZWxlbWVudCBv ciBhIHNlZ21lbnQuIFRob3NlIGxhdGVuY3kgZXhwb3N1cmVzIGFyZSB0aGUgZm91bmRhdGlvbiBm b3IgKGZ1dHVyZSkgbGF0ZW5jeSBvcHRpbWl6ZWQgY29udHJvbCBwbGFuZS4gDQoNCg0KRm9yIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0 b3JzLg0KDQo= From nobody Wed Oct 19 05:17:48 2016 Return-Path: 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 81EF6129602; Wed, 19 Oct 2016 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2istxZ-WZb9R; Wed, 19 Oct 2016 05:17:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4131129405; Wed, 19 Oct 2016 05:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3158; q=dns/txt; s=iport; t=1476879463; x=1478089063; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2a/WOaSI3pS49Aubpqks60m4kMIGDC1GluQuz1981qw=; b=Kw3B+cUXSWNkjwidDTNYX6JWKYWJpdH6MKnu/bFza8S3jx9TWiXLQLV6 b9TwgyuTB+1VKgLpBg2yZyNUlB9CtybvJiQDowb4mIqxRg1fkiLJ5mxnG gQVe347Z53iQ3N/qnig799U+SJ2KLFm/XRgw2rbefby8QDeiY580NhyJY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQAqZAdY/4oNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR1XfAeNLZZ7lDqCCBwLhTBKHIF7OBQBAgEBAQEBAQFiJ4R?= =?us-ascii?q?hAQEBBAEBASAROAIdAQgRAQMBAQMCCBcEAwIEJQsUAQIFAQoEARKIUg62aY0DA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBB4U2gX2CWIQZEQEzgm0sgi8FmUNIAYY?= =?us-ascii?q?oiWEKgWSEaYkijH6DfwEeNlWDADqBOnKGHYEggQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,514,1473120000"; d="scan'208";a="159263418" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2016 12:17:42 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9JCHgNM029003 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 12:17:42 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 08:17:41 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 08:17:41 -0400 From: "Patrick Wetterwald (pwetterw)" To: "Pascal Thubert (pthubert)" , "detnet@ietf.org" , "matthew.bocci@nokia.com" , "dlnex@ietf.org" , "linda.dunbar@huawei.com" Thread-Topic: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes Thread-Index: AQHSKgLKlz3O0ZwIFEGMCOdFJZiYkg== Date: Wed, 19 Oct 2016 12:17:41 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.30] Content-Type: text/plain; charset="utf-8" Content-ID: <92C5F67ECED7F04190ECBACA18D90A00@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 12:17:45 -0000 Q2FuIHNvbWVvbmUgZXhwbGFpbiBtZSB3aHkgdGhpcyBtYWlsaW5nIGxpc3QgaXMgY3JlYXRlZCBv dXRzaWRlIG9mIERldE5ldD8NCg0KVGhpcyBzb3VuZHMgbGlrZSBhIHN1YnNldCBvZiBEZXRuZXQg bm8/DQoNClRoYW5rcywNCg0KUGF0cmljaw0KDQoNCk9uIDE5LzEwLzIwMTYsIDA3OjU2LCAiZGV0 bmV0IG9uIGJlaGFsZiBvZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8ZGV0bmV0LWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHB0aHViZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAg ICBGcm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KICAgIFNlbnQ6IG1hcmRpIDE4IG9j dG9icmUgMjAxNiAyMjozNg0KICAgIFRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0IDxpZXRmLWFu bm91bmNlQGlldGYub3JnPg0KICAgIENjOiBtYXR0aGV3LmJvY2NpQG5va2lhLmNvbTsgZGxuZXhA aWV0Zi5vcmc7IGxpbmRhLmR1bmJhckBodWF3ZWkuY29tDQogICAgU3ViamVjdDogTmV3IE5vbi1X RyBNYWlsaW5nIExpc3Q6IERMTkVYIC0tIERpc2N1c3Npb24gb2YgcmVsaWFibGUgYW5kIGRldGVy bWluaXN0aWMgbGF0ZW5jeSBhdHRyaWJ1dGVzDQogICAgDQogICAgDQogICAgQSBuZXcgSUVURiBu b24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuDQogICAgDQogICAg TGlzdCBhZGRyZXNzOmRsbmV4QGlldGYub3JnDQogICAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1kbG5leA0KICAgIFRvIHN1YnNj cmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbG5leA0KICAgIA0K ICAgIFB1cnBvc2U6IA0KICAgIERMTkVYIGlzIHRvIGRpc2N1c3MgdmFyaW91cyBsYXRlbmN5IGNo YXJhY3RlcmlzdGljcyB0aGF0IGNhbiBiZSBleHBvc2VkIGJ5IG5ldHdvcmsgZWxlbWVudHMgb3Ig c2VnbWVudHMgYW5kIHRvIGV4cGxvcmUgaWYgdGhlcmUgYXJlIGFueSBsYXRlbmN5IHJlbGF0ZWQg YXR0cmlidXRlcyB0aGF0IGNhbiBiZSB1dGlsaXplZCBieSB1cHBlciBsYXllci4gRm9yIGV4YW1w bGUsIGNvdWxkIHRoZXJlIGJlIGxhdGVuY3kgZXhwb3N1cmUgdGhhdCB1cHBlciBsYXllciBjYW4g dXRpbGl6ZSB0byBwbGFuIGhvdyB0byBkaXN0cmlidXRlIHRoZWlyIGNvbnRlbnQgdG8gdGhlIHJp Z2h0IGVkZ2VzIHRvIGFjaGlldmUgb3B0aW1hbCB1c2VyIGV4cGVyaWVuY2U/IE9yIHNvbWV0aGlu ZyB1c2VkIGJ5IEludGVyYWN0aXZlIEFSIGNvbnRyb2xsZXIgdG8gb3B0aW1pemUgdGhlaXIgc2Vy dmljZXM/IElzIHRoZXJlIGFueSB2YWx1ZSBnYWluZWQgYnkgdXBwZXIgbGF5ZXIgZXhwcmVzc2lu ZyB0aGF0IHRoZXkgd291bGQgcmF0aGVyIGhhdmUgZml4ZWQgbGF0ZW5jeSB0aGFuIGxvc2luZyBw YWNrZXRzPw0KICAgIA0KICAgIFRoZSBkaXNjdXNzaW9uIGlzIHRvIGFuc3dlciBxdWVzdGlvbnMg bGlrZTogYXJlIHRoZXJlIGFueSBlZmZlY3RpdmUgaW50ZXJhY3Rpb24vY29vcmRpbmF0aW9uIGJl dHdlZW4gdXBwZXIgbGF5ZXIgYW5kIGxvd2VyIGxheWVyIHRvIGFjaGlldmUgbW9yZSBlZmZpY2ll bnQgb3B0aW1pemF0aW9uIGZvciBsYXRlbmN5IHNlbnNpdGl2ZSBzZXJ2aWNlcz8NCiAgICANCiAg ICBUaGlzIGRpc2N1c3Npb24gZ3JvdXAgaXMgYWxzbyBhIHBsYWNlIHRvIHNob3djYXNlIHRoZSBz dGF0ZSBvZiB0aGUgYXJ0cyBpbiBsYXRlbmN5IG9wdGltaXplZCBzd2l0Y2hpbmcgYXJjaGl0ZWN0 dXJlIGFuZCBpbnRlcmZhY2UgZGVzaWducywgYXMgdGhlIGZlYXNpYmlsaXR5IGV4ZXJjaXNlIGZv ciBhY2hpZXZpbmcgcmVsaWFibGUgYW5kIGRldGVybWluaXN0aWMgbGF0ZW5jeSB0aHJvdWdoIGEg bmV0d29yayBlbGVtZW50IG9yIGEgc2VnbWVudC4gVGhvc2UgbGF0ZW5jeSBleHBvc3VyZXMgYXJl IHRoZSBmb3VuZGF0aW9uIGZvciAoZnV0dXJlKSBsYXRlbmN5IG9wdGltaXplZCBjb250cm9sIHBs YW5lLiANCiAgICANCiAgICANCiAgICBGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgcGxlYXNl IGNvbnRhY3QgdGhlIGxpc3QgYWRtaW5pc3RyYXRvcnMuDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBkZXRuZXQgbWFpbGluZyBs aXN0DQogICAgZGV0bmV0QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kZXRuZXQNCiAgICANCg0K From nobody Wed Oct 19 08:46:43 2016 Return-Path: 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 C3303129670; Wed, 19 Oct 2016 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qJtZkjB3V0OE; Wed, 19 Oct 2016 08:46:37 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7789C12950C; Wed, 19 Oct 2016 08:46:37 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 184so10429416yby.2; Wed, 19 Oct 2016 08:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wAYf6vN58J7m3W4vljX4segnfCuLCzztVxBeUJE8jYI=; b=VFou/PxRxU6efyC8+HpI8U7jD4zAFm21Nryj5BCupFf1jFPDlHjs5AsrM3dxrqdpov xWGLBsy3aExF86fFOScRdzr8u7FjlENbXNevquKukCf7GbtG1NfKrXEtAhMjEyjktMrY AYBZIunGmvlpJEZrHxD1XfqaSy0poNb3OKYeIA5iEwJrVCJw2Ltp//srH3rUSr+jzWxp l7aQCXC9vo4PTSTY6AfzlKaVld7pIwNcDqFoOBZ0H23aiKGabDP23g0IvzAP29bIRDDh DniTiGcV+8wEfH7gFpAXAstWbZ9v1tcScBvYCT+X1Hmx7sYiIOMCv9omP2sV1tRW1CHm vDxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wAYf6vN58J7m3W4vljX4segnfCuLCzztVxBeUJE8jYI=; b=EqVQJqyAaiRtfAuYjjpiTsNzb2AiLw2G9zJOEERpIcfId3IXQLLOJJjVjo/WoER7PJ +zUBZ+4Bd/DzslH7xGCLr1ZAtU9SNQsTsxcgDjzMb/jUfvNP7dyQQOg0eRJNZsF1gwJJ t8aaPp8n9aLqTyQUFP2WIFgw3LCP97bW5R5EUp67PPMgs/RNRFfIxZYgo+7DmRAHIrWk 9cDBXCrM++dwjQQ5KxzOKlGeBF07Qt6M0vqItpzE71niPtC+9PeEGZXa/yJ/JWvaFPNd dMIm8r5V9vmeQH+5/AU9Z6WV2rFRCm7qbx9MKVLGSHHn2q7pM73kSd4Y3HOHBLAH1K/g l2qA== X-Gm-Message-State: AA6/9RmIwKc7jwAb6Fdl5PYMfpr3vt/AizrsRdzaeXixTJ7cxKsTqSDVJTcISlIHZJ4zMEkzb2oVPhLN/ZINbg== X-Received: by 10.37.125.135 with SMTP id y129mr6490919ybc.179.1476891996506; Wed, 19 Oct 2016 08:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.133 with HTTP; Wed, 19 Oct 2016 08:46:35 -0700 (PDT) In-Reply-To: References: From: Alia Atlas Date: Wed, 19 Oct 2016 11:46:35 -0400 Message-ID: To: "Patrick Wetterwald (pwetterw)" Content-Type: multipart/alternative; boundary=001a114e2d32d2ce8b053f39b606 Archived-At: Cc: "matthew.bocci@nokia.com" , "Pascal Thubert \(pthubert\)" , "detnet@ietf.org" , "dlnex@ietf.org" , "linda.dunbar@huawei.com" Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 15:46:40 -0000 --001a114e2d32d2ce8b053f39b606 Content-Type: text/plain; charset=UTF-8 Hi Patrick, The discussion intended on dlnex, a non-WG mailing list, is, I think, broader - spanning the range of communications between upper layer applications and the network. It is not clear yet what work might develop. Be sure that I will be watching for any specific overlap with DetNet. I feel that it is useful to make it easy for groups to have a list to brainstorm about their ideas before work is mature enough to consider for standardization. Regards, Alia On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw) < pwetterw@cisco.com> wrote: > Can someone explain me why this mailing list is created outside of DetNet? > > This sounds like a subset of Detnet no? > > Thanks, > > Patrick > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert (pthubert)" < > detnet-bounces@ietf.org on behalf of pthubert@cisco.com> wrote: > > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf > Of IETF Secretariat > Sent: mardi 18 octobre 2016 22:36 > To: IETF Announcement List > Cc: matthew.bocci@nokia.com; dlnex@ietf.org; linda.dunbar@huawei.com > Subject: New Non-WG Mailing List: DLNEX -- Discussion of reliable and > deterministic latency attributes > > > A new IETF non-working group email list has been created. > > List address:dlnex@ietf.org > Archive: https://mailarchive.ietf.org/arch/search/?email_list=dlnex > To subscribe: https://www.ietf.org/mailman/listinfo/dlnex > > Purpose: > DLNEX is to discuss various latency characteristics that can be > exposed by network elements or segments and to explore if there are any > latency related attributes that can be utilized by upper layer. For > example, could there be latency exposure that upper layer can utilize to > plan how to distribute their content to the right edges to achieve optimal > user experience? Or something used by Interactive AR controller to optimize > their services? Is there any value gained by upper layer expressing that > they would rather have fixed latency than losing packets? > > The discussion is to answer questions like: are there any effective > interaction/coordination between upper layer and lower layer to achieve > more efficient optimization for latency sensitive services? > > This discussion group is also a place to showcase the state of the > arts in latency optimized switching architecture and interface designs, as > the feasibility exercise for achieving reliable and deterministic latency > through a network element or a segment. Those latency exposures are the > foundation for (future) latency optimized control plane. > > > For additional information, please contact the list administrators. > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a114e2d32d2ce8b053f39b606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Patrick,

The discussion intended on = dlnex, a non-WG mailing list, is, I think, broader - spanning the range of = communications between upper layer applications and the network.=C2=A0 It i= s not clear yet what work might develop.=C2=A0 Be sure that I will be watch= ing for any specific overlap with DetNet.

I feel t= hat it is useful to make it easy for groups to have a list to brainstorm ab= out their ideas before work is mature enough to consider for standardizatio= n.

Regards,
Alia

On Wed, Oct 19, 2016 at 8:1= 7 AM, Patrick Wetterwald (pwetterw) <pwetterw@cisco.com> wr= ote:
Can someone explain me why this mail= ing list is created outside of DetNet?

This sounds like a subset of Detnet no?

Thanks,

Patrick


On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert (pthubert)&q= uot; <detnet-bounces@ietf.org= on behalf of pthubert@cisco.com<= /a>> wrote:

=C2=A0 =C2=A0 From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF= Secretariat
=C2=A0 =C2=A0 Sent: mardi 18 octobre 2016 22:36
=C2=A0 =C2=A0 To: IETF Announcement List <ietf-announce@ietf.org>
=C2=A0 =C2=A0 Cc: matthew= .bocci@nokia.com; dlnex@ietf.org;= linda.dunbar@huawei.com
=C2=A0 =C2=A0 Subject: New Non-WG Mailing List: D= LNEX -- Discussion of reliable and deterministic latency attributes


=C2=A0 =C2=A0 A new IETF non-working group= email list has been created.

=C2=A0 =C2=A0 List address:dlne= x@ietf.org
=C2=A0 =C2=A0 Archive: https://mailarchi= ve.ietf.org/arch/search/?email_list=3Ddlnex
=C2=A0 =C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/dlnex

=C2=A0 =C2=A0 Purpose:
=C2=A0 =C2=A0 DLNEX is to discuss various latency characteristics that can = be exposed by network elements or segments and to explore if there are any = latency related attributes that can be utilized by upper layer. For example= , could there be latency exposure that upper layer can utilize to plan how = to distribute their content to the right edges to achieve optimal user expe= rience? Or something used by Interactive AR controller to optimize their se= rvices? Is there any value gained by upper layer expressing that they would= rather have fixed latency than losing packets?

=C2=A0 =C2=A0 The discussion is to answer questions like: are there any eff= ective interaction/coordination between upper layer and lower layer to achi= eve more efficient optimization for latency sensitive services?

=C2=A0 =C2=A0 This discussion group is also a place to showcase the state o= f the arts in latency optimized switching architecture and interface design= s, as the feasibility exercise for achieving reliable and deterministic lat= ency through a network element or a segment. Those latency exposures are th= e foundation for (future) latency optimized control plane.


=C2=A0 =C2=A0 For additional information, please contact the list administr= ators.

=C2=A0 =C2=A0 ______________= _________________________________
=C2=A0 =C2=A0 detnet mailing list
=C2=A0 =C2=A0 detnet@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/detnet


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

--001a114e2d32d2ce8b053f39b606-- From nobody Wed Oct 19 09:49:50 2016 Return-Path: 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 A060512967D; Wed, 19 Oct 2016 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 IZaglTE2F3Ns; Wed, 19 Oct 2016 09:49:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9BB12951D; Wed, 19 Oct 2016 09:49:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYN93414; Wed, 19 Oct 2016 16:49:37 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 19 Oct 2016 17:49:36 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 19 Oct 2016 09:49:30 -0700 From: Linda Dunbar To: "dlnex@ietf.org" , "detnet@ietf.org" Thread-Topic: passive probe measuring network latency in combination of network exposing Latency for special services Thread-Index: AdIqJktwDPj+dhwvS7KEnfB6wzP2DA== Date: Wed, 19 Oct 2016 16:49:29 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F5D06E@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.160] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F5D06Edfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5807A422.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a757845e09f4ce6102b4afd85a42d980 Archived-At: Subject: [Detnet] passive probe measuring network latency in combination of network exposing Latency for special services X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 16:49:45 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F5D06Edfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At NANOG this week, there are many companies showing off their network moni= toring capability, from BGP route monitoring to Latency Monitoring. Compani= es like Teridion, ThousandEyes, Internap, etc. all use passive probe packet= s to measure the latency through a network. Some of those companies can pro= vide shorter latency path for upper layer. If network elements or segments support DETNET, OIF's FlexEthernet, or othe= r latency optimized mechanisms within a node, and can allocate resource for= a percentage of traffic (latency sensitive flows), is it is more valuable = for those nodes or segments to expose the upper bound latency to upper laye= rs on those flows than the passive monitoring with probes? Possible for upp= er layer to request those resources (via some kind of control plane)? Like = what CCAMP has done? Facebook presentation at NANOG pointed out (https://www.nanog.org/sites/def= ault/files/20160922_Quinn_Being_Open_How_v1.pdf ): BGP can only do so much * BGP offers little data about the forwarding plane * BGP "best" paths are oblivious to: * Capacity * Latency * Packet Loss What if the network elements can expose those attributes? Just some points for discussion. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F5D06Edfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At NANOG this week, there are many companies showing= off their network monitoring capability, from BGP route monitoring to Late= ncy Monitoring. Companies like Teridion, ThousandEyes, Internap, etc. all u= se passive probe packets to measure the latency through a network. Some of those companies can provide shorter= latency path for upper layer.

 

If network elements or segments support DETNET, OIF&= #8217;s FlexEthernet, or other latency optimized mechanisms within a node, = and can allocate resource for a percentage of traffic (latency sensitive fl= ows), is it is more valuable for those nodes or segments to expose the upper bound latency to upper layers on those flo= ws than the passive monitoring with probes? Possible for upper layer to req= uest those resources (via some kind of control plane)? Like what CCAMP has = done?

 

Facebook presentation at NANOG pointed out (https://www.nanog.org/sites/default/files/20160922_Quinn_Being_Ope= n_How_v1.pdf ):

BGP can only do so much

• BGP offers little data about the forwarding plane

• BGP “best” paths are oblivious to:

• Capacity

• Latency

• Packet Loss

What if the network elements can expose those attrib= utes?

 

Just some points for discussion.

 

Linda Dunbar

 

 

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F5D06Edfweml501mbb_-- From nobody Wed Oct 19 14:00:04 2016 Return-Path: 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 17283129453 for ; Wed, 19 Oct 2016 13:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 k_J9zDyHSa6A for ; Wed, 19 Oct 2016 13:59:57 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id DE8EB129484 for ; Wed, 19 Oct 2016 13:59:56 -0700 (PDT) Received: (qmail 31520 invoked by uid 0); 19 Oct 2016 20:59:55 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 19 Oct 2016 20:59:55 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id xYzr1t0062SSUrH01YzuCm; Wed, 19 Oct 2016 14:59:55 -0600 X-Authority-Analysis: v=2.1 cv=IecUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=CH0kA5CcgfcA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=9qxNCY_qAAAA:8 a=i0EeH86SAAAA:8 a=6_kXp5x7VGk6fYuAkQkA:9 a=hv_1VFgo34U6P6Pw:21 a=pe_vwDJHV1CLcc1L:21 a=pILNOxqGKmIA:10 a=9gMDlhcZUWAA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=A2X48xt2e1hG9NJDz63Y:22 a=02toJ7V-nxh73JlV0Smw: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:Cc:References:To:Subject; bh=TtVCF/uY1rhoWiLGvkpEnVnwqHVEKlx8sYIBX2hdTWM=; b=LfHN+GsGZtsPKFGWZxdJDd1i1O 9dzwaI+YD0MYG65BL4XUkW9dsyxJ5hRE1n/RxGZDlGITvb7fyWA6bvwbNq/OPWdzYD9gq7bFpObJj EMfnRVTHk3FWi5jnj3DszVeqp; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:52812 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bwxxm-00077Z-UF; Wed, 19 Oct 2016 14:59:51 -0600 To: Alia Atlas , "Patrick Wetterwald (pwetterw)" References: From: Lou Berger Message-ID: Date: Wed, 19 Oct 2016 16:59:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 100.15.85.191 X-Exim-ID: 1bwxxm-00077Z-UF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:52812 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "matthew.bocci@nokia.com" , "Pascal Thubert \(pthubert\)" , "detnet@ietf.org" , "dlnex@ietf.org" , "linda.dunbar@huawei.com" Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:59:59 -0000 Hi Alia, Overlap looks likely. I hope that when it does occur, you send folks over here to contribute -- additional input / WG participation would be great! (For folks not familiar with DetNet, check out our charter at https://datatracker.ietf.org/wg/detnet/charter/) I expect we'll have some good data plane centric discussions at this meeting, for those who may be interested (there's even still time to submit related drafts!) Cheers, Lou DetNet Co-chair On 10/19/2016 11:46 AM, Alia Atlas wrote: > Hi Patrick, > > The discussion intended on dlnex, a non-WG mailing list, is, I think, > broader - spanning the range of communications between upper layer > applications and the network. It is not clear yet what work might > develop. Be sure that I will be watching for any specific overlap > with DetNet. > > I feel that it is useful to make it easy for groups to have a list to > brainstorm about their ideas before work is mature enough to consider > for standardization. > > Regards, > Alia > > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw) > > wrote: > > Can someone explain me why this mailing list is created outside of > DetNet? > > This sounds like a subset of Detnet no? > > Thanks, > > Patrick > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert > (pthubert)" on behalf of pthubert@cisco.com > > wrote: > > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org > ] On Behalf Of IETF Secretariat > Sent: mardi 18 octobre 2016 22:36 > To: IETF Announcement List > > Cc: matthew.bocci@nokia.com ; > dlnex@ietf.org ; linda.dunbar@huawei.com > > Subject: New Non-WG Mailing List: DLNEX -- Discussion of > reliable and deterministic latency attributes > > > A new IETF non-working group email list has been created. > > List address:dlnex@ietf.org > Archive: > https://mailarchive.ietf.org/arch/search/?email_list=dlnex > > To subscribe: https://www.ietf.org/mailman/listinfo/dlnex > > > Purpose: > DLNEX is to discuss various latency characteristics that can > be exposed by network elements or segments and to explore if there > are any latency related attributes that can be utilized by upper > layer. For example, could there be latency exposure that upper > layer can utilize to plan how to distribute their content to the > right edges to achieve optimal user experience? Or something used > by Interactive AR controller to optimize their services? Is there > any value gained by upper layer expressing that they would rather > have fixed latency than losing packets? > > The discussion is to answer questions like: are there any > effective interaction/coordination between upper layer and lower > layer to achieve more efficient optimization for latency sensitive > services? > > This discussion group is also a place to showcase the state of > the arts in latency optimized switching architecture and interface > designs, as the feasibility exercise for achieving reliable and > deterministic latency through a network element or a segment. > Those latency exposures are the foundation for (future) latency > optimized control plane. > > > For additional information, please contact the list > administrators. > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Oct 19 15:25:32 2016 Return-Path: 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 59C87129854 for ; Wed, 19 Oct 2016 15:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 PPJ37TBnqwQi for ; Wed, 19 Oct 2016 15:25:21 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E8D1297F3 for ; Wed, 19 Oct 2016 15:25:19 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id 83so46796086vkd.0 for ; Wed, 19 Oct 2016 15:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=59HaUBHOZ5cinEW5z/Lh3g738sOwS+jz5qtshEMmRl8=; b=TrBesy3twMAFB/MJHO+W7ewxbjZOPTRcmPx51KGUptuXgiEf05oPuKUWBJZFqIFUUa 1hlxo7Rxx5WW392jKgKNddnvkULn5d1hyzSO6R2XMBhE3biuvlvLm7es8UWDYyXyQvAJ sjxZYmSM0uf66mMWbur+mOmIvkXGpkxFkI5g0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=59HaUBHOZ5cinEW5z/Lh3g738sOwS+jz5qtshEMmRl8=; b=KfMErQPt2k82OojR4Knnd9gx7Ro0R1pC4rv99YL571mgeOosYR5mSprqwQgOOGMHN9 InU7Rj5IZjJe46Z82BfyBXxu74tu603GeC8CKhw21DEdd36kH84jpjUuRsPnmy99Grcn gmbhkGjXne3HrqTZ6to9f/ijnR+xUL6/SrGuQHYVJZhqClMj+1c0PCaBMfOUzvUoURrV +KO8MBRPHsXEwS7iBhMXW6+FNMLW8ouL8rfv/eRJeuNQHT1K0HUZDHVMmMUH4C1Ng1Wz Q2BaEPVgb1IwAePt/F1j9KekwFpKhTqm11fVwP/J32qegiJ5xHDonX26VXVCnyvxC7gd OYwQ== X-Gm-Message-State: AA6/9RkrdLqpDXLA+jOgW8IC3cGMelHWizrmt+0BAziHylFqNfiyKtP9oQVSNNIETfj3E3N+vmOpn/9KLbNDc4FZ X-Received: by 10.31.52.66 with SMTP id b63mr7727010vka.9.1476915918734; Wed, 19 Oct 2016 15:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.177 with HTTP; Wed, 19 Oct 2016 15:25:18 -0700 (PDT) In-Reply-To: References: From: Pat Thaler Date: Wed, 19 Oct 2016 15:25:18 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a1143f104b3c32e053f3f48ab Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "dlnex@ietf.org" , "Patrick Wetterwald \(pwetterw\)" , Alia Atlas , "matthew.bocci@nokia.com" , "linda.dunbar@huawei.com" , "detnet@ietf.org" Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:25:26 -0000 --001a1143f104b3c32e053f3f48ab Content-Type: text/plain; charset=UTF-8 We have been having recent discussions about latency such as what type of latency is important. As far as the "feasibility exercise for achieving reliable and deterministic latency through a network element or a segment" that overlaps very much what DetNet and IEEE 802.1 TSN have been doing. I believe we have already shown that it is feasible and are not on specifying how to do that. I'm concerned about the overlap between what that paragraph describes and our work. There could be useful work on communication from the upper layer of the flow characteristics, behavior and requirements. There probably is some gap to fill that would help our work. I'm concerned that the list description focuses only on exposing lower layer characteristics to the upper layer. The network can't provide a bounded or deterministic latency to an unbounded flow - to determine what latency can be provided, one has to know something about the bandwidth utilization of the flow. Regards, Pat On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger wrote: > Hi Alia, > > Overlap looks likely. I hope that when it does occur, you send > folks over here to contribute -- additional input / WG participation > would be great! (For folks not familiar with DetNet, check out our > charter at https://datatracker.ietf.org/wg/detnet/charter/) > > I expect we'll have some good data plane centric discussions at this > meeting, for those who may be interested (there's even still time to > submit related drafts!) > > Cheers, > > Lou > > DetNet Co-chair > > On 10/19/2016 11:46 AM, Alia Atlas wrote: > > Hi Patrick, > > > > The discussion intended on dlnex, a non-WG mailing list, is, I think, > > broader - spanning the range of communications between upper layer > > applications and the network. It is not clear yet what work might > > develop. Be sure that I will be watching for any specific overlap > > with DetNet. > > > > I feel that it is useful to make it easy for groups to have a list to > > brainstorm about their ideas before work is mature enough to consider > > for standardization. > > > > Regards, > > Alia > > > > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw) > > > wrote: > > > > Can someone explain me why this mailing list is created outside of > > DetNet? > > > > This sounds like a subset of Detnet no? > > > > Thanks, > > > > Patrick > > > > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert > > (pthubert)" > on behalf of pthubert@cisco.com > > > wrote: > > > > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org > > ] On Behalf Of IETF > Secretariat > > Sent: mardi 18 octobre 2016 22:36 > > To: IETF Announcement List > > > > Cc: matthew.bocci@nokia.com ; > > dlnex@ietf.org ; linda.dunbar@huawei.com > > > > Subject: New Non-WG Mailing List: DLNEX -- Discussion of > > reliable and deterministic latency attributes > > > > > > A new IETF non-working group email list has been created. > > > > List address:dlnex@ietf.org > > Archive: > > https://mailarchive.ietf.org/arch/search/?email_list=dlnex > > > > To subscribe: https://www.ietf.org/mailman/listinfo/dlnex > > > > > > Purpose: > > DLNEX is to discuss various latency characteristics that can > > be exposed by network elements or segments and to explore if there > > are any latency related attributes that can be utilized by upper > > layer. For example, could there be latency exposure that upper > > layer can utilize to plan how to distribute their content to the > > right edges to achieve optimal user experience? Or something used > > by Interactive AR controller to optimize their services? Is there > > any value gained by upper layer expressing that they would rather > > have fixed latency than losing packets? > > > > The discussion is to answer questions like: are there any > > effective interaction/coordination between upper layer and lower > > layer to achieve more efficient optimization for latency sensitive > > services? > > > > This discussion group is also a place to showcase the state of > > the arts in latency optimized switching architecture and interface > > designs, as the feasibility exercise for achieving reliable and > > deterministic latency through a network element or a segment. > > Those latency exposures are the foundation for (future) latency > > optimized control plane. > > > > > > For additional information, please contact the list > > administrators. > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a1143f104b3c32e053f3f48ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have been having recent discussions about latency such = as what type of latency is important.

As far as the &quo= t;feasibility exercise=C2=A0for achieving reliable and deterministic latency = through a network element or a segment" that overlaps very much what D= etNet and IEEE 802.1 TSN have been doing. I believe we have already shown t= hat it is feasible and are not on specifying how to do that. I'm concer= ned about the overlap between what that paragraph describes and our work.

Ther= e could be useful work on communication from the upper layer of the flow ch= aracteristics, behavior and requirements. There probably is some gap to fil= l that would help our work. I'm concerned that the list description foc= uses only on exposing lower layer characteristics to the upper layer. The n= etwork can't provide a bounded or deterministic latency to an unbounded= flow - to determine what latency can be provided, one has to know somethin= g about the bandwidth utilization of the flow.

Regards,
Pat

On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger <lberger@labn= .net> wrote:
Hi Alia,

=C2=A0 =C2=A0 Overlap looks likely.=C2=A0 I hope that when it does occur, y= ou send
folks over here to contribute -- additional input / WG participation
would be great!=C2=A0 (For folks not familiar with DetNet, check out our charter at https://datatracker.ietf.org/wg/detn= et/charter/)

I expect we'll have some good data plane centric discussions at this meeting, for those who may be interested (there's even still time to submit related drafts!)

Cheers,

Lou

DetNet Co-chair

On 10/19/2016 11:46 AM, Alia Atlas wrote:
> Hi Patrick,
>
> The discussion intended on dlnex, a non-WG mailing list, is, I think,<= br> > broader - spanning the range of communications between upper layer
> applications and the network.=C2=A0 It is not clear yet what work migh= t
> develop.=C2=A0 Be sure that I will be watching for any specific overla= p
> with DetNet.
>
> I feel that it is useful to make it easy for groups to have a list to<= br> > brainstorm about their ideas before work is mature enough to consider<= br> > for standardization.
>
> Regards,
> Alia
>
> On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw)
> <pwet= terw@cisco.com <mailto:pwetter= w@cisco.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Can someone explain me why this mailing list is cre= ated outside of
>=C2=A0 =C2=A0 =C2=A0DetNet?
>
>=C2=A0 =C2=A0 =C2=A0This sounds like a subset of Detnet no?
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>
>=C2=A0 =C2=A0 =C2=A0Patrick
>
>
>=C2=A0 =C2=A0 =C2=A0On 19/10/2016, 07:56, "detnet on behalf of Pas= cal Thubert
>=C2=A0 =C2=A0 =C2=A0(pthubert)" <detnet-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:detnet-bounces@ietf.org> on behalf of pthubert@cisco.com
>=C2=A0 =C2=A0 =C2=A0<mailto:pthubert@cisco.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: IETF-Announce [mailto:ietf-announce-bounces@ietf.= org
>=C2=A0 =C2=A0 =C2=A0<mailto:ietf-announce-bounces@ietf.org>] On Behalf Of IETF Se= cretariat
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: mardi 18 octobre 2016 22:36
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: IETF Announcement List <ietf-announce@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:ietf-announce@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: matthew.bocci@nokia.com <mailto:matthew.bocci@nokia.com>;
>=C2=A0 =C2=A0 =C2=A0dlnex@ietf.org <mailto:dlnex@ietf.org>; linda.dunbar@huawei.com
>=C2=A0 =C2=A0 =C2=A0<mailto:linda.dunbar@huawei.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Non-WG = Mailing List: DLNEX -- Discussion of
>=C2=A0 =C2=A0 =C2=A0reliable and deterministic latency attributes
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new IETF non-working group email li= st has been created.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0List address:dlnex@ietf.org <mailto:address%3Adlnex@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Archive:
>=C2=A0 =C2=A0 =C2=A0https://mailarch= ive.ietf.org/arch/search/?email_list=3Ddlnex
>=C2=A0 =C2=A0 =C2=A0<https://mailarchive.ietf.org/arch/search/?email_list=3Ddln= ex>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To subscribe: https= ://www.ietf.org/mailman/listinfo/dlnex
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/dlnex>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Purpose:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DLNEX is to discuss various latency c= haracteristics that can
>=C2=A0 =C2=A0 =C2=A0be exposed by network elements or segments and to e= xplore if there
>=C2=A0 =C2=A0 =C2=A0are any latency related attributes that can be util= ized by upper
>=C2=A0 =C2=A0 =C2=A0layer. For example, could there be latency exposure= that upper
>=C2=A0 =C2=A0 =C2=A0layer can utilize to plan how to distribute their c= ontent to the
>=C2=A0 =C2=A0 =C2=A0right edges to achieve optimal user experience? Or = something used
>=C2=A0 =C2=A0 =C2=A0by Interactive AR controller to optimize their serv= ices? Is there
>=C2=A0 =C2=A0 =C2=A0any value gained by upper layer expressing that the= y would rather
>=C2=A0 =C2=A0 =C2=A0have fixed latency than losing packets?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The discussion is to answer questions= like: are there any
>=C2=A0 =C2=A0 =C2=A0effective interaction/coordination between upper la= yer and lower
>=C2=A0 =C2=A0 =C2=A0layer to achieve more efficient optimization for la= tency sensitive
>=C2=A0 =C2=A0 =C2=A0services?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This discussion group is also a place= to showcase the state of
>=C2=A0 =C2=A0 =C2=A0the arts in latency optimized switching architectur= e and interface
>=C2=A0 =C2=A0 =C2=A0designs, as the feasibility exercise for achieving = reliable and
>=C2=A0 =C2=A0 =C2=A0deterministic latency through a network element or = a segment.
>=C2=A0 =C2=A0 =C2=A0Those latency exposures are the foundation for (fut= ure) latency
>=C2=A0 =C2=A0 =C2=A0optimized control plane.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For additional information, please co= ntact the list
>=C2=A0 =C2=A0 =C2=A0administrators.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0________________________________= _______________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0detnet mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0detnet@ietf.org <mailto:detnet@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/mailman/listinfo/detnet
>=C2=A0 =C2=A0 =C2=A0<https://www= .ietf.org/mailman/listinfo/detnet>
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0detnet mailing list
>=C2=A0 =C2=A0 =C2=A0detnet@ie= tf.org <mailto:detnet@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/detnet
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/detnet>
>
>
>
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

--001a1143f104b3c32e053f3f48ab-- From nobody Wed Oct 19 16:10:12 2016 Return-Path: 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 2099C129510; Wed, 19 Oct 2016 16:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 OA_nZOq3iI6j; Wed, 19 Oct 2016 16:10:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F8D1293F3; Wed, 19 Oct 2016 16:10:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYO25646; Wed, 19 Oct 2016 23:10:01 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 20 Oct 2016 00:10:00 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 19 Oct 2016 16:09:53 -0700 From: Linda Dunbar To: Pat Thaler , Lou Berger Thread-Topic: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes Thread-Index: AQHSKgLKlz3O0ZwIFEGMCOdFJZiYkqCwYUSAgABXgwCAABfjAP//kK3Q Date: Wed, 19 Oct 2016 23:09:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F5D2FD@dfweml501-mbb> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.182] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F5D2FDdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5807FD4A.0091, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4376e766f04982912b3e52489fe5db57 Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "dlnex@ietf.org" , "Patrick Wetterwald \(pwetterw\)" , Alia Atlas , "matthew.bocci@nokia.com" , "detnet@ietf.org" Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:10:10 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F5D2FDdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF0LA0KDQpXaGF0IHlvdSBzYWlkIGlzIHNvIHRydWU6IOKAnFRoZSBuZXR3b3JrIGNhbid0IHBy b3ZpZGUgYSBib3VuZGVkIG9yIGRldGVybWluaXN0aWMgbGF0ZW5jeSB0byBhbiB1bmJvdW5kZWQg Zmxvd+KAnS4NCg0KREVUTkVUIGNoYXJ0ZXIgc3RhcnRzIHdpdGgNClRoZSBEZXRlcm1pbmlzdGlj IE5ldHdvcmtpbmcgKERldE5ldCkgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uDQpkZXRlcm1pbmlz dGljIGRhdGEgcGF0aHMgdGhhdCBvcGVyYXRlIG92ZXIgTGF5ZXIgMiBicmlkZ2VkIGFuZCBMYXll ciAzDQpyb3V0ZWQgc2VnbWVudHMsIHdoZXJlIHN1Y2ggcGF0aHMgY2FuIHByb3ZpZGUgYm91bmRz IG9uIGxhdGVuY3ksIGxvc3MsDQphbmQgcGFja2V0IGRlbGF5IHZhcmlhdGlvbiAoaml0dGVyKSwg YW5kIGhpZ2ggcmVsaWFiaWxpdHkNCg0KSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgREVU TkVUIGZvY3VzZXMgb24gdGhlIGVuYWJsaW5nIHRlY2hub2xvZ2llcyB0byBlbnN1cmUgZGV0ZXJt aW5pc3RpYyBsYXRlbmN5IHBhdGggYWNyb3NzIGEgc2V0IG9mIG5vZGVzLg0KDQpFMkUgbG93IGxh dGVuY3kgc2VydmljZXMgaGFzIG1hbnkgaXNzdWVzLCBzdWNoIGFzOg0KDQrCtyAgICAgICAgVGhl cmUgY291bGQgYmUg4oCcYm91bmRlZCBmbG93c+KAnSB0aGF0IG5lZWQgbG93IGxhdGVuY3kgc2Vy dmljZXMgbWl4ZWQgd2l0aCBvdGhlciB0cmFmZmljIGluIHRoZSBuZXR3b3JrLg0KDQrCtyAgICAg ICAgRTJFIHNlcnZpY2VzIG1heSBoYXZlIHRvIGdvIHRocm91Z2ggbWFueSBob3BzLCBsaW5rcyB3 aXRoIHNvbWUgbGlua3Mgbm90IHN1cHBvcnRpbmcgREVUTkVULg0KDQrCtyAgICAgICAgdGhlcmUg Y291bGQgYmUgdmFyaW91cyBwcm90ZWN0aW9uL3JlLXJvdXRlIG1lY2hhbmlzbXMgd2hpY2ggYWxs IGluY3JlYXNlIGxhdGVuY3kuDQoNCsK3ICAgICAgICBldGMNCg0KU29tZSBwcm9ibGVtcyBzcGVj aWZpYyB0byBXQU4gaW5jbHVkZSBob3cgdG8gaXNvbGF0ZSB0aGUgdmFyaW91cyBzZXJ2aWNlIHRy YWZmaWMsIGFuZCBwcm92aWRlIG1heGltdW0gbWFuYWdlYWJpbGl0eSB0byB1cHBlciBsYXllcnMu DQoNCk9uZSBjb21wYW55IGluIE5BTk9HIGFza2VkIHdoeSBub3QgdXNlIElDTVAgdG8gbWFyayB0 aGUgZGVsYXkgYWxvbmcgdGhlIHBhdGggdG8gZ2l2ZSB1cHBlciBsaW5rLCAuLg0KDQpMaW5kYQ0K DQoNCkxpbmRhDQoNCkZyb206IFBhdCBUaGFsZXIgW21haWx0bzpwYXQudGhhbGVyQGJyb2FkY29t LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxOSwgMjAxNiA1OjI1IFBNDQpUbzogTG91 IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkNjOiBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWls LmNvbT47IFBhdHJpY2sgV2V0dGVyd2FsZCAocHdldHRlcncpIDxwd2V0dGVyd0BjaXNjby5jb20+ OyBtYXR0aGV3LmJvY2NpQG5va2lhLmNvbTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRo dWJlcnRAY2lzY28uY29tPjsgZGV0bmV0QGlldGYub3JnOyBkbG5leEBpZXRmLm9yZzsgTGluZGEg RHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBG VzogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IERMTkVYIC0tIERpc2N1c3Npb24gb2YgcmVsaWFi bGUgYW5kIGRldGVybWluaXN0aWMgbGF0ZW5jeSBhdHRyaWJ1dGVzDQoNCldlIGhhdmUgYmVlbiBo YXZpbmcgcmVjZW50IGRpc2N1c3Npb25zIGFib3V0IGxhdGVuY3kgc3VjaCBhcyB3aGF0IHR5cGUg b2YgbGF0ZW5jeSBpcyBpbXBvcnRhbnQuDQoNCkFzIGZhciBhcyB0aGUgImZlYXNpYmlsaXR5IGV4 ZXJjaXNlIGZvciBhY2hpZXZpbmcgcmVsaWFibGUgYW5kIGRldGVybWluaXN0aWMgbGF0ZW5jeSB0 aHJvdWdoIGEgbmV0d29yayBlbGVtZW50IG9yIGEgc2VnbWVudCIgdGhhdCBvdmVybGFwcyB2ZXJ5 IG11Y2ggd2hhdCBEZXROZXQgYW5kIElFRUUgODAyLjEgVFNOIGhhdmUgYmVlbiBkb2luZy4gSSBi ZWxpZXZlIHdlIGhhdmUgYWxyZWFkeSBzaG93biB0aGF0IGl0IGlzIGZlYXNpYmxlIGFuZCBhcmUg bm90IG9uIHNwZWNpZnlpbmcgaG93IHRvIGRvIHRoYXQuIEknbSBjb25jZXJuZWQgYWJvdXQgdGhl IG92ZXJsYXAgYmV0d2VlbiB3aGF0IHRoYXQgcGFyYWdyYXBoIGRlc2NyaWJlcyBhbmQgb3VyIHdv cmsuDQoNClRoZXJlIGNvdWxkIGJlIHVzZWZ1bCB3b3JrIG9uIGNvbW11bmljYXRpb24gZnJvbSB0 aGUgdXBwZXIgbGF5ZXIgb2YgdGhlIGZsb3cgY2hhcmFjdGVyaXN0aWNzLCBiZWhhdmlvciBhbmQg cmVxdWlyZW1lbnRzLiBUaGVyZSBwcm9iYWJseSBpcyBzb21lIGdhcCB0byBmaWxsIHRoYXQgd291 bGQgaGVscCBvdXIgd29yay4gSSdtIGNvbmNlcm5lZCB0aGF0IHRoZSBsaXN0IGRlc2NyaXB0aW9u IGZvY3VzZXMgb25seSBvbiBleHBvc2luZyBsb3dlciBsYXllciBjaGFyYWN0ZXJpc3RpY3MgdG8g dGhlIHVwcGVyIGxheWVyLiBUaGUgbmV0d29yayBjYW4ndCBwcm92aWRlIGEgYm91bmRlZCBvciBk ZXRlcm1pbmlzdGljIGxhdGVuY3kgdG8gYW4gdW5ib3VuZGVkIGZsb3cgLSB0byBkZXRlcm1pbmUg d2hhdCBsYXRlbmN5IGNhbiBiZSBwcm92aWRlZCwgb25lIGhhcyB0byBrbm93IHNvbWV0aGluZyBh Ym91dCB0aGUgYmFuZHdpZHRoIHV0aWxpemF0aW9uIG9mIHRoZSBmbG93Lg0KDQpSZWdhcmRzLA0K UGF0DQoNCk9uIFdlZCwgT2N0IDE5LCAyMDE2IGF0IDE6NTkgUE0sIExvdSBCZXJnZXIgPGxiZXJn ZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCkhpIEFsaWEsDQoN CiAgICBPdmVybGFwIGxvb2tzIGxpa2VseS4gIEkgaG9wZSB0aGF0IHdoZW4gaXQgZG9lcyBvY2N1 ciwgeW91IHNlbmQNCmZvbGtzIG92ZXIgaGVyZSB0byBjb250cmlidXRlIC0tIGFkZGl0aW9uYWwg aW5wdXQgLyBXRyBwYXJ0aWNpcGF0aW9uDQp3b3VsZCBiZSBncmVhdCEgIChGb3IgZm9sa3Mgbm90 IGZhbWlsaWFyIHdpdGggRGV0TmV0LCBjaGVjayBvdXQgb3VyDQpjaGFydGVyIGF0IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZGV0bmV0L2NoYXJ0ZXIvKQ0KDQpJIGV4cGVjdCB3ZSds bCBoYXZlIHNvbWUgZ29vZCBkYXRhIHBsYW5lIGNlbnRyaWMgZGlzY3Vzc2lvbnMgYXQgdGhpcw0K bWVldGluZywgZm9yIHRob3NlIHdobyBtYXkgYmUgaW50ZXJlc3RlZCAodGhlcmUncyBldmVuIHN0 aWxsIHRpbWUgdG8NCnN1Ym1pdCByZWxhdGVkIGRyYWZ0cyEpDQoNCkNoZWVycywNCg0KTG91DQoN CkRldE5ldCBDby1jaGFpcg0KDQpPbiAxMC8xOS8yMDE2IDExOjQ2IEFNLCBBbGlhIEF0bGFzIHdy b3RlOg0KPiBIaSBQYXRyaWNrLA0KPg0KPiBUaGUgZGlzY3Vzc2lvbiBpbnRlbmRlZCBvbiBkbG5l eCwgYSBub24tV0cgbWFpbGluZyBsaXN0LCBpcywgSSB0aGluaywNCj4gYnJvYWRlciAtIHNwYW5u aW5nIHRoZSByYW5nZSBvZiBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHVwcGVyIGxheWVyDQo+IGFw cGxpY2F0aW9ucyBhbmQgdGhlIG5ldHdvcmsuICBJdCBpcyBub3QgY2xlYXIgeWV0IHdoYXQgd29y ayBtaWdodA0KPiBkZXZlbG9wLiAgQmUgc3VyZSB0aGF0IEkgd2lsbCBiZSB3YXRjaGluZyBmb3Ig YW55IHNwZWNpZmljIG92ZXJsYXANCj4gd2l0aCBEZXROZXQuDQo+DQo+IEkgZmVlbCB0aGF0IGl0 IGlzIHVzZWZ1bCB0byBtYWtlIGl0IGVhc3kgZm9yIGdyb3VwcyB0byBoYXZlIGEgbGlzdCB0bw0K PiBicmFpbnN0b3JtIGFib3V0IHRoZWlyIGlkZWFzIGJlZm9yZSB3b3JrIGlzIG1hdHVyZSBlbm91 Z2ggdG8gY29uc2lkZXINCj4gZm9yIHN0YW5kYXJkaXphdGlvbi4NCj4NCj4gUmVnYXJkcywNCj4g QWxpYQ0KPg0KPiBPbiBXZWQsIE9jdCAxOSwgMjAxNiBhdCA4OjE3IEFNLCBQYXRyaWNrIFdldHRl cndhbGQgKHB3ZXR0ZXJ3KQ0KPiA8cHdldHRlcndAY2lzY28uY29tPG1haWx0bzpwd2V0dGVyd0Bj aXNjby5jb20+IDxtYWlsdG86cHdldHRlcndAY2lzY28uY29tPG1haWx0bzpwd2V0dGVyd0BjaXNj by5jb20+Pj4gd3JvdGU6DQo+DQo+ICAgICBDYW4gc29tZW9uZSBleHBsYWluIG1lIHdoeSB0aGlz IG1haWxpbmcgbGlzdCBpcyBjcmVhdGVkIG91dHNpZGUgb2YNCj4gICAgIERldE5ldD8NCj4NCj4g ICAgIFRoaXMgc291bmRzIGxpa2UgYSBzdWJzZXQgb2YgRGV0bmV0IG5vPw0KPg0KPiAgICAgVGhh bmtzLA0KPg0KPiAgICAgUGF0cmljaw0KPg0KPg0KPiAgICAgT24gMTkvMTAvMjAxNiwgMDc6NTYs ICJkZXRuZXQgb24gYmVoYWxmIG9mIFBhc2NhbCBUaHViZXJ0DQo+ICAgICAocHRodWJlcnQpIiA8 ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnPg0K PiAgICAgPG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGV0bmV0LWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgcHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1 YmVydEBjaXNjby5jb20+DQo+ICAgICA8bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tPj4+IHdyb3RlOg0KPg0KPiAgICAgICAgIEZyb206IElFVEYtQW5u b3VuY2UgW21haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlldGYt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86aWV0Zi1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnPG1haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc+Pl0g T24gQmVoYWxmIE9mIElFVEYgU2VjcmV0YXJpYXQNCj4gICAgICAgICBTZW50OiBtYXJkaSAxOCBv Y3RvYnJlIDIwMTYgMjI6MzYNCj4gICAgICAgICBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdCA8 aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCj4g ICAgIDxtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZz4+Pg0KPiAgICAgICAgIENjOiBtYXR0aGV3LmJvY2NpQG5va2lhLmNvbTxtYWlsdG86 bWF0dGhldy5ib2NjaUBub2tpYS5jb20+IDxtYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5jb208 bWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9raWEuY29tPj47DQo+ICAgICBkbG5leEBpZXRmLm9yZzxt YWlsdG86ZGxuZXhAaWV0Zi5vcmc+IDxtYWlsdG86ZGxuZXhAaWV0Zi5vcmc8bWFpbHRvOmRsbmV4 QGlldGYub3JnPj47IGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJA aHVhd2VpLmNvbT4NCj4gICAgIDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb208bWFpbHRv OmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4NCj4gICAgICAgICBTdWJqZWN0OiBOZXcgTm9uLVdH IE1haWxpbmcgTGlzdDogRExORVggLS0gRGlzY3Vzc2lvbiBvZg0KPiAgICAgcmVsaWFibGUgYW5k IGRldGVybWluaXN0aWMgbGF0ZW5jeSBhdHRyaWJ1dGVzDQo+DQo+DQo+ICAgICAgICAgQSBuZXcg SUVURiBub24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuDQo+DQo+ ICAgICAgICAgTGlzdCBhZGRyZXNzOmRsbmV4QGlldGYub3JnPG1haWx0bzphZGRyZXNzJTNBZGxu ZXhAaWV0Zi5vcmc+IDxtYWlsdG86YWRkcmVzcyUzQWRsbmV4QGlldGYub3JnPG1haWx0bzphZGRy ZXNzJTI1M0FkbG5leEBpZXRmLm9yZz4+DQo+ICAgICAgICAgQXJjaGl2ZToNCj4gICAgIGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZGxuZXgNCj4g ICAgIDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2VhcmNoLz9lbWFpbF9saXN0 PWRsbmV4Pg0KPiAgICAgICAgIFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kbG5leA0KPiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGxuZXg+DQo+DQo+ICAgICAgICAgUHVycG9zZToNCj4gICAgICAgICBETE5FWCBp cyB0byBkaXNjdXNzIHZhcmlvdXMgbGF0ZW5jeSBjaGFyYWN0ZXJpc3RpY3MgdGhhdCBjYW4NCj4g ICAgIGJlIGV4cG9zZWQgYnkgbmV0d29yayBlbGVtZW50cyBvciBzZWdtZW50cyBhbmQgdG8gZXhw bG9yZSBpZiB0aGVyZQ0KPiAgICAgYXJlIGFueSBsYXRlbmN5IHJlbGF0ZWQgYXR0cmlidXRlcyB0 aGF0IGNhbiBiZSB1dGlsaXplZCBieSB1cHBlcg0KPiAgICAgbGF5ZXIuIEZvciBleGFtcGxlLCBj b3VsZCB0aGVyZSBiZSBsYXRlbmN5IGV4cG9zdXJlIHRoYXQgdXBwZXINCj4gICAgIGxheWVyIGNh biB1dGlsaXplIHRvIHBsYW4gaG93IHRvIGRpc3RyaWJ1dGUgdGhlaXIgY29udGVudCB0byB0aGUN Cj4gICAgIHJpZ2h0IGVkZ2VzIHRvIGFjaGlldmUgb3B0aW1hbCB1c2VyIGV4cGVyaWVuY2U/IE9y IHNvbWV0aGluZyB1c2VkDQo+ICAgICBieSBJbnRlcmFjdGl2ZSBBUiBjb250cm9sbGVyIHRvIG9w dGltaXplIHRoZWlyIHNlcnZpY2VzPyBJcyB0aGVyZQ0KPiAgICAgYW55IHZhbHVlIGdhaW5lZCBi eSB1cHBlciBsYXllciBleHByZXNzaW5nIHRoYXQgdGhleSB3b3VsZCByYXRoZXINCj4gICAgIGhh dmUgZml4ZWQgbGF0ZW5jeSB0aGFuIGxvc2luZyBwYWNrZXRzPw0KPg0KPiAgICAgICAgIFRoZSBk aXNjdXNzaW9uIGlzIHRvIGFuc3dlciBxdWVzdGlvbnMgbGlrZTogYXJlIHRoZXJlIGFueQ0KPiAg ICAgZWZmZWN0aXZlIGludGVyYWN0aW9uL2Nvb3JkaW5hdGlvbiBiZXR3ZWVuIHVwcGVyIGxheWVy IGFuZCBsb3dlcg0KPiAgICAgbGF5ZXIgdG8gYWNoaWV2ZSBtb3JlIGVmZmljaWVudCBvcHRpbWl6 YXRpb24gZm9yIGxhdGVuY3kgc2Vuc2l0aXZlDQo+ICAgICBzZXJ2aWNlcz8NCj4NCj4gICAgICAg ICBUaGlzIGRpc2N1c3Npb24gZ3JvdXAgaXMgYWxzbyBhIHBsYWNlIHRvIHNob3djYXNlIHRoZSBz dGF0ZSBvZg0KPiAgICAgdGhlIGFydHMgaW4gbGF0ZW5jeSBvcHRpbWl6ZWQgc3dpdGNoaW5nIGFy Y2hpdGVjdHVyZSBhbmQgaW50ZXJmYWNlDQo+ICAgICBkZXNpZ25zLCBhcyB0aGUgZmVhc2liaWxp dHkgZXhlcmNpc2UgZm9yIGFjaGlldmluZyByZWxpYWJsZSBhbmQNCj4gICAgIGRldGVybWluaXN0 aWMgbGF0ZW5jeSB0aHJvdWdoIGEgbmV0d29yayBlbGVtZW50IG9yIGEgc2VnbWVudC4NCj4gICAg IFRob3NlIGxhdGVuY3kgZXhwb3N1cmVzIGFyZSB0aGUgZm91bmRhdGlvbiBmb3IgKGZ1dHVyZSkg bGF0ZW5jeQ0KPiAgICAgb3B0aW1pemVkIGNvbnRyb2wgcGxhbmUuDQo+DQo+DQo+ICAgICAgICAg Rm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0DQo+ICAg ICBhZG1pbmlzdHJhdG9ycy4NCj4NCj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgIGRldG5ldCBtYWlsaW5nIGxpc3QNCj4g ICAgICAgICBkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4gPG1haWx0bzpk ZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4+DQo+ICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCj4gICAgIDxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldD4NCj4NCj4NCj4gICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBkZXRuZXQgbWFp bGluZyBsaXN0DQo+ICAgICBkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4g PG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4+DQo+ICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPiAgICAgPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Pg0KPg0KPg0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkZXRuZXQg bWFpbGluZyBsaXN0DQo+IGRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGV0bmV0IG1haWxpbmcg bGlzdA0KZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657F5D2FDdfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlBUIFNlcmlmIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTc0MTcxNTg2Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjA2ODU1MDEy IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4yNWluOw0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDoxLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4y NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjMuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6NC43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgeW91IHNhaWQgaXMgc28gdHJ1ZTog4oCcPC9zcGFu PlRoZSBuZXR3b3JrIGNhbid0IHByb3ZpZGUgYSBib3VuZGVkIG9yIGRldGVybWluaXN0aWMgbGF0 ZW5jeSB0byBhbiB1bmJvdW5kZWQgZmxvd+KAnS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+REVUTkVUIGNoYXJ0ZXIgc3RhcnRzIHdpdGg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIFNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlRoZSBEZXRlcm1pbmlz dGljIE5ldHdvcmtpbmcgKERldE5ldCkgV29ya2luZyBHcm91cCBmb2N1c2VzIG9uPGJyPg0KZGV0 ZXJtaW5pc3RpYyBkYXRhIHBhdGhzIHRoYXQgb3BlcmF0ZSBvdmVyIExheWVyIDIgYnJpZGdlZCBh bmQgTGF5ZXIgMzxicj4NCnJvdXRlZCBzZWdtZW50cywgd2hlcmUgc3VjaCBwYXRocyBjYW4gcHJv dmlkZSBib3VuZHMgb24gbGF0ZW5jeSwgbG9zcyw8YnI+DQphbmQgcGFja2V0IGRlbGF5IHZhcmlh dGlvbiAoaml0dGVyKSwgYW5kIGhpZ2ggcmVsaWFiaWxpdHk8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJl Y3RseSwgREVUTkVUIGZvY3VzZXMgb24gdGhlIGVuYWJsaW5nIHRlY2hub2xvZ2llcyB0byBlbnN1 cmUgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5IHBhdGggYWNyb3NzIGEgc2V0IG9mIG5vZGVzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FMkUgbG93IGxhdGVuY3kg c2VydmljZXMgaGFzIG1hbnkgaXNzdWVzLCBzdWNoIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGNvdWxkIGJlIOKAnGJvdW5k ZWQgZmxvd3PigJ0gdGhhdCBuZWVkIGxvdyBsYXRlbmN5IHNlcnZpY2VzIG1peGVkIHdpdGggb3Ro ZXIgdHJhZmZpYyBpbiB0aGUgbmV0d29yay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkUyRSBzZXJ2aWNlcyBtYXkgaGF2ZSB0byBnbyB0 aHJvdWdoIG1hbnkgaG9wcywgbGlua3Mgd2l0aCBzb21lIGxpbmtzIG5vdCBzdXBwb3J0aW5nIERF VE5FVC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPnRoZXJlIGNvdWxkIGJlIHZhcmlvdXMgcHJvdGVjdGlvbi9yZS1yb3V0ZSBtZWNoYW5p c21zIHdoaWNoIGFsbCBpbmNyZWFzZSBsYXRlbmN5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXRjPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tb21lIHByb2JsZW1zIHNwZWNpZmljIHRvIFdBTiBpbmNs dWRlIGhvdyB0byBpc29sYXRlIHRoZSB2YXJpb3VzIHNlcnZpY2UgdHJhZmZpYywgYW5kIHByb3Zp ZGUgbWF4aW11bSBtYW5hZ2VhYmlsaXR5IHRvIHVwcGVyIGxheWVycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSBjb21wYW55IGluIE5BTk9HIGFza2VkIHdo eSBub3QgdXNlIElDTVAgdG8gbWFyayB0aGUgZGVsYXkgYWxvbmcgdGhlIHBhdGggdG8gZ2l2ZSB1 cHBlciBsaW5rLCAuLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5MaW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkxpbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBhdCBUaGFsZXIgW21haWx0bzpwYXQu dGhhbGVyQGJyb2FkY29tLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9i ZXIgMTksIDIwMTYgNToyNSBQTTxicj4NCjxiPlRvOjwvYj4gTG91IEJlcmdlciAmbHQ7bGJlcmdl ckBsYWJuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IEFsaWEgQXRsYXMgJmx0O2FrYXRsYXNAZ21h aWwuY29tJmd0OzsgUGF0cmljayBXZXR0ZXJ3YWxkIChwd2V0dGVydykgJmx0O3B3ZXR0ZXJ3QGNp c2NvLmNvbSZndDs7IG1hdHRoZXcuYm9jY2lAbm9raWEuY29tOyBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7OyBkZXRuZXRAaWV0Zi5vcmc7IGRsbmV4 QGlldGYub3JnOyBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJhckBodWF3ZWkuY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RldG5ldF0gRlc6IE5ldyBOb24tV0cgTWFpbGluZyBM aXN0OiBETE5FWCAtLSBEaXNjdXNzaW9uIG9mIHJlbGlhYmxlIGFuZCBkZXRlcm1pbmlzdGljIGxh dGVuY3kgYXR0cmlidXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl IGhhdmUgYmVlbiBoYXZpbmcgcmVjZW50IGRpc2N1c3Npb25zIGFib3V0IGxhdGVuY3kgc3VjaCBh cyB3aGF0IHR5cGUgb2YgbGF0ZW5jeSBpcyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmYXIgYXMgdGhlICZxdW90O2ZlYXNpYmlsaXR5 IGV4ZXJjaXNlPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7Zm9yIGFjaGlldmlu ZyByZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5IHRocm91Z2ggYSBuZXR3b3JrIGVs ZW1lbnQgb3IgYSBzZWdtZW50JnF1b3Q7IHRoYXQgb3ZlcmxhcHMgdmVyeSBtdWNoIHdoYXQgRGV0 TmV0IGFuZCBJRUVFIDgwMi4xIFRTTiBoYXZlIGJlZW4gZG9pbmcuIEkgYmVsaWV2ZQ0KIHdlIGhh dmUgYWxyZWFkeSBzaG93biB0aGF0IGl0IGlzIGZlYXNpYmxlIGFuZCBhcmUgbm90IG9uIHNwZWNp ZnlpbmcgaG93IHRvIGRvIHRoYXQuIEknbSBjb25jZXJuZWQgYWJvdXQgdGhlIG92ZXJsYXAgYmV0 d2VlbiB3aGF0IHRoYXQgcGFyYWdyYXBoIGRlc2NyaWJlcyBhbmQgb3VyIHdvcmsuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBjb3VsZCBiZSB1c2VmdWwgd29yayBvbiBjb21tdW5pY2F0aW9uIGZyb20gdGhlIHVwcGVyIGxh eWVyIG9mIHRoZSBmbG93IGNoYXJhY3RlcmlzdGljcywgYmVoYXZpb3IgYW5kIHJlcXVpcmVtZW50 cy4gVGhlcmUgcHJvYmFibHkgaXMgc29tZSBnYXAgdG8gZmlsbCB0aGF0IHdvdWxkIGhlbHAgb3Vy IHdvcmsuIEknbSBjb25jZXJuZWQgdGhhdCB0aGUgbGlzdCBkZXNjcmlwdGlvbiBmb2N1c2VzIG9u bHkgb24NCiBleHBvc2luZyBsb3dlciBsYXllciBjaGFyYWN0ZXJpc3RpY3MgdG8gdGhlIHVwcGVy IGxheWVyLiBUaGUgbmV0d29yayBjYW4ndCBwcm92aWRlIGEgYm91bmRlZCBvciBkZXRlcm1pbmlz dGljIGxhdGVuY3kgdG8gYW4gdW5ib3VuZGVkIGZsb3cgLSB0byBkZXRlcm1pbmUgd2hhdCBsYXRl bmN5IGNhbiBiZSBwcm92aWRlZCwgb25lIGhhcyB0byBrbm93IHNvbWV0aGluZyBhYm91dCB0aGUg YmFuZHdpZHRoIHV0aWxpemF0aW9uIG9mIHRoZSBmbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDE5LCAyMDE2 IGF0IDE6NTkgUE0sIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4u bmV0IiB0YXJnZXQ9Il9ibGFuayI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsaWEsPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPdmVybGFwIGxvb2tzIGxpa2VseS4mbmJzcDsgSSBob3Bl IHRoYXQgd2hlbiBpdCBkb2VzIG9jY3VyLCB5b3Ugc2VuZDxicj4NCmZvbGtzIG92ZXIgaGVyZSB0 byBjb250cmlidXRlIC0tIGFkZGl0aW9uYWwgaW5wdXQgLyBXRyBwYXJ0aWNpcGF0aW9uPGJyPg0K d291bGQgYmUgZ3JlYXQhJm5ic3A7IChGb3IgZm9sa3Mgbm90IGZhbWlsaWFyIHdpdGggRGV0TmV0 LCBjaGVjayBvdXQgb3VyPGJyPg0KY2hhcnRlciBhdCA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL3dnL2RldG5ldC9jaGFydGVyLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9kZXRuZXQvY2hhcnRlci88L2E+KTxicj4NCjxicj4N CkkgZXhwZWN0IHdlJ2xsIGhhdmUgc29tZSBnb29kIGRhdGEgcGxhbmUgY2VudHJpYyBkaXNjdXNz aW9ucyBhdCB0aGlzPGJyPg0KbWVldGluZywgZm9yIHRob3NlIHdobyBtYXkgYmUgaW50ZXJlc3Rl ZCAodGhlcmUncyBldmVuIHN0aWxsIHRpbWUgdG88YnI+DQpzdWJtaXQgcmVsYXRlZCBkcmFmdHMh KTxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQpMb3U8YnI+DQo8YnI+DQpEZXROZXQgQ28t Y2hhaXI8YnI+DQo8YnI+DQpPbiAxMC8xOS8yMDE2IDExOjQ2IEFNLCBBbGlhIEF0bGFzIHdyb3Rl Ojxicj4NCiZndDsgSGkgUGF0cmljayw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZGlzY3Vzc2lv biBpbnRlbmRlZCBvbiBkbG5leCwgYSBub24tV0cgbWFpbGluZyBsaXN0LCBpcywgSSB0aGluayw8 YnI+DQomZ3Q7IGJyb2FkZXIgLSBzcGFubmluZyB0aGUgcmFuZ2Ugb2YgY29tbXVuaWNhdGlvbnMg YmV0d2VlbiB1cHBlciBsYXllcjxicj4NCiZndDsgYXBwbGljYXRpb25zIGFuZCB0aGUgbmV0d29y ay4mbmJzcDsgSXQgaXMgbm90IGNsZWFyIHlldCB3aGF0IHdvcmsgbWlnaHQ8YnI+DQomZ3Q7IGRl dmVsb3AuJm5ic3A7IEJlIHN1cmUgdGhhdCBJIHdpbGwgYmUgd2F0Y2hpbmcgZm9yIGFueSBzcGVj aWZpYyBvdmVybGFwPGJyPg0KJmd0OyB3aXRoIERldE5ldC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ IGZlZWwgdGhhdCBpdCBpcyB1c2VmdWwgdG8gbWFrZSBpdCBlYXN5IGZvciBncm91cHMgdG8gaGF2 ZSBhIGxpc3QgdG88YnI+DQomZ3Q7IGJyYWluc3Rvcm0gYWJvdXQgdGhlaXIgaWRlYXMgYmVmb3Jl IHdvcmsgaXMgbWF0dXJlIGVub3VnaCB0byBjb25zaWRlcjxicj4NCiZndDsgZm9yIHN0YW5kYXJk aXphdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgQWxpYTxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFdlZCwgT2N0IDE5LCAyMDE2IGF0IDg6MTcgQU0sIFBhdHJpY2sg V2V0dGVyd2FsZCAocHdldHRlcncpPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB3ZXR0 ZXJ3QGNpc2NvLmNvbSI+cHdldHRlcndAY2lzY28uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpwd2V0dGVyd0BjaXNjby5jb20iPnB3ZXR0ZXJ3QGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FuIHNvbWVv bmUgZXhwbGFpbiBtZSB3aHkgdGhpcyBtYWlsaW5nIGxpc3QgaXMgY3JlYXRlZCBvdXRzaWRlIG9m PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7RGV0TmV0Pzxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIHNvdW5kcyBsaWtlIGEgc3Vic2V0IG9mIERldG5ldCBu bz88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VGhhbmtzLDxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtQYXRyaWNrPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtPbiAxOS8xMC8yMDE2LCAwNzo1NiwgJnF1 b3Q7ZGV0bmV0IG9uIGJlaGFsZiBvZiBQYXNjYWwgVGh1YmVydDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyhwdGh1YmVydCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91 bmNlc0BpZXRmLm9yZyI+ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNA aWV0Zi5vcmciPmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mDQo8 YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+ PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6 PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RnJv bTogSUVURi1Bbm5vdW5jZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlLWJv dW5jZXNAaWV0Zi5vcmciPmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZXRmLWFu bm91bmNlLWJvdW5jZXNAaWV0Zi5vcmciPmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7XSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VudDogbWFyZGkgMTggb2N0b2JyZSAyMDE2IDIyOjM2 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUbzogSUVURiBBbm5v dW5jZW1lbnQgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmci PmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyI+aWV0Zi1h bm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Q2M6IDxhIGhyZWY9Im1haWx0bzptYXR0aGV3LmJvY2NpQG5va2lhLmNv bSI+bWF0dGhldy5ib2NjaUBub2tpYS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om1hdHRoZXcuYm9jY2lAbm9raWEuY29tIj5tYXR0aGV3LmJvY2NpQG5va2lhLmNvbTwvYT4mZ3Q7 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpkbG5leEBpZXRm Lm9yZyI+ZGxuZXhAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRsbmV4 QGlldGYub3JnIj5kbG5leEBpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmxpbmRh LmR1bmJhckBodWF3ZWkuY29tIj5saW5kYS5kdW5iYXJAaHVhd2VpLmNvbTwvYT48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3ViamVjdDogTmV3IE5vbi1XRyBNYWls aW5nIExpc3Q6IERMTkVYIC0tIERpc2N1c3Npb24gb2Y8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtyZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5IGF0dHJpYnV0ZXM8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 QSBuZXcgSUVURiBub24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TGlz dCA8YSBocmVmPSJtYWlsdG86YWRkcmVzcyUzQWRsbmV4QGlldGYub3JnIj5hZGRyZXNzOmRsbmV4 QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGRyZXNzJTI1M0FkbG5l eEBpZXRmLm9yZyI+YWRkcmVzcyUzQWRsbmV4QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FyY2hpdmU6PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3Nl YXJjaC8/ZW1haWxfbGlzdD1kbG5leCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZGxuZXg8L2E+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2Vh cmNoLz9lbWFpbF9saXN0PWRsbmV4IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1kbG5leDwvYT4mZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUbyBzdWJzY3JpYmU6IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGxuZXgiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGxuZXg8L2E+PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGxuZXgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4PC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQdXJwb3NlOjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RExORVggaXMgdG8gZGlzY3VzcyB2YXJpb3Vz IGxhdGVuY3kgY2hhcmFjdGVyaXN0aWNzIHRoYXQgY2FuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7YmUgZXhwb3NlZCBieSBuZXR3b3JrIGVsZW1lbnRzIG9yIHNlZ21lbnRzIGFuZCB0byBl eHBsb3JlIGlmIHRoZXJlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YXJlIGFueSBsYXRl bmN5IHJlbGF0ZWQgYXR0cmlidXRlcyB0aGF0IGNhbiBiZSB1dGlsaXplZCBieSB1cHBlcjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2xheWVyLiBGb3IgZXhhbXBsZSwgY291bGQgdGhlcmUg YmUgbGF0ZW5jeSBleHBvc3VyZSB0aGF0IHVwcGVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7bGF5ZXIgY2FuIHV0aWxpemUgdG8gcGxhbiBob3cgdG8gZGlzdHJpYnV0ZSB0aGVpciBjb250 ZW50IHRvIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3JpZ2h0IGVkZ2VzIHRvIGFj aGlldmUgb3B0aW1hbCB1c2VyIGV4cGVyaWVuY2U/IE9yIHNvbWV0aGluZyB1c2VkPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7YnkgSW50ZXJhY3RpdmUgQVIgY29udHJvbGxlciB0byBvcHRp bWl6ZSB0aGVpciBzZXJ2aWNlcz8gSXMgdGhlcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDthbnkgdmFsdWUgZ2FpbmVkIGJ5IHVwcGVyIGxheWVyIGV4cHJlc3NpbmcgdGhhdCB0aGV5IHdv dWxkIHJhdGhlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2hhdmUgZml4ZWQgbGF0ZW5j eSB0aGFuIGxvc2luZyBwYWNrZXRzPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBkaXNjdXNzaW9uIGlzIHRvIGFuc3dlciBxdWVzdGlvbnMg bGlrZTogYXJlIHRoZXJlIGFueTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2VmZmVjdGl2 ZSBpbnRlcmFjdGlvbi9jb29yZGluYXRpb24gYmV0d2VlbiB1cHBlciBsYXllciBhbmQgbG93ZXI8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtsYXllciB0byBhY2hpZXZlIG1vcmUgZWZmaWNp ZW50IG9wdGltaXphdGlvbiBmb3IgbGF0ZW5jeSBzZW5zaXRpdmU8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtzZXJ2aWNlcz88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRpc2N1c3Npb24gZ3JvdXAgaXMgYWxzbyBhIHBsYWNlIHRv IHNob3djYXNlIHRoZSBzdGF0ZSBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBh cnRzIGluIGxhdGVuY3kgb3B0aW1pemVkIHN3aXRjaGluZyBhcmNoaXRlY3R1cmUgYW5kIGludGVy ZmFjZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2lnbnMsIGFzIHRoZSBmZWFzaWJp bGl0eSBleGVyY2lzZSBmb3IgYWNoaWV2aW5nIHJlbGlhYmxlIGFuZDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO2RldGVybWluaXN0aWMgbGF0ZW5jeSB0aHJvdWdoIGEgbmV0d29yayBlbGVt ZW50IG9yIGEgc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaG9zZSBsYXRl bmN5IGV4cG9zdXJlcyBhcmUgdGhlIGZvdW5kYXRpb24gZm9yIChmdXR1cmUpIGxhdGVuY3k8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvcHRpbWl6ZWQgY29udHJvbCBwbGFuZS48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Rm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YWRtaW5pc3RyYXRvcnMuPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RldG5ldCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rl dG5ldDwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldDwvYT4mZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO2RldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9h PiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRu ZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RldG5ldDwvYT4mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IGRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpk ZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpkZXRuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9y ZyI+ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGV0bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657F5D2FDdfweml501mbb_-- From nobody Thu Oct 20 12:35:49 2016 Return-Path: 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 A847E1296C3 for ; Thu, 20 Oct 2016 12:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 eiyASCK6iHLU for ; Thu, 20 Oct 2016 12:35:45 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 272C21296BD for ; Thu, 20 Oct 2016 12:35:45 -0700 (PDT) Received: (qmail 12948 invoked by uid 0); 20 Oct 2016 19:35:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 20 Oct 2016 19:35:44 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id xvbg1t01B2SSUrH01vbjfl; Thu, 20 Oct 2016 13:35:43 -0600 X-Authority-Analysis: v=2.1 cv=IecUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=CH0kA5CcgfcA:10 a=Q-fNiiVtAAAA:8 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=9qxNCY_qAAAA:8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=fdgzkQ7Ff76vt9hW5PwA:9 a=VC2IY7vq5sI5JajD:21 a=t7iCXiolvrOacOC7:21 a=QEXdDO2ut3YA:10 a=Fp8MccfUoT0GBdDC_Lng:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=A2X48xt2e1hG9NJDz63Y:22 a=w1C3t2QeGrPiZgrLijVG:22 a=02toJ7V-nxh73JlV0Smw: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:Cc:References:To:Subject; bh=l3BSWCE0vV1DKhCOlXb/z4oC3U/+CP0gWJ1zQy6w3Z0=; b=08sTkzOXq6bdOyptDWAo9zbMya Dm+dbMN1f0zP8kg0xt03T2Fzphb07VQDmlOA5cPeEgKo+771e7hQynvpOSZV1rHtKx0nUo1jfCieo h0C19bPNeLJrcULVzAYOlM1k9; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:41139 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bxJ7s-0006Fk-M0; Thu, 20 Oct 2016 13:35:40 -0600 To: Linda Dunbar , Pat Thaler References: <4A95BA014132FF49AE685FAB4B9F17F657F5D2FD@dfweml501-mbb> From: Lou Berger Message-ID: <108fba9d-2879-78b2-4152-95d9c16692dc@labn.net> Date: Thu, 20 Oct 2016 15:35:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F5D2FD@dfweml501-mbb> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: 100.15.85.191 X-Exim-ID: 1bxJ7s-0006Fk-M0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:41139 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "dlnex@ietf.org" , "Patrick Wetterwald \(pwetterw\)" , Alia Atlas , "matthew.bocci@nokia.com" , "detnet@ietf.org" Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:35:48 -0000 Hi Linda, Could you (or anyone on DLNEX) elaborate on the type of documents you're thinking of delivering? In detnet, we've so far been more focused on applications/use cases and data plane options. But we're really looking forward to contributions/drafts on the information that is needed to support the control of deterministic flows. The charter states this as: Data flow information model: This work will identify the information needed for flow establishment and control and be used by reservation protocols and YANG data models. The work will be independent from the protocol(s) used to control the flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). Any drafts/contributions on this topic or willingness to help define these would be great. If there are sufficiently developed ideas, we could probably even find time to discuss in our Seoul session. (Or perhaps just informally, if there aren't.) Thanks, Lou On 10/19/2016 7:09 PM, Linda Dunbar wrote: > > Pat, > > > > What you said is so true: “The network can't provide a bounded or > deterministic latency to an unbounded flow”. > > > > DETNET charter starts with > > The Deterministic Networking (DetNet) Working Group focuses on > deterministic data paths that operate over Layer 2 bridged and Layer 3 > routed segments, where such paths can provide bounds on latency, loss, > and packet delay variation (jitter), and high reliability > > > > If I understand it correctly, DETNET focuses on the enabling > technologies to ensure deterministic latency path across a set of nodes. > > > > E2E low latency services has many issues, such as: > > · There could be “bounded flows” that need low latency services > mixed with other traffic in the network. > > · E2E services may have to go through many hops, links with > some links not supporting DETNET. > > · there could be various protection/re-route mechanisms which > all increase latency. > > · etc > > > > Some problems specific to WAN include how to isolate the various > service traffic, and provide maximum manageability to upper layers. > > > > One company in NANOG asked why not use ICMP to mark the delay along > the path to give upper link, .. > > > > Linda > > > > > > Linda > > > > *From:*Pat Thaler [mailto:pat.thaler@broadcom.com] > *Sent:* Wednesday, October 19, 2016 5:25 PM > *To:* Lou Berger > *Cc:* Alia Atlas ; Patrick Wetterwald (pwetterw) > ; matthew.bocci@nokia.com; Pascal Thubert > (pthubert) ; detnet@ietf.org; dlnex@ietf.org; > Linda Dunbar > *Subject:* Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- > Discussion of reliable and deterministic latency attributes > > > > We have been having recent discussions about latency such as what type > of latency is important. > > > > As far as the "feasibility exercise for achieving reliable and > deterministic latency through a network element or a segment" that > overlaps very much what DetNet and IEEE 802.1 TSN have been doing. I > believe we have already shown that it is feasible and are not on > specifying how to do that. I'm concerned about the overlap between > what that paragraph describes and our work. > > > > There could be useful work on communication from the upper layer of > the flow characteristics, behavior and requirements. There probably is > some gap to fill that would help our work. I'm concerned that the list > description focuses only on exposing lower layer characteristics to > the upper layer. The network can't provide a bounded or deterministic > latency to an unbounded flow - to determine what latency can be > provided, one has to know something about the bandwidth utilization of > the flow. > > > > Regards, > > Pat > > > > On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger > wrote: > > Hi Alia, > > Overlap looks likely. I hope that when it does occur, you send > folks over here to contribute -- additional input / WG participation > would be great! (For folks not familiar with DetNet, check out our > charter at https://datatracker.ietf.org/wg/detnet/charter/ > ) > > I expect we'll have some good data plane centric discussions at this > meeting, for those who may be interested (there's even still time to > submit related drafts!) > > Cheers, > > Lou > > DetNet Co-chair > > On 10/19/2016 11:46 AM, Alia Atlas wrote: > > Hi Patrick, > > > > The discussion intended on dlnex, a non-WG mailing list, is, I > think, > > broader - spanning the range of communications between upper layer > > applications and the network. It is not clear yet what work might > > develop. Be sure that I will be watching for any specific overlap > > with DetNet. > > > > I feel that it is useful to make it easy for groups to have a > list to > > brainstorm about their ideas before work is mature enough to > consider > > for standardization. > > > > Regards, > > Alia > > > > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw) > > > >> wrote: > > > > Can someone explain me why this mailing list is created > outside of > > DetNet? > > > > This sounds like a subset of Detnet no? > > > > Thanks, > > > > Patrick > > > > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert > > (pthubert)" > > > on behalf of pthubert@cisco.com > > > >> wrote: > > > > From: IETF-Announce > [mailto:ietf-announce-bounces@ietf.org > > > >] On Behalf Of IETF > Secretariat > > Sent: mardi 18 octobre 2016 22:36 > > To: IETF Announcement List > > >> > > Cc: matthew.bocci@nokia.com > >; > > dlnex@ietf.org > >; > linda.dunbar@huawei.com > > > > > Subject: New Non-WG Mailing List: DLNEX -- Discussion of > > reliable and deterministic latency attributes > > > > > > A new IETF non-working group email list has been created. > > > > List address:dlnex@ietf.org > > > > Archive: > > https://mailarchive.ietf.org/arch/search/?email_list=dlnex > > > > > To subscribe: > https://www.ietf.org/mailman/listinfo/dlnex > > > > > > > Purpose: > > DLNEX is to discuss various latency characteristics that can > > be exposed by network elements or segments and to explore if > there > > are any latency related attributes that can be utilized by upper > > layer. For example, could there be latency exposure that upper > > layer can utilize to plan how to distribute their content to the > > right edges to achieve optimal user experience? Or something > used > > by Interactive AR controller to optimize their services? Is > there > > any value gained by upper layer expressing that they would > rather > > have fixed latency than losing packets? > > > > The discussion is to answer questions like: are there any > > effective interaction/coordination between upper layer and lower > > layer to achieve more efficient optimization for latency > sensitive > > services? > > > > This discussion group is also a place to showcase the > state of > > the arts in latency optimized switching architecture and > interface > > designs, as the feasibility exercise for achieving reliable and > > deterministic latency through a network element or a segment. > > Those latency exposures are the foundation for (future) latency > > optimized control plane. > > > > > > For additional information, please contact the list > > administrators. > > > > _______________________________________________ > > detnet mailing list > > > detnet@ietf.org > > > > https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > > > https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Oct 20 13:18:42 2016 Return-Path: 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 CB93912964C; Thu, 20 Oct 2016 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 xFPXyGtyuZZX; Thu, 20 Oct 2016 13:18:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CD61294FE; Thu, 20 Oct 2016 13:18:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTN70707; Thu, 20 Oct 2016 20:18:33 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 20 Oct 2016 21:18:32 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 20 Oct 2016 13:18:28 -0700 From: Linda Dunbar To: Lou Berger , Pat Thaler Thread-Topic: Various sources contributing to E2E latency/delay-- Discussion of reliable and deterministic latency attributes Thread-Index: AdIrDxuw2OFXwG9GTJOdZ0wBpv5utA== Date: Thu, 20 Oct 2016 20:18:28 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F5EDD1@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F5EDD1dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5809269A.01D1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e327ce07d40987e69b5ca21500249d1c Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "dlnex@ietf.org" , Bob Briscoe , "Patrick Wetterwald \(pwetterw\)" , Alia Atlas , "matthew.bocci@nokia.com" , "detnet@ietf.org" Subject: [Detnet] Various sources contributing to E2E latency/delay-- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 20:18:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F5EDD1dfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG91LA0KDQpDaGFuZ2UgdGhlIHN1YmplY3QgdG8gbWFrZSB0aGUgZGlzY3Vzc2lvbiBtb3JlIGZv Y3VzZWQuDQoNCkFzIG9mIG5vdywgdGhlIERMTmV4IGlzIHRvIGV4cGxvcmUgd2hhdCBraW5kIG9m IGNoYXJhY3RlcmlzdGljcyBjYW4gYmUgZXhwb3NlZCBieSBuZXR3b3JrLCBvciBjYW4gYmUgaW1w b3NlZCBieSB1cHBlciBsYXllciwgdG8gbWFrZSB0aGUgZGVsYXkvbGF0ZW5jeSBvZiBFMkUgc2Vy dmljZXMgbW9yZSBwcmVkaWN0YWJsZSBvciBtb3JlIG9wdGltYWwuIFRoZSBmaW5hbCB3b3JrIG1h eSBldmVudHVhbGx5IGZhbGwgaW50byBzb21lIGV4aXN0aW5nIElFVEYgV0dzLiBIZXJlLCBJIGFt IGp1c3QgYnJhaW5zdG9ybWluZyBzb21lIHBvdGVudGlhbCBleHBvc3VyZXM6DQoNClRoaXMgcGFw ZXIgIlJlZHVjaW5nIEludGVybmV0IExhdGVuY3k6IEEgU3VydmV5IG9mIFRlY2huaXF1ZXMgYW5k IHRoZWlyIE1lcml0cyIgKGh0dHA6Ly93d3cuYm9iYnJpc2NvZS5uZXQvcHVicy5odG1sI2xhdGVu Y3lfc3VydmV5ICkgbGlzdGVkIG11bHRpcGxlIHNvdXJjZXMgdGhhdCBjb250cmlidXRpbmcgdG8g TGF0ZW5jeS9kZWxheSBmb3IgRTJFIHNlcnZpY2VzOg0KDQogICAgICBUaGUgc291cmNlcyBvZiBk ZWxheSBhcmUgY2xhc3NpZmllZCBpbnRvIGZpdmUgbWFpbiBjYXRlZ29yaWVzOiBzdHJ1Y3R1cmFs IGRlbGF5cywgaW50ZXJhY3Rpb24gYmV0d2VlbiBlbmRwb2ludHMsIGRlbGF5cyBhbG9uZyB0cmFu c21pc3Npb24gcGF0aHMsIGRlbGF5cyByZWxhdGVkIHRvIGxpbmsgY2FwYWNpdGllcywgYW5kIGlu dHJhLWVuZC1ob3N0IGRlbGF5cy4NCg0KICAgICAgU3RydWN0dXJhbCBkZWxheXMgYXJpc2UgZnJv bSB0aGUgc3RydWN0dXJlIG9mIHRoZSBuZXR3b3JrIG9yIHRoZSBjb21tdW5pY2F0aW9uIHBhdGgg dGhhdCBpcyB1c2VkLg0KICAgICAgVGhlIHBhcGVyIHNob3dzIHRoYXQgb25lIEUyRSBzZXJ2aWNl IGNhbiB1c2UgRE5TIG11bHRpcGxlIHRpbWVzLiBUaGVyZWZvcmUsIHdoZXJlIEROUyBpcyBsb2Nh dGVkIGlzIGEgYmlnIGNvbnRyaWJ1dG9yIHRvIHRoZSBvdmVyYWxsIGxhdGVuY3kuIFRoaXMgY291 bGQgYmUgYSBwb3RlbnRpYWwgZXhwb3N1cmUgYnkgdGhlIG5ldHdvcmsuDQoNCiAgICAgIERlbGF5 cyByZXN1bHRpbmcgZnJvbSB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBlbmRwb2ludHMgaW5jbHVk ZSBkZWxheXMgZHVlIHRvIHRyYW5zcG9ydCBpbml0aWFsaXphdGlvbiBhbmQgc2VjdXJlIHNlc3Np b24gaW5pdGlhbGl6YXRpb24sIGFzIHdlbGwgYXMgZGVsYXlzIGZyb20gcmVjb3ZlcmluZyBsb3N0 IHBhY2tldHMgYW5kIGZyb20gbWVzc2FnZS1hZ2dyZWdhdGlvbiB0ZWNobmlxdWVzDQogICAgICBJ cyBpdCBhbm90aGVyIGV4cG9zdXJlPyBJcyB0aGVyZSBzZWN1cmUgY2hhbm5lbCB1c2VkPw0KDQog ICAgICBEZWxheXMgYWxvbmcgdHJhbnNtaXNzaW9uIHBhdGhzIGNhcHR1cmVzIHRoZSBkZWxheXMg dGhhdCBtYXkgYmUgZW5jb3VudGVyZWQgYXMgZGF0YSB0cmF2ZWxzIGJldHdlZW4gYSBzZW5kZXIg YW5kIGEgcmVjZWl2ZXIuDQogICAgICBJZiBzb21lIHNlZ21lbnRzIGFsb25nIHRoZSB0cmFuc21p c3Npb24gcGF0aHMgYXJlIERldE5ldCBlbmFibGVkIG9yIE9JRuKAmXMgRmxleEV0aGVybmV0IGVu YWJsZWQsIHRoaXMgZGVmaW5pdGVseSBzaG91bGQgYmUgZXhwb3NlZC4gVGhlbiB0aGUgdXBwZXIg bGF5ZXIgY2FuIGNvbnRyb2wvcmVzZXJ2ZSB0aGUgcmVzb3VyY2UgYXMgQ0NBTVAgaGFzIGRvbmUg Zm9yIE1QTFMgcGF0aHMgYW5kIG9wdGljYWwgY2hhbm5lbHMuDQoNCiAgICAgIERlbGF5cyByZWxh dGVkIHRvIGxpbmsgY2FwYWNpdGllcyBpbmNsdWRlIGJvdGggZGVsYXlzIHJlc3VsdGluZyBmcm9t IHNoYXJpbmcgbGltaXRlZCBjYXBhY2l0eSBhbmQgZGVsYXlzIGZyb20gcHJvdG9jb2wgaW5lZmZp Y2llbmNpZXMgdGhhdCB1bmRlci11dGlsaXplIGNhcGFjaXR5IGFuZCB0aGVyZWZvcmUgY29tbXVu aWNhdGlvbiB0YWtlcyBsb25nZXIgdGhhbiBuZWNlc3NhcnkuDQogICAgICBJIGFzc3VtZSB0aGlz IGlzIHRoZSB0eXBlIG9mIHdvcmsgdGhhdCBDQ0FNUCBpcyB0byBhZGRyZXNzLg0KDQogICAgICBJ bnRyYS1lbmQtaG9zdCBkZWxheXMgYXJlIGRlbGF5cyB0aGF0IG9jY3VyIGludGVybmFsbHkgd2l0 aGluIGhvc3QgZW5kcG9pbnRzLiBUaGlzIGluY2x1ZGVzIGRlbGF5cyBkdWUgdG8gYnVmZmVyaW5n IGluIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgc3RhY2sgYW5kIGRlbGF5cyB3aXRoaW4gdGhlIG9w ZXJhdGluZyBzeXN0ZW0uDQogICAgICBUaGlzIGlzIHRoZSBlbmQgaG9zdHMgVENQL1VEUCBsYXll ci4NCg0KTGluZGENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJn ZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjAs IDIwMTYgMjozNiBQTQ0KVG86IExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ OyBQYXQgVGhhbGVyIDxwYXQudGhhbGVyQGJyb2FkY29tLmNvbT4NCkNjOiBQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+OyBkbG5leEBpZXRmLm9yZzsgUGF0cmlj ayBXZXR0ZXJ3YWxkIChwd2V0dGVydykgPHB3ZXR0ZXJ3QGNpc2NvLmNvbT47IEFsaWEgQXRsYXMg PGFrYXRsYXNAZ21haWwuY29tPjsgbWF0dGhldy5ib2NjaUBub2tpYS5jb207IGRldG5ldEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtEZXRuZXRdIEZXOiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDog RExORVggLS0gRGlzY3Vzc2lvbiBvZiByZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5 IGF0dHJpYnV0ZXMNCg0KSGkgTGluZGEsDQoNCiAgICBDb3VsZCB5b3UgKG9yIGFueW9uZSBvbiBE TE5FWCkgZWxhYm9yYXRlIG9uIHRoZSB0eXBlIG9mIGRvY3VtZW50cyB5b3UncmUgdGhpbmtpbmcg b2YgZGVsaXZlcmluZz8NCg0KSW4gZGV0bmV0LCB3ZSd2ZSBzbyBmYXIgYmVlbiBtb3JlIGZvY3Vz ZWQgb24gYXBwbGljYXRpb25zL3VzZSBjYXNlcyBhbmQgZGF0YSBwbGFuZSBvcHRpb25zLiAgQnV0 IHdlJ3JlIHJlYWxseSBsb29raW5nIGZvcndhcmQgdG8gY29udHJpYnV0aW9ucy9kcmFmdHMgb24g dGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgbmVlZGVkIHRvIHN1cHBvcnQgdGhlIGNvbnRyb2wgb2Yg ZGV0ZXJtaW5pc3RpYyBmbG93cy4gIFRoZSBjaGFydGVyIHN0YXRlcyB0aGlzIGFzOg0KDQogICAg RGF0YSBmbG93IGluZm9ybWF0aW9uIG1vZGVsOiBUaGlzIHdvcmsgd2lsbCBpZGVudGlmeSB0aGUN CiAgICBpbmZvcm1hdGlvbiBuZWVkZWQgZm9yIGZsb3cgZXN0YWJsaXNobWVudCBhbmQgY29udHJv bCBhbmQgYmUNCiAgICB1c2VkIGJ5IHJlc2VydmF0aW9uIHByb3RvY29scyBhbmQgWUFORyBkYXRh IG1vZGVscy4gVGhlIHdvcmsNCiAgICB3aWxsIGJlIGluZGVwZW5kZW50IGZyb20gdGhlIHByb3Rv Y29sKHMpIHVzZWQgdG8gY29udHJvbCB0aGUNCiAgICBmbG93cyAoZS5nLiBZQU5HK05FVENPTkYv UkVTVENPTkYsIFBDRVAgb3IgR01QTFMpLg0KDQpBbnkgZHJhZnRzL2NvbnRyaWJ1dGlvbnMgb24g dGhpcyB0b3BpYyBvciB3aWxsaW5nbmVzcyB0byBoZWxwIGRlZmluZSB0aGVzZSB3b3VsZCBiZSBn cmVhdC4NCg0KSWYgdGhlcmUgYXJlIHN1ZmZpY2llbnRseSBkZXZlbG9wZWQgaWRlYXMsIHdlIGNv dWxkIHByb2JhYmx5IGV2ZW4gZmluZCB0aW1lIHRvIGRpc2N1c3MgaW4gb3VyIFNlb3VsIHNlc3Np b24uICAoT3IgcGVyaGFwcyBqdXN0IGluZm9ybWFsbHksIGlmIHRoZXJlIGFyZW4ndC4pDQoNClRo YW5rcywNCkxvdQ0KDQpPbiAxMC8xOS8yMDE2IDc6MDkgUE0sIExpbmRhIER1bmJhciB3cm90ZToN Cj4NCj4gUGF0LA0KPg0KPg0KPg0KPiBXaGF0IHlvdSBzYWlkIGlzIHNvIHRydWU6IOKAnFRoZSBu ZXR3b3JrIGNhbid0IHByb3ZpZGUgYSBib3VuZGVkIG9yDQo+IGRldGVybWluaXN0aWMgbGF0ZW5j eSB0byBhbiB1bmJvdW5kZWQgZmxvd+KAnS4NCj4NCj4NCj4NCj4gREVUTkVUIGNoYXJ0ZXIgc3Rh cnRzIHdpdGgNCj4NCj4gVGhlIERldGVybWluaXN0aWMgTmV0d29ya2luZyAoRGV0TmV0KSBXb3Jr aW5nIEdyb3VwIGZvY3VzZXMgb24NCj4gZGV0ZXJtaW5pc3RpYyBkYXRhIHBhdGhzIHRoYXQgb3Bl cmF0ZSBvdmVyIExheWVyIDIgYnJpZGdlZCBhbmQgTGF5ZXIgMw0KPiByb3V0ZWQgc2VnbWVudHMs IHdoZXJlIHN1Y2ggcGF0aHMgY2FuIHByb3ZpZGUgYm91bmRzIG9uIGxhdGVuY3ksIGxvc3MsDQo+ IGFuZCBwYWNrZXQgZGVsYXkgdmFyaWF0aW9uIChqaXR0ZXIpLCBhbmQgaGlnaCByZWxpYWJpbGl0 eQ0KPg0KPg0KPg0KPiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCBERVRORVQgZm9jdXNl cyBvbiB0aGUgZW5hYmxpbmcNCj4gdGVjaG5vbG9naWVzIHRvIGVuc3VyZSBkZXRlcm1pbmlzdGlj IGxhdGVuY3kgcGF0aCBhY3Jvc3MgYSBzZXQgb2Ygbm9kZXMuDQo+DQo+DQo+DQo+IEUyRSBsb3cg bGF0ZW5jeSBzZXJ2aWNlcyBoYXMgbWFueSBpc3N1ZXMsIHN1Y2ggYXM6DQo+DQo+IMK3ICAgICAg ICBUaGVyZSBjb3VsZCBiZSDigJxib3VuZGVkIGZsb3dz4oCdIHRoYXQgbmVlZCBsb3cgbGF0ZW5j eSBzZXJ2aWNlcw0KPiBtaXhlZCB3aXRoIG90aGVyIHRyYWZmaWMgaW4gdGhlIG5ldHdvcmsuDQo+ DQo+IMK3ICAgICAgICBFMkUgc2VydmljZXMgbWF5IGhhdmUgdG8gZ28gdGhyb3VnaCBtYW55IGhv cHMsIGxpbmtzIHdpdGgNCj4gc29tZSBsaW5rcyBub3Qgc3VwcG9ydGluZyBERVRORVQuDQo+DQo+ IMK3ICAgICAgICB0aGVyZSBjb3VsZCBiZSB2YXJpb3VzIHByb3RlY3Rpb24vcmUtcm91dGUgbWVj aGFuaXNtcyB3aGljaA0KPiBhbGwgaW5jcmVhc2UgbGF0ZW5jeS4NCj4NCj4gwrcgICAgICAgIGV0 Yw0KPg0KPg0KPg0KPiBTb21lIHByb2JsZW1zIHNwZWNpZmljIHRvIFdBTiBpbmNsdWRlIGhvdyB0 byBpc29sYXRlIHRoZSB2YXJpb3VzDQo+IHNlcnZpY2UgdHJhZmZpYywgYW5kIHByb3ZpZGUgbWF4 aW11bSBtYW5hZ2VhYmlsaXR5IHRvIHVwcGVyIGxheWVycy4NCj4NCj4NCj4NCj4gT25lIGNvbXBh bnkgaW4gTkFOT0cgYXNrZWQgd2h5IG5vdCB1c2UgSUNNUCB0byBtYXJrIHRoZSBkZWxheSBhbG9u Zw0KPiB0aGUgcGF0aCB0byBnaXZlIHVwcGVyIGxpbmssIC4uDQo+DQo+DQo+DQo+IExpbmRhDQo+ DQo+DQo+DQo+DQo+DQo+IExpbmRhDQo+DQo+DQo+DQo+ICpGcm9tOipQYXQgVGhhbGVyIFttYWls dG86cGF0LnRoYWxlckBicm9hZGNvbS5jb21dDQo+ICpTZW50OiogV2VkbmVzZGF5LCBPY3RvYmVy IDE5LCAyMDE2IDU6MjUgUE0NCj4gKlRvOiogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxt YWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQo+ICpDYzoqIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21h aWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+OyBQYXRyaWNrIFdldHRlcndhbGQgKHB3 ZXR0ZXJ3KQ0KPiA8cHdldHRlcndAY2lzY28uY29tPG1haWx0bzpwd2V0dGVyd0BjaXNjby5jb20+ PjsgbWF0dGhldy5ib2NjaUBub2tpYS5jb208bWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9raWEuY29t PjsgUGFzY2FsIFRodWJlcnQNCj4gKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0 bzpwdGh1YmVydEBjaXNjby5jb20+PjsgZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0 Zi5vcmc+OyBkbG5leEBpZXRmLm9yZzxtYWlsdG86ZGxuZXhAaWV0Zi5vcmc+Ow0KPiBMaW5kYSBE dW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2Vp LmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtEZXRuZXRdIEZXOiBOZXcgTm9uLVdHIE1haWxpbmcg TGlzdDogRExORVggLS0NCj4gRGlzY3Vzc2lvbiBvZiByZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3Rp YyBsYXRlbmN5IGF0dHJpYnV0ZXMNCj4NCj4NCj4NCj4gV2UgaGF2ZSBiZWVuIGhhdmluZyByZWNl bnQgZGlzY3Vzc2lvbnMgYWJvdXQgbGF0ZW5jeSBzdWNoIGFzIHdoYXQgdHlwZQ0KPiBvZiBsYXRl bmN5IGlzIGltcG9ydGFudC4NCj4NCj4NCj4NCj4gQXMgZmFyIGFzIHRoZSAiZmVhc2liaWxpdHkg ZXhlcmNpc2UgZm9yIGFjaGlldmluZyByZWxpYWJsZSBhbmQNCj4gZGV0ZXJtaW5pc3RpYyBsYXRl bmN5IHRocm91Z2ggYSBuZXR3b3JrIGVsZW1lbnQgb3IgYSBzZWdtZW50IiB0aGF0DQo+IG92ZXJs YXBzIHZlcnkgbXVjaCB3aGF0IERldE5ldCBhbmQgSUVFRSA4MDIuMSBUU04gaGF2ZSBiZWVuIGRv aW5nLiBJDQo+IGJlbGlldmUgd2UgaGF2ZSBhbHJlYWR5IHNob3duIHRoYXQgaXQgaXMgZmVhc2li bGUgYW5kIGFyZSBub3Qgb24NCj4gc3BlY2lmeWluZyBob3cgdG8gZG8gdGhhdC4gSSdtIGNvbmNl cm5lZCBhYm91dCB0aGUgb3ZlcmxhcCBiZXR3ZWVuDQo+IHdoYXQgdGhhdCBwYXJhZ3JhcGggZGVz Y3JpYmVzIGFuZCBvdXIgd29yay4NCj4NCj4NCj4NCj4gVGhlcmUgY291bGQgYmUgdXNlZnVsIHdv cmsgb24gY29tbXVuaWNhdGlvbiBmcm9tIHRoZSB1cHBlciBsYXllciBvZg0KPiB0aGUgZmxvdyBj aGFyYWN0ZXJpc3RpY3MsIGJlaGF2aW9yIGFuZCByZXF1aXJlbWVudHMuIFRoZXJlIHByb2JhYmx5 IGlzDQo+IHNvbWUgZ2FwIHRvIGZpbGwgdGhhdCB3b3VsZCBoZWxwIG91ciB3b3JrLiBJJ20gY29u Y2VybmVkIHRoYXQgdGhlIGxpc3QNCj4gZGVzY3JpcHRpb24gZm9jdXNlcyBvbmx5IG9uIGV4cG9z aW5nIGxvd2VyIGxheWVyIGNoYXJhY3RlcmlzdGljcyB0bw0KPiB0aGUgdXBwZXIgbGF5ZXIuIFRo ZSBuZXR3b3JrIGNhbid0IHByb3ZpZGUgYSBib3VuZGVkIG9yIGRldGVybWluaXN0aWMNCj4gbGF0 ZW5jeSB0byBhbiB1bmJvdW5kZWQgZmxvdyAtIHRvIGRldGVybWluZSB3aGF0IGxhdGVuY3kgY2Fu IGJlDQo+IHByb3ZpZGVkLCBvbmUgaGFzIHRvIGtub3cgc29tZXRoaW5nIGFib3V0IHRoZSBiYW5k d2lkdGggdXRpbGl6YXRpb24gb2YNCj4gdGhlIGZsb3cuDQo+DQo+DQo+DQo+IFJlZ2FyZHMsDQo+ DQo+IFBhdA0KPg0KPg0KPg0KPiBPbiBXZWQsIE9jdCAxOSwgMjAxNiBhdCAxOjU5IFBNLCBMb3Ug QmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0DQo+IDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+IHdy b3RlOg0KPg0KPiAgICAgSGkgQWxpYSwNCj4NCj4gICAgICAgICBPdmVybGFwIGxvb2tzIGxpa2Vs eS4gIEkgaG9wZSB0aGF0IHdoZW4gaXQgZG9lcyBvY2N1ciwgeW91IHNlbmQNCj4gICAgIGZvbGtz IG92ZXIgaGVyZSB0byBjb250cmlidXRlIC0tIGFkZGl0aW9uYWwgaW5wdXQgLyBXRyBwYXJ0aWNp cGF0aW9uDQo+ICAgICB3b3VsZCBiZSBncmVhdCEgIChGb3IgZm9sa3Mgbm90IGZhbWlsaWFyIHdp dGggRGV0TmV0LCBjaGVjayBvdXQgb3VyDQo+ICAgICBjaGFydGVyIGF0IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvd2cvZGV0bmV0L2NoYXJ0ZXIvDQo+ICAgICA8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy93Zy9kZXRuZXQvY2hhcnRlci8+KQ0KPg0KPiAgICAgSSBleHBlY3Qgd2Un bGwgaGF2ZSBzb21lIGdvb2QgZGF0YSBwbGFuZSBjZW50cmljIGRpc2N1c3Npb25zIGF0IHRoaXMN Cj4gICAgIG1lZXRpbmcsIGZvciB0aG9zZSB3aG8gbWF5IGJlIGludGVyZXN0ZWQgKHRoZXJlJ3Mg ZXZlbiBzdGlsbCB0aW1lIHRvDQo+ICAgICBzdWJtaXQgcmVsYXRlZCBkcmFmdHMhKQ0KPg0KPiAg ICAgQ2hlZXJzLA0KPg0KPiAgICAgTG91DQo+DQo+ICAgICBEZXROZXQgQ28tY2hhaXINCj4NCj4g ICAgIE9uIDEwLzE5LzIwMTYgMTE6NDYgQU0sIEFsaWEgQXRsYXMgd3JvdGU6DQo+ICAgICA+IEhp IFBhdHJpY2ssDQo+ICAgICA+DQo+ICAgICA+IFRoZSBkaXNjdXNzaW9uIGludGVuZGVkIG9uIGRs bmV4LCBhIG5vbi1XRyBtYWlsaW5nIGxpc3QsIGlzLCBJDQo+ICAgICB0aGluaywNCj4gICAgID4g YnJvYWRlciAtIHNwYW5uaW5nIHRoZSByYW5nZSBvZiBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHVw cGVyIGxheWVyDQo+ICAgICA+IGFwcGxpY2F0aW9ucyBhbmQgdGhlIG5ldHdvcmsuICBJdCBpcyBu b3QgY2xlYXIgeWV0IHdoYXQgd29yayBtaWdodA0KPiAgICAgPiBkZXZlbG9wLiAgQmUgc3VyZSB0 aGF0IEkgd2lsbCBiZSB3YXRjaGluZyBmb3IgYW55IHNwZWNpZmljIG92ZXJsYXANCj4gICAgID4g d2l0aCBEZXROZXQuDQo+ICAgICA+DQo+ICAgICA+IEkgZmVlbCB0aGF0IGl0IGlzIHVzZWZ1bCB0 byBtYWtlIGl0IGVhc3kgZm9yIGdyb3VwcyB0byBoYXZlIGENCj4gICAgIGxpc3QgdG8NCj4gICAg ID4gYnJhaW5zdG9ybSBhYm91dCB0aGVpciBpZGVhcyBiZWZvcmUgd29yayBpcyBtYXR1cmUgZW5v dWdoIHRvDQo+ICAgICBjb25zaWRlcg0KPiAgICAgPiBmb3Igc3RhbmRhcmRpemF0aW9uLg0KPiAg ICAgPg0KPiAgICAgPiBSZWdhcmRzLA0KPiAgICAgPiBBbGlhDQo+ICAgICA+DQo+ICAgICA+IE9u IFdlZCwgT2N0IDE5LCAyMDE2IGF0IDg6MTcgQU0sIFBhdHJpY2sgV2V0dGVyd2FsZCAocHdldHRl cncpDQo+ICAgICA+IDxwd2V0dGVyd0BjaXNjby5jb20gPG1haWx0bzpwd2V0dGVyd0BjaXNjby5j b208bWFpbHRvOnB3ZXR0ZXJ3QGNpc2NvLmNvbSUyMDxtYWlsdG86cHdldHRlcndAY2lzY28uY29t Pj4NCj4gICAgIDxtYWlsdG86cHdldHRlcndAY2lzY28uY29tIDxtYWlsdG86cHdldHRlcndAY2lz Y28uY29tPj4+IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiAgICAgQ2FuIHNvbWVvbmUgZXhwbGFp biBtZSB3aHkgdGhpcyBtYWlsaW5nIGxpc3QgaXMgY3JlYXRlZA0KPiAgICAgb3V0c2lkZSBvZg0K PiAgICAgPiAgICAgRGV0TmV0Pw0KPiAgICAgPg0KPiAgICAgPiAgICAgVGhpcyBzb3VuZHMgbGlr ZSBhIHN1YnNldCBvZiBEZXRuZXQgbm8/DQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGFua3MsDQo+ ICAgICA+DQo+ICAgICA+ICAgICBQYXRyaWNrDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAg ICBPbiAxOS8xMC8yMDE2LCAwNzo1NiwgImRldG5ldCBvbiBiZWhhbGYgb2YgUGFzY2FsIFRodWJl cnQNCj4gICAgID4gICAgIChwdGh1YmVydCkiIDxkZXRuZXQtYm91bmNlc0BpZXRmLm9yZw0KPiAg ICAgPG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgID4gICAgIDxtYWlsdG86 ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgcHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBj aXNjby5jb20+DQo+ICAgICA8bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4NCj4gICAgID4gICAg IDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4+ IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgIEZyb206IElFVEYtQW5ub3VuY2UNCj4g ICAgIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnDQo+ICAgICA8bWFpbHRv OmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgID4gICAgIDxtYWlsdG86aWV0 Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOmlldGYtYW5ub3VuY2Ut Ym91bmNlc0BpZXRmLm9yZz4+XSBPbiBCZWhhbGYgT2YgSUVURg0KPiAgICAgU2VjcmV0YXJpYXQN Cj4gICAgID4gICAgICAgICBTZW50OiBtYXJkaSAxOCBvY3RvYnJlIDIwMTYgMjI6MzYNCj4gICAg ID4gICAgICAgICBUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdCA8aWV0Zi1hbm5vdW5jZUBpZXRm Lm9yZw0KPiAgICAgPG1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnPg0KPiAgICAgPiAgICAg PG1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIDxtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRm Lm9yZz4+Pg0KPiAgICAgPiAgICAgICAgIENjOiBtYXR0aGV3LmJvY2NpQG5va2lhLmNvbTxtYWls dG86bWF0dGhldy5ib2NjaUBub2tpYS5jb20+DQo+ICAgICA8bWFpbHRvOm1hdHRoZXcuYm9jY2lA bm9raWEuY29tPiA8bWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9raWEuY29tDQo+ICAgICA8bWFpbHRv Om1hdHRoZXcuYm9jY2lAbm9raWEuY29tPj47DQo+ICAgICA+ICAgICBkbG5leEBpZXRmLm9yZzxt YWlsdG86ZGxuZXhAaWV0Zi5vcmc+IDxtYWlsdG86ZGxuZXhAaWV0Zi5vcmc+DQo+ICAgICA8bWFp bHRvOmRsbmV4QGlldGYub3JnIDxtYWlsdG86ZGxuZXhAaWV0Zi5vcmc+PjsNCj4gICAgIGxpbmRh LmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4gPG1haWx0 bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4NCj4gICAgID4gICAgIDxtYWlsdG86bGluZGEuZHVu YmFyQGh1YXdlaS5jb20NCj4gICAgIDxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0K PiAgICAgPiAgICAgICAgIFN1YmplY3Q6IE5ldyBOb24tV0cgTWFpbGluZyBMaXN0OiBETE5FWCAt LSBEaXNjdXNzaW9uIG9mDQo+ICAgICA+ICAgICByZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyBs YXRlbmN5IGF0dHJpYnV0ZXMNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgICAgICBBIG5l dyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4gY3JlYXRlZC4NCj4g ICAgID4NCj4gICAgID4gICAgICAgICBMaXN0IGFkZHJlc3M6ZGxuZXhAaWV0Zi5vcmcNCj4gICAg IDxtYWlsdG86YWRkcmVzcyUzQWRsbmV4QGlldGYub3JnPiA8bWFpbHRvOmFkZHJlc3MlM0FkbG5l eEBpZXRmLm9yZw0KPiAgICAgPG1haWx0bzphZGRyZXNzJTI1M0FkbG5leEBpZXRmLm9yZz4+DQo+ ICAgICA+ICAgICAgICAgQXJjaGl2ZToNCj4gICAgID4gICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZGxuZXgNCj4NCj4gICAgID4gICAgIDxo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2VhcmNoLz9lbWFpbF9saXN0PWRsbmV4 Pg0KPiAgICAgPiAgICAgICAgIFRvIHN1YnNjcmliZToNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGxuZXgNCj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RsbmV4Pg0KPiAgICAgPiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGxuZXg+DQo+ICAgICA+DQo+ICAgICA+ICAgICAgICAgUHVycG9z ZToNCj4gICAgID4gICAgICAgICBETE5FWCBpcyB0byBkaXNjdXNzIHZhcmlvdXMgbGF0ZW5jeSBj aGFyYWN0ZXJpc3RpY3MgdGhhdCBjYW4NCj4gICAgID4gICAgIGJlIGV4cG9zZWQgYnkgbmV0d29y ayBlbGVtZW50cyBvciBzZWdtZW50cyBhbmQgdG8gZXhwbG9yZSBpZg0KPiAgICAgdGhlcmUNCj4g ICAgID4gICAgIGFyZSBhbnkgbGF0ZW5jeSByZWxhdGVkIGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUg dXRpbGl6ZWQgYnkgdXBwZXINCj4gICAgID4gICAgIGxheWVyLiBGb3IgZXhhbXBsZSwgY291bGQg dGhlcmUgYmUgbGF0ZW5jeSBleHBvc3VyZSB0aGF0IHVwcGVyDQo+ICAgICA+ICAgICBsYXllciBj YW4gdXRpbGl6ZSB0byBwbGFuIGhvdyB0byBkaXN0cmlidXRlIHRoZWlyIGNvbnRlbnQgdG8gdGhl DQo+ICAgICA+ICAgICByaWdodCBlZGdlcyB0byBhY2hpZXZlIG9wdGltYWwgdXNlciBleHBlcmll bmNlPyBPciBzb21ldGhpbmcNCj4gICAgIHVzZWQNCj4gICAgID4gICAgIGJ5IEludGVyYWN0aXZl IEFSIGNvbnRyb2xsZXIgdG8gb3B0aW1pemUgdGhlaXIgc2VydmljZXM/IElzDQo+ICAgICB0aGVy ZQ0KPiAgICAgPiAgICAgYW55IHZhbHVlIGdhaW5lZCBieSB1cHBlciBsYXllciBleHByZXNzaW5n IHRoYXQgdGhleSB3b3VsZA0KPiAgICAgcmF0aGVyDQo+ICAgICA+ICAgICBoYXZlIGZpeGVkIGxh dGVuY3kgdGhhbiBsb3NpbmcgcGFja2V0cz8NCj4gICAgID4NCj4gICAgID4gICAgICAgICBUaGUg ZGlzY3Vzc2lvbiBpcyB0byBhbnN3ZXIgcXVlc3Rpb25zIGxpa2U6IGFyZSB0aGVyZSBhbnkNCj4g ICAgID4gICAgIGVmZmVjdGl2ZSBpbnRlcmFjdGlvbi9jb29yZGluYXRpb24gYmV0d2VlbiB1cHBl ciBsYXllciBhbmQgbG93ZXINCj4gICAgID4gICAgIGxheWVyIHRvIGFjaGlldmUgbW9yZSBlZmZp Y2llbnQgb3B0aW1pemF0aW9uIGZvciBsYXRlbmN5DQo+ICAgICBzZW5zaXRpdmUNCj4gICAgID4g ICAgIHNlcnZpY2VzPw0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgIFRoaXMgZGlzY3Vzc2lvbiBn cm91cCBpcyBhbHNvIGEgcGxhY2UgdG8gc2hvd2Nhc2UgdGhlDQo+ICAgICBzdGF0ZSBvZg0KPiAg ICAgPiAgICAgdGhlIGFydHMgaW4gbGF0ZW5jeSBvcHRpbWl6ZWQgc3dpdGNoaW5nIGFyY2hpdGVj dHVyZSBhbmQNCj4gICAgIGludGVyZmFjZQ0KPiAgICAgPiAgICAgZGVzaWducywgYXMgdGhlIGZl YXNpYmlsaXR5IGV4ZXJjaXNlIGZvciBhY2hpZXZpbmcgcmVsaWFibGUgYW5kDQo+ICAgICA+ICAg ICBkZXRlcm1pbmlzdGljIGxhdGVuY3kgdGhyb3VnaCBhIG5ldHdvcmsgZWxlbWVudCBvciBhIHNl Z21lbnQuDQo+ICAgICA+ICAgICBUaG9zZSBsYXRlbmN5IGV4cG9zdXJlcyBhcmUgdGhlIGZvdW5k YXRpb24gZm9yIChmdXR1cmUpIGxhdGVuY3kNCj4gICAgID4gICAgIG9wdGltaXplZCBjb250cm9s IHBsYW5lLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgICAgIEZvciBhZGRpdGlvbmFs IGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCB0aGUgbGlzdA0KPiAgICAgPiAgICAgYWRtaW5p c3RyYXRvcnMuDQo+ICAgICA+DQo+ICAgICA+ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4gICAgICAgICBkZXRuZXQgbWFpbGlu ZyBsaXN0DQo+DQo+ICAgICA+ICAgICAgICAgZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRA aWV0Zi5vcmc+IDxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpkZXRuZXRA aWV0Zi5vcmcgPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KPiAgICAgPiAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+ICAgICA+ICAgICA8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ+DQo+ICAgICA+DQo+ICAg ICA+DQo+ICAgICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiAgICAgPiAgICAgZGV0bmV0IG1haWxpbmcgbGlzdA0KPiAgICAgPiAgICAgZGV0 bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+IDxtYWlsdG86ZGV0bmV0QGlldGYu b3JnPg0KPiAgICAgPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmcgPG1haWx0bzpkZXRuZXRAaWV0Zi5v cmc+Pg0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k ZXRuZXQNCj4NCj4gICAgID4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RldG5ldD4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgID4g ZGV0bmV0IG1haWxpbmcgbGlzdA0KPiAgICAgPiBkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5l dEBpZXRmLm9yZz4gPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQo+ICAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+DQo+ICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgZGV0bmV0IG1haWxpbmcg bGlzdA0KPiAgICAgZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+IDxtYWls dG86ZGV0bmV0QGlldGYub3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kZXRuZXQNCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPiBkZXRuZXRA aWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657F5EDD1dfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+TG91LCA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PkNoYW5nZSB0aGUgc3ViamVjdCB0byBtYWtlIHRoZSBkaXNjdXNzaW9uIG1vcmUgZm9j dXNlZC4gPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj5BcyBvZiBub3csIHRoZSBETE5leCBpcyB0byBleHBsb3JlIHdoYXQg a2luZCBvZiBjaGFyYWN0ZXJpc3RpY3MgY2FuIGJlIGV4cG9zZWQgYnkgbmV0d29yaywgb3IgY2Fu IGJlIGltcG9zZWQgYnkgdXBwZXIgbGF5ZXIsIHRvIG1ha2UgdGhlIGRlbGF5L2xhdGVuY3kgb2Yg RTJFIHNlcnZpY2VzIG1vcmUgcHJlZGljdGFibGUgb3IgbW9yZSBvcHRpbWFsLiBUaGUgZmluYWwg d29yayBtYXkgZXZlbnR1YWxseSBmYWxsIGludG8gc29tZSBleGlzdGluZw0KSUVURiBXR3MuIEhl cmUsIEkgYW0ganVzdCBicmFpbnN0b3JtaW5nIHNvbWUgcG90ZW50aWFsIGV4cG9zdXJlczogPC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2 Pg0KPGRpdj5UaGlzIHBhcGVyICZxdW90O1JlZHVjaW5nIEludGVybmV0IExhdGVuY3k6IEEgU3Vy dmV5IG9mIFRlY2huaXF1ZXMgYW5kIHRoZWlyIE1lcml0cyZxdW90OyAoPGEgaHJlZj0iaHR0cDov L3d3dy5ib2JicmlzY29lLm5ldC9wdWJzLmh0bWwjbGF0ZW5jeV9zdXJ2ZXkiPjxmb250IGNvbG9y PSIjMDU2M0MxIj48dT5odHRwOi8vd3d3LmJvYmJyaXNjb2UubmV0L3B1YnMuaHRtbCNsYXRlbmN5 X3N1cnZleTwvdT48L2ZvbnQ+PC9hPiApIGxpc3RlZCBtdWx0aXBsZSBzb3VyY2VzDQp0aGF0IGNv bnRyaWJ1dGluZyB0byBMYXRlbmN5L2RlbGF5IGZvciBFMkUgc2VydmljZXM6IDwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYg c3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+PGZvbnQgY29sb3I9IiMwMDcwQzAiPjxpPlRoZSBz b3VyY2VzIG9mIGRlbGF5PC9pPjxpPiA8L2k+PGk+YXJlIGNsYXNzaWZpZWQgaW50byBmaXZlIG1h aW4gY2F0ZWdvcmllczogc3RydWN0dXJhbCBkZWxheXMsIGludGVyYWN0aW9uPC9pPjxpPiA8L2k+ PGk+YmV0d2VlbiBlbmRwb2ludHMsIGRlbGF5cyBhbG9uZyB0cmFuc21pc3Npb24gcGF0aHMsPC9p PjxpPiA8L2k+PGk+ZGVsYXlzIHJlbGF0ZWQNCnRvIGxpbmsgY2FwYWNpdGllcywgYW5kIGludHJh LWVuZC1ob3N0IGRlbGF5cy48L2k+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PC9hPg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij48Zm9udCBjb2xvcj0iIzAw NzBDMCI+PGk+U3RydWN0dXJhbCBkZWxheXMgYXJpc2UgZnJvbSB0aGUgc3RydWN0dXJlIG9mIHRo ZSBuZXR3b3JrIG9yIHRoZSBjb21tdW5pY2F0aW9uIHBhdGggdGhhdCBpcyB1c2VkLjwvaT48aT4g PC9pPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+VGhlIHBh cGVyIHNob3dzIHRoYXQgb25lIEUyRSBzZXJ2aWNlIGNhbiB1c2UgRE5TIG11bHRpcGxlIHRpbWVz LiBUaGVyZWZvcmUsIHdoZXJlIEROUyBpcyBsb2NhdGVkIGlzIGEgYmlnIGNvbnRyaWJ1dG9yIHRv IHRoZSBvdmVyYWxsIGxhdGVuY3kuIFRoaXMgY291bGQgYmUgYSBwb3RlbnRpYWwgZXhwb3N1cmUg YnkgdGhlIG5ldHdvcmsuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij48Zm9u dCBjb2xvcj0iIzAwNzBDMCI+PGk+RGVsYXlzIHJlc3VsdGluZyBmcm9tIHRoZSBpbnRlcmFjdGlv biBiZXR3ZWVuIGVuZHBvaW50czwvaT48aT4gPC9pPjxpPmluY2x1ZGUgZGVsYXlzIGR1ZSB0byB0 cmFuc3BvcnQgaW5pdGlhbGl6YXRpb24gYW5kIHNlY3VyZTwvaT48aT4gPC9pPjxpPnNlc3Npb24g aW5pdGlhbGl6YXRpb24sIGFzIHdlbGwgYXMgZGVsYXlzIGZyb20gcmVjb3ZlcmluZw0KbG9zdDwv aT48aT4gPC9pPjxpPnBhY2tldHMgYW5kIGZyb20gbWVzc2FnZS1hZ2dyZWdhdGlvbiB0ZWNobmlx dWVzPC9pPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+SXMg aXQgYW5vdGhlciBleHBvc3VyZT8gSXMgdGhlcmUgc2VjdXJlIGNoYW5uZWwgdXNlZD8gPC9kaXY+ DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7 Ij48Zm9udCBjb2xvcj0iIzAwNzBDMCI+PGk+RGVsYXlzIGFsb25nIHRyYW5zbWlzc2lvbiBwYXRo cyBjYXB0dXJlcyB0aGUgZGVsYXlzPC9pPjxpPiA8L2k+PGk+dGhhdCBtYXkgYmUgZW5jb3VudGVy ZWQgYXMgZGF0YSB0cmF2ZWxzIGJldHdlZW4gYSBzZW5kZXIgYW5kPC9pPjxpPiA8L2k+PGk+YSBy ZWNlaXZlci48L2k+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7 Ij5JZiBzb21lIHNlZ21lbnRzIGFsb25nIHRoZSB0cmFuc21pc3Npb24gcGF0aHMgYXJlIERldE5l dCBlbmFibGVkIG9yIE9JRuKAmXMgRmxleEV0aGVybmV0IGVuYWJsZWQsIHRoaXMgZGVmaW5pdGVs eSBzaG91bGQgYmUgZXhwb3NlZC4gVGhlbiB0aGUgdXBwZXIgbGF5ZXIgY2FuIGNvbnRyb2wvcmVz ZXJ2ZSB0aGUgcmVzb3VyY2UgYXMgQ0NBTVAgaGFzIGRvbmUgZm9yIE1QTFMgcGF0aHMgYW5kIG9w dGljYWwNCmNoYW5uZWxzLiA8L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+ PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0iIzAwNzBDMCI+Jm5ic3A7PC9mb250 PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij48Zm9udCBjb2xvcj0iIzAw NzBDMCI+PGk+RGVsYXlzIHJlbGF0ZWQgdG8gbGluayBjYXBhY2l0aWVzIGluY2x1ZGUgYm90aCBk ZWxheXM8L2k+PGk+IDwvaT48aT5yZXN1bHRpbmcgZnJvbSBzaGFyaW5nIGxpbWl0ZWQgY2FwYWNp dHkgYW5kIGRlbGF5cyBmcm9tIHByb3RvY29sPC9pPjxpPiA8L2k+PGk+aW5lZmZpY2llbmNpZXMg dGhhdCB1bmRlci11dGlsaXplIGNhcGFjaXR5IGFuZCB0aGVyZWZvcmU8L2k+PGk+DQo8L2k+PGk+ Y29tbXVuaWNhdGlvbiB0YWtlcyBsb25nZXIgdGhhbiBuZWNlc3NhcnkuPC9pPjwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+SSBhc3N1bWUgdGhpcyBpcyB0aGUg dHlwZSBvZiB3b3JrIHRoYXQgQ0NBTVAgaXMgdG8gYWRkcmVzcy4gPC9kaXY+DQo8ZGl2IHN0eWxl PSJwYWRkaW5nLWxlZnQ6MzZwdDsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9 IiMwMDcwQzAiPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDoz NnB0OyI+PGZvbnQgY29sb3I9IiMwMDcwQzAiPjxpPkludHJhLWVuZC1ob3N0IGRlbGF5czwvaT48 aT4gPC9pPjxpPmFyZSBkZWxheXMgdGhhdCBvY2N1ciBpbnRlcm5hbGx5PC9pPjxpPiA8L2k+PGk+ d2l0aGluIGhvc3QgZW5kcG9pbnRzLiBUaGlzIGluY2x1ZGVzIGRlbGF5cyBkdWUgdG8gYnVmZmVy aW5nPC9pPjxpPiA8L2k+PGk+aW4gdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBzdGFjayBhbmQgZGVs YXlzDQp3aXRoaW4gdGhlIG9wZXJhdGluZzwvaT48aT4gPC9pPjxpPnN5c3RlbS48L2k+PC9mb250 PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij5UaGlzIGlzIHRoZSBlbmQg aG9zdHMgVENQL1VEUCBsYXllci4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5MaW5k YTwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZyb206IExvdSBC ZXJnZXIgWzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5tYWlsdG86bGJlcmdlckBs YWJuLm5ldDwvYT5dIDxicj4NCg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjAsIDIwMTYgMjoz NiBQTTxicj4NCg0KVG86IExpbmRhIER1bmJhciAmbHQ7bGluZGEuZHVuYmFyQGh1YXdlaS5jb20m Z3Q7OyBQYXQgVGhhbGVyICZsdDtwYXQudGhhbGVyQGJyb2FkY29tLmNvbSZndDs8YnI+DQoNCkNj OiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7OyBk bG5leEBpZXRmLm9yZzsgUGF0cmljayBXZXR0ZXJ3YWxkIChwd2V0dGVydykgJmx0O3B3ZXR0ZXJ3 QGNpc2NvLmNvbSZndDs7IEFsaWEgQXRsYXMgJmx0O2FrYXRsYXNAZ21haWwuY29tJmd0OzsgbWF0 dGhldy5ib2NjaUBub2tpYS5jb207IGRldG5ldEBpZXRmLm9yZzxicj4NCg0KU3ViamVjdDogUmU6 IFtEZXRuZXRdIEZXOiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogRExORVggLS0gRGlzY3Vzc2lv biBvZiByZWxpYWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5IGF0dHJpYnV0ZXM8L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2PkhpIExpbmRhLDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvdWxkIHlvdSAob3IgYW55b25lIG9uIERMTkVYKSBlbGFib3JhdGUgb24gdGhlIHR5 cGUgb2YgZG9jdW1lbnRzIHlvdSdyZSB0aGlua2luZyBvZiBkZWxpdmVyaW5nPzwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gZGV0bmV0LCB3ZSd2ZSBzbyBmYXIgYmVlbiBtb3JlIGZv Y3VzZWQgb24gYXBwbGljYXRpb25zL3VzZSBjYXNlcyBhbmQgZGF0YSBwbGFuZSBvcHRpb25zLiZu YnNwOyBCdXQgd2UncmUgcmVhbGx5IGxvb2tpbmcgZm9yd2FyZCB0byBjb250cmlidXRpb25zL2Ry YWZ0cyBvbiB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVkZWQgdG8gc3VwcG9ydCB0aGUgY29u dHJvbCBvZiBkZXRlcm1pbmlzdGljIGZsb3dzLiZuYnNwOyBUaGUgY2hhcnRlciBzdGF0ZXMgdGhp cw0KYXM6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsg RGF0YSBmbG93IGluZm9ybWF0aW9uIG1vZGVsOiBUaGlzIHdvcmsgd2lsbCBpZGVudGlmeSB0aGU8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgZmxv dyBlc3RhYmxpc2htZW50IGFuZCBjb250cm9sIGFuZCBiZTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJz cDsmbmJzcDsgdXNlZCBieSByZXNlcnZhdGlvbiBwcm90b2NvbHMgYW5kIFlBTkcgZGF0YSBtb2Rl bHMuIFRoZSB3b3JrPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyB3aWxsIGJlIGluZGVw ZW5kZW50IGZyb20gdGhlIHByb3RvY29sKHMpIHVzZWQgdG8gY29udHJvbCB0aGU8L2Rpdj4NCjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZsb3dzIChlLmcuIFlBTkcmIzQzO05FVENPTkYvUkVTVENP TkYsIFBDRVAgb3IgR01QTFMpLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QW55IGRy YWZ0cy9jb250cmlidXRpb25zIG9uIHRoaXMgdG9waWMgb3Igd2lsbGluZ25lc3MgdG8gaGVscCBk ZWZpbmUgdGhlc2Ugd291bGQgYmUgZ3JlYXQuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+SWYgdGhlcmUgYXJlIHN1ZmZpY2llbnRseSBkZXZlbG9wZWQgaWRlYXMsIHdlIGNvdWxkIHBy b2JhYmx5IGV2ZW4gZmluZCB0aW1lIHRvIGRpc2N1c3MgaW4gb3VyIFNlb3VsIHNlc3Npb24uJm5i c3A7IChPciBwZXJoYXBzIGp1c3QgaW5mb3JtYWxseSwgaWYgdGhlcmUgYXJlbid0Lik8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+TG91PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PbiAxMC8xOS8yMDE2IDc6MDkgUE0sIExpbmRhIER1bmJh ciB3cm90ZTo8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFBhdCw8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsgV2hhdCB5b3Ugc2FpZCBpcyBzbyB0cnVlOiDigJxUaGUgbmV0d29yayBjYW4ndCBw cm92aWRlIGEgYm91bmRlZCBvciA8L2Rpdj4NCjxkaXY+Jmd0OyBkZXRlcm1pbmlzdGljIGxhdGVu Y3kgdG8gYW4gdW5ib3VuZGVkIGZsb3figJ0uPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IERFVE5FVCBjaGFy dGVyIHN0YXJ0cyB3aXRoPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGUgRGV0 ZXJtaW5pc3RpYyBOZXR3b3JraW5nIChEZXROZXQpIFdvcmtpbmcgR3JvdXAgZm9jdXNlcyBvbiA8 L2Rpdj4NCjxkaXY+Jmd0OyBkZXRlcm1pbmlzdGljIGRhdGEgcGF0aHMgdGhhdCBvcGVyYXRlIG92 ZXIgTGF5ZXIgMiBicmlkZ2VkIGFuZCBMYXllciAzIDwvZGl2Pg0KPGRpdj4mZ3Q7IHJvdXRlZCBz ZWdtZW50cywgd2hlcmUgc3VjaCBwYXRocyBjYW4gcHJvdmlkZSBib3VuZHMgb24gbGF0ZW5jeSwg bG9zcywgPC9kaXY+DQo8ZGl2PiZndDsgYW5kIHBhY2tldCBkZWxheSB2YXJpYXRpb24gKGppdHRl ciksIGFuZCBoaWdoIHJlbGlhYmlsaXR5PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IElmIEkgdW5kZXJzdGFu ZCBpdCBjb3JyZWN0bHksIERFVE5FVCBmb2N1c2VzIG9uIHRoZSBlbmFibGluZyA8L2Rpdj4NCjxk aXY+Jmd0OyB0ZWNobm9sb2dpZXMgdG8gZW5zdXJlIGRldGVybWluaXN0aWMgbGF0ZW5jeSBwYXRo IGFjcm9zcyBhIHNldCBvZiBub2Rlcy48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgRTJFIGxvdyBsYXRlbmN5 IHNlcnZpY2VzIGhhcyBtYW55IGlzc3Vlcywgc3VjaCBhczo8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7IMK3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZXJlIGNvdWxkIGJlIOKAnGJvdW5kZWQgZmxvd3PigJ0gdGhhdCBuZWVkIGxvdyBsYXRlbmN5 IHNlcnZpY2VzPC9kaXY+DQo8ZGl2PiZndDsgbWl4ZWQgd2l0aCBvdGhlciB0cmFmZmljIGluIHRo ZSBuZXR3b3JrLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgwrcmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRTJFIHNlcnZpY2VzIG1heSBoYXZlIHRv IGdvIHRocm91Z2ggbWFueSBob3BzLCBsaW5rcyB3aXRoPC9kaXY+DQo8ZGl2PiZndDsgc29tZSBs aW5rcyBub3Qgc3VwcG9ydGluZyBERVRORVQuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyDCtyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVyZSBj b3VsZCBiZSB2YXJpb3VzIHByb3RlY3Rpb24vcmUtcm91dGUgbWVjaGFuaXNtcyB3aGljaDwvZGl2 Pg0KPGRpdj4mZ3Q7IGFsbCBpbmNyZWFzZSBsYXRlbmN5LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsgwrcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZXRjPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+ Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFNvbWUgcHJvYmxlbXMgc3BlY2lmaWMgdG8gV0FOIGluY2x1 ZGUgaG93IHRvIGlzb2xhdGUgdGhlIHZhcmlvdXMgPC9kaXY+DQo8ZGl2PiZndDsgc2VydmljZSB0 cmFmZmljLCBhbmQgcHJvdmlkZSBtYXhpbXVtIG1hbmFnZWFiaWxpdHkgdG8gdXBwZXIgbGF5ZXJz LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyBPbmUgY29tcGFueSBpbiBOQU5PRyBhc2tlZCB3aHkgbm90IHVz ZSBJQ01QIHRvIG1hcmsgdGhlIGRlbGF5IGFsb25nIDwvZGl2Pg0KPGRpdj4mZ3Q7IHRoZSBwYXRo IHRvIGdpdmUgdXBwZXIgbGluaywgLi48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgTGluZGE8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBMaW5kYTwv ZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyAqRnJvbToqUGF0IFRoYWxlciBbPGEgaHJlZj0ibWFpbHRvOnBhdC50 aGFsZXJAYnJvYWRjb20uY29tIj5tYWlsdG86cGF0LnRoYWxlckBicm9hZGNvbS5jb208L2E+XTwv ZGl2Pg0KPGRpdj4mZ3Q7ICpTZW50OiogV2VkbmVzZGF5LCBPY3RvYmVyIDE5LCAyMDE2IDU6MjUg UE08L2Rpdj4NCjxkaXY+Jmd0OyAqVG86KiBMb3UgQmVyZ2VyICZsdDs8YSBocmVmPSJtYWlsdG86 bGJlcmdlckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsgKkNjOiogQWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29t Ij5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7OyBQYXRyaWNrIFdldHRlcndhbGQgKHB3ZXR0ZXJ3 KSA8L2Rpdj4NCjxkaXY+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB3ZXR0ZXJ3QGNpc2NvLmNv bSI+cHdldHRlcndAY2lzY28uY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzptYXR0aGV3LmJv Y2NpQG5va2lhLmNvbSI+bWF0dGhldy5ib2NjaUBub2tpYS5jb208L2E+OyBQYXNjYWwgVGh1YmVy dDwvZGl2Pg0KPGRpdj4mZ3Q7IChwdGh1YmVydCkgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVy dEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86 ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZGxu ZXhAaWV0Zi5vcmciPmRsbmV4QGlldGYub3JnPC9hPjsgPC9kaXY+DQo8ZGl2PiZndDsgTGluZGEg RHVuYmFyICZsdDs8YSBocmVmPSJtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20iPmxpbmRh LmR1bmJhckBodWF3ZWkuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAqU3ViamVjdDoqIFJl OiBbRGV0bmV0XSBGVzogTmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IERMTkVYIC0tIDwvZGl2Pg0K PGRpdj4mZ3Q7IERpc2N1c3Npb24gb2YgcmVsaWFibGUgYW5kIGRldGVybWluaXN0aWMgbGF0ZW5j eSBhdHRyaWJ1dGVzPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rp dj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFdlIGhhdmUgYmVlbiBoYXZpbmcgcmVjZW50 IGRpc2N1c3Npb25zIGFib3V0IGxhdGVuY3kgc3VjaCBhcyB3aGF0IHR5cGUgPC9kaXY+DQo8ZGl2 PiZndDsgb2YgbGF0ZW5jeSBpcyBpbXBvcnRhbnQuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEFzIGZhciBh cyB0aGUgJnF1b3Q7ZmVhc2liaWxpdHkgZXhlcmNpc2UgZm9yIGFjaGlldmluZyByZWxpYWJsZSBh bmQgPC9kaXY+DQo8ZGl2PiZndDsgZGV0ZXJtaW5pc3RpYyBsYXRlbmN5IHRocm91Z2ggYSBuZXR3 b3JrIGVsZW1lbnQgb3IgYSBzZWdtZW50JnF1b3Q7IHRoYXQgPC9kaXY+DQo8ZGl2PiZndDsgb3Zl cmxhcHMgdmVyeSBtdWNoIHdoYXQgRGV0TmV0IGFuZCBJRUVFIDgwMi4xIFRTTiBoYXZlIGJlZW4g ZG9pbmcuIEkgPC9kaXY+DQo8ZGl2PiZndDsgYmVsaWV2ZSB3ZSBoYXZlIGFscmVhZHkgc2hvd24g dGhhdCBpdCBpcyBmZWFzaWJsZSBhbmQgYXJlIG5vdCBvbiA8L2Rpdj4NCjxkaXY+Jmd0OyBzcGVj aWZ5aW5nIGhvdyB0byBkbyB0aGF0LiBJJ20gY29uY2VybmVkIGFib3V0IHRoZSBvdmVybGFwIGJl dHdlZW4gPC9kaXY+DQo8ZGl2PiZndDsgd2hhdCB0aGF0IHBhcmFncmFwaCBkZXNjcmliZXMgYW5k IG91ciB3b3JrLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+ DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGVyZSBjb3VsZCBiZSB1c2VmdWwgd29yayBv biBjb21tdW5pY2F0aW9uIGZyb20gdGhlIHVwcGVyIGxheWVyIG9mIDwvZGl2Pg0KPGRpdj4mZ3Q7 IHRoZSBmbG93IGNoYXJhY3RlcmlzdGljcywgYmVoYXZpb3IgYW5kIHJlcXVpcmVtZW50cy4gVGhl cmUgcHJvYmFibHkgaXMgPC9kaXY+DQo8ZGl2PiZndDsgc29tZSBnYXAgdG8gZmlsbCB0aGF0IHdv dWxkIGhlbHAgb3VyIHdvcmsuIEknbSBjb25jZXJuZWQgdGhhdCB0aGUgbGlzdCA8L2Rpdj4NCjxk aXY+Jmd0OyBkZXNjcmlwdGlvbiBmb2N1c2VzIG9ubHkgb24gZXhwb3NpbmcgbG93ZXIgbGF5ZXIg Y2hhcmFjdGVyaXN0aWNzIHRvIDwvZGl2Pg0KPGRpdj4mZ3Q7IHRoZSB1cHBlciBsYXllci4gVGhl IG5ldHdvcmsgY2FuJ3QgcHJvdmlkZSBhIGJvdW5kZWQgb3IgZGV0ZXJtaW5pc3RpYyA8L2Rpdj4N CjxkaXY+Jmd0OyBsYXRlbmN5IHRvIGFuIHVuYm91bmRlZCBmbG93IC0gdG8gZGV0ZXJtaW5lIHdo YXQgbGF0ZW5jeSBjYW4gYmUgPC9kaXY+DQo8ZGl2PiZndDsgcHJvdmlkZWQsIG9uZSBoYXMgdG8g a25vdyBzb21ldGhpbmcgYWJvdXQgdGhlIGJhbmR3aWR0aCB1dGlsaXphdGlvbiBvZiA8L2Rpdj4N CjxkaXY+Jmd0OyB0aGUgZmxvdy48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5i c3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgUmVnYXJkcyw8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFBhdDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBPbiBXZWQsIE9j dCAxOSwgMjAxNiBhdCAxOjU5IFBNLCBMb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0IDwv ZGl2Pg0KPGRpdj4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+bWFp bHRvOmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0OyZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIaSBBbGlhLDwvZGl2Pg0K PGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgT3ZlcmxhcCBsb29rcyBsaWtlbHkuJm5ic3A7IEkgaG9wZSB0aGF0 IHdoZW4gaXQgZG9lcyBvY2N1ciwgeW91IHNlbmQ8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBmb2xrcyBvdmVyIGhlcmUgdG8gY29udHJpYnV0ZSAtLSBhZGRpdGlvbmFs IGlucHV0IC8gV0cgcGFydGljaXBhdGlvbjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHdvdWxkIGJlIGdyZWF0ISZuYnNwOyAoRm9yIGZvbGtzIG5vdCBmYW1pbGlhciB3 aXRoIERldE5ldCwgY2hlY2sgb3V0IG91cjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNoYXJ0ZXIgYXQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy93Zy9kZXRuZXQvY2hhcnRlci8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZGV0 bmV0L2NoYXJ0ZXIvPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RldG5ldC9jaGFy dGVyLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9kZXRuZXQvY2hhcnRlci88L2E+ Jmd0Oyk8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgZXhwZWN0IHdlJ2xsIGhhdmUgc29tZSBnb29kIGRhdGEgcGxhbmUgY2VudHJpYyBk aXNjdXNzaW9ucyBhdCB0aGlzPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbWVldGluZywgZm9yIHRob3NlIHdobyBtYXkgYmUgaW50ZXJlc3RlZCAodGhlcmUncyBldmVu IHN0aWxsIHRpbWUgdG88L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz dWJtaXQgcmVsYXRlZCBkcmFmdHMhKTwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hlZXJzLDwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTG91PC9kaXY+DQo8ZGl2PiZndDs8L2Rp dj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEZXROZXQgQ28tY2hhaXI8L2Rp dj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9u IDEwLzE5LzIwMTYgMTE6NDYgQU0sIEFsaWEgQXRsYXMgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBIaSBQYXRyaWNrLDwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IFRoZSBkaXNjdXNzaW9uIGludGVuZGVkIG9uIGRsbmV4LCBhIG5v bi1XRyBtYWlsaW5nIGxpc3QsIGlzLCBJPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGhpbmssPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBicm9hZGVyIC0gc3Bhbm5pbmcgdGhlIHJhbmdlIG9mIGNvbW11bmljYXRpb25zIGJldHdl ZW4gdXBwZXIgbGF5ZXI8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGFwcGxpY2F0aW9ucyBhbmQgdGhlIG5ldHdvcmsuJm5ic3A7IEl0IGlzIG5vdCBjbGVhciB5 ZXQgd2hhdCB3b3JrIG1pZ2h0PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBkZXZlbG9wLiZuYnNwOyBCZSBzdXJlIHRoYXQgSSB3aWxsIGJlIHdhdGNoaW5nIGZv ciBhbnkgc3BlY2lmaWMgb3ZlcmxhcDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgd2l0aCBEZXROZXQuPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgSSBmZWVsIHRoYXQgaXQgaXMgdXNlZnVsIHRvIG1ha2UgaXQgZWFzeSBmb3IgZ3JvdXBzIHRv IGhhdmUgYTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgdG88 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGJyYWluc3Rvcm0g YWJvdXQgdGhlaXIgaWRlYXMgYmVmb3JlIHdvcmsgaXMgbWF0dXJlIGVub3VnaCB0bzwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyPC9kaXY+DQo8ZGl2PiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBmb3Igc3RhbmRhcmRpemF0aW9uLjwvZGl2 Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBBbGlhPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgT24gV2VkLCBPY3QgMTksIDIwMTYgYXQgODoxNyBBTSwgUGF0cmljayBXZXR0 ZXJ3YWxkIChwd2V0dGVydyk8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cHdldHRlcndAY2lzY28uY29tICZsdDttYWlsdG86 cHdldHRlcndAY2lzY28uY29tIj5wd2V0dGVyd0BjaXNjby5jb20gJmx0O21haWx0bzpwd2V0dGVy d0BjaXNjby5jb208L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cHdldHRlcndAY2lzY28uY29tICZsdDttYWlsdG86cHdl dHRlcndAY2lzY28uY29tIj5tYWlsdG86cHdldHRlcndAY2lzY28uY29tICZsdDttYWlsdG86cHdl dHRlcndAY2lzY28uY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYW4gc29tZW9uZSBleHBs YWluIG1lIHdoeSB0aGlzIG1haWxpbmcgbGlzdCBpcyBjcmVhdGVkPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3V0c2lkZSBvZjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGV0TmV0Pzwv ZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoaXMgc291bmRzIGxpa2UgYSBzdWJzZXQgb2YgRGV0bmV0IG5vPzwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8L2Rpdj4N CjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXRy aWNrPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDE5 LzEwLzIwMTYsIDA3OjU2LCAmcXVvdDtkZXRuZXQgb24gYmVoYWxmIG9mIFBhc2NhbCBUaHViZXJ0 PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAocHRodWJlcnQpJnF1b3Q7ICZsdDtkZXRuZXQtYm91bmNlc0BpZXRmLm9y ZzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJt YWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iIj48L2E+bWFpbHRvOmRldG5l dC1ib3VuY2VzQGlldGYub3JnPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRl dG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7IG9uIGJlaGFsZiBvZiA8YSBocmVmPSJt YWlsdG86cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+PC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1 YmVydEBjaXNjby5jb20iPm1haWx0bzpwdGh1YmVydEBjaXNjby5jb208L2E+Jmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20gJmx0O21haWx0bzpw dGh1YmVydEBjaXNjby5jb20iPm1haWx0bzpwdGh1YmVydEBjaXNjby5jb20gJmx0O21haWx0bzpw dGh1YmVydEBjaXNjby5jb208L2E+Jmd0OyZndDsmZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEZyb206IElFVEYtQW5ub3VuY2U8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBbPGEgaHJlZj0iIj48L2E+bWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNl c0BpZXRmLm9yZzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWV0 Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBo cmVmPSIiPjwvYT5tYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm LWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0OyZndDtdIE9uIEJlaGFsZiBPZiBJRVRGPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjcmV0YXJpYXQ8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNlbnQ6IG1hcmRpIDE4IG9jdG9icmUgMjAxNiAyMjozNjwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3Qg Jmx0O2lldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmciPm1h aWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBo cmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyAmbHQ7bWFpbHRvOmlldGYtYW5ub3Vu Y2VAaWV0Zi5vcmciPm1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnICZsdDttYWlsdG86aWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENjOiA8YSBocmVmPSJtYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5j b20iPm1hdHRoZXcuYm9jY2lAbm9raWEuY29tPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5j b20iPm1haWx0bzptYXR0aGV3LmJvY2NpQG5va2lhLmNvbTwvYT4mZ3Q7ICZsdDs8YSBocmVmPSIi PjwvYT5tYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5jb208L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9r aWEuY29tIj5tYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5jb208L2E+Jmd0OyZndDs7PC9kaXY+ DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8YSBocmVmPSJtYWlsdG86ZGxuZXhAaWV0Zi5vcmciPmRsbmV4QGlldGYub3JnPC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRsbmV4QGlldGYub3JnIj5tYWlsdG86ZGxuZXhAaWV0Zi5v cmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8 YSBocmVmPSJtYWlsdG86ZGxuZXhAaWV0Zi5vcmcgJmx0O21haWx0bzpkbG5leEBpZXRmLm9yZyI+ bWFpbHRvOmRsbmV4QGlldGYub3JnICZsdDttYWlsdG86ZGxuZXhAaWV0Zi5vcmc8L2E+Jmd0OyZn dDs7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFp bHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tIj5saW5kYS5kdW5iYXJAaHVhd2VpLmNvbTwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSI+bWFpbHRvOmxpbmRh LmR1bmJhckBodWF3ZWkuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSIiPjwv YT5tYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWku Y29tIj5tYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0OyZndDs8L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IE5ldyBOb24tV0cgTWFpbGluZyBM aXN0OiBETE5FWCAtLSBEaXNjdXNzaW9uIG9mPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWxpYWJsZSBhbmQgZGV0 ZXJtaW5pc3RpYyBsYXRlbmN5IGF0dHJpYnV0ZXM8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBuZXcgSUVURiBu b24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuPC9kaXY+DQo8ZGl2 PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTGlzdCBhZGRyZXNzOmRsbmV4QGlldGYub3JnPC9kaXY+DQo8ZGl2PiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGRyZXNzJTNB ZGxuZXhAaWV0Zi5vcmciPm1haWx0bzphZGRyZXNzJTNBZGxuZXhAaWV0Zi5vcmc8L2E+Jmd0OyAm bHQ7PGEgaHJlZj0iIj48L2E+bWFpbHRvOmFkZHJlc3MlM0FkbG5leEBpZXRmLm9yZzwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRk cmVzcyUyNTNBZGxuZXhAaWV0Zi5vcmciPm1haWx0bzphZGRyZXNzJTI1M0FkbG5leEBpZXRmLm9y ZzwvYT4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJjaGl2 ZTo8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZGxuZXgiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZGxuZXg8L2E+PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4N CjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2Vh cmNoLz9lbWFpbF9saXN0PWRsbmV4Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv c2VhcmNoLz9lbWFpbF9saXN0PWRsbmV4PC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRvIHN1YnNjcmliZTo8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RsbmV4Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4PC9hPjwv ZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4PC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RsbmV4PC9hPiZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBQdXJwb3NlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgRExORVggaXMgdG8gZGlzY3VzcyB2YXJpb3VzIGxhdGVuY3kgY2hhcmFjdGVyaXN0aWNzIHRo YXQgY2FuPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBleHBvc2VkIGJ5IG5ldHdvcmsgZWxlbWVudHMgb3Igc2Vn bWVudHMgYW5kIHRvIGV4cGxvcmUgaWY8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGVyZTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIGFueSBsYXRlbmN5IHJlbGF0ZWQgYXR0cmli dXRlcyB0aGF0IGNhbiBiZSB1dGlsaXplZCBieSB1cHBlcjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGF5ZXIuIEZv ciBleGFtcGxlLCBjb3VsZCB0aGVyZSBiZSBsYXRlbmN5IGV4cG9zdXJlIHRoYXQgdXBwZXI8L2Rp dj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxheWVyIGNhbiB1dGlsaXplIHRvIHBsYW4gaG93IHRvIGRpc3RyaWJ1dGUgdGhl aXIgY29udGVudCB0byB0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJpZ2h0IGVkZ2VzIHRvIGFjaGlldmUgb3B0 aW1hbCB1c2VyIGV4cGVyaWVuY2U/IE9yIHNvbWV0aGluZzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWQ8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IEludGVyYWN0aXZlIEFSIGNv bnRyb2xsZXIgdG8gb3B0aW1pemUgdGhlaXIgc2VydmljZXM/IElzPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlcmU8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFueSB2YWx1ZSBnYWlu ZWQgYnkgdXBwZXIgbGF5ZXIgZXhwcmVzc2luZyB0aGF0IHRoZXkgd291bGQ8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByYXRoZXI8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmUgZml4 ZWQgbGF0ZW5jeSB0aGFuIGxvc2luZyBwYWNrZXRzPzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSBkaXNjdXNzaW9uIGlzIHRvIGFuc3dlciBxdWVzdGlvbnMgbGlrZTogYXJlIHRoZXJlIGFu eTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZWZmZWN0aXZlIGludGVyYWN0aW9uL2Nvb3JkaW5hdGlvbiBiZXR3ZWVu IHVwcGVyIGxheWVyIGFuZCBsb3dlcjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGF5ZXIgdG8gYWNoaWV2ZSBtb3Jl IGVmZmljaWVudCBvcHRpbWl6YXRpb24gZm9yIGxhdGVuY3k8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzZW5zaXRpdmU8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2VzPzwvZGl2 Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZGlzY3Vzc2lvbiBncm91cCBpcyBhbHNvIGEgcGxh Y2UgdG8gc2hvd2Nhc2UgdGhlPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc3RhdGUgb2Y8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhcnRzIGluIGxhdGVuY3kgb3B0aW1pemVkIHN3 aXRjaGluZyBhcmNoaXRlY3R1cmUgYW5kPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaW50ZXJmYWNlPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNpZ25zLCBhcyB0aGUgZmVhc2liaWxp dHkgZXhlcmNpc2UgZm9yIGFjaGlldmluZyByZWxpYWJsZSBhbmQ8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRldGVy bWluaXN0aWMgbGF0ZW5jeSB0aHJvdWdoIGEgbmV0d29yayBlbGVtZW50IG9yIGEgc2VnbWVudC48 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRob3NlIGxhdGVuY3kgZXhwb3N1cmVzIGFyZSB0aGUgZm91bmRhdGlvbiBm b3IgKGZ1dHVyZSkgbGF0ZW5jeTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW1pemVkIGNvbnRyb2wgcGxhbmUu PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFj dCB0aGUgbGlzdDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRtaW5pc3RyYXRvcnMuPC9kaXY+DQo8ZGl2PiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRldG5ldCBtYWlsaW5nIGxpc3Q8 L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+bWFpbHRvOmRldG5ldEBpZXRmLm9yZzwvYT4m Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmcgJmx0O21haWx0bzpkZXRuZXRAaWV0Zi5vcmciPm1haWx0 bzpkZXRuZXRAaWV0Zi5vcmcgJmx0O21haWx0bzpkZXRuZXRAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RldG5ldDwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGV0bmV0IG1haWxpbmcgbGlzdDwvZGl2 Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3Jn PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+bWFpbHRvOmRldG5ldEBp ZXRmLm9yZzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmcgJmx0O21haWx0bzpkZXRuZXRAaWV0 Zi5vcmciPm1haWx0bzpkZXRuZXRAaWV0Zi5vcmcgJmx0O21haWx0bzpkZXRuZXRAaWV0Zi5vcmc8 L2E+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGV0bmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RldG5ldDwvYT48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldDwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGRldG5ldCBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZXRuZXRA aWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRA aWV0Zi5vcmciPm1haWx0bzpkZXRuZXRAaWV0Zi5vcmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGV0bmV0PC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXRu ZXQgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+bWFpbHRvOmRldG5ldEBpZXRmLm9yZzwv YT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7PC9k aXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyBkZXRuZXQgbWFpbGluZyBs aXN0PC9kaXY+DQo8ZGl2PiZndDsgPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0 bmV0QGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RldG5ldDwvYT48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657F5EDD1dfweml501mbb_-- From nobody Thu Oct 20 14:31:42 2016 Return-Path: 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 8EFF5129443 for ; Thu, 20 Oct 2016 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 i2xxYuqwsLnT for ; Thu, 20 Oct 2016 14:31:38 -0700 (PDT) Received: from know-smtprelay-omc-11.server.virginmedia.net (know-smtprelay-omc-11.server.virginmedia.net [80.0.253.75]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB512945E for ; Thu, 20 Oct 2016 14:31:36 -0700 (PDT) Received: from [192.168.4.60] ([82.21.85.55]) by know-smtprelay-11-imp with bizsmtp id xxXa1t00k1BdnUJ01xXanU; Thu, 20 Oct 2016 22:31:34 +0100 X-Originating-IP: [82.21.85.55] X-Spam: 0 X-Authority: v=2.1 cv=e9z7Mvd/ c=1 sm=1 tr=0 a=JBiNpTwF/IB2dYUHhn0UHw==:117 a=JBiNpTwF/IB2dYUHhn0UHw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=le6d79QuAAAA:8 a=ZYOxkDpqAAAA:8 a=AgGRapqp4q260cWlsjkA:9 a=zQQe70veJ2LvxRBk:21 a=g6JhX6RwtbeXgPpY:21 a=pILNOxqGKmIA:10 a=qww3Fqun1X0A:10 a=8e6UPD3b6gFGu7cK:21 a=vPiZbr6FtOuDgSY9:21 a=wVo0evA9Me-cF8b5:21 a=_W_S_7VecoQA:10 a=QbAMNLWdp4a7deKPGBBn:22 a=DSX8VK-MHXYh3DGVmxOZ:22 From: John Grant Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-433-475687960 Date: Thu, 20 Oct 2016 22:31:34 +0100 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F5EDD1@dfweml501-mbb> To: detnet@ietf.org References: <4A95BA014132FF49AE685FAB4B9F17F657F5EDD1@dfweml501-mbb> Message-Id: <4ACC8DD4-3B69-40EA-BC92-7C1C1C51A39F@ninetiles.com> X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [Detnet] Various sources contributing to E2E latency/delay-- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:31:40 -0000 --Apple-Mail-433-475687960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 As I understand it, DetNet is mostly concerned with the latency of = continuous media, e.g. the round trip delay in an audio conversation or = a control loop. However, most of the items in this list refer to the time to respond to = an event of which there is no forewarning, e.g. the time between = clicking on a link and seeing the new page, for which the DetNet = synchronous or asynchronous services are unlikely to be of much help. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com On 20 Oct 2016, at 21:18, Linda Dunbar wrote: > Lou, > =20 > Change the subject to make the discussion more focused. > =20 > As of now, the DLNex is to explore what kind of characteristics can be = exposed by network, or can be imposed by upper layer, to make the = delay/latency of E2E services more predictable or more optimal. The = final work may eventually fall into some existing IETF WGs. Here, I am = just brainstorming some potential exposures: > =20 > This paper "Reducing Internet Latency: A Survey of Techniques and = their Merits" (http://www.bobbriscoe.net/pubs.html#latency_survey ) = listed multiple sources that contributing to Latency/delay for E2E = services: > =20 > The sources of delay are classified into five main categories: = structural delays, interaction between endpoints, delays along = transmission paths, delays related to link capacities, and = intra-end-host delays. > =20 > Structural delays arise from the structure of the network or the = communication path that is used. > The paper shows that one E2E service can use DNS multiple times. = Therefore, where DNS is located is a big contributor to the overall = latency. This could be a potential exposure by the network. > =20 > Delays resulting from the interaction between endpoints include delays = due to transport initialization and secure session initialization, as = well as delays from recovering lost packets and from message-aggregation = techniques > Is it another exposure? Is there secure channel used? > =20 > Delays along transmission paths captures the delays that may be = encountered as data travels between a sender and a receiver. > If some segments along the transmission paths are DetNet enabled or = OIF=92s FlexEthernet enabled, this definitely should be exposed. Then = the upper layer can control/reserve the resource as CCAMP has done for = MPLS paths and optical channels. > =20 > Delays related to link capacities include both delays resulting from = sharing limited capacity and delays from protocol inefficiencies that = under-utilize capacity and therefore communication takes longer than = necessary. > I assume this is the type of work that CCAMP is to address. > =20 > Intra-end-host delays are delays that occur internally within host = endpoints. This includes delays due to buffering in the transport = protocol stack and delays within the operating system. > This is the end hosts TCP/UDP layer. > =20 > Linda --Apple-Mail-433-475687960 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
John Grant
Nine Tiles, = Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 20 Oct 2016, at 21:18, = Linda Dunbar wrote:

Lou,
Change the subject = to make the discussion more focused.
 
As of now, the DLNex is to explore = what kind of characteristics can be exposed by network, or can be = imposed by upper layer, to make the delay/latency of E2E services more = predictable or more optimal. The final work may eventually fall into = some existing IETF WGs. Here, I am just brainstorming some potential = exposures:
 
This paper "Reducing Internet Latency: A Survey of = Techniques and their Merits" (http://www.bobbriscoe.net/pubs.html#latency_survey ) listed = multiple sources that contributing to Latency/delay for E2E = services:
 
The sources of = delay are = classified into five main categories: structural delays, = interaction between endpoints, = delays along transmission paths, delays related to = link capacities, and intra-end-host delays.
 
Structural delays arise from the structure of the = network or the communication path that is = used.
The paper shows that one E2E service can use DNS = multiple times. Therefore, where DNS is located is a big contributor to = the overall latency. This could be a potential exposure by the = network.
 
Delays resulting from = the interaction between endpoints include delays due = to transport initialization and secure session = initialization, as well as delays from recovering lost packets and from = message-aggregation techniques
Is it another exposure? Is there secure = channel used?
 
Delays along transmission paths captures the = delays that may be = encountered as data travels between a sender and a = receiver.
If some segments along the transmission paths are = DetNet enabled or OIF=92s FlexEthernet enabled, this definitely should = be exposed. Then the upper layer can control/reserve the resource as = CCAMP has done for MPLS paths and optical channels.
 
Delays related to link capacities include both = delays resulting from = sharing limited capacity and delays from protocol inefficiencies that = under-utilize capacity and therefore communication takes = longer than necessary.
I assume this is the type of work that = CCAMP is to address.
 
Intra-end-host= delays are delays that = occur internally within host = endpoints. This includes delays due to buffering in the transport = protocol stack and delays within the operating system.
This is = the end hosts TCP/UDP layer.
, "Pascal Thubert (pthubert)" , "detnet@ietf.org" , "matthew.bocci@nokia.com" , "dlnex@ietf.org" , "linda.dunbar@huawei.com" References: From: Lou Berger Message-ID: <55059a4b-4694-a423-5abd-7848a85518f8@labn.net> Date: Fri, 21 Oct 2016 12:13:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 100.15.85.191 X-Exim-ID: 1bxcRf-0004cB-R5 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:43166 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Detnet] Use cases (was: Re: FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 16:13:44 -0000 It would be good to hear from the DLNEX folks on if there are applications use cases that we missed or don't cover, see https://tools.ietf.org/html/draft-ietf-detnet-use-case This may help determine the relationship of DLNEX is overlapping or not... Lou On 10/19/2016 8:17 AM, Patrick Wetterwald (pwetterw) wrote: > Can someone explain me why this mailing list is created outside of DetNet? > > This sounds like a subset of Detnet no? > > Thanks, > > Patrick > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert (pthubert)" wrote: > > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: mardi 18 octobre 2016 22:36 > To: IETF Announcement List > Cc: matthew.bocci@nokia.com; dlnex@ietf.org; linda.dunbar@huawei.com > Subject: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes > > > A new IETF non-working group email list has been created. > > List address:dlnex@ietf.org > Archive: https://mailarchive.ietf.org/arch/search/?email_list=dlnex > To subscribe: https://www.ietf.org/mailman/listinfo/dlnex > > Purpose: > DLNEX is to discuss various latency characteristics that can be exposed by network elements or segments and to explore if there are any latency related attributes that can be utilized by upper layer. For example, could there be latency exposure that upper layer can utilize to plan how to distribute their content to the right edges to achieve optimal user experience? Or something used by Interactive AR controller to optimize their services? Is there any value gained by upper layer expressing that they would rather have fixed latency than losing packets? > > The discussion is to answer questions like: are there any effective interaction/coordination between upper layer and lower layer to achieve more efficient optimization for latency sensitive services? > > This discussion group is also a place to showcase the state of the arts in latency optimized switching architecture and interface designs, as the feasibility exercise for achieving reliable and deterministic latency through a network element or a segment. Those latency exposures are the foundation for (future) latency optimized control plane. > > > For additional information, please contact the list administrators. > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Fri Oct 21 16:29:42 2016 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C51296CC; Fri, 21 Oct 2016 16:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208330.28214.5472891453898967645.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:23 -0700 Archived-At: Cc: detnet@ietf.org, db3546@att.com Subject: [Detnet] detnet - Requested session has been scheduled for IETF 97 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:26 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. detnet Session 1 (2:00:00) Tuesday, Morning Session I 0930-1200 Room Name: Park Ballroom 1 size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmm dime pce teas ccamp netmod mpls l4s Second Priority: rtgwg bier 6tisch nvo3 tsvwg pals bess Third Priority: aqm Special Requests: 3rd priority also avoid Monday. Pat is coming from IEEE 802 in San Antonio. Flight delays could push her arrival to Monday. --------------------------------------------------------- From nobody Mon Oct 24 07:39:37 2016 Return-Path: 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 520A7129856 for ; Mon, 24 Oct 2016 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 HWZdb3UqTMEM for ; Mon, 24 Oct 2016 07:39:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A3C129854 for ; Mon, 24 Oct 2016 07:39:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id r16so100393363pfg.1 for ; Mon, 24 Oct 2016 07:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=hXAVEET2klheWu+iCvxLU849Q1CR+fr5Po6k5fpgDNA=; b=FwapVuxbT3Ou/wT5Wi9MnKs5Yx7ymzC0+C1zkJJS+ARLIVC6CXp5BAc/RYfF8eEZyo 5ud2cmzSBi4bEAGWWStwpvmxxREa1sBlB5jIpykBw++brklstpHdVmQo0cNpJEDPfGFy scYeXg3291E+epLIDPH4d/WmPuJ2bYBu7a/zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=hXAVEET2klheWu+iCvxLU849Q1CR+fr5Po6k5fpgDNA=; b=WTmc5e2ntr/uDP2VsKqw4mP9wHyuY0kBoqvWuGCBFkJ7WiH5HD7t3YTyCwG6/YyvOO JWxqrzJkC4ZOTvYEHiph2rFWhbJxhe2AeuyHr5nUCUem5QY0UgnzAncYXeggo+qY3QZJ +3nUhof5Ae0KQK2846zmqCYLUOjDv8+IeUqr5FBgh0CKT7rrbLYtk+ekZRm6QYjFQm8S 94dg8TzV4dI03L55dn+H+c6D6JqEkuKvnOBtZ6fXPyG5Uns7voQSv0jAjq8lkOA1+ihW tW0xrTK2TbOFbMXfuFYGSunNG3P1b3rmI65JxDizAhJ/EYrCP9vRHrs5gZQZYkgQdrnX 1H9w== X-Gm-Message-State: ABUngvfqbfPr/8mImPCmxsV4ETqmwgt/9Bw8PAc/OPSmp69JY0abCK5sTy1jVg56WT6NsI7t X-Received: by 10.98.156.7 with SMTP id f7mr29637394pfe.134.1477319973887; Mon, 24 Oct 2016 07:39:33 -0700 (PDT) Received: from ?IPv6:2601:647:4200:e520:a4be:4634:75db:6111? ([2601:647:4200:e520:a4be:4634:75db:6111]) by smtp.gmail.com with ESMTPSA id 73sm26070337pfn.45.2016.10.24.07.39.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 24 Oct 2016 07:39:33 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2016 07:39:32 -0700 Message-Id: To: detnet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jouni Korhonen , detnet-chairs@ietf.org Subject: [Detnet] Agenda requests for IETF97 in Seoul X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:39:36 -0000 Folks, The final agenda was published last Friday, see = https://datatracker.ietf.org/meeting/97/agenda.html. DetNet WG is on air = 9:30-12:00 Tuesday, November 15, 2016 in Park Ballroom 1. If you'd like to have a presentation slot in Seoul, please send a = request to the chairs and me by Friday October 28th. Also pay attention = to the important dates listed below. Specifically, the document = submission deadline is on Monday UTC 23:59 on October 31st. When = requesting a slot having a draft that has alrady been seen and discussed = on the list is highly encouraged. Any WG draft not being discussed/presented needs to a status update sent = to the list by Friday November 11th. Please also provide a summary slide = by Sunday, November 13th. We'll need all slides for presentations by Sunday, November 13th. The = earlier, the better, though. Cheers, Jouni, Lou & Pat =3D=3D=3D=3D=3D> Important dates <=3D=3D=3D=3D=3D * 2016-10-31 (Monday): Internet Draft submission cut-off (for all = drafts, including -00) by UTC 23:59, upload usingIETF ID Submission = Tool. * 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. * 2016-11-04 (Friday): Early Bird registration and payment cut-off at = UTC 23:59. * 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. * 2016-11-07 (Monday): Registration cancellation cut-off at UTC 23:59.=20= * 2016-11-11 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local meeting time. * 2016-11-13 - 2016-11-18: IETF 97 in Seoul, South Korea= From nobody Thu Oct 27 09:39:58 2016 Return-Path: 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 D85A51294CA; Thu, 27 Oct 2016 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 UnZil-8Y5aFp; Thu, 27 Oct 2016 09:39:47 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 62DBF129575; Thu, 27 Oct 2016 09:39:46 -0700 (PDT) Received: from 213.6.208.46.dyn.plus.net ([46.208.6.213]:51117 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bzniR-00062H-Ev; Thu, 27 Oct 2016 17:39:44 +0100 To: Linda Dunbar , Lou Berger , Pat Thaler References: <4A95BA014132FF49AE685FAB4B9F17F657F5EDD1@dfweml501-mbb> From: Bob Briscoe Message-ID: Date: Thu, 27 Oct 2016 17:39:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F5EDD1@dfweml501-mbb> Content-Type: multipart/alternative; boundary="------------0094B4F07805FC552BE9680E" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "dlnex@ietf.org" , "Patrick Wetterwald \(pwetterw\)" , Alia Atlas , "matthew.bocci@nokia.com" , "detnet@ietf.org" Subject: Re: [Detnet] Various sources contributing to E2E latency/delay-- Discussion of reliable and deterministic latency attributes X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 16:39:52 -0000 This is a multi-part message in MIME format. --------------0094B4F07805FC552BE9680E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Linda, Probably the most useful part of that paper (other than saving you reading over 300 references) is Chapter IX. It attempts to select some of the most interesting approaches, and to quantify how much of the overall latency (in selected scenarios) they remove. Both as text, and as a visualization of their relative merits (mean and variance) in some nice (deliberately approximate) bubble diagrams, using the colour coding of the categories Linda outlined below. Bob On 20/10/16 21:18, Linda Dunbar wrote: > Lou, > Change the subject to make the discussion more focused. > As of now, the DLNex is to explore what kind of characteristics can be > exposed by network, or can be imposed by upper layer, to make the > delay/latency of E2E services more predictable or more optimal. The > final work may eventually fall into some existing IETF WGs. Here, I am > just brainstorming some potential exposures: > This paper "Reducing Internet Latency: A Survey of Techniques and > their Merits" (_http://www.bobbriscoe.net/pubs.html#latency_survey_ ) > listed multiple sources that contributing to Latency/delay for E2E > services: > /The sources of delay////are classified into five main categories: > structural delays, interaction////between endpoints, delays along > transmission paths,////delays related to link capacities, and > intra-end-host delays./ > /Structural delays arise from the structure of the network or the > communication path that is used./// > The paper shows that one E2E service can use DNS multiple times. > Therefore, where DNS is located is a big contributor to the overall > latency. This could be a potential exposure by the network. > /Delays resulting from the interaction between endpoints////include > delays due to transport initialization and secure////session > initialization, as well as delays from recovering lost////packets and > from message-aggregation techniques/ > Is it another exposure? Is there secure channel used? > /Delays along transmission paths captures the delays////that may be > encountered as data travels between a sender and////a receiver./ > If some segments along the transmission paths are DetNet enabled or > OIF’s FlexEthernet enabled, this definitely should be exposed. Then > the upper layer can control/reserve the resource as CCAMP has done for > MPLS paths and optical channels. > /Delays related to link capacities include both delays////resulting > from sharing limited capacity and delays from > protocol////inefficiencies that under-utilize capacity and > therefore////communication takes longer than necessary./ > I assume this is the type of work that CCAMP is to address. > /Intra-end-host delays////are delays that occur internally////within > host endpoints. This includes delays due to buffering////in the > transport protocol stack and delays within the operating////system./ > This is the end hosts TCP/UDP layer. > Linda > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, October 20, 2016 2:36 PM > To: Linda Dunbar ; Pat Thaler > > Cc: Pascal Thubert (pthubert) ; dlnex@ietf.org; > Patrick Wetterwald (pwetterw) ; Alia Atlas > ; matthew.bocci@nokia.com; detnet@ietf.org > Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion > of reliable and deterministic latency attributes > Hi Linda, > Could you (or anyone on DLNEX) elaborate on the type of documents > you're thinking of delivering? > In detnet, we've so far been more focused on applications/use cases > and data plane options. But we're really looking forward to > contributions/drafts on the information that is needed to support the > control of deterministic flows. The charter states this as: > Data flow information model: This work will identify the > information needed for flow establishment and control and be > used by reservation protocols and YANG data models. The work > will be independent from the protocol(s) used to control the > flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). > Any drafts/contributions on this topic or willingness to help define > these would be great. > If there are sufficiently developed ideas, we could probably even find > time to discuss in our Seoul session. (Or perhaps just informally, if > there aren't.) > Thanks, > Lou > On 10/19/2016 7:09 PM, Linda Dunbar wrote: > > > > Pat, > > > > > > > > What you said is so true: “The network can't provide a bounded or > > deterministic latency to an unbounded flow”. > > > > > > > > DETNET charter starts with > > > > The Deterministic Networking (DetNet) Working Group focuses on > > deterministic data paths that operate over Layer 2 bridged and Layer 3 > > routed segments, where such paths can provide bounds on latency, loss, > > and packet delay variation (jitter), and high reliability > > > > > > > > If I understand it correctly, DETNET focuses on the enabling > > technologies to ensure deterministic latency path across a set of nodes. > > > > > > > > E2E low latency services has many issues, such as: > > > > · There could be “bounded flows” that need low latency services > > mixed with other traffic in the network. > > > > · E2E services may have to go through many hops, links with > > some links not supporting DETNET. > > > > · there could be various protection/re-route mechanisms which > > all increase latency. > > > > · etc > > > > > > > > Some problems specific to WAN include how to isolate the various > > service traffic, and provide maximum manageability to upper layers. > > > > > > > > One company in NANOG asked why not use ICMP to mark the delay along > > the path to give upper link, .. > > > > > > > > Linda > > > > > > > > > > > > Linda > > > > > > > > *From:*Pat Thaler [mailto:pat.thaler@broadcom.com] > > *Sent:* Wednesday, October 19, 2016 5:25 PM > > *To:* Lou Berger > > > *Cc:* Alia Atlas >; Patrick Wetterwald > (pwetterw) > > >; > matthew.bocci@nokia.com ; Pascal Thubert > > (pthubert) >; detnet@ietf.org > ; dlnex@ietf.org ; > > Linda Dunbar > > > *Subject:* Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- > > Discussion of reliable and deterministic latency attributes > > > > > > > > We have been having recent discussions about latency such as what type > > of latency is important. > > > > > > > > As far as the "feasibility exercise for achieving reliable and > > deterministic latency through a network element or a segment" that > > overlaps very much what DetNet and IEEE 802.1 TSN have been doing. I > > believe we have already shown that it is feasible and are not on > > specifying how to do that. I'm concerned about the overlap between > > what that paragraph describes and our work. > > > > > > > > There could be useful work on communication from the upper layer of > > the flow characteristics, behavior and requirements. There probably is > > some gap to fill that would help our work. I'm concerned that the list > > description focuses only on exposing lower layer characteristics to > > the upper layer. The network can't provide a bounded or deterministic > > latency to an unbounded flow - to determine what latency can be > > provided, one has to know something about the bandwidth utilization of > > the flow. > > > > > > > > Regards, > > > > Pat > > > > > > > > On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger > > wrote: > > > > Hi Alia, > > > > Overlap looks likely. I hope that when it does occur, you send > > folks over here to contribute -- additional input / WG participation > > would be great! (For folks not familiar with DetNet, check out our > > charter athttps://datatracker.ietf.org/wg/detnet/charter/ > > ) > > > > I expect we'll have some good data plane centric discussions at this > > meeting, for those who may be interested (there's even still time to > > submit related drafts!) > > > > Cheers, > > > > Lou > > > > DetNet Co-chair > > > > On 10/19/2016 11:46 AM, Alia Atlas wrote: > > > Hi Patrick, > > > > > > The discussion intended on dlnex, a non-WG mailing list, is, I > > think, > > > broader - spanning the range of communications between upper layer > > > applications and the network. It is not clear yet what work might > > > develop. Be sure that I will be watching for any specific overlap > > > with DetNet. > > > > > > I feel that it is useful to make it easy for groups to have a > > list to > > > brainstorm about their ideas before work is mature enough to > > consider > > > for standardization. > > > > > > Regards, > > > Alia > > > > > > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw) > > > > > > >>> wrote: > > > > > > Can someone explain me why this mailing list is created > > outside of > > > DetNet? > > > > > > This sounds like a subset of Detnet no? > > > > > > Thanks, > > > > > > Patrick > > > > > > > > > On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert > > > (pthubert)" > > > > > > on behalf of pthubert@cisco.com > > > > > > >>> wrote: > > > > > > From: IETF-Announce > > [mailto:ietf-announce-bounces@ietf.org > > > > > > >] On Behalf Of IETF > > Secretariat > > > Sent: mardi 18 octobre 2016 22:36 > > > To: IETF Announcement List > > > > >>> > > > Cc:matthew.bocci@nokia.com > > > >; > > >dlnex@ietf.org > > >>; > >linda.dunbar@huawei.com > > > > > > > > > Subject: New Non-WG Mailing List: DLNEX -- Discussion of > > > reliable and deterministic latency attributes > > > > > > > > > A new IETF non-working group email list has been created. > > > > > > List address:dlnex@ietf.org > > > > > > > Archive: > > >https://mailarchive.ietf.org/arch/search/?email_list=dlnex > > > > > > > > To subscribe: > >https://www.ietf.org/mailman/listinfo/dlnex > > > > > > > > > > > Purpose: > > > DLNEX is to discuss various latency characteristics that can > > > be exposed by network elements or segments and to explore if > > there > > > are any latency related attributes that can be utilized by upper > > > layer. For example, could there be latency exposure that upper > > > layer can utilize to plan how to distribute their content to the > > > right edges to achieve optimal user experience? Or something > > used > > > by Interactive AR controller to optimize their services? Is > > there > > > any value gained by upper layer expressing that they would > > rather > > > have fixed latency than losing packets? > > > > > > The discussion is to answer questions like: are there any > > > effective interaction/coordination between upper layer and lower > > > layer to achieve more efficient optimization for latency > > sensitive > > > services? > > > > > > This discussion group is also a place to showcase the > > state of > > > the arts in latency optimized switching architecture and > > interface > > > designs, as the feasibility exercise for achieving reliable and > > > deterministic latency through a network element or a segment. > > > Those latency exposures are the foundation for (future) latency > > > optimized control plane. > > > > > > > > > For additional information, please contact the list > > > administrators. > > > > > >_______________________________________________ > > > detnet mailing list > > > > >detnet@ietf.org > > >> > > >https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > > > > >_______________________________________________ > > > detnet mailing list > > >detnet@ietf.org > > >> > > >https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > detnet mailing list > > >detnet@ietf.org > > >https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > > detnet mailing list > >detnet@ietf.org > >https://www.ietf.org/mailman/listinfo/detnet > > > > > > > > > > > > _______________________________________________ > > detnet mailing list > >detnet@ietf.org > >https://www.ietf.org/mailman/listinfo/detnet -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0094B4F07805FC552BE9680E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Linda,

Probably the most useful part of that paper (other than saving you reading over 300 references) is Chapter IX. It attempts to select some of the most interesting approaches, and to quantify how much of the overall latency (in selected scenarios) they remove. Both as text, and as a visualization of their relative merits (mean and variance) in some nice (deliberately approximate) bubble diagrams, using the colour coding of the categories Linda outlined below.



Bob

On 20/10/16 21:18, Linda Dunbar wrote:
Lou,
 
Change the subject to make the discussion more focused.
 
As of now, the DLNex is to explore what kind of characteristics can be exposed by network, or can be imposed by upper layer, to make the delay/latency of E2E services more predictable or more optimal. The final work may eventually fall into some existing IETF WGs. Here, I am just brainstorming some potential exposures:
 
This paper "Reducing Internet Latency: A Survey of Techniques and their Merits" (http://www.bobbriscoe.net/pubs.html#latency_survey ) listed multiple sources that contributing to Latency/delay for E2E services:
 
The sources of delay are classified into five main categories: structural delays, interaction between endpoints, delays along transmission paths, delays related to link capacities, and intra-end-host delays.
 
Structural delays arise from the structure of the network or the communication path that is used.
The paper shows that one E2E service can use DNS multiple times. Therefore, where DNS is located is a big contributor to the overall latency. This could be a potential exposure by the network.
 
Delays resulting from the interaction between endpoints include delays due to transport initialization and secure session initialization, as well as delays from recovering lost packets and from message-aggregation techniques
Is it another exposure? Is there secure channel used?
 
Delays along transmission paths captures the delays that may be encountered as data travels between a sender and a receiver.
If some segments along the transmission paths are DetNet enabled or OIF’s FlexEthernet enabled, this definitely should be exposed. Then the upper layer can control/reserve the resource as CCAMP has done for MPLS paths and optical channels.
 
Delays related to link capacities include both delays resulting from sharing limited capacity and delays from protocol inefficiencies that under-utilize capacity and therefore communication takes longer than necessary.
I assume this is the type of work that CCAMP is to address.
 
Intra-end-host delays are delays that occur internally within host endpoints. This includes delays due to buffering in the transport protocol stack and delays within the operating system.
This is the end hosts TCP/UDP layer.
 
Linda
 
-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]
Sent: Thursday, October 20, 2016 2:36 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; Pat Thaler <pat.thaler@broadcom.com>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; dlnex@ietf.org; Patrick Wetterwald (pwetterw) <pwetterw@cisco.com>; Alia Atlas <akatlas@gmail.com>; matthew.bocci@nokia.com; detnet@ietf.org
Subject: Re: [Detnet] FW: New Non-WG Mailing List: DLNEX -- Discussion of reliable and deterministic latency attributes
 
Hi Linda,
 
    Could you (or anyone on DLNEX) elaborate on the type of documents you're thinking of delivering?
 
In detnet, we've so far been more focused on applications/use cases and data plane options.  But we're really looking forward to contributions/drafts on the information that is needed to support the control of deterministic flows.  The charter states this as:
 
    Data flow information model: This work will identify the
    information needed for flow establishment and control and be
    used by reservation protocols and YANG data models. The work
    will be independent from the protocol(s) used to control the
    flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).
 
Any drafts/contributions on this topic or willingness to help define these would be great.
 
If there are sufficiently developed ideas, we could probably even find time to discuss in our Seoul session.  (Or perhaps just informally, if there aren't.)
 
Thanks,
Lou
 
On 10/19/2016 7:09 PM, Linda Dunbar wrote:
>
> Pat,
>
> 
>
> What you said is so true: “The network can't provide a bounded or
> deterministic latency to an unbounded flow”.
>
> 
>
> DETNET charter starts with
>
> The Deterministic Networking (DetNet) Working Group focuses on
> deterministic data paths that operate over Layer 2 bridged and Layer 3
> routed segments, where such paths can provide bounds on latency, loss,
> and packet delay variation (jitter), and high reliability
>
> 
>
> If I understand it correctly, DETNET focuses on the enabling
> technologies to ensure deterministic latency path across a set of nodes.
>
> 
>
> E2E low latency services has many issues, such as:
>
> ·        There could be “bounded flows” that need low latency services
> mixed with other traffic in the network.
>
> ·        E2E services may have to go through many hops, links with
> some links not supporting DETNET.
>
> ·        there could be various protection/re-route mechanisms which
> all increase latency.
>
> ·        etc
>
> 
>
> Some problems specific to WAN include how to isolate the various
> service traffic, and provide maximum manageability to upper layers.
>
> 
>
> One company in NANOG asked why not use ICMP to mark the delay along
> the path to give upper link, ..
>
> 
>
> Linda
>
> 
>
> 
>
> Linda
>
> 
>
> *From:*Pat Thaler [mailto:pat.thaler@broadcom.com]
> *Sent:* Wednesday, October 19, 2016 5:25 PM
> *To:* Lou Berger <lberger@labn.net>
> *Cc:* Alia Atlas <akatlas@gmail.com>; Patrick Wetterwald (pwetterw)
> Linda Dunbar <linda.dunbar@huawei.com>
> *Subject:* Re: [Detnet] FW: New Non-WG Mailing List: DLNEX --
> Discussion of reliable and deterministic latency attributes
>
> 
>
> We have been having recent discussions about latency such as what type
> of latency is important.
>
> 
>
> As far as the "feasibility exercise for achieving reliable and
> deterministic latency through a network element or a segment" that
> overlaps very much what DetNet and IEEE 802.1 TSN have been doing. I
> believe we have already shown that it is feasible and are not on
> specifying how to do that. I'm concerned about the overlap between
> what that paragraph describes and our work.
>
> 
>
> There could be useful work on communication from the upper layer of
> the flow characteristics, behavior and requirements. There probably is
> some gap to fill that would help our work. I'm concerned that the list
> description focuses only on exposing lower layer characteristics to
> the upper layer. The network can't provide a bounded or deterministic
> latency to an unbounded flow - to determine what latency can be
> provided, one has to know something about the bandwidth utilization of
> the flow.
>
> 
>
> Regards,
>
> Pat
>
> 
>
> On Wed, Oct 19, 2016 at 1:59 PM, Lou Berger <lberger@labn.net
>
>     Hi Alia,
>
>         Overlap looks likely.  I hope that when it does occur, you send
>     folks over here to contribute -- additional input / WG participation
>     would be great!  (For folks not familiar with DetNet, check out our
>
>     I expect we'll have some good data plane centric discussions at this
>     meeting, for those who may be interested (there's even still time to
>     submit related drafts!)
>
>     Cheers,
>
>     Lou
>
>     DetNet Co-chair
>
>     On 10/19/2016 11:46 AM, Alia Atlas wrote:
>     > Hi Patrick,
>     >
>     > The discussion intended on dlnex, a non-WG mailing list, is, I
>     think,
>     > broader - spanning the range of communications between upper layer
>     > applications and the network.  It is not clear yet what work might
>     > develop.  Be sure that I will be watching for any specific overlap
>     > with DetNet.
>     >
>     > I feel that it is useful to make it easy for groups to have a
>     list to
>     > brainstorm about their ideas before work is mature enough to
>     consider
>     > for standardization.
>     >
>     > Regards,
>     > Alia
>     >
>     > On Wed, Oct 19, 2016 at 8:17 AM, Patrick Wetterwald (pwetterw)
>     >
>     >     Can someone explain me why this mailing list is created
>     outside of
>     >     DetNet?
>     >
>     >     This sounds like a subset of Detnet no?
>     >
>     >     Thanks,
>     >
>     >     Patrick
>     >
>     >
>     >     On 19/10/2016, 07:56, "detnet on behalf of Pascal Thubert
>     >     (pthubert)" <detnet-bounces@ietf.org
>     >     <mailto:detnet-bounces@ietf.org
>     >
>     >         From: IETF-Announce
>     <mailto:ietf-announce-bounces@ietf.org>>] On Behalf Of IETF
>     Secretariat
>     >         Sent: mardi 18 octobre 2016 22:36
>     >         To: IETF Announcement List <ietf-announce@ietf.org
>     >         Cc: matthew.bocci@nokia.com
>     >     <mailto:linda.dunbar@huawei.com
>     >         Subject: New Non-WG Mailing List: DLNEX -- Discussion of
>     >     reliable and deterministic latency attributes
>     >
>     >
>     >         A new IETF non-working group email list has been created.
>     >
>     >         List address:dlnex@ietf.org
>     >         Archive:
>
>     >         To subscribe:
>     >
>     >         Purpose:
>     >         DLNEX is to discuss various latency characteristics that can
>     >     be exposed by network elements or segments and to explore if
>     there
>     >     are any latency related attributes that can be utilized by upper
>     >     layer. For example, could there be latency exposure that upper
>     >     layer can utilize to plan how to distribute their content to the
>     >     right edges to achieve optimal user experience? Or something
>     used
>     >     by Interactive AR controller to optimize their services? Is
>     there
>     >     any value gained by upper layer expressing that they would
>     rather
>     >     have fixed latency than losing packets?
>     >
>     >         The discussion is to answer questions like: are there any
>     >     effective interaction/coordination between upper layer and lower
>     >     layer to achieve more efficient optimization for latency
>     sensitive
>     >     services?
>     >
>     >         This discussion group is also a place to showcase the
>     state of
>     >     the arts in latency optimized switching architecture and
>     interface
>     >     designs, as the feasibility exercise for achieving reliable and
>     >     deterministic latency through a network element or a segment.
>     >     Those latency exposures are the foundation for (future) latency
>     >     optimized control plane.
>     >
>     >
>     >         For additional information, please contact the list
>     >     administrators.
>     >
>     >         _______________________________________________
>     >         detnet mailing list
>
>     >         detnet@ietf.org <mailto:detnet@ietf.org>
>     >
>     >
>     >     _______________________________________________
>     >     detnet mailing list
>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > detnet mailing list
>
>     _______________________________________________
>     detnet mailing list
>
> 
>
>
>
> _______________________________________________
> detnet mailing list
 
 
 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0094B4F07805FC552BE9680E-- From nobody Mon Oct 31 01:24:32 2016 Return-Path: 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 829E91293E4 for ; Mon, 31 Oct 2016 01:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 wE02Ric2r2cw for ; Mon, 31 Oct 2016 01:24:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 9F990127A90 for ; Mon, 31 Oct 2016 01:24:28 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-ef-5816ffbaf1e0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id BF.DD.03250.ABFF6185; Mon, 31 Oct 2016 09:24:27 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Oct 2016 09:24:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TqZL/xQR9wlYYO1aWNkX/lfFMHcokj2zSTSxVF0HQwU=; b=E8hjZejpZvWEOxqdFuMMEyHVJg1g3r1uN6dTo7eoN59AUlIVsCi/kDbuj/2ru/JhBuejz6yFG0OAto2lo1Vta4TX9NaDFZrNc0n0G8sn6GU+D/0aDE8qgXMNHyQykP2Wzxo1zTPLxib8wrcgcsTHwtxqk7pg46GTJjOP76aYDXw= Received: from DBXPR07MB128.eurprd07.prod.outlook.com (10.242.138.156) by DBXPR07MB126.eurprd07.prod.outlook.com (10.242.138.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Mon, 31 Oct 2016 08:24:25 +0000 Received: from DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.213]) by DBXPR07MB128.eurprd07.prod.outlook.com ([169.254.3.213]) with mapi id 15.01.0707.002; Mon, 31 Oct 2016 08:24:25 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: "detnet@ietf.org" Thread-Topic: Service model draft updated Thread-Index: AdIzT3E7DNDnRHC3RW+/iIujBxPP2A== Date: Mon, 31 Oct 2016 08:24:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [178.164.213.204] x-ms-office365-filtering-correlation-id: 4175599e-0927-409c-4d1d-08d401675301 x-microsoft-exchange-diagnostics: 1; DBXPR07MB126; 7:86s2P62fjf55gzDINydMj6Rw+Ai0l27EuZXmH+Qij1KMmBlgrO4nwRxQZ6/79u+AToFRMrEEXvw21lvT3QH/fkKC22GPPn5jt1gN6oHqrEmLMYts1ptF+KzStY5pRyvUS775PZ2CzaQ/kzpGjaSyz+G+VYFjWBe+qjsNKKoOcnZZZTupQVJQ1HrTjcxVnGcL/wRy1WXhmaVafjW7X1QU2c1C9Jl+fX/zPKCFSrS2A/N2c1lu9crEnhdyq4YhVlF0KnDzTOfVdmCoeWzOiSn26/xR0B2v9X4LsbSYelDIpbpm9zG0ci1oGHYt82ST4zRRZGA1mEeXdwO6A28bplgIbP9oVowe8fqDqfvcG7yyINE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB126; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB126; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB126; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(199003)(5640700001)(11100500001)(68736007)(7696004)(9686002)(110136003)(3480700004)(6916009)(2501003)(66066001)(8936002)(586003)(6116002)(102836003)(3846002)(450100001)(229853001)(2351001)(15650500001)(15975445007)(74316002)(19580395003)(4001150100001)(76576001)(54356999)(50986999)(8676002)(81156014)(81166006)(305945005)(97736004)(1730700003)(105586002)(7736002)(87936001)(7846002)(107886002)(3660700001)(85182001)(106356001)(2900100001)(85202003)(5002640100001)(122556002)(92566002)(2906002)(5660300001)(101416001)(10400500002)(33656002)(3280700002)(189998001)(86362001)(140573001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB126; H:DBXPR07MB128.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 08:24:24.8936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB126 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUyM2K7h+7u/2IRBnNms1r8/jSbxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQfnmxasYqvYOaGdsYFxClsXIyeHhICJRHvbJqYuRi4OIYF1 jBKbFrazQjgnGCX6Tr5mAXFYBHqZJf5+egtVNpVJ4uvOGVBlRxglrt2Yww4yjE3ARWLHpjms ILaIgLpE25trjCC2sICKRNfEx4wQcU2JBU8eM0HYehJn1uwHq2cRUJV4eXMb2FG8AlES62dd YgGxGQXEJL6fWgNWzywgLnHryXwmiMMFJJbsOc8MYYtKvHz8jxWiPk7i9/4GqLiyxJeHu1kh bF+Jvr+vwI6WEJjPLLHp+QWgBRxAjqvExAOyEGamxKT36RDlWhIdR2YxQZRvY5SYPfk51BwZ iSv3tjJCJJaxSTybOA3sMSGBVInla1uhHpaSuHulE8qWkXhxZy8ryAJmoOfX79KH+EVRYkr3 Q/YJjOqzkLw2C6FqFpKqWeBQEZQ4OfMJywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsY genh4JbfBjsYXz53PMQowMGoxMNr4CwWIcSaWFZcmXuIUYKDWUmEd+ofoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2MKz+/Ck5yW8f9guVml6iuSPnL kIyapGtz2pgOPZkzI36tm023zIbAM1qL4/56BSVZJZT5SqkFHz4k2Vd+t0DJRW/v7ngWzbrq 0nlBRUtU9Q4fbWyzuZ3iKm624f8E82vr1+aGMr+75X+NT327/K5zWyW//lV8d++kq+GX+FlJ rJ6yYhF5WxcrsRRnJBpqMRcVJwIA1SeHswsDAAA= Archived-At: Subject: [Detnet] Service model draft updated X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 08:24:31 -0000 SGksDQpBIG5ldyB2ZXJzaW9uIG9mIHRoZSBzZXJ2aWNlIG1vZGVsIGRyYWZ0IGlzIGF2YWlsYWJs ZS4NCkNoYW5nZXMgcmVsYXRlZCB0bzoNCi0gZmxvdyBkZWZpbml0aW9ucw0KLSBlbmQgc3lzdGVt IGFuZCBzZXJ2aWNlIG1vZGVsIGRlc2NyaXB0aW9ucw0KLSB1cGRhdGUgb2Ygc2VydmljZSBpbnN0 YW5jZQ0KLSBuZXcgdGV4dCBvbiBpbnRlZ3JhdGluZyBMYXllciAzIGFuZCBMYXllciAyIFFvUyBm b3IgRGV0TmV0DQpDaGVlcnMNCkJhbGEnenMNCg0KTmFtZToJCWRyYWZ0LXZhcmdhLWRldG5ldC1z ZXJ2aWNlLW1vZGVsDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJRGV0TmV0IFNlcnZpY2UgTW9kZWwN CkRvY3VtZW50IGRhdGU6CTIwMTYtMTAtMzENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTI5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXZhcmdhLWRldG5ldC1zZXJ2aWNlLW1vZGVsLTAxLnR4dA0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12YXJnYS1kZXRuZXQt c2VydmljZS1tb2RlbC0wMQ0KDQo= From nobody Mon Oct 31 07:26:55 2016 Return-Path: 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 C7DA712973E for ; Mon, 31 Oct 2016 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 Eb1V9XxpflJ1 for ; Mon, 31 Oct 2016 07:26:48 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 9DB6C12964B for ; Mon, 31 Oct 2016 07:26:48 -0700 (PDT) Received: (qmail 12226 invoked by uid 0); 31 Oct 2016 14:26:45 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 31 Oct 2016 14:26:45 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 2ESf1u0052SSUrH01ESi3i; Mon, 31 Oct 2016 08:26:43 -0600 X-Authority-Analysis: v=2.1 cv=PIacp5aC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=CH0kA5CcgfcA:10 a=48vgC7mUAAAA:8 a=LEgbZSImoRZr8fvRqu8A:9 a=JpBOPxq1ZO_ZaVOz:21 a=nW5Rm9NN0IWY5fJg:21 a=pILNOxqGKmIA:10 a=8GSp_-7PivkA:10 a=w1C3t2QeGrPiZgrLijVG: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:Cc:References:To:Subject; bh=G1ct2YqH5bdzl3+Pk+0CcE5AKJ1ABHLGcTLvNmXtngo=; b=FhsYi3sonsuTO/NMZKYX7fXSaE 9yxzi+p6IRHTw+tgazHqOv1iS1GvsBbXBBlyzWwxrAG1fEK1Qu6ih0TKA1HEQaBstzDSG1AQMPhkL 2Aucm4GSJGsmP4p+c8PcwPsfZ; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:48273 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c1DXs-0005NJ-EJ; Mon, 31 Oct 2016 08:26:40 -0600 To: detnet@ietf.org References: From: Lou Berger Message-ID: <47b6daaf-9674-9103-9a5d-ba721d0b15a6@labn.net> Date: Mon, 31 Oct 2016 10:26:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 100.15.85.191 X-Exim-ID: 1c1DXs-0005NJ-EJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:48273 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: Jouni Korhonen , detnet-chairs@ietf.org Subject: Re: [Detnet] Agenda requests for IETF97 in Seoul X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 14:26:50 -0000 Just a reminder, time to get in your requests... On 10/24/2016 10:39 AM, Jouni Korhonen wrote: > Folks, > > The final agenda was published last Friday, see https://datatracker.ietf.org/meeting/97/agenda.html. DetNet WG is on air 9:30-12:00 Tuesday, November 15, 2016 in Park Ballroom 1. > > If you'd like to have a presentation slot in Seoul, please send a request to the chairs and me by Friday October 28th. Also pay attention to the important dates listed below. Specifically, the document submission deadline is on Monday UTC 23:59 on October 31st. When requesting a slot having a draft that has alrady been seen and discussed on the list is highly encouraged. > > Any WG draft not being discussed/presented needs to a status update sent to the list by Friday November 11th. Please also provide a summary slide by Sunday, November 13th. > > We'll need all slides for presentations by Sunday, November 13th. The earlier, the better, though. > > Cheers, > Jouni, Lou & Pat > > > =====> Important dates <===== > > * 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload usingIETF ID Submission Tool. > * 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. > * 2016-11-04 (Friday): Early Bird registration and payment cut-off at UTC 23:59. > * 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. > * 2016-11-07 (Monday): Registration cancellation cut-off at UTC 23:59. > * 2016-11-11 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. > * 2016-11-13 - 2016-11-18: IETF 97 in Seoul, South Korea > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Mon Oct 31 16:55:15 2016 Return-Path: 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 DCC7F129C07 for ; Mon, 31 Oct 2016 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 IzSOzkA8l8ac for ; Mon, 31 Oct 2016 16:55:01 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 47BD7129C02 for ; Mon, 31 Oct 2016 16:55:01 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9VNoDff008046; Mon, 31 Oct 2016 16:54:59 -0700 Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 26cqa0wahf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Oct 2016 16:54:59 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 16:53:50 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 16:53:50 -0700 From: "Grossman, Ethan A." To: "Pascal Thubert (pthubert)" , Olivier Marce , "nfinn (nfinn@alumni.caltech.edu)" Thread-Topic: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? Thread-Index: AdIfSZ9RlRHX+JyBRHenm9cDBBOMdgAYleeAABH2gIAA/mHzgAP4r93w Date: Mon, 31 Oct 2016 23:53:50 +0000 Message-ID: <6211952161fe433a93219e8fe14f88bb@DLB-XCHPW03.dolby.net> References: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> <2c9cfd1f09b84ad4808871c9bcaf540b@XCH-RCD-001.cisco.com> In-Reply-To: <2c9cfd1f09b84ad4808871c9bcaf540b@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-31_09:, , signatures=0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 23:55:08 -0000 Hi Pascal, Olivier, Norm, WG, So the consensus is, to paraphrase Norm:=20 1) Make sure that the time protocols are able to report, along with the tim= e, the accuracy provided. =20 2) The application will decide whether that is sufficient. =20 3) The accuracy reported will likely consist of several parameters (frequen= cy accuracy, absolute accuracy, etc.). =20 4) Different time protocols may have different parameters for accuracy. =20 5) An application might care about one or more of those parameters. =20 6) An application might then operate in one of various modes, depending on = the accuracy provided. =20 If anyone has any other understanding or input, please reply. Thanks, Ethan. -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Tuesday, October 11, 2016 4:29 AM To: Olivier Marce; detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time = accuracy and reliability needs? This is my understanding too, Olivier.=20 Also, time-related work is done elsewhere, whether one thinks of IETF or ou= tside the IETF. We do not want to be taken in the middle of that storm. Best can do is probably state requirements, but for all I know we are using= time as an information provided by external means, as opposed to managing = it. Cheers, Pascal -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Olivier Marce Sent: jeudi 6 octobre 2016 12:05 To: detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time = accuracy and reliability needs? Hi, I'm in favor of Norm' position: DetNet should concentrate on reliable, on-= time delivery of packets. Time accuracy is required for DetNet but out of s= cope, as many solutions exist and is not only a networking topic. At most, DetNet could provide some reference examples on how providing requ= ired time accuracy. Regards Le 06/10/2016 =E0 03:30, nfinn a =E9crit : > Interesting question. > > It seems more useful to me to make sure that the time protocols are=20 > able to report, along with the time, the accuracy provided. The=20 > application can then decide whether that is sufficient. The accuracy=20 > reported will likely consist of several parameters (frequency=20 > accuracy, absolute accuracy, etc.). Different time protocols may have=20 > different parameters for accuracy. The application might worried=20 > about one or the other of those parameters. It might operate in=20 > different modes, depending on the accuracy provided. I don't see the=20 > value in moving the decision point anywhere else. > > With DetNet, one can imagine a bandwidth reservation crossing a=20 > boundary between two different master clock domains. My inclination=20 > would be to disallow that, at least for now. Given an application=20 > that runs for long enough, any frequency difference between source and=20 > sink will eventually cause starvation or overflow. > > All that said, let's suppose that you have a solid use case that is=20 > expected to *try* to run across clock domain boundaries, and we want=20 > to prevent that when it won't work. This could be solved by an=20 > application-level protocol that exchanges clock domain information. > This could be solved by configuring the network controller to=20 > disallow domain crossings. This could be handled by parameters in the=20 > reservation protocol, as you suggest, so that the controller can allow=20 > some reservations but not others. I'll leave it to timing experts to=20 > pick some number of appropriate parameters. > > One last consideration - Are you sure that all applications that have=20 > these timing requirements also require bandwidth reservations? I'm=20 > not sure of that. And, if not, a protocol separate from the bandwidth=20 > reservation might be indicated. > > - Norm > >> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. > > wrote: >> >> Hi Folks, >> >> As of our IETF 96 meeting there were still a couple of Use Case=20 >> Statements that I would like clarity on. Here's the first, remaining=20 >> to follow in separate emails. >> >> Question: >> How will an application express its time accuracy and reliability=20 >> needs? Is that within scope of DetNet? >> >> Discussion: >> In AVB/TSN when an application (talker) attempts to make a stream=20 >> reservation it must state how much bandwidth that stream reservation=20 >> requires. Presumably in a LAN this is sufficient since a LAN=20 >> presumably has consistent time accuracy and reliability metrics. >> >> For DetNet, in which we support interconnected DetNet networks and=20 >> have widely varying requirements for timing accuracy and reliability=20 >> depending on the use case, it appears to me that we need to allow an=20 >> application to provide this kind of information to the network, and a=20 >> way for the network to either agree or decline to provide the=20 >> requested service (analogous to AVB/TSN accepting or declining a=20 >> stream reservation based on the bandwidth requested). >> >> We have had some discussion about this (see below) but nothing near=20 >> consensus. Other thoughts from anyone? >> Ethan. >> >> -------------------------------- >> Discussion, oldest item first: >> >> Ethan Grossman wrote: >> Timekeeping - the only explicit DetNet Ask for this is in the use=20 >> cases is in M2M as "Precise time synchronization accuracy (1us)" and=20 >> I think the intent (as in other use cases) is that the DetNet Ask is=20 >> for a way to specify the required accuracy, not how to achieve that accu= racy. >> >> Norm Finn wrote: >> Timekeeping is an essential part of many, probably most, of the=20 >> applications that also find DetNet useful. That having been said, so=20 >> is protection against EMI and electrical power saving. Let's=20 >> concentrate DetNet on reliable, on-time delivery of packets. I'm not=20 >> even sure that "a way to specify the required accuracy" need be in scope= . >> >> Rodney Cummings wrote: >> I rarely disagree with Norm, but on this point I'll have to quibble a bi= t. >> I agree that we don't need DetNet to specify how time sync is=20 >> accomplished. There are plenty of IEEE 1588 techniques (and similar)=20 >> for that purpose. >> I also agree that we should concentrate on reliable, on-time delivery=20 >> of packets (i.e. worst-case latency). >> If I don't know how accurate my time sync is, then how do I know when=20 >> a packet is delivered on time? If I don't know the reliability of my=20 >> time sync, how can I reliably measure that packet delivery? >> Almost all (if not 100%) of DetNet use cases require time sync at the=20 >> end systems to some degree of accuracy. I agree that we don't need to=20 >> address the implementation of that time sync, but the application=20 >> requirements are needed for time sync (including reliability) just as=20 >> much as for packet delivery. >> -------------------------------- >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/detnet > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Olivier Marc=E9 Nokia Bell Labs France "we need to guard against increased levels of reporting and other requireme= nts that distract you from doing what you really need to be doing." Rajeev = Suri, Nokia CEO, April 2016 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Oct 31 17:05:06 2016 Return-Path: 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 35C31129C01 for ; Mon, 31 Oct 2016 17:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 oMSZGbEj5Btt for ; Mon, 31 Oct 2016 17:05:03 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 316AB129BFF for ; Mon, 31 Oct 2016 17:05:03 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA1052SP017413; Mon, 31 Oct 2016 17:05:02 -0700 Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 26cqa0wb1p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Oct 2016 17:05:02 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 17:03:52 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 17:03:52 -0700 From: "Grossman, Ethan A." To: Gordon Bechtel , Olivier Marce , "nfinn (nfinn@alumni.caltech.edu)" Thread-Topic: [Detnet] DetNet Use Case Statements - Latency matching Thread-Index: AdIfXd/Gq1HxYlFESUmAufZ2/y8alwAT+SCAABHjRwAAC91zAATrdwIw Date: Tue, 1 Nov 2016 00:03:52 +0000 Message-ID: <8b69ab05d2574a69802c1d5e5c3cc0c1@DLB-XCHPW03.dolby.net> References: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> <87f5bd9e-ebe9-3b91-8cca-49614452a3e7@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_8b69ab05d2574a69802c1d5e5c3cc0c1DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-31_09:, , signatures=0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 00:05:05 -0000 --_000_8b69ab05d2574a69802c1d5e5c3cc0c1DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR29yZHksIE5vcm0sIE9saXZpZXIsIFdHLA0KSSB1bmRlcnN0YW5kIHRoZSBjb25zZW5zdXMg aXM6DQoNCjEpICAgICAgVGhlIG5ldHdvcmsgbXVzdCBiZSBhYmxlIHRvIHJlcG9ydCBpdHMgY2Fw YWJpbGl0aWVzIGZvciBsYXRlbmN5IChwcmVzdW1hYmx5IGJvdGggbWluIGFuZCBtYXgsIHRodXMg Ym91bmRpbmcgaml0dGVyKS4NCg0KMikgICAgICBUaGUgYXBwbGljYXRpb24gbXVzdCBhZGQgaXRz IG93biBkZWxheXMgdG8gYSDigJxmYXN0ZXLigJ0gcGF0aCB0byBtYXRjaCBhIOKAnHNsb3dlcuKA nSBwYXRoIGlmIGl0IG5lZWRzIHRvLg0KDQoNCklmIGFueW9uZSBoYXMgYW55IG90aGVyIHVuZGVy c3RhbmRpbmcgb3IgaW5wdXQsIHBsZWFzZSByZXBseS4NCg0KVGhhbmtzLA0KDQpFdGhhbi4NCg0K RnJvbTogZGV0bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBHb3Jkb24gQmVjaHRlbA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIwMTYgODo1NiBB TQ0KVG86IE9saXZpZXIgTWFyY2UNCkNjOiBkZXRuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb RGV0bmV0XSBEZXROZXQgVXNlIENhc2UgU3RhdGVtZW50cyAtIExhdGVuY3kgbWF0Y2hpbmcNCg0K U2VlbXMgdG8gbWUgdGhhdCB0aGUgcXVlc3Rpb24gb2YgbGF0ZW5jeSBtZXRyaWNzIGNhbiBiZSBy ZXNvbHZlZCBpbiB0aGUgc2FtZSB3YXkgTm9ybSBzdWdnZXN0ZWQgZm9yIHRpbWluZyBhbmQgYmFu ZHdpZHRoOiBMZXQgdGhlIG5ldHdvcmsgcmVwb3J0IG9uIHdoYXQgaXQgaXMgY2FwYWJsZSBvZiAo d2l0aCB3aGF0ZXZlciBtZXRyaWNzIHRoaXMgZ3JvdXAgZmVlbHMgbWFrZXMgc2Vuc2UpIGFuZCBs ZXQgdGhlIGFwcGxpY2F0aW9uIGRlY2lkZSBob3cgYmVzdCB0byB1c2UgKG9yIG5vdCB1c2UpIHRo ZSBuZXR3b3JrLg0KDQpJbiB0aGUgcGFydGljdWxhciBjYXNlIG9mIG1hdGNoZWQgbGF0ZW5jaWVz LCB0aGUgbmV0d29yayBzaG91bGQgcmVwb3J0IHRoZSBsYXRlbmN5IG1ldHJpY3MgZm9yIGVhY2gg ZGlyZWN0aW9uIG9mIHRoZSBmbG93LCBhbmQgdGhlIGFwcGxpY2F0aW9uIGNhbiBkZWNpZGUgaWYg dGhpcyBpcyBzdWZmaWNpZW50LiAgU29tZSBhcHBsaWNhdGlvbnMgbmVlZCBzeW1tZXRyaWMgbGF0 ZW5jaWVzIChpdCBzb3VuZHMgbGlrZSB0aGUgdXRpbGl0eSBhcHBsaWNhdGlvbnMgZG8pIGFuZCBz b21lIGRvbid0LiAgQnV0IHRoZSBuZXR3b3JrIGRvZXNuJ3Qga25vdyB0aGF0LiAgT25seSB0aGUg YXBwbGljYXRpb24gZG9lcy4NCg0KR29yZHkNCg0KT24gVGh1LCBPY3QgNiwgMjAxNiBhdCA0OjE2 IEFNLCBPbGl2aWVyIE1hcmNlIDxPbGl2aWVyLk1hcmNlQG5va2lhLmNvbTxtYWlsdG86T2xpdmll ci5NYXJjZUBub2tpYS5jb20+PiB3cm90ZToNCkhpLA0KSSBoYXZlIHRoZSBmZWVsaW5nIHRoYXQg ZXhwcmVzc2luZyBtaW4gbGF0ZW5jeSBpbiBhZGRpdGlvbiB0byBtYXggbGF0ZW5jeSBpcyBhIGxv b3NlIHdheSB0byBleHByZXNzIGppdHRlciBjb250cm9sLg0KVGhlcmUgaXMgYSB0cmFkZW9mZiBi ZXR3ZWVuIGxhdGVuY3kvaml0dGVyIGNvbnN0cmFpbnRzIGFuZCBwcm90ZWN0aW9uL3BhdGhzIHJl ZHVuZGFuY2llczogb25lIGNvdWxkIG5vdCBleHBlY3QgaGF2aW5nIHRoZSBzYW1lIGxhdGVuY3kg YW5kIGppdHRlciBmb3Igb25lIHNpbmdsZSBwYXRoLCB0aGFuIGZvciBtdWx0aXBsZSBjb25jdXJy ZW50IHBhdGhzLg0KQXMgc3VjaCBqaXR0ZXIgc2hvdWxkIGJlIGRlcGVuZGVudCBvZiBsZXZlbCBv ZiBwcm90ZWN0aW9ucyBpLmUuIG1vcmUgcGF0aHMsIGhpZ2hlciBhY2NlcHRhYmxlIGppdHRlci4N Cg0KSSBkbyBub3Qgc2VlICh5ZXQpIGFueSByZWFzb24gZm9yIGhhdmluZyBzaW1pbGFyIGxhdGVu Y3kgb24gc2VuZCBhbmQgcmV0dXJuIHBhdGhzLg0KDQpSZWdhcmRzDQoNCkxlIDA2LzEwLzIwMTYg w6AgMDM6NDMsIG5maW5uIGEgw6ljcml0IDoNClRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgc3RpbGwg bWVudGlvbnMgYm90aCBtaW5pbXVtIGFuZCBtYXhpbXVtIGxhdGVuY3kNCmFzIHNwZWNpZmlhYmxl LiAgSW4gc29tZSBzZW5zZSwgdGhhdCBzb2x2ZXMgdGhlIHByb2JsZW0uICBUaGUgaXNzdWUsIG9m DQpjb3Vyc2UsIGlzIHBpY2tpbmcgdGhlIG1pbmltdW0gYW5kIG1heGltdW0gbnVtYmVycy4gIFBl cmhhcHMgdGhlcmUgaXMNCnNvbWUgd2F5IHRvIHByb3ZpZGUgY2x1ZXMgdG8gdGhlIGFwcCBzbyBp dCBjYW4gcGljayBzdWl0YWJsZSBudW1iZXJzLg0KDQpCaXQsIGFzIEkgdGhpbmsgYWJvdXQgaXQs IGJpLWRpcmVjdGlvbmFsIGxhdGVuY3kgZXF1YWxpdHkgaXMgbm90IGF0IGFsbA0KdHJpdmlhbCB0 byBtYWludGFpbi4gIFRoZSBleGlzdGluZyBUU04gc3RhbmRhcmRzIHJlcG9ydCBsYXRlbmN5LCBp bnN0ZWFkDQpvZiBzYXRpc2Z5aW5nIGEgcmVxdWlyZW1lbnQgZm9yIGxhdGVuY3kuICBUaGUgaW1h Z2luZWQgdXNlIChieSBtZSwNCmFueXdheSkgb2YgYSBtYXggbGF0ZW5jeSBwYXJhbWV0ZXIgaXMg dG8gYWxsb3cgdGhlIG5ldHdvcmsgdG8gY2hhbmdlDQp0b3BvbG9neSwgb3IgcmVyb3V0ZSBhIHN0 cmVhbSwgb3IgYWRkIGhpZ2hlci1wcmlvcml0eSBmbG93cywgYW5kIHN0aWxsDQpndWFyYW50ZWUg dGhlIG1heCBsYXRlbmN5IGlzIG1ldC4gIElmLCBieSBiaWRpcmVjdGlvbmFsIGxhdGVuY3kNCm1h dGNoaW5nLCB5b3UgbWVhbiwg4oCcbWFrZSBib3RoIHNsb3cgaWYgb25lIGlzIHNsb3csIGFuZCB2 aWNlLXZlcnNhLOKAnSBJDQpkb27igJl0IGtub3cgaG93IHRvIGRvIHRoYXQuICBJZiB5b3UgbWVh biDigJxtZWV0IG1pbiBhbmQgbWF4IGxhdGVuY3kNCnNwZWNpZmljYXRpb25zIGZvciB0aGUgZmxv d+KAnSwgdGhlbiB3ZXJlIG9uIHRoZSByaWdodCB0cmFjaywgYWxyZWFkeS4NCg0K4oCUIE5vcm0N Ck9uIE9jdCA1LCAyMDE2LCBhdCA0OjI1IFBNLCBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bk b2xieS5jb208bWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20+DQo8bWFpbHRvOmVhZ3Jvc0Bkb2xieS5j b208bWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20+Pj4gd3JvdGU6DQoNClN0YXRlbWVudDoNCkxhdGVu Y3kgbWF0Y2hpbmcg4oCTIHNpbmdsZS0gb3IgYmktZGlyZWN0aW9uYWwuIFRoZSBVdGlsaXRpZXMg dXNlIGNhc2UNCm5lZWRzIHRoaXMsIGJ1dCBpcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIGFk ZHJlc3MgaW4gRGV0TmV0Pw0KDQpEaXNjdXNzaW9uIChvbGRlc3QgZmlyc3QpOg0KDQpFdGhhbiBH cm9zc21hbiB3cm90ZToNClRoaXMgY2FtZSB1cCBiZWNhdXNlIGF0IGxlYXN0IG9uZSB1c2UgY2Fz ZSBtZW50aW9uZWQgYSBuZWVkIGZvcg0KbXVsdGlwbGUgb3V0Z29pbmcgcGF0aHMgKG9yIHRoZSBz ZW5kIGFuZCByZXR1cm4gcGF0aHMpIHRvIGhhdmUgbWF0Y2hlZA0KbGF0ZW5jaWVzLiBJIHN1cHBv c2Ugb25lIHdheSB0byBkbyB0aGlzIGlzIHRvIHNwZWNpZnkgYSBsYXRlbmN5IHdoaWNoDQppcyB0 aGUgbWluaW11bSwgYW5kIHRoZSBhZGQgZGVsYXkgdG8gdGhlIG90aGVyIHBhdGgocykgdG8gbWF0 Y2ggaXQg4oCTDQpidXQgZG9lcyB0aGlzIGhhcHBlbiBhdCB0aGUgRGV0TmV0IGxldmVsIG9yIGlz IGl0IHNvbWV0aGluZyB0aGUNCmFwcGxpY2F0aW9uIGxheWVyIHdvdWxkIGRvPw0KDQpQYXNjYWwg VGh1YmVydCB3cm90ZToNClRoaXMgc2VlbXMgcmVsYXRlZCB0byB0aGUgaW4tb3JkZXIgcGFja2V0 cyBkZWxpdmVyeSBpdGVtLiBBIHRpZ2h0DQpsYXRlbmN5IGNvbnRyb2wgY2FuIGJlIHVzZWZ1bCB0 byBtYWludGFpbiB0aGF0IG9yZGVyLiBCdXQgZG9lc27igJl0IHRoaXMNCmltcGx5IFRpbWUgdHJp Z2dlcmVkIG9wZXJhdGlvbnM/DQpXZSBjb3VsZCBhbHNvIGFkZCB0aGF0IGZlYXR1cmUgb2Ygdm9s dW50YXJ5IGxhdGVuY3kgYWRkaXRpb24sIHByb2JhYmx5DQphc3NvY2lhdGVkIHRvIGppdHRlciBl bGltaW5hdGlvbi4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9yZzxtYWlsdG86 ZGV0bmV0QGlldGYub3JnPiA8bWFpbHRvOmRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGll dGYub3JnPj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fZGV0bmV0JmQ9RFFNRmFRJmM9bEk4WmI2VHpNM2QxdFg0 aUV1N2JwZyZyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmbT1uYmRQWEk2c1lGV3R2aGR5Vm9ycENX YU1ZVlhFWnZGUlZSUHJlTElGTGVBJnM9TW1lWENyTnlzOUZmbG1WZVdKTWZXRHlCeWU5eW1mNlJ0 UVJsX05ZX3ljZyZlPT4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpkZXRuZXQgbWFpbGluZyBsaXN0DQpkZXRuZXRAaWV0Zi5vcmc8bWFpbHRv OmRldG5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGV0bmV0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGV0bmV0JmQ9RFFNRmFRJmM9bEk4WmI2 VHpNM2QxdFg0aUV1N2JwZyZyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmbT1uYmRQWEk2c1lGV3R2 aGR5Vm9ycENXYU1ZVlhFWnZGUlZSUHJlTElGTGVBJnM9TW1lWENyTnlzOUZmbG1WZVdKTWZXRHlC eWU5eW1mNlJ0UVJsX05ZX3ljZyZlPT4NCg0KLS0NCk9saXZpZXIgTWFyY8OpDQpOb2tpYSBCZWxs IExhYnMgRnJhbmNlDQoid2UgbmVlZCB0byBndWFyZCBhZ2FpbnN0IGluY3JlYXNlZCBsZXZlbHMg b2YgcmVwb3J0aW5nIGFuZCBvdGhlcg0KcmVxdWlyZW1lbnRzIHRoYXQgZGlzdHJhY3QgeW91IGZy b20gZG9pbmcgd2hhdCB5b3UgcmVhbGx5IG5lZWQgdG8gYmUgZG9pbmcuIiBSYWplZXYgU3VyaSwg Tm9raWEgQ0VPLCBBcHJpbCAyMDE2DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9yZzxt YWlsdG86ZGV0bmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kZXRuZXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19kZXRuZXQmZD1EUU1GYVEmYz1s SThaYjZUek0zZDF0WDRpRXU3YnBnJnI9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPW5iZFBYSTZz WUZXdHZoZHlWb3JwQ1dhTVlWWEVadkZSVlJQcmVMSUZMZUEmcz1NbWVYQ3JOeXM5RmZsbVZlV0pN ZldEeUJ5ZTl5bWY2UnRRUmxfTllfeWNnJmU9Pg0KDQo= --_000_8b69ab05d2574a69802c1d5e5c3cc0c1DLBXCHPW03dolbynet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJ e21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NTc2MDg5NTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTM0MDc5MDcwIDY3Njk4NzA1IDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEdvcmR5LCBOb3JtLCBPbGl2aWVyLCBXRyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB1bmRlcnN0YW5kIHRoZSBjb25zZW5zdXMg aXM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG5ldHdvcmsgbXVzdCBiZSBhYmxlIHRvIHJlcG9ydCBp dHMgY2FwYWJpbGl0aWVzIGZvciBsYXRlbmN5IChwcmVzdW1hYmx5IGJvdGggbWluIGFuZCBtYXgs IHRodXMgYm91bmRpbmcgaml0dGVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGFwcGxpY2F0aW9uIG11 c3QgYWRkIGl0cyBvd24gZGVsYXlzIHRvIGEg4oCcZmFzdGVy4oCdIHBhdGggdG8gbWF0Y2ggYSDi gJxzbG93ZXLigJ0gcGF0aCBpZiBpdCBuZWVkcyB0by4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgYW55b25lIGhhcyBhbnkgb3RoZXIg dW5kZXJzdGFuZGluZyBvciBpbnB1dCwgcGxlYXNlIHJlcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkV0aGFuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRldG5ldCBb bWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Hb3Jk b24gQmVjaHRlbDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAwNiwgMjAxNiA4 OjU2IEFNPGJyPg0KPGI+VG86PC9iPiBPbGl2aWVyIE1hcmNlPGJyPg0KPGI+Q2M6PC9iPiBkZXRu ZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRdIERldE5ldCBVc2Ug Q2FzZSBTdGF0ZW1lbnRzIC0gTGF0ZW5jeSBtYXRjaGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlZW1zIHRvIG1lIHRoYXQgdGhlIHF1ZXN0aW9uIG9mIGxhdGVuY3kg bWV0cmljcyBjYW4gYmUgcmVzb2x2ZWQgaW4gdGhlIHNhbWUgd2F5IE5vcm0gc3VnZ2VzdGVkIGZv ciB0aW1pbmcgYW5kIGJhbmR3aWR0aDogTGV0IHRoZSBuZXR3b3JrDQo8aT48dT5yZXBvcnQ8L3U+ PC9pPiBvbiB3aGF0IGl0IGlzIGNhcGFibGUgb2YgKHdpdGggd2hhdGV2ZXIgbWV0cmljcyB0aGlz IGdyb3VwIGZlZWxzIG1ha2VzIHNlbnNlKSBhbmQgbGV0IHRoZSBhcHBsaWNhdGlvbg0KPGk+PHU+ ZGVjaWRlPC91PjwvaT4gaG93IGJlc3QgdG8gdXNlIChvciBub3QgdXNlKSB0aGUgbmV0d29yay48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBwYXJ0 aWN1bGFyIGNhc2Ugb2YgbWF0Y2hlZCBsYXRlbmNpZXMsIHRoZSBuZXR3b3JrIHNob3VsZCByZXBv cnQgdGhlIGxhdGVuY3kgbWV0cmljcyBmb3IgZWFjaCBkaXJlY3Rpb24gb2YgdGhlIGZsb3csIGFu ZCB0aGUgYXBwbGljYXRpb24gY2FuIGRlY2lkZSBpZiB0aGlzIGlzIHN1ZmZpY2llbnQuJm5ic3A7 IFNvbWUgYXBwbGljYXRpb25zIG5lZWQgc3ltbWV0cmljIGxhdGVuY2llcyAoaXQgc291bmRzIGxp a2UNCiB0aGUgdXRpbGl0eSBhcHBsaWNhdGlvbnMgZG8pIGFuZCBzb21lIGRvbid0LiZuYnNwOyBC dXQgdGhlIG5ldHdvcmsgZG9lc24ndCBrbm93IHRoYXQuJm5ic3A7IE9ubHkgdGhlIGFwcGxpY2F0 aW9uIGRvZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdvcmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFRodSwgT2N0IDYsIDIwMTYgYXQgNDoxNiBBTSwgT2xpdmllciBNYXJjZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOk9saXZpZXIuTWFyY2VAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFu ayI+T2xpdmllci5NYXJjZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCkkgaGF2ZSB0aGUgZmVlbGluZyB0aGF0IGV4 cHJlc3NpbmcgbWluIGxhdGVuY3kgaW4gYWRkaXRpb24gdG8gbWF4IGxhdGVuY3kgaXMgYSBsb29z ZSB3YXkgdG8gZXhwcmVzcyBqaXR0ZXIgY29udHJvbC48YnI+DQpUaGVyZSBpcyBhIHRyYWRlb2Zm IGJldHdlZW4gbGF0ZW5jeS9qaXR0ZXIgY29uc3RyYWludHMgYW5kIHByb3RlY3Rpb24vcGF0aHMg cmVkdW5kYW5jaWVzOiBvbmUgY291bGQgbm90IGV4cGVjdCBoYXZpbmcgdGhlIHNhbWUgbGF0ZW5j eSBhbmQgaml0dGVyIGZvciBvbmUgc2luZ2xlIHBhdGgsIHRoYW4gZm9yIG11bHRpcGxlIGNvbmN1 cnJlbnQgcGF0aHMuPGJyPg0KQXMgc3VjaCBqaXR0ZXIgc2hvdWxkIGJlIGRlcGVuZGVudCBvZiBs ZXZlbCBvZiBwcm90ZWN0aW9ucyBpLmUuIG1vcmUgcGF0aHMsIGhpZ2hlciBhY2NlcHRhYmxlIGpp dHRlci48YnI+DQo8YnI+DQpJIGRvIG5vdCBzZWUgKHlldCkgYW55IHJlYXNvbiBmb3IgaGF2aW5n IHNpbWlsYXIgbGF0ZW5jeSBvbiBzZW5kIGFuZCByZXR1cm4gcGF0aHMuPGJyPg0KPGJyPg0KUmVn YXJkczxicj4NCjxicj4NCkxlIDA2LzEwLzIwMTYgw6AgMDM6NDMsIG5maW5uIGEgw6ljcml0IDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhlIGFyY2hpdGVjdHVyZSBkcmFmdCBzdGlsbCBtZW50aW9ucyBib3RoIG1pbmlt dW0gYW5kIG1heGltdW0gbGF0ZW5jeTxicj4NCmFzIHNwZWNpZmlhYmxlLiZuYnNwOyBJbiBzb21l IHNlbnNlLCB0aGF0IHNvbHZlcyB0aGUgcHJvYmxlbS4mbmJzcDsgVGhlIGlzc3VlLCBvZjxicj4N CmNvdXJzZSwgaXMgcGlja2luZyB0aGUgbWluaW11bSBhbmQgbWF4aW11bSBudW1iZXJzLiZuYnNw OyBQZXJoYXBzIHRoZXJlIGlzPGJyPg0Kc29tZSB3YXkgdG8gcHJvdmlkZSBjbHVlcyB0byB0aGUg YXBwIHNvIGl0IGNhbiBwaWNrIHN1aXRhYmxlIG51bWJlcnMuPGJyPg0KPGJyPg0KQml0LCBhcyBJ IHRoaW5rIGFib3V0IGl0LCBiaS1kaXJlY3Rpb25hbCBsYXRlbmN5IGVxdWFsaXR5IGlzIG5vdCBh dCBhbGw8YnI+DQp0cml2aWFsIHRvIG1haW50YWluLiZuYnNwOyBUaGUgZXhpc3RpbmcgVFNOIHN0 YW5kYXJkcyByZXBvcnQgbGF0ZW5jeSwgaW5zdGVhZDxicj4NCm9mIHNhdGlzZnlpbmcgYSByZXF1 aXJlbWVudCBmb3IgbGF0ZW5jeS4mbmJzcDsgVGhlIGltYWdpbmVkIHVzZSAoYnkgbWUsPGJyPg0K YW55d2F5KSBvZiBhIG1heCBsYXRlbmN5IHBhcmFtZXRlciBpcyB0byBhbGxvdyB0aGUgbmV0d29y ayB0byBjaGFuZ2U8YnI+DQp0b3BvbG9neSwgb3IgcmVyb3V0ZSBhIHN0cmVhbSwgb3IgYWRkIGhp Z2hlci1wcmlvcml0eSBmbG93cywgYW5kIHN0aWxsPGJyPg0KZ3VhcmFudGVlIHRoZSBtYXggbGF0 ZW5jeSBpcyBtZXQuJm5ic3A7IElmLCBieSBiaWRpcmVjdGlvbmFsIGxhdGVuY3k8YnI+DQptYXRj aGluZywgeW91IG1lYW4sIOKAnG1ha2UgYm90aCBzbG93IGlmIG9uZSBpcyBzbG93LCBhbmQgdmlj ZS12ZXJzYSzigJ0gSTxicj4NCmRvbuKAmXQga25vdyBob3cgdG8gZG8gdGhhdC4mbmJzcDsgSWYg eW91IG1lYW4g4oCcbWVldCBtaW4gYW5kIG1heCBsYXRlbmN5PGJyPg0Kc3BlY2lmaWNhdGlvbnMg Zm9yIHRoZSBmbG934oCdLCB0aGVuIHdlcmUgb24gdGhlIHJpZ2h0IHRyYWNrLCBhbHJlYWR5Ljxi cj4NCjxicj4NCuKAlCBOb3JtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBPY3QgNSwgMjAxNiwgYXQgNDoyNSBQTSwgR3Jvc3NtYW4sIEV0aGFuIEEuICZsdDs8YSBocmVm PSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVhZ3Jvc0Bkb2xieS5j b208L2E+PGJyPg0KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVhZ3Jvc0Bkb2xieS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0K PGJyPg0KU3RhdGVtZW50Ojxicj4NCkxhdGVuY3kgbWF0Y2hpbmcg4oCTIHNpbmdsZS0gb3IgYmkt ZGlyZWN0aW9uYWwuIFRoZSBVdGlsaXRpZXMgdXNlIGNhc2U8YnI+DQpuZWVkcyB0aGlzLCBidXQg aXMgdGhpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBhZGRyZXNzIGluIERldE5ldD88YnI+DQo8YnI+ DQpEaXNjdXNzaW9uIChvbGRlc3QgZmlyc3QpOjxicj4NCjxicj4NCkV0aGFuIEdyb3NzbWFuIHdy b3RlOjxicj4NClRoaXMgY2FtZSB1cCBiZWNhdXNlIGF0IGxlYXN0IG9uZSB1c2UgY2FzZSBtZW50 aW9uZWQgYSBuZWVkIGZvcjxicj4NCm11bHRpcGxlIG91dGdvaW5nIHBhdGhzIChvciB0aGUgc2Vu ZCBhbmQgcmV0dXJuIHBhdGhzKSB0byBoYXZlIG1hdGNoZWQ8YnI+DQpsYXRlbmNpZXMuIEkgc3Vw cG9zZSBvbmUgd2F5IHRvIGRvIHRoaXMgaXMgdG8gc3BlY2lmeSBhIGxhdGVuY3kgd2hpY2g8YnI+ DQppcyB0aGUgbWluaW11bSwgYW5kIHRoZSBhZGQgZGVsYXkgdG8gdGhlIG90aGVyIHBhdGgocykg dG8gbWF0Y2ggaXQg4oCTPGJyPg0KYnV0IGRvZXMgdGhpcyBoYXBwZW4gYXQgdGhlIERldE5ldCBs ZXZlbCBvciBpcyBpdCBzb21ldGhpbmcgdGhlPGJyPg0KYXBwbGljYXRpb24gbGF5ZXIgd291bGQg ZG8/PGJyPg0KPGJyPg0KUGFzY2FsIFRodWJlcnQgd3JvdGU6PGJyPg0KVGhpcyBzZWVtcyByZWxh dGVkIHRvIHRoZSBpbi1vcmRlciBwYWNrZXRzIGRlbGl2ZXJ5IGl0ZW0uIEEgdGlnaHQ8YnI+DQps YXRlbmN5IGNvbnRyb2wgY2FuIGJlIHVzZWZ1bCB0byBtYWludGFpbiB0aGF0IG9yZGVyLiBCdXQg ZG9lc27igJl0IHRoaXM8YnI+DQppbXBseSBUaW1lIHRyaWdnZXJlZCBvcGVyYXRpb25zPzxicj4N CldlIGNvdWxkIGFsc28gYWRkIHRoYXQgZmVhdHVyZSBvZiB2b2x1bnRhcnkgbGF0ZW5jeSBhZGRp dGlvbiwgcHJvYmFibHk8YnI+DQphc3NvY2lhdGVkIHRvIGppdHRlciBlbGltaW5hdGlvbi48YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCmRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86ZGV0bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGV0bmV0QGlldGYub3JnPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fZGV0bmV0JmFtcDtkPURRTUZhUSZhbXA7Yz1sSThaYjZUek0zZDF0WDRpRXU3 YnBnJmFtcDtyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmYW1wO209bmJkUFhJNnNZRld0dmhkeVZv cnBDV2FNWVZYRVp2RlJWUlByZUxJRkxlQSZhbXA7cz1NbWVYQ3JOeXM5RmZsbVZlV0pNZldEeUJ5 ZTl5bWY2UnRRUmxfTllfeWNnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CmRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fZGV0bmV0JmFtcDtkPURRTUZhUSZhbXA7Yz1sSThaYjZUek0z ZDF0WDRpRXU3YnBnJmFtcDtyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmYW1wO209bmJkUFhJNnNZ Rld0dmhkeVZvcnBDV2FNWVZYRVp2RlJWUlByZUxJRkxlQSZhbXA7cz1NbWVYQ3JOeXM5RmZsbVZl V0pNZldEeUJ5ZTl5bWY2UnRRUmxfTllfeWNnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4N CjxzcGFuIGNsYXNzPSJob2VuemIiPi0tIDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpi Ij5PbGl2aWVyIE1hcmPDqTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5Ob2tpYSBC ZWxsIExhYnMgRnJhbmNlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZxdW90O3dl IG5lZWQgdG8gZ3VhcmQgYWdhaW5zdCBpbmNyZWFzZWQgbGV2ZWxzIG9mIHJlcG9ydGluZyBhbmQg b3RoZXI8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+cmVxdWlyZW1lbnRzIHRoYXQg ZGlzdHJhY3QgeW91IGZyb20gZG9pbmcgd2hhdCB5b3UgcmVhbGx5IG5lZWQgdG8gYmUgZG9pbmcu JnF1b3Q7IFJhamVldiBTdXJpLCBOb2tpYSBDRU8sIEFwcmlsIDIwMTY8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CmRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fZGV0bmV0JmFtcDtkPURRTUZhUSZhbXA7Yz1sSThaYjZUek0z ZDF0WDRpRXU3YnBnJmFtcDtyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmYW1wO209bmJkUFhJNnNZ Rld0dmhkeVZvcnBDV2FNWVZYRVp2RlJWUlByZUxJRkxlQSZhbXA7cz1NbWVYQ3JOeXM5RmZsbVZl V0pNZldEeUJ5ZTl5bWY2UnRRUmxfTllfeWNnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8b69ab05d2574a69802c1d5e5c3cc0c1DLBXCHPW03dolbynet_-- From nobody Mon Oct 31 23:57:11 2016 Return-Path: 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 92FB7129536 for ; Mon, 31 Oct 2016 23:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 cPfOKBV21HUJ for ; Mon, 31 Oct 2016 23:57:06 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id 213BA129453 for ; Mon, 31 Oct 2016 23:57:06 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 7D03C120180; Mon, 31 Oct 2016 23:57:02 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 7D03C120180 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1477983422; bh=U/Lw/HNbhTGxWCJl1X6GGNztzjz8r3eRSQ5EWIAT518=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date: In-Reply-To:Cc:To:References; b=B09ur+V3K4KVzLq88O1qpvOXIIBgnq7W4QBwKDlCrhcGwj9Jh5lA57VRmBnbinuHk kkPvdARo48fv9Ew5Ylzw5b5hS71YGL8z2QvWgyLqv3vqGmADWWWG8b3gXuO2DEcPqo JBXTRjdbFub/K4Ctfv0zFVMCGEKCZCcNWAQz3x7c= From: nfinn Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_840F1A82-BA99-4265-BC91-85C59212E9E4" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Mon, 31 Oct 2016 23:57:01 -0700 In-Reply-To: <8b69ab05d2574a69802c1d5e5c3cc0c1@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." References: <99768945c86b4c799b3bfdf0eb8f95a7@DLB-XCHPW03.dolby.net> <1AA54660-A765-4BD5-8FFC-FAC919F251AE@alumni.caltech.edu> <87f5bd9e-ebe9-3b91-8cca-49614452a3e7@nokia.com> <8b69ab05d2574a69802c1d5e5c3cc0c1@DLB-XCHPW03.dolby.net> X-Mailer: Apple Mail (2.3251) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 7D03C120180.AE018 X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.099, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: Gordon Bechtel , "detnet@ietf.org" , Olivier Marce Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 06:57:08 -0000 --Apple-Mail=_840F1A82-BA99-4265-BC91-85C59212E9E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think we=E2=80=99re still talking about symmetrical latencies. There are still multiple possibilities. IF we assume that the network = can provide both minimum and maximum latency guarantees, then I would = ask the network what it=E2=80=99s max latency is in both directions, = then pick max/min values to demand of the network that are not much = larger than the slowest max latency of the two directions. If the = network has sufficient buffering, the network will do the work of = matching the latencies. If the network doesn=E2=80=99t have the buffering, then yes, the app has = to do the buffering. =E2=80=94 Norm > On Oct 31, 2016, at 5:03 PM, Grossman, Ethan A. = wrote: >=20 > Hi Gordy, Norm, Olivier, WG, > I understand the consensus is: > 1) The network must be able to report its capabilities for = latency (presumably both min and max, thus bounding jitter). > 2) The application must add its own delays to a =E2=80=9Cfaster=E2=80= =9D path to match a =E2=80=9Cslower=E2=80=9D path if it needs to. > =20 > If anyone has any other understanding or input, please reply. > Thanks, > Ethan. > =20 > From: detnet [mailto:detnet-bounces@ietf.org = ] On Behalf Of Gordon Bechtel > Sent: Thursday, October 06, 2016 8:56 AM > To: Olivier Marce > Cc: detnet@ietf.org > Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching > =20 > Seems to me that the question of latency metrics can be resolved in = the same way Norm suggested for timing and bandwidth: Let the network = report on what it is capable of (with whatever metrics this group feels = makes sense) and let the application decide how best to use (or not use) = the network. > =20 > In the particular case of matched latencies, the network should report = the latency metrics for each direction of the flow, and the application = can decide if this is sufficient. Some applications need symmetric = latencies (it sounds like the utility applications do) and some don't. = But the network doesn't know that. Only the application does. > =20 > Gordy > =20 > On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce > wrote: > Hi, > I have the feeling that expressing min latency in addition to max = latency is a loose way to express jitter control. > There is a tradeoff between latency/jitter constraints and = protection/paths redundancies: one could not expect having the same = latency and jitter for one single path, than for multiple concurrent = paths. > As such jitter should be dependent of level of protections i.e. more = paths, higher acceptable jitter. >=20 > I do not see (yet) any reason for having similar latency on send and = return paths. >=20 > Regards >=20 > Le 06/10/2016 =C3=A0 03:43, nfinn a =C3=A9crit : > The architecture draft still mentions both minimum and maximum latency > as specifiable. In some sense, that solves the problem. The issue, = of > course, is picking the minimum and maximum numbers. Perhaps there is > some way to provide clues to the app so it can pick suitable numbers. >=20 > Bit, as I think about it, bi-directional latency equality is not at = all > trivial to maintain. The existing TSN standards report latency, = instead > of satisfying a requirement for latency. The imagined use (by me, > anyway) of a max latency parameter is to allow the network to change > topology, or reroute a stream, or add higher-priority flows, and still > guarantee the max latency is met. If, by bidirectional latency > matching, you mean, =E2=80=9Cmake both slow if one is slow, and = vice-versa,=E2=80=9D I > don=E2=80=99t know how to do that. If you mean =E2=80=9Cmeet min and = max latency > specifications for the flow=E2=80=9D, then were on the right track, = already. >=20 > =E2=80=94 Norm >=20 > On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. > >> wrote: >=20 > Statement: > Latency matching =E2=80=93 single- or bi-directional. The Utilities = use case > needs this, but is this something we need to address in DetNet? >=20 > Discussion (oldest first): >=20 > Ethan Grossman wrote: > This came up because at least one use case mentioned a need for > multiple outgoing paths (or the send and return paths) to have matched > latencies. I suppose one way to do this is to specify a latency which > is the minimum, and the add delay to the other path(s) to match it =E2=80= =93 > but does this happen at the DetNet level or is it something the > application layer would do? >=20 > Pascal Thubert wrote: > This seems related to the in-order packets delivery item. A tight > latency control can be useful to maintain that order. But doesn=E2=80=99= t this > imply Time triggered operations? > We could also add that feature of voluntary latency addition, probably > associated to jitter elimination. > --------------------------------------------------------- >=20 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > > MailScanner has detected a possible fraud attempt from = "urldefense.proofpoint.com" claiming to = behttps://www.ietf.org/mailman/listinfo/detnet = >=20 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > MailScanner has detected a possible fraud attempt from = "urldefense.proofpoint.com" claiming to = behttps://www.ietf.org/mailman/listinfo/detnet = >=20 > --=20 > Olivier Marc=C3=A9 > Nokia Bell Labs France > "we need to guard against increased levels of reporting and other > requirements that distract you from doing what you really need to be = doing." Rajeev Suri, Nokia CEO, April 2016 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > MailScanner has detected a possible fraud attempt from = "urldefense.proofpoint.com" claiming to = behttps://www.ietf.org/mailman/listinfo/detnet = > =20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_840F1A82-BA99-4265-BC91-85C59212E9E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think we=E2=80=99re still talking about symmetrical = latencies.

There are = still multiple possibilities.  IF we assume that the network can = provide both minimum and maximum latency guarantees, then I would ask = the network what it=E2=80=99s max latency is in both directions, then = pick max/min values to demand of the network that are not much larger = than the slowest max latency of the two directions.  If the network = has sufficient buffering, the network will do the work of matching the = latencies.

If = the network doesn=E2=80=99t have the buffering, then yes, the app has to = do the buffering.

=E2=80=94 Norm

On = Oct 31, 2016, at 5:03 PM, Grossman, Ethan A. <eagros@dolby.com> = wrote:

Hi Gordy, Norm, Olivier, WG,
I understand the consensus is:
1)      The network must be able to report its = capabilities for latency (presumably both min and max, thus bounding = jitter).
2)      The application must add its own delays to = a =E2=80=9Cfaster=E2=80=9D path to match a =E2=80=9Cslower=E2=80=9D path = if it needs to.
 
If anyone = has any other understanding or input, please reply.
Thanks,
Ethan.
 
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf = Of Gordon = Bechtel
Sent: Thursday, October 06, 2016 = 8:56 AM
To: Olivier Marce
Cc: detnet@ietf.org
Subject: Re: [Detnet] DetNet Use = Case Statements - Latency matching
 
Seems to me that the = question of latency metrics can be resolved in the same way Norm = suggested for timing and bandwidth: Let the network report on what it is capable of = (with whatever metrics this group feels makes sense) and let the = application decide how best to use (or not = use) the network.
 
In the particular case of matched latencies, the = network should report the latency metrics for each direction of the = flow, and the application can decide if this is sufficient.  Some = applications need symmetric latencies (it sounds like the utility = applications do) and some don't.  But the network doesn't know = that.  Only the application does.
 
Gordy
 
On Thu, Oct 6, 2016 at 4:16 AM, Olivier = Marce <Olivier.Marce@nokia.com> wrote:
Hi,I have the feeling that expressing min latency in addition = to max latency is a loose way to express jitter control.
There is a tradeoff between latency/jitter constraints and = protection/paths redundancies: one could not expect having the same = latency and jitter for one single path, than for multiple concurrent = paths.
As such jitter should be dependent of level of = protections i.e. more paths, higher acceptable jitter.

I do not see (yet) any reason for having similar latency on = send and return paths.

Regards

Le 06/10/2016 =C3=A0 03:43, nfinn a =C3=A9crit = :

The = architecture draft still mentions both minimum and maximum latency
as specifiable.  In some sense, that solves the = problem.  The issue, of
course, is picking the = minimum and maximum numbers.  Perhaps there is
some = way to provide clues to the app so it can pick suitable numbers.

Bit, as I think about it, bi-directional = latency equality is not at all
trivial to maintain.  = The existing TSN standards report latency, instead
of = satisfying a requirement for latency.  The imagined use (by me,
anyway) of a max latency parameter is to allow the network to = change
topology, or reroute a stream, or add = higher-priority flows, and still
guarantee the max latency = is met.  If, by bidirectional latency
matching, you = mean, =E2=80=9Cmake both slow if one is slow, and vice-versa,=E2=80=9D = I
don=E2=80=99t know how to do that.  If you mean = =E2=80=9Cmeet min and max latency
specifications for the = flow=E2=80=9D, then were on the right track, already.

=E2=80=94 Norm

On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. <eagros@dolby.com
<mailto:eagros@dolby.com>> wrote:

Statement:
Latency matching =E2=80=93 single- = or bi-directional. The Utilities use case
needs this, but = is this something we need to address in DetNet?

Discussion (oldest first):

Ethan = Grossman wrote:
This came up because at least one use case = mentioned a need for
multiple outgoing paths (or the send = and return paths) to have matched
latencies. I suppose one = way to do this is to specify a latency which
is the = minimum, and the add delay to the other path(s) to match it =E2=80=93
but does this happen at the DetNet level or is it something = the
application layer would do?

Pascal Thubert wrote:
This seems related to the = in-order packets delivery item. A tight
latency control = can be useful to maintain that order. But doesn=E2=80=99t this
imply Time triggered operations?
We could also = add that feature of voluntary latency addition, probably
associated to jitter elimination.
---------------------------------------------------------



_______________________________________________
detnet mailing list
detnet@ietf.org <mailto:detnet@ietf.org>MailScanner has = detected a possible fraud attempt from "urldefense.proofpoint.com" = claiming to = behttps://www.ietf.org/mailman/listinfo/detnet




_______________________________________________
detnet mailing list
detnet@ietf.org
MailScanner has = detected a possible fraud attempt from "urldefense.proofpoint.com" = claiming to = behttps://www.ietf.org/mailman/listinfo/detnet


-- 
Olivier Marc=C3=A9
Nokia Bell Labs France
"we need to guard against increased levels of reporting = and other
requirements that = distract you from doing what you really need to be doing." Rajeev Suri, = Nokia CEO, April 2016


_______________________________________________
detnet mailing list
detnet@ietf.org
MailScanner has = detected a possible fraud attempt from "urldefense.proofpoint.com" = claiming to = behttps://www.ietf.org/mailman/listinfo/detnet
 
_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_840F1A82-BA99-4265-BC91-85C59212E9E4-- From nobody Mon Oct 31 23:59:20 2016 Return-Path: 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 B465C129537 for ; Mon, 31 Oct 2016 23:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumni.caltech.edu 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 Bn_AP08k6mDE for ; Mon, 31 Oct 2016 23:59:16 -0700 (PDT) Received: from mail.alumni.caltech.edu (mail.alumni.caltech.edu [131.215.242.114]) by ietfa.amsl.com (Postfix) with ESMTP id E2AB812942F for ; Mon, 31 Oct 2016 23:59:15 -0700 (PDT) Received: from [192.168.1.104] (c-24-4-25-128.hsd1.ca.comcast.net [24.4.25.128]) (Authenticated sender: nfinn@alumni.caltech.edu) by mail.alumni.caltech.edu (Postfix) with ESMTPSA id 859D6120480; Mon, 31 Oct 2016 23:59:10 -0700 (PDT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.alumni.caltech.edu 859D6120480 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alumni.caltech.edu; s=enforce; t=1477983551; bh=CP2pt6GziHzfwT5JKEZaaxL43YgGnDKOrc7c9LwvTEo=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date: In-Reply-To:Cc:To:References; b=UGbddFi7retQ2Jj4xOWitrUrvbObEQ4VT7XxmPEdIoOjPsmRmZFtXQ4frAG9fSicV 9SEz9wq7CnxPgYDjmURLI9DhKMLJaYQpYyQRmU0P9PCPkyODMOLnQXZhA+uMG/cFYf ZeLjBGhAn+djjCasLf1ca7lyaXvSBizOrXZRtp0Q= From: nfinn Message-Id: <0CDAEFE4-1125-4C93-B9AB-F090596EE66B@alumni.caltech.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1FE9C6CD-2693-46F4-9BA9-993F16CF8392" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Mon, 31 Oct 2016 23:59:09 -0700 In-Reply-To: <6211952161fe433a93219e8fe14f88bb@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." References: <8620772c4ff1410ca6281384696a791b@DLB-XCHPW03.dolby.net> <89124517-CB41-4AAD-A6D9-96DBB57324E3@alumni.caltech.edu> <2c9cfd1f09b84ad4808871c9bcaf540b@XCH-RCD-001.cisco.com> <6211952161fe433a93219e8fe14f88bb@DLB-XCHPW03.dolby.net> X-Mailer: Apple Mail (2.3251) X-MailScanner-Information-Alumni: X-Alumni-MailScanner-ID: 859D6120480.AEF7E X-MailScanner-Alumni: No Virii found X-Spam-Status-Alumni: not spam, SpamAssassin (not cached, score=-1.099, required 5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00) X-MailScanner-From: nfinn@alumni.caltech.edu Archived-At: Cc: Pascal Thubert , "detnet@ietf.org" , Olivier Marce Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 06:59:19 -0000 --Apple-Mail=_1FE9C6CD-2693-46F4-9BA9-993F16CF8392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think that=E2=80=99s a very good summary of my preferred approach. Is = it satisfactory for you? =E2=80=94 Norm > On Oct 31, 2016, at 4:53 PM, Grossman, Ethan A. = wrote: >=20 > Hi Pascal, Olivier, Norm, WG, > So the consensus is, to paraphrase Norm:=20 >=20 > 1) Make sure that the time protocols are able to report, along with = the time, the accuracy provided. =20 > 2) The application will decide whether that is sufficient. =20 > 3) The accuracy reported will likely consist of several parameters = (frequency accuracy, absolute accuracy, etc.). =20 > 4) Different time protocols may have different parameters for = accuracy. =20 > 5) An application might care about one or more of those parameters. =20= > 6) An application might then operate in one of various modes, = depending on the accuracy provided. =20 >=20 > If anyone has any other understanding or input, please reply. > Thanks, > Ethan. >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org = ] On Behalf Of Pascal Thubert (pthubert) > Sent: Tuesday, October 11, 2016 4:29 AM > To: Olivier Marce; detnet@ietf.org > Subject: Re: [Detnet] DetNet Use Case Statements - How to express app = time accuracy and reliability needs? >=20 > This is my understanding too, Olivier.=20 >=20 > Also, time-related work is done elsewhere, whether one thinks of IETF = or outside the IETF. We do not want to be taken in the middle of that = storm. > Best can do is probably state requirements, but for all I know we are = using time as an information provided by external means, as opposed to = managing it. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org = ] On Behalf Of Olivier Marce > Sent: jeudi 6 octobre 2016 12:05 > To: detnet@ietf.org > Subject: Re: [Detnet] DetNet Use Case Statements - How to express app = time accuracy and reliability needs? >=20 > Hi, > I'm in favor of Norm' position: DetNet should concentrate on = reliable, on-time delivery of packets. Time accuracy is required for = DetNet but out of scope, as many solutions exist and is not only a = networking topic. > At most, DetNet could provide some reference examples on how providing = required time accuracy. >=20 >=20 > Regards >=20 > Le 06/10/2016 =C3=A0 03:30, nfinn a =C3=A9crit : >> Interesting question. >>=20 >> It seems more useful to me to make sure that the time protocols are=20= >> able to report, along with the time, the accuracy provided. The=20 >> application can then decide whether that is sufficient. The accuracy=20= >> reported will likely consist of several parameters (frequency=20 >> accuracy, absolute accuracy, etc.). Different time protocols may = have=20 >> different parameters for accuracy. The application might worried=20 >> about one or the other of those parameters. It might operate in=20 >> different modes, depending on the accuracy provided. I don't see the=20= >> value in moving the decision point anywhere else. >>=20 >> With DetNet, one can imagine a bandwidth reservation crossing a=20 >> boundary between two different master clock domains. My inclination=20= >> would be to disallow that, at least for now. Given an application=20 >> that runs for long enough, any frequency difference between source = and=20 >> sink will eventually cause starvation or overflow. >>=20 >> All that said, let's suppose that you have a solid use case that is=20= >> expected to *try* to run across clock domain boundaries, and we want=20= >> to prevent that when it won't work. This could be solved by an=20 >> application-level protocol that exchanges clock domain information. >> This could be solved by configuring the network controller to=20 >> disallow domain crossings. This could be handled by parameters in = the=20 >> reservation protocol, as you suggest, so that the controller can = allow=20 >> some reservations but not others. I'll leave it to timing experts to=20= >> pick some number of appropriate parameters. >>=20 >> One last consideration - Are you sure that all applications that have=20= >> these timing requirements also require bandwidth reservations? I'm=20= >> not sure of that. And, if not, a protocol separate from the = bandwidth=20 >> reservation might be indicated. >>=20 >> - Norm >>=20 >>> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. >> >> wrote: >>>=20 >>> Hi Folks, >>>=20 >>> As of our IETF 96 meeting there were still a couple of Use Case=20 >>> Statements that I would like clarity on. Here's the first, remaining=20= >>> to follow in separate emails. >>>=20 >>> Question: >>> How will an application express its time accuracy and reliability=20 >>> needs? Is that within scope of DetNet? >>>=20 >>> Discussion: >>> In AVB/TSN when an application (talker) attempts to make a stream=20 >>> reservation it must state how much bandwidth that stream reservation=20= >>> requires. Presumably in a LAN this is sufficient since a LAN=20 >>> presumably has consistent time accuracy and reliability metrics. >>>=20 >>> For DetNet, in which we support interconnected DetNet networks and=20= >>> have widely varying requirements for timing accuracy and reliability=20= >>> depending on the use case, it appears to me that we need to allow an=20= >>> application to provide this kind of information to the network, and = a=20 >>> way for the network to either agree or decline to provide the=20 >>> requested service (analogous to AVB/TSN accepting or declining a=20 >>> stream reservation based on the bandwidth requested). >>>=20 >>> We have had some discussion about this (see below) but nothing near=20= >>> consensus. Other thoughts from anyone? >>> Ethan. >>>=20 >>> -------------------------------- >>> Discussion, oldest item first: >>>=20 >>> Ethan Grossman wrote: >>> Timekeeping - the only explicit DetNet Ask for this is in the use=20 >>> cases is in M2M as "Precise time synchronization accuracy (1us)" and=20= >>> I think the intent (as in other use cases) is that the DetNet Ask is=20= >>> for a way to specify the required accuracy, not how to achieve that = accuracy. >>>=20 >>> Norm Finn wrote: >>> Timekeeping is an essential part of many, probably most, of the=20 >>> applications that also find DetNet useful. That having been said, = so=20 >>> is protection against EMI and electrical power saving. Let's=20 >>> concentrate DetNet on reliable, on-time delivery of packets. I'm = not=20 >>> even sure that "a way to specify the required accuracy" need be in = scope. >>>=20 >>> Rodney Cummings wrote: >>> I rarely disagree with Norm, but on this point I'll have to quibble = a bit. >>> I agree that we don't need DetNet to specify how time sync is=20 >>> accomplished. There are plenty of IEEE 1588 techniques (and similar)=20= >>> for that purpose. >>> I also agree that we should concentrate on reliable, on-time = delivery=20 >>> of packets (i.e. worst-case latency). >>> If I don't know how accurate my time sync is, then how do I know = when=20 >>> a packet is delivered on time? If I don't know the reliability of my=20= >>> time sync, how can I reliably measure that packet delivery? >>> Almost all (if not 100%) of DetNet use cases require time sync at = the=20 >>> end systems to some degree of accuracy. I agree that we don't need = to=20 >>> address the implementation of that time sync, but the application=20 >>> requirements are needed for time sync (including reliability) just = as=20 >>> much as for packet delivery. >>> -------------------------------- >>>=20 >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >=20 >>> https://www.ietf.org/mailman/listinfo/detnet = >>=20 >>=20 >>=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet = >>=20 >=20 > -- > Olivier Marc=C3=A9 > Nokia Bell Labs France > "we need to guard against increased levels of reporting and other = requirements that distract you from doing what you really need to be = doing." Rajeev Suri, Nokia CEO, April 2016 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = --Apple-Mail=_1FE9C6CD-2693-46F4-9BA9-993F16CF8392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think that=E2=80=99s a very good summary of my preferred = approach.  Is it satisfactory for you?

=E2=80=94 Norm

On = Oct 31, 2016, at 4:53 PM, Grossman, Ethan A. <eagros@dolby.com> = wrote:

Hi Pascal, Olivier, Norm, WG,
So the consensus = is, to paraphrase Norm: 

1) Make sure that the time protocols are = able to report, along with the time, the accuracy provided. =  
2) The application will decide whether that is = sufficient.  
3) The accuracy reported will likely consist of = several parameters (frequency accuracy, absolute accuracy, etc.). =  
4) Different time protocols may have different = parameters for accuracy.  
5) An application might care about one or = more of those parameters.  
6) An application might then operate in = one of various modes, depending on the accuracy provided. =  

If anyone has any = other understanding or input, please reply.
Thanks,
Ethan.

-----Original Message-----
From: detnet = [mailto:detnet-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: Tuesday, October 11, 2016 4:29 = AM
To: Olivier Marce; detnet@ietf.org
Subject: Re: = [Detnet] DetNet Use Case Statements - How to express app time accuracy = and reliability needs?

This is my understanding too, Olivier. 

Also, time-related work is done = elsewhere, whether one thinks of IETF or outside the IETF. We do not = want to be taken in the middle of that storm.
Best can do is = probably state requirements, but for all I know we are using time as an = information provided by external means, as opposed to managing = it.

Cheers,

Pascal

-----Original Message-----
From: detnet = [mailto:detnet-bounces@ietf.org] On Behalf Of = Olivier Marce
Sent: jeudi 6 octobre 2016 12:05
To: detnet@ietf.org
Subject: Re: = [Detnet] DetNet Use Case Statements - How to express app time accuracy = and reliability needs?

Hi,
I'm in favor of Norm' position: DetNet = should concentrate on  reliable, on-time delivery of packets. Time = accuracy is required for DetNet but out of scope, as many solutions = exist and is not only a networking topic.
At most, DetNet could provide some = reference examples on how providing required time accuracy.


Regards

Le 06/10/2016 =C3=A0 03:30, nfinn a =C3=A9crit = :
Interesting question.

It seems more useful to me to make sure that = the time protocols are 
able to = report, along with the time, the accuracy provided.  The 
application = can then decide whether that is sufficient.  The accuracy 
reported = will likely consist of several parameters (frequency 
accuracy, = absolute accuracy, etc.).  Different time protocols may have 
different = parameters for accuracy.  The application might worried 
about one or = the other of those parameters.  It might operate in 
different = modes, depending on the accuracy provided.  I don't see the 
value in = moving the decision point anywhere else.

With= DetNet, one can imagine a bandwidth reservation crossing a 
boundary = between two different master clock domains.  My inclination 
would be to = disallow that, at least for now.  Given an application 
that runs = for long enough, any frequency difference between source and 
sink will = eventually cause starvation or overflow.

All = that said, let's suppose that you have a solid use case that is 
expected to = *try* to run across clock domain boundaries, and we want 
to prevent = that when it won't work.  This could be solved by an 
application-level protocol that exchanges clock domain = information.
This could be solved by configuring the = network controller to 
disallow = domain crossings.  This could be handled by parameters in the 
reservation = protocol, as you suggest, so that the controller can allow 
some = reservations but not others.  I'll leave it to timing experts = to 
pick = some number of appropriate parameters.

One = last consideration - Are you sure that all applications that have 
these timing = requirements also require bandwidth reservations?  I'm 
not sure of = that.  And, if not, a protocol separate from the bandwidth 
reservation = might be indicated.

- Norm

On Oct 5, 2016, at 4:09 = PM, Grossman, Ethan A. <eagros@dolby.com 
<mailto:eagros@dolby.com>> wrote:

Hi Folks,

As of our IETF 96 = meeting there were still a couple of Use Case 
Statements = that I would like clarity on. Here's the first, remaining 
to follow in = separate emails.

Question:
How = will an application express its time accuracy and reliability 
needs? Is = that within scope of DetNet?

Discussion:
In AVB/TSN when an application (talker) attempts to make a = stream 
reservation it must state how much bandwidth that stream = reservation 
requires. Presumably in a LAN this is sufficient since a = LAN 
presumably has consistent time accuracy and reliability = metrics.

For DetNet, in which we support = interconnected DetNet networks and 
have widely = varying requirements for timing accuracy and reliability 
depending on = the use case, it appears to me that we need to allow an 
application = to provide this kind of information to the network, and a 
way for the = network to either agree or decline to provide the 
requested = service (analogous to AVB/TSN accepting or declining a 
stream = reservation based on the bandwidth requested).

We have had some discussion about this (see below) but = nothing near 
consensus. Other thoughts from anyone?
Ethan.

--------------------------------
Discussion, oldest item first:

Ethan Grossman wrote:
Timekeeping - the only = explicit DetNet Ask for this is in the use 
cases is in = M2M as "Precise time synchronization accuracy (1us)" and 
I think the = intent (as in other use cases) is that the DetNet Ask is 
for a way to = specify the required accuracy, not how to achieve that accuracy.

Norm Finn wrote:
Timekeeping is = an essential part of many, probably most, of the 
applications = that also find DetNet useful.  That having been said, so 
is = protection against EMI and electrical power saving. Let's 
concentrate = DetNet on reliable, on-time delivery of packets.  I'm not 
even sure = that "a way to specify the required accuracy" need be in scope.

Rodney Cummings wrote:
I rarely = disagree with Norm, but on this point I'll have to quibble a bit.
I agree that we don't need DetNet to specify how time sync = is 
accomplished. There are plenty of IEEE 1588 techniques (and = similar) 
for that purpose.
I also agree that we should = concentrate on reliable, on-time delivery 
of packets = (i.e. worst-case latency).
If I don't know how accurate my = time sync is, then how do I know when 
a packet is = delivered on time? If I don't know the reliability of my 
time sync, = how can I reliably measure that packet delivery?
Almost = all (if not 100%) of DetNet use cases require time sync at the 
end systems = to some degree of accuracy. I agree that we don't need to 
address the = implementation of that time sync, but the application 
requirements = are needed for time sync (including reliability) just as 
much as for = packet delivery.
--------------------------------

_______________________________________________
detnet mailing list
detnet@ietf.org <mailto:detnet@ietf.org> 
https://www.ietf.org/mailman/listinfo/detnet



_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


--
Olivier Marc=C3=A9
Nokia Bell Labs = France
"we need to guard against increased levels of = reporting and other requirements that distract you from doing what you = really need to be doing." Rajeev Suri, Nokia CEO, April 2016

_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing = list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

= --Apple-Mail=_1FE9C6CD-2693-46F4-9BA9-993F16CF8392--