From nobody Tue Jul 11 23:21:59 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8D212EC34 for ; Tue, 11 Jul 2017 23:21:54 -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] autolearn=unavailable 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 qI8o1YIkEBLm for ; Tue, 11 Jul 2017 23:21:53 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E473712EC19 for ; Tue, 11 Jul 2017 23:21:49 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B2F90340DB7; Wed, 12 Jul 2017 08:21:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.16961); Wed, 12 Jul 2017 08:21:48 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 12 Jul 2017 08:21:48 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 23479494; Wed, 12 Jul 2017 08:21:48 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_A7BE1DFC-36AF-425E-A861-42A8165102AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 12 Jul 2017 08:21:47 +0200 Message-Id: Cc: panrg@irtf.org To: tsv-area@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 06:21:54 -0000 --Apple-Mail=_A7BE1DFC-36AF-425E-A861-42A8165102AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We'll be having a first meeting of the proposed Path Aware Networking = (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress = Hall 3. Since bringing path awareness to the endpoint has been the = focus, at least in part, of a couple of running TSV working groups = (MPTCP, TAPS), this RG seems to be of general interest to the transport = area. Olivier Bonaventure will give a review and overview of research = to date in this space, and Adrian Perrig will present a fully path-aware = Internet architecture, as an illustration of what is possible when = path-awareness is promoted to a first-order goal. =46rom our proposed charter = (https://datatracker.ietf.org/group/panrg/about): The Internet architecture assumes a division between the end-to-end functionality of the transport layer and the properties of the path = between the endpoints. The path is assumed to be invisible, homogeneous, singular, = with dynamics solely determined by the connectivity of the endpoints and the = Internet control plane. Endpoints have very little information about the paths = over which their traffic is carried, and no control at all beyond the destination = address. Increased diversity in access networks, and ubiquitous mobile = connectivity, have made this architecture's assumptions about paths less tenable. Multipath protocols taking advantage of this mobile connectivity begin to show us = a way forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available = to them. This research group aims to support research in bringing path awareness = to transport and application layer protocols, and to bring research in this = space to the attention of the Internet engineering and protocol design = community. The scope of work within the RG includes, but is not strictly limited = to: - communication and discovery of information about the properties of a = path on local networks and in internetworks, exploration of trust and risk = models associated with this information, and algorithms for path selection at endpoints based on this information. - algorithms for making transport-layer scheduling decisions based on information about path properties. - algorithms for reconciling path selection at endpoints with widely = deployed routing protocols and network operations best practices. The research group's scope overlaps with existing IETF and IRTF efforts, = and will collaborate with groups chartered to work on multipath transport = protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected = environments (ICCRG), and alternate routing architectures (e.g. LISP), and is related = to the questions raised in the multiple recent BoF sessions that have = addressed path awareness and multiply-connected networks (e.g. SPUD, PLUS, = BANANA). he PAN(P)RG intends to meet at each IETF meeting until a determination is made whether or not to charter it. Afterward, the RG = intends to meet at 1-3 IETF meetings per year, and hold one workshop per year, = colocated with a related academic conference. --Apple-Mail=_A7BE1DFC-36AF-425E-A861-42A8165102AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZZb/8AAoJEIoSt78L6kajC4cP/2gZ5CGCu+kThZ9O9/YjGOqM 3zMsjomGhISjXrd8AkzEO0hAk2MFjDToE3ig21HayjsN04wmcNtU15zFO+l5BDo5 B3h8NynFCiAOcbjWLkCIEHUWOFaVgXEP8TUweS7N+7eG5wDftTnzT+xZ0CXTCzOa jn3OwfcTS2DijeVZG6PRq8crZLsxZNXJ5tryQmoV8V6a8G6ytWmbqImD3W2YNGHH fqXDgZ2TCxyaM3q+a2muBG8M2Nk97EvdkbvE30Bdxe1mNrc/eDHsSK35FNP9luvq t5zLZ+pnRZ2ABGT/lw8IA9QxMj1xMUa6OPT+YcsGSi2xS4jvttJOyQUDrBJq+9NH D+aXKLJQyl4QUaCMwD3+Dl4Wlg3H75CIOwZ40cgLyKvPVxxQJkmKzLpl1oD5UuEP pbtrUFbYoNaPWDyk4ZKHBnQkUMmsPHGWE2IgLWFDsd38oNI29hBSJ50/juEzoQES 662ocjiakWKRXfaq6KmOn2tKXtwgZL+XIfprL+A5gccWW9cImz8ronvIyQZWnzoY 4r/BMBkek6mqluMjSgghmMDKfJh4Lm9DwQ2ZWIXiqyX189M/AM8P6qIuT3l2drrk h/coyZDsrW+C2qIOLUiaJKhUMitx7AhghETmfLLn2czwq+GRUnSeb9W4HPoGPCJF f29Vs8EDrm3rQtKqW4eN =daET -----END PGP SIGNATURE----- --Apple-Mail=_A7BE1DFC-36AF-425E-A861-42A8165102AE-- From nobody Wed Jul 12 01:47:05 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5961F12EC3B for ; Wed, 12 Jul 2017 01:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 lb4ItcojSqUg for ; Wed, 12 Jul 2017 01:46:57 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6A512ECBC for ; Wed, 12 Jul 2017 01:46:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,349,1496127600"; d="asc'?scan'208";a="200072922" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 12 Jul 2017 01:21:36 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Jul 2017 01:41:54 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 12 Jul 2017 01:41:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FoiWiWvYOPO3yVflfzddq36JY9+wqkRffyE+EucmBKY=; b=nFcO9Mzj+X4DSqjnVJ1fTfk1ItmaUYfdFha7qV+mqU77gmPhSFF31G12+zZzh5sDL/0x5N60Cr4c/pZ8fMix3Kh5SX3jjnHrAIuUhLFg47xSTnxCUSs3KEBpIb9xo+F1ojvB7sy+deR0pyhV2vRP8mPXI1GUPe8T1TnGmIj2Cg4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 12 Jul 2017 08:41:52 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1261.015; Wed, 12 Jul 2017 08:41:52 +0000 From: "Eggert, Lars" To: "Brian Trammell (IETF)" CC: "tsv-area@ietf.org" , "panrg@irtf.org" Thread-Topic: Proposed Path Aware Networking RG Thread-Index: AQHS+tcy4ngGgCSlmUu3yRy9qWXA+aJP37uA Date: Wed, 12 Jul 2017 08:41:52 +0000 Message-ID: <9C7D5582-E8F7-43C8-A8C3-543E48C66EBC@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: trammell.ch; dkim=none (message not signed) header.d=none;trammell.ch; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 7:41JrqqMr1G4Oi2dAnEZ+fEpSWUpW9BdZPt+1WMkOn2y8XpncZZvVbgJaZzrEEiU7HvnhN9EQp/QA1ARMGFHBswuYTFYFgMoylTiP+61bGXaUr4z5PKzeI79puJ9utnzGRBdZv0jvXmqsf2HWLxq+XuRfZuOnAJR2ZNTCyOWIIeDBz7u72SP5/yb3msHCUrnQK3596AaPEVOaHR2Wf2YTS3R6npPSny11pPoZ0o0x0G8eBlfkzTqD9zjPsCPOcvS4y6i2W3zI2lKupTe+wcULNJMijJLdNX2OuEAoaLxX/9TWkXmp3I8LEbFBcP6HTx84tLWw/a6zU8bf27ExsheUKEERWVmGbNUThVNv0WqtwMOoMX+uuQ7WFLnOLBjZ1OApfVHJG+catEQTg3gsH4M6PtDmPfUQoH/RWZPnO/dPLEJiwxBgz+e608OaxMJVif2I69Cp2l4C5Z13BG4H4Nf6s8yRYIdZhJyCdxi5fx+PCWI1BXXj3bi4REDVgnr2CT3ihT9/oJ2LahyzUtmDampY39KmTgTAmGea0YiiSk3vE1g6LIiCDfkawACmyRTUrpmDuvds/5I3l7lgaEeZV//11vUctVU5S26/pJNtkUmj5maJ4Yoc3H222edr8JPq4hOU1yfxBcbtpqBHsZvz4lf3YunkuEfks9Qe1Q1DW1/nKEyjoYACIAZ+2EAE47E1LKTYHPjGrkAuO/scmoVkjU/5EsgOIHXWoc64VBakOHKGpZyLItqcXq9m4Lrf7Z+L0u8ufS2NZyvN22/RXeZooTND3gPrrs1PIRb4f0s0f3Jj6L8= x-ms-office365-filtering-correlation-id: 477d23d5-2f7d-4485-3bfe-08d4c901d854 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-exchange-antispam-report-test: UriScan:(133145235818549)(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39850400002)(39410400002)(39840400002)(377424004)(24454002)(99286003)(86362001)(54906002)(6486002)(36756003)(3846002)(305945005)(53936002)(6116002)(102836003)(6512007)(478600001)(76176999)(50986999)(33656002)(77096006)(6306002)(83716003)(7736002)(8676002)(6436002)(6506006)(25786009)(81166006)(3660700001)(50226002)(966005)(8936002)(6916009)(57306001)(2950100002)(53546010)(99936001)(3280700002)(14454004)(66066001)(110136004)(38730400002)(4001150100001)(6246003)(2900100001)(229853002)(4326008)(2906002)(189998001)(82746002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A7019CB5-CABD-4025-B55C-4E029A5FA3B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 08:41:52.6850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:46:58 -0000 --Apple-Mail=_A7019CB5-CABD-4025-B55C-4E029A5FA3B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-7-12, at 8:21, Brian Trammell (IETF) wrote: > This research group aims to support research in bringing path = awareness to > transport and application layer protocols, and to bring research in = this space > to the attention of the Internet engineering and protocol design = community. there was a bunch of work related to a "TERNLI" (Transport-Enhancing = Refinements to the Network Layer Interface) BOF attempt about ten years = ago that may be relevant (and older work referred to by it). = Specifically: * https://www.ietf.org/proceedings/66/slides/intarea-3.pdf * https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01 * https://www.ietf.org/proceedings/66/slides/MobOpts-4/sld1.htm * https://tools.ietf.org/html/rfc4907 by the IAB Other folks may have other pointers from that time? Lars --Apple-Mail=_A7019CB5-CABD-4025-B55C-4E029A5FA3B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlll4M8ACgkQVLXDCb9w wVeSmxAA0EJ+sA8KRChcBus3UnRLsUboKPnJ5SY6Z6NgBZk4+CexwCJ8RlQZbIlZ Jas67s43UFdvdU7BWfkddFR+UQzrWRq/fR74sqasZ6U15QRbn/OdA056ou3COOpz p5Kh5aNEAIyvZ+1o7bqh90sXbpcP+YUTta6nik7IJWlmQ5Lu+mjmR/5ak4t/fbUY 8bmv+wFIhhrbKn8AFN7IWur6JUUpscYbo2ZEJKB/DYO0CflTHvGGRaeYE7UfjqPE RTr5rdWR7RYnHqWibvwuMsFLd76E52/AckPSHVdA81L6CSA7fWY/XkR+ZowF05cH MnRZrs2oeIWQGKtVsCbEUbZSi7Ka/Ih+mEphYN1oiLrU9b0PT885aZ9LDDXvK1ox /mmMC1V3EntmOPumM9jNPLXoZ/aScqwv0DhVVczymC35jHAy2F6TZItavRju0CbH gJQZpcJC6OUiZCwjn2mLXxOaua9GK6afc//Myo9+MZjVUWYz+ATZI2mQqkH5aZIb yYXpT8Sjr/foAU0TI2oDVImw6EeeGlrsj/YnIq4NwrE/33eXivnPCwY2YWfkPCK8 Y6tJUG8yGh83WHDl96Q4g0udHkM5CKbqqV2DR8hzYO3bhcUzJ7vKtTLhChxHxfWO Iw+eFG/gPvLwYe55Ug39Zy1IpeSHbeLCYt2OW6BNRcnBSNKg84I= =gVFT -----END PGP SIGNATURE----- --Apple-Mail=_A7019CB5-CABD-4025-B55C-4E029A5FA3B8-- From nobody Wed Jul 12 05:52:59 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F21E13189A for ; Wed, 12 Jul 2017 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 kBk1soDAlpIo for ; Wed, 12 Jul 2017 05:52:49 -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 32087131896 for ; Wed, 12 Jul 2017 05:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TD/WZxouYAKuUIE4pSd5IVXm8VGOwbFObMqEJLmGu/Q=; b=e7MA9dNwABq4Ze+mZXT7+++T3b 9mN6Pak63pCaiq+2XVHIesAcjH6eaIoZSamx8ShsRXQjckmjZESgt7ZJE9bXFfm22JyPXEqOAVYD9 GFt0BbIr0+do0peT9CydFNzhOGNOnNxRsXHZvLaualsEdvUWkwandeEwj+SBVmgMa2haKLGp7Daw4 6WniSrQVch82KYCd4XYU0+F5zmkNScD8UeFRZar3gQXgglcmuXdu1WDrFI1wO8Sn01Lp0Ou9P1M2L 3B6gucNDlMcR2Ait952vLkPY9QrxKa9KrctO+WA1DZ0xq1l9yxi6z28eEXE4Q0LgsnggY7qMaNpFb 6nWepVMQ==; Received: from [31.185.128.124] (port=44906 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dVH8J-0004Ig-Bh; Wed, 12 Jul 2017 13:52:47 +0100 To: "Brian Trammell (IETF)" , tsv-area@ietf.org Cc: panrg@irtf.org References: From: Bob Briscoe Message-ID: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> Date: Wed, 12 Jul 2017 13:52:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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 - irtf.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: Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:52:53 -0000 Brian, 1/ The IRTF sounds like a good landing point for all the previous attempts to get the IETF to add path-awareness protocols. BTW, this goes back a lot further than SPUD. A good summary of pre-2007 efforts in this space is in a section of Pasi's draft on this from 2007: https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and TERNLI (2006). [I wrote this before seeing Lars's email pointing to TERNLI] 2/ The advantages of opacity (invisibility) of path characteristics should also be in scope. In general the tone of the text seems to be "awareness = good; unawareness = bad". If I have detected this tone correctly, it would represent an implicit value judgement; which would not be a good starting point for research. * You've alluded to potential security advantages in the phrase "exploration of trust and risk models". * There are also evolvability advantages. I recall David Clark (I think) saying that the rudimentary interface between transport and network was a feature not a bug. Admittedly it's a pain for the transport to have to discover available path capacity, path delay, etc. However, the alternative would have been to require all L2 technologies to be able to give information that would require them to make assumptions about the transport. That in turn would ossify transports and L2 technologies. We might be saying that the Internet is moving into a new phase where performance is now more important than evolvability. That's a point to debate, but I know you, at least, still believe that stack evolution will remain important. Bob On 12/07/17 07:21, Brian Trammell (IETF) wrote: > Greetings, all, > > We'll be having a first meeting of the proposed Path Aware Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3. Since bringing path awareness to the endpoint has been the focus, at least in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG seems to be of general interest to the transport area. Olivier Bonaventure will give a review and overview of research to date in this space, and Adrian Perrig will present a fully path-aware Internet architecture, as an illustration of what is possible when path-awareness is promoted to a first-order goal. > > From our proposed charter (https://datatracker.ietf.org/group/panrg/about): > > The Internet architecture assumes a division between the end-to-end > functionality of the transport layer and the properties of the path between the > endpoints. The path is assumed to be invisible, homogeneous, singular, with > dynamics solely determined by the connectivity of the endpoints and the Internet > control plane. Endpoints have very little information about the paths over which > their traffic is carried, and no control at all beyond the destination address. > > Increased diversity in access networks, and ubiquitous mobile connectivity, have > made this architecture's assumptions about paths less tenable. Multipath > protocols taking advantage of this mobile connectivity begin to show us a way > forward, though: if endpoints cannot control the path, at least they can > determine the properties of the path by choosing among paths available to them. > > This research group aims to support research in bringing path awareness to > transport and application layer protocols, and to bring research in this space > to the attention of the Internet engineering and protocol design community. > > The scope of work within the RG includes, but is not strictly limited to: > > - communication and discovery of information about the properties of a path on > local networks and in internetworks, exploration of trust and risk models > associated with this information, and algorithms for path selection at > endpoints based on this information. > > - algorithms for making transport-layer scheduling decisions based on > information about path properties. > > - algorithms for reconciling path selection at endpoints with widely deployed > routing protocols and network operations best practices. > > The research group's scope overlaps with existing IETF and IRTF efforts, and > will collaborate with groups chartered to work on multipath transport protocols > (MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments > (ICCRG), and alternate routing architectures (e.g. LISP), and is related to > the questions raised in the multiple recent BoF sessions that have addressed > path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA). > > he PAN(P)RG intends to meet at each IETF meeting until a > determination is made whether or not to charter it. Afterward, the RG intends to > meet at 1-3 IETF meetings per year, and hold one workshop per year, colocated > with a related academic conference. > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jul 12 08:30:27 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DA1316DA for ; Wed, 12 Jul 2017 08:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 3sPz1AN0dlpK for ; Wed, 12 Jul 2017 08:30:24 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 3721F12F4EA for ; Wed, 12 Jul 2017 08:30:24 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id f194so8184586yba.3 for ; Wed, 12 Jul 2017 08:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TbBih1wMMCK3h31tDxxqWHrdKhbacHrDvM12nBDA5cs=; b=tkcjaDZcQXPbaueJzQ+OfeVUNkIKHzTB/HsQIwGgajpzeKVDDZM0V1jbP4eyS2RaN1 RbMnIxEQV/sAraGdGK68nWPLHrnYvr9vWEWVwVr01IxtL4/RPvob0dH13L3nbKHF+CQw 4qEK6FbI6+DJou8swgOzPdbRth+py5ziM3SJIrJ1f9JEqMHfzhiUhLRKcbABI5cLVBx2 kJZPlpx6EP+GGH7IxsfM0rtGpE64UTN3Z5W1E4yStTDplRflnUKzhfETWhsIStuSE+Ny fd+sEwJ4d0HGZ1gAi6QllUa7gty8hia0Wnb83VTdHSAjRf6GQZlIces+RdYY5qU7qEEW KX9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TbBih1wMMCK3h31tDxxqWHrdKhbacHrDvM12nBDA5cs=; b=bpSXlzuAskynohR6iI/TdGHnBQSA0KR1cF4uw6jvwFqPzokNbqB9mKiW2jWFnBQFwp zsTvOuAt8mqtoXAQdzWVj+npSjQAA1bukyPZ1GXw6PrTXNCT8M46N2uuCBqZr0z5zq7z v5u+g4mnr/65XT6O3lfMI1tZ9dNKNYtSgC17JFeYI1z110aNyKXexCytSzlC+BWacmkf wtkmRHMgD8S39ZRLFJV+82A6JCImaPgS+l6dqSANMmNdL1YkV0Wnjysgc0aebjSziuMc /U630k5MWQxzL2aLdGgda+r74caRqNryne13TqB9eRAv/xlqeZj1CoRIspYm2tVBXYNp hWjA== X-Gm-Message-State: AIVw112Kx60RJ1K1tEBqpKtF0HmI9yNQmpHDfX9xV2818kWUfGkb9yxK 0jnTfcNeCIGOLa23VBDcEC6J/6kEuw== X-Received: by 10.37.101.138 with SMTP id z132mr1180401ybb.176.1499873423303; Wed, 12 Jul 2017 08:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 12 Jul 2017 08:30:22 -0700 (PDT) In-Reply-To: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> References: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> From: Spencer Dawkins at IETF Date: Wed, 12 Jul 2017 10:30:22 -0500 Message-ID: To: Bob Briscoe Cc: "Brian Trammell (IETF)" , "tsv-area@ietf.org >> tsv-area@ietf.org" , panrg@irtf.org Content-Type: multipart/alternative; boundary="001a1142fd809ab2b20554207e78" Archived-At: Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 15:30:27 -0000 --001a1142fd809ab2b20554207e78 Content-Type: text/plain; charset="UTF-8" Brian, Bob, and Lars, On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe wrote: > Brian, > > 1/ The IRTF sounds like a good landing point for all the previous attempts > to get the IETF to add path-awareness protocols. > > BTW, this goes back a lot further than SPUD. A good summary of pre-2007 > efforts in this space is in a section of Pasi's draft on this from 2007: > https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 > , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and > TERNLI (2006). > > [I wrote this before seeing Lars's email pointing to TERNLI] > > > 2/ The advantages of opacity (invisibility) of path characteristics should > also be in scope. > > In general the tone of the text seems to be "awareness = good; unawareness > = bad". If I have detected this tone correctly, it would represent an > implicit value judgement; which would not be a good starting point for > research. > > * You've alluded to potential security advantages in the phrase > "exploration of trust and risk models". > > * There are also evolvability advantages. I recall David Clark (I think) > saying that the rudimentary interface between transport and network was a > feature not a bug. Admittedly it's a pain for the transport to have to > discover available path capacity, path delay, etc. However, the alternative > would have been to require all L2 technologies to be able to give > information that would require them to make assumptions about the > transport. That in turn would ossify transports and L2 technologies. > > We might be saying that the Internet is moving into a new phase where > performance is now more important than evolvability. That's a point to > debate, but I know you, at least, still believe that stack evolution will > remain important. > > > Bob > > > On 12/07/17 07:21, Brian Trammell (IETF) wrote: > >> Greetings, all, >> >> We'll be having a first meeting of the proposed Path Aware Networking >> (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall >> 3. Since bringing path awareness to the endpoint has been the focus, at >> least in part, of a couple of running TSV working groups (MPTCP, TAPS), >> this RG seems to be of general interest to the transport area. Olivier >> Bonaventure will give a review and overview of research to date in this >> space, and Adrian Perrig will present a fully path-aware Internet >> architecture, as an illustration of what is possible when path-awareness is >> promoted to a first-order goal. >> >> From our proposed charter (https://datatracker.ietf.org/ >> group/panrg/about): >> >> The Internet architecture assumes a division between the end-to-end >> functionality of the transport layer and the properties of the path >> between the >> endpoints. The path is assumed to be invisible, homogeneous, singular, >> with >> dynamics solely determined by the connectivity of the endpoints and the >> Internet >> control plane. Endpoints have very little information about the paths >> over which >> their traffic is carried, and no control at all beyond the destination >> address. >> >> Increased diversity in access networks, and ubiquitous mobile >> connectivity, have >> made this architecture's assumptions about paths less tenable. Multipath >> protocols taking advantage of this mobile connectivity begin to show us a >> way >> forward, though: if endpoints cannot control the path, at least they can >> determine the properties of the path by choosing among paths available to >> them. >> >> This research group aims to support research in bringing path awareness to >> transport and application layer protocols, and to bring research in this >> space >> to the attention of the Internet engineering and protocol design >> community. >> >> The scope of work within the RG includes, but is not strictly limited to: >> >> - communication and discovery of information about the properties of a >> path on >> local networks and in internetworks, exploration of trust and risk >> models >> associated with this information, and algorithms for path selection at >> endpoints based on this information. >> >> - algorithms for making transport-layer scheduling decisions based on >> information about path properties. >> >> - algorithms for reconciling path selection at endpoints with widely >> deployed >> routing protocols and network operations best practices. >> >> The research group's scope overlaps with existing IETF and IRTF efforts, >> and >> will collaborate with groups chartered to work on multipath transport >> protocols >> (MPTCP, QUIC, TSVWG), congestion control in multiply-connected >> environments >> (ICCRG), and alternate routing architectures (e.g. LISP), and is related >> to >> the questions raised in the multiple recent BoF sessions that have >> addressed >> path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA). >> >> he PAN(P)RG intends to meet at each IETF meeting until a >> determination is made whether or not to charter it. Afterward, the RG >> intends to >> meet at 1-3 IETF meetings per year, and hold one workshop per year, >> colocated >> with a related academic conference. > > Brian, thank you for taking this on, in the first place. We've been dancing around the topic in the IETF for a while, and if I've learned anything from attending that dance, this isn't engineering (yet) and isn't IETF timescale (yet). So, the IRTF seems appropriate. Lars and Bob, thank you for the pointers to prior art. I was aware of some of that (for better or worse, I co-chaired the TRIGTRAN BoF, but co-chairing PILC might have made up for some of that), but certainly not all of it, and much of what you two named happened while I was off doing RAI stuff after PILC concluded. I look forward to the first PANRG session in Prague, and I'll encourage TSV area chairs to consider whether PANRG should be on their conflict lists for future IETF meetings. Travel safely, and I'll see many of you next week. Spencer, as TSV AD and at-large IRSG member --001a1142fd809ab2b20554207e78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian, Bob, and Lars,

On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe <ietf@= bobbriscoe.net> wrote:
Bria= n,

1/ The IRTF sounds like a good landing point for all the previous attempts = to get the IETF to add path-awareness protocols.

BTW, this goes back a lot further than SPUD. A good summary of pre-2007 eff= orts in this space is in a section of Pasi's draft on this from 2007: <= a href=3D"https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#s= ection-6" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/= draft-sarolahti-tsvwg-crosslayer-01#section-6 , which reminds= us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and TERNLI (2006).
[I wrote this before seeing Lars's email pointing to TERNLI]


2/ The advantages of opacity (invisibility) of path characteristics should = also be in scope.

In general the tone of the text seems to be "awareness =3D good; unawa= reness =3D bad". If I have detected this tone correctly, it would repr= esent an implicit value judgement; which would not be a good starting point= for research.

* You've alluded to potential security advantages in the phrase "e= xploration of trust and risk models".

* There are also evolvability advantages. I recall David Clark (I think) sa= ying that the rudimentary interface between transport and network was a fea= ture not a bug. Admittedly it's a pain for the transport to have to dis= cover available path capacity, path delay, etc. However, the alternative wo= uld have been to require all L2 technologies to be able to give information= that would require them to make assumptions about the transport. That in t= urn would ossify transports and L2 technologies.

We might be saying that the Internet is moving into a new phase where perfo= rmance is now more important than evolvability. That's a point to debat= e, but I know you, at least, still believe that stack evolution will remain= important.


Bob


On 12/07/17 07:21, Brian Trammell (IETF) wrote:
Greetings, all,

We'll be having a first meeting of the proposed Path Aware Networking (= PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3.= Since bringing path awareness to the endpoint has been the focus, at least= in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG = seems to be of general interest to the transport area.=C2=A0 Olivier Bonave= nture will give a review and overview of research to date in this space, an= d Adrian Perrig will present a fully path-aware Internet architecture, as a= n illustration of what is possible when path-awareness is promoted to a fir= st-order goal.

=C2=A0From our proposed charter (https://datatracker.i= etf.org/group/panrg/about):

The Internet architecture assumes a division between the end-to-end
functionality of the transport layer and the properties of the path between= the
endpoints. The path is assumed to be invisible, homogeneous, singular, with=
dynamics solely determined by the connectivity of the endpoints and the Int= ernet
control plane. Endpoints have very little information about the paths over = which
their traffic is carried, and no control at all beyond the destination addr= ess.

Increased diversity in access networks, and ubiquitous mobile connectivity,= have
made this architecture's assumptions about paths less tenable. Multipat= h
protocols taking advantage of this mobile connectivity begin to show us a w= ay
forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available to t= hem.

This research group aims to support research in bringing path awareness to<= br> transport and application layer protocols, and to bring research in this sp= ace
to the attention of the Internet engineering and protocol design community.=

The scope of work within the RG includes, but is not strictly limited to:
- communication and discovery of information about the properties of a path= on
=C2=A0 local networks and in internetworks, exploration of trust and risk m= odels
=C2=A0 associated with this information, and algorithms for path selection = at
=C2=A0 endpoints based on this information.

- algorithms for making transport-layer scheduling decisions based on
=C2=A0 information about path properties.

- algorithms for reconciling path selection at endpoints with widely deploy= ed
=C2=A0 routing protocols and network operations best practices.

The research group's scope overlaps with existing IETF and IRTF efforts= , and
will collaborate with groups chartered to work on multipath transport proto= cols
(MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments=
(ICCRG), and alternate routing architectures (e.g. LISP), and is related to=
the questions raised in the multiple recent BoF sessions that have addresse= d
path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA).
he PAN(P)RG intends to meet at each IETF meeting until a
determination is made whether or not to charter it. Afterward, the RG inten= ds to
meet at 1-3 IETF meetings per year, and hold one workshop per year, colocat= ed
with a related academic conference.

Brian, thank you for taking this on, in the first place. = We've been dancing around the topic in the IETF for a while, and if I&#= 39;ve learned anything from attending that dance, this isn't engineerin= g (yet) and isn't IETF timescale (yet). So, the IRTF seems appropriate.=

Lars and Bob, thank you for the pointers to prior= art. I was aware of some of that (for better or worse, I co-chaired the TR= IGTRAN BoF, but co-chairing PILC might have made up for some of that), but = certainly not all of it, and much of what you two named happened while I wa= s off doing RAI stuff after PILC concluded.

I look= forward to the first PANRG session in Prague, and I'll encourage TSV a= rea chairs to consider whether PANRG should be on their conflict lists for = future IETF meetings.

Travel safely, and I'll = see many of you next week.

Spencer, as TSV AD and = at-large IRSG member=C2=A0
--001a1142fd809ab2b20554207e78-- From nobody Wed Jul 12 15:06:57 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8784C12EBF7 for ; Wed, 12 Jul 2017 15:06:55 -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] 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 QZ2_ztGa-WTt for ; Wed, 12 Jul 2017 15:06:52 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FFD129B36 for ; Wed, 12 Jul 2017 15:06:52 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D8DB3340F10; Thu, 13 Jul 2017 00:06:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.25441); Thu, 13 Jul 2017 00:06:50 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 13 Jul 2017 00:06:50 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 23573224; Thu, 13 Jul 2017 00:06:50 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F23FB6CD-D8BA-424F-8098-391050EEC20C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> Date: Thu, 13 Jul 2017 00:06:49 +0200 Cc: tsv-area@ietf.org, panrg@irtf.org Message-Id: <29837BC0-02A5-4445-B0CE-67B4B6105245@trammell.ch> References: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> To: Bob Briscoe , Lars Eggert X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 22:06:55 -0000 --Apple-Mail=_F23FB6CD-D8BA-424F-8098-391050EEC20C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Bob, (hi Lars), > On 12 Jul 2017, at 14:52, Bob Briscoe wrote: >=20 > Brian, >=20 > 1/ The IRTF sounds like a good landing point for all the previous = attempts to get the IETF to add path-awareness protocols. >=20 > BTW, this goes back a lot further than SPUD. A good summary of = pre-2007 efforts in this space is in a section of Pasi's draft on this = from 2007: = https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 = , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and = TERNLI (2006). >=20 > [I wrote this before seeing Lars's email pointing to TERNLI] Of course, and thanks to the pointers (also to the list). Previous efforts here (indeed, including my own) seem to be focused on = cross-layer approaches and involve signaling across the layer boundary. = MPTCP shows that path-aware protocols can be implemented, albeit in a = limited fashion, without such signaling. So I think the scope is a = little bigger here. > 2/ The advantages of opacity (invisibility) of path characteristics = should also be in scope. >=20 > In general the tone of the text seems to be "awareness =3D good; = unawareness =3D bad". If I have detected this tone correctly, it would = represent an implicit value judgement; which would not be a good = starting point for research. Possibly. I'm taking the fact that this theme winds through an array of = current work in the IETF as an indication that awareness is something = that is being driven toward, so if it's not "good", then it's at least = something we need to be ready for. Perhaps the language is a bit = boosterish, though. > * You've alluded to potential security advantages in the phrase = "exploration of trust and risk models". Here, what I think needs exploration is "how can you ensure that the = information flow, implicit or explicit, in path-aware architectures or = (even partially) path-aware technologies is trustworthy, and that the = level of exposure is appropriate?" You could, of course, implement path = awareness at the transport layer without any signaling across layers at = all. This is how MPTCP works. Anytime you do add signaling for path = awareness, the trust establishment problem comes up. PLUS included an = attempt to sidestep this through severe restrictions on the vocabulary, = and I still think that's a field worth exploring in more concrete = detail. Another way to do this is to derive path property information = from a (secure, trusted) control plane; SCION does this, albeit with a = somewhat different architecture than the Internet presently follows. > * There are also evolvability advantages. I recall David Clark (I = think) saying that the rudimentary interface between transport and = network was a feature not a bug. Admittedly it's a pain for the = transport to have to discover available path capacity, path delay, etc. = However, the alternative would have been to require all L2 technologies = to be able to give information that would require them to make = assumptions about the transport. That in turn would ossify transports = and L2 technologies. ... which are, of course, not ossified now. ;) I think we paid a price = here and didn't get the full benefit, but that's with the benefit of a = bit more hindsight. >=20 > We might be saying that the Internet is moving into a new phase where = performance is now more important than evolvability. That's a point to = debate, but I know you, at least, still believe that stack evolution = will remain important. I would personally say that a core requirement of anything that comes = out of PANRG and into the IETF is that it be evolvability-preserving, = but that's me, and as you say, that belief is I think obvious from my = body of work on the subject. But yes, this is another axis to bring = under discussion. Thanks, cheers, Brian >=20 > Bob >=20 > On 12/07/17 07:21, Brian Trammell (IETF) wrote: >> Greetings, all, >>=20 >> We'll be having a first meeting of the proposed Path Aware Networking = (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress = Hall 3. Since bringing path awareness to the endpoint has been the = focus, at least in part, of a couple of running TSV working groups = (MPTCP, TAPS), this RG seems to be of general interest to the transport = area. Olivier Bonaventure will give a review and overview of research to = date in this space, and Adrian Perrig will present a fully path-aware = Internet architecture, as an illustration of what is possible when = path-awareness is promoted to a first-order goal. >>=20 >> =46rom our proposed charter = (https://datatracker.ietf.org/group/panrg/about): >>=20 >> The Internet architecture assumes a division between the end-to-end >> functionality of the transport layer and the properties of the path = between the >> endpoints. The path is assumed to be invisible, homogeneous, = singular, with >> dynamics solely determined by the connectivity of the endpoints and = the Internet >> control plane. Endpoints have very little information about the paths = over which >> their traffic is carried, and no control at all beyond the = destination address. >>=20 >> Increased diversity in access networks, and ubiquitous mobile = connectivity, have >> made this architecture's assumptions about paths less tenable. = Multipath >> protocols taking advantage of this mobile connectivity begin to show = us a way >> forward, though: if endpoints cannot control the path, at least they = can >> determine the properties of the path by choosing among paths = available to them. >>=20 >> This research group aims to support research in bringing path = awareness to >> transport and application layer protocols, and to bring research in = this space >> to the attention of the Internet engineering and protocol design = community. >>=20 >> The scope of work within the RG includes, but is not strictly limited = to: >>=20 >> - communication and discovery of information about the properties of = a path on >> local networks and in internetworks, exploration of trust and risk = models >> associated with this information, and algorithms for path selection = at >> endpoints based on this information. >>=20 >> - algorithms for making transport-layer scheduling decisions based on >> information about path properties. >>=20 >> - algorithms for reconciling path selection at endpoints with widely = deployed >> routing protocols and network operations best practices. >>=20 >> The research group's scope overlaps with existing IETF and IRTF = efforts, and >> will collaborate with groups chartered to work on multipath transport = protocols >> (MPTCP, QUIC, TSVWG), congestion control in multiply-connected = environments >> (ICCRG), and alternate routing architectures (e.g. LISP), and is = related to >> the questions raised in the multiple recent BoF sessions that have = addressed >> path awareness and multiply-connected networks (e.g. SPUD, PLUS, = BANANA). >>=20 >> he PAN(P)RG intends to meet at each IETF meeting until a >> determination is made whether or not to charter it. Afterward, the RG = intends to >> meet at 1-3 IETF meetings per year, and hold one workshop per year, = colocated >> with a related academic conference. >>=20 >>=20 >=20 > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > Panrg mailing list > Panrg@irtf.org > https://www.irtf.org/mailman/listinfo/panrg --Apple-Mail=_F23FB6CD-D8BA-424F-8098-391050EEC20C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZZp15AAoJEIoSt78L6kajR5MQAKnJr3tR8560VPrCHCUZnrQt hVvt7to6M9M7TX4fHFB1+lFGn2McHWZH9dDfySzniffBjtwV06b5syfifgg/UkfE C03hghvHoLbzVZ3meIC/o4tIX95gtLZZNtxT6kKaGUft9bv/oHwcGE3Jyu/z/zD1 KikNUBL2zZU0DxM9X6D021wVt5B6LzGiN01wmJY1TTRMKrITWp5IlHnP7pit3aoA HCdRwRAyh+Ytq/93VI1Q9eYBYkxQr+u324ffv61izFsBwpGs1OeU11+2UoMKTyux SSaBRoI869YpY1Fdcxf/vrVtrBYQCNrlkXtq15KVDbbT2L4keZ4Rgd7qBZeF9P8/ CMItathyovi84bOm2da5i4Rq8QTpsmeSdLj59bxMxIoffdL18mqzHlAq/pyDB3AI cN5sS3YbBSz+/Vi10m61fX+FT4S2CPPJfwVMrlKPLO+7TMTQT0/YsPlFObBmppcv 6hk8ecRIH24V1OvpZ1I3s3btNFLkCl9pTQH/vGlGdFZ8e8mwqRHUWJHk3syX8yoL oe/1ICE7De4lworUYLtz5TU8YvW6eJYJApTJBWIegNvJTZpMnyRzDKoio/H2TYot hr6V3UqAoXsQMv1TGMctFBTb2n+1uDj0Zimc1mHKxeUNyr+GyM09NmQ7pK2IjrRs a8FAJQe2TKK/l7ZkCqvz =86ex -----END PGP SIGNATURE----- --Apple-Mail=_F23FB6CD-D8BA-424F-8098-391050EEC20C-- From nobody Thu Jul 13 06:42:05 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B694131A70 for ; Thu, 13 Jul 2017 06:41:59 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 UFSV3dTPRAUc for ; Thu, 13 Jul 2017 06:41:55 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B501F131A6F for ; Thu, 13 Jul 2017 06:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3x7cS167vLz15LZJ; Thu, 13 Jul 2017 15:41:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjHi4D3sqybI; Thu, 13 Jul 2017 15:41:51 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC212C.dip0.t-ipconnect.de [93.236.33.44]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 13 Jul 2017 15:41:50 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <29837BC0-02A5-4445-B0CE-67B4B6105245@trammell.ch> Date: Thu, 13 Jul 2017 15:41:49 +0200 Cc: Bob Briscoe , Lars Eggert , tsv-area@ietf.org, panrg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> <29837BC0-02A5-4445-B0CE-67B4B6105245@trammell.ch> To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 13:42:00 -0000 Hi all, I would like to add one point because I was involved in the scope = discussion for this proposed research group early on. Other than with = the efforts listed below, this activity does not focus on protocol (or = interface) design. It's rather about mechanisms, especially for path = selection, that can use this kind of path information if available, = or/and to figure what the information is that we need to exchange in = existing or new protocols to realize the proposed mechanism. These = mechanisms may be very similar in different scenarios that are already = consider in various existing working groups but usually out of scope for = those working groups as in the IETF the focus is on protocol design. So = hopefully this research group can be a good supplement for existing and = future IETF working in this space. Mirja > Am 13.07.2017 um 00:06 schrieb Brian Trammell (IETF) = : >=20 > hi Bob, (hi Lars), >=20 >> On 12 Jul 2017, at 14:52, Bob Briscoe wrote: >>=20 >> Brian, >>=20 >> 1/ The IRTF sounds like a good landing point for all the previous = attempts to get the IETF to add path-awareness protocols. >>=20 >> BTW, this goes back a lot further than SPUD. A good summary of = pre-2007 efforts in this space is in a section of Pasi's draft on this = from 2007: = https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 = , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and = TERNLI (2006). >>=20 >> [I wrote this before seeing Lars's email pointing to TERNLI] >=20 > Of course, and thanks to the pointers (also to the list). >=20 > Previous efforts here (indeed, including my own) seem to be focused on = cross-layer approaches and involve signaling across the layer boundary. = MPTCP shows that path-aware protocols can be implemented, albeit in a = limited fashion, without such signaling. So I think the scope is a = little bigger here. >=20 >> 2/ The advantages of opacity (invisibility) of path characteristics = should also be in scope. >>=20 >> In general the tone of the text seems to be "awareness =3D good; = unawareness =3D bad". If I have detected this tone correctly, it would = represent an implicit value judgement; which would not be a good = starting point for research. >=20 > Possibly. I'm taking the fact that this theme winds through an array = of current work in the IETF as an indication that awareness is something = that is being driven toward, so if it's not "good", then it's at least = something we need to be ready for. Perhaps the language is a bit = boosterish, though. >=20 >> * You've alluded to potential security advantages in the phrase = "exploration of trust and risk models". >=20 > Here, what I think needs exploration is "how can you ensure that the = information flow, implicit or explicit, in path-aware architectures or = (even partially) path-aware technologies is trustworthy, and that the = level of exposure is appropriate?" You could, of course, implement path = awareness at the transport layer without any signaling across layers at = all. This is how MPTCP works. Anytime you do add signaling for path = awareness, the trust establishment problem comes up. PLUS included an = attempt to sidestep this through severe restrictions on the vocabulary, = and I still think that's a field worth exploring in more concrete = detail. Another way to do this is to derive path property information = from a (secure, trusted) control plane; SCION does this, albeit with a = somewhat different architecture than the Internet presently follows. >=20 >> * There are also evolvability advantages. I recall David Clark (I = think) saying that the rudimentary interface between transport and = network was a feature not a bug. Admittedly it's a pain for the = transport to have to discover available path capacity, path delay, etc. = However, the alternative would have been to require all L2 technologies = to be able to give information that would require them to make = assumptions about the transport. That in turn would ossify transports = and L2 technologies. >=20 > ... which are, of course, not ossified now. ;) I think we paid a price = here and didn't get the full benefit, but that's with the benefit of a = bit more hindsight. >=20 >>=20 >> We might be saying that the Internet is moving into a new phase where = performance is now more important than evolvability. That's a point to = debate, but I know you, at least, still believe that stack evolution = will remain important. >=20 > I would personally say that a core requirement of anything that comes = out of PANRG and into the IETF is that it be evolvability-preserving, = but that's me, and as you say, that belief is I think obvious from my = body of work on the subject. But yes, this is another axis to bring = under discussion. >=20 > Thanks, cheers, >=20 > Brian >=20 >>=20 >> Bob >>=20 >> On 12/07/17 07:21, Brian Trammell (IETF) wrote: >>> Greetings, all, >>>=20 >>> We'll be having a first meeting of the proposed Path Aware = Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in = Congress Hall 3. Since bringing path awareness to the endpoint has been = the focus, at least in part, of a couple of running TSV working groups = (MPTCP, TAPS), this RG seems to be of general interest to the transport = area. Olivier Bonaventure will give a review and overview of research to = date in this space, and Adrian Perrig will present a fully path-aware = Internet architecture, as an illustration of what is possible when = path-awareness is promoted to a first-order goal. >>>=20 >>> =46rom our proposed charter = (https://datatracker.ietf.org/group/panrg/about): >>>=20 >>> The Internet architecture assumes a division between the end-to-end >>> functionality of the transport layer and the properties of the path = between the >>> endpoints. The path is assumed to be invisible, homogeneous, = singular, with >>> dynamics solely determined by the connectivity of the endpoints and = the Internet >>> control plane. Endpoints have very little information about the = paths over which >>> their traffic is carried, and no control at all beyond the = destination address. >>>=20 >>> Increased diversity in access networks, and ubiquitous mobile = connectivity, have >>> made this architecture's assumptions about paths less tenable. = Multipath >>> protocols taking advantage of this mobile connectivity begin to show = us a way >>> forward, though: if endpoints cannot control the path, at least they = can >>> determine the properties of the path by choosing among paths = available to them. >>>=20 >>> This research group aims to support research in bringing path = awareness to >>> transport and application layer protocols, and to bring research in = this space >>> to the attention of the Internet engineering and protocol design = community. >>>=20 >>> The scope of work within the RG includes, but is not strictly = limited to: >>>=20 >>> - communication and discovery of information about the properties of = a path on >>> local networks and in internetworks, exploration of trust and risk = models >>> associated with this information, and algorithms for path selection = at >>> endpoints based on this information. >>>=20 >>> - algorithms for making transport-layer scheduling decisions based = on >>> information about path properties. >>>=20 >>> - algorithms for reconciling path selection at endpoints with widely = deployed >>> routing protocols and network operations best practices. >>>=20 >>> The research group's scope overlaps with existing IETF and IRTF = efforts, and >>> will collaborate with groups chartered to work on multipath = transport protocols >>> (MPTCP, QUIC, TSVWG), congestion control in multiply-connected = environments >>> (ICCRG), and alternate routing architectures (e.g. LISP), and is = related to >>> the questions raised in the multiple recent BoF sessions that have = addressed >>> path awareness and multiply-connected networks (e.g. SPUD, PLUS, = BANANA). >>>=20 >>> he PAN(P)RG intends to meet at each IETF meeting until a >>> determination is made whether or not to charter it. Afterward, the = RG intends to >>> meet at 1-3 IETF meetings per year, and hold one workshop per year, = colocated >>> with a related academic conference. >>>=20 >>>=20 >>=20 >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >>=20 >> _______________________________________________ >> Panrg mailing list >> Panrg@irtf.org >> https://www.irtf.org/mailman/listinfo/panrg >=20 > _______________________________________________ > Panrg mailing list > Panrg@irtf.org > https://www.irtf.org/mailman/listinfo/panrg From nobody Fri Jul 14 00:05:31 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449F131451 for ; Wed, 12 Jul 2017 00:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 iVVESFi5fNNi for ; Wed, 12 Jul 2017 00:19:50 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30132.outbound.protection.outlook.com [40.107.3.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420EE12F3CB for ; Wed, 12 Jul 2017 00:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VPhv0MJgU+nZCRIHb4VkZSpjOqZMavZJrSnd6cctYVc=; b=W5MISDSa6Ug2dWRcGn2DWl11BqAJccD8/HLlsswYenZ+BzLBAwLHy3kWfQMv2mg8uElm1Nu89yJGO8cBDFmFzQ2bwggKk6D3skvIBvq2CmtMU5n55Kbzb6hcNsQk3V17EUptW7OnIWjAW6XHGuVAXB48e760gkHG8pXKdvQNej8= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2305.eurprd07.prod.outlook.com (10.169.152.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 12 Jul 2017 07:19:48 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1261.015; Wed, 12 Jul 2017 07:19:48 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "Brian Trammell (IETF)" , "tsv-area@ietf.org" CC: "panrg@irtf.org" Thread-Topic: Proposed Path Aware Networking RG Thread-Index: AQHS+tcpACGGUFDVR0OwCDGqRwgd8KJPx3Pw Date: Wed, 12 Jul 2017 07:19:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: trammell.ch; dkim=none (message not signed) header.d=none;trammell.ch; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.203.142.91] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2305; 7:FQBFqV/BnaCbYBFL9rxBd9b3kmWb4HjWOk4D9qJfFG96VOPE4kXZuAn+Qxwth3HZDPTV4N2eLAj4E1vz9dFnqh683QRP/9G8HkoUG7wYHMWDNohsWAZqxm4hvjjkxnPwIuibYYhooBOF1usadoH1TXj3PVvgw0aaiv34JlwSk9UcgTe25W9vORt20IQwUoUvFQeH0Qj2Kdj0JkWYwVh+beIy7qUG7Ky2D6KMjlEHq5kT/vk8FpNJzIub6fwE9W7p2V+RV2S+wJG+L1dW6jFNL/udJJU43m+a6nwctJC/oQQE2eOkiJcEB+Rn9GwFGbBoZ2WIwIB6dxOvGlYsdLcyVAm32z9QnGVblLmAJPN08DGhvodTLae7h212jPmvVp1DWYP+B3g24DsvqO4dLGaiT3xmK8UKY/tDWuFLpeQ7nWIRRc48Z8IDxQ6ateNm1xV9A2cwKNnuMTXWtQd9M7y4B4L1WMcsMMkXiM3wfwcBo8EDevxaybfV+4U57WSquFj5pf0/LXrjVuu9La3Fu60qkjfDm/d7iHdxamKhCrSrknqzDHn6eSEKPjy8czdCElbzhkFGMvzDHyFmafvbQv0htkOW0wv7DEScRYkLaLr2Kls0bKqEEH7r6oy4ypuR2+0OpTRHCqI9HoAEFj1VTAhrL6E3Fsb7itGc0V9V/Fk4Tr/FUqVE+eGsZG+f1KCXkILZotKf/9/6aubn+e3d0q0Ih1niF4H9SgBGjCTRN6UKzn2/EcyxVsKVj9qfHOQJtquDMl8t/+vW1PBVQYsinERshq9nnSyEANqHD1b38kHXMFg= x-ms-office365-filtering-correlation-id: 2ad0b1c5-90b0-4797-14d7-08d4c8f66110 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2305; x-ms-traffictypediagnostic: AM5PR0701MB2305: x-exchange-antispam-report-test: UriScan:(133145235818549)(120809045254105)(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2305; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2305; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39860400002)(39840400002)(13464003)(2906002)(81166006)(6306002)(50986999)(76176999)(305945005)(8676002)(9686003)(25786009)(86362001)(54356999)(2900100001)(53546010)(6436002)(3280700002)(6116002)(102836003)(99286003)(8936002)(3846002)(7736002)(66066001)(74316002)(6246003)(3660700001)(14454004)(55016002)(38730400002)(189998001)(229853002)(33656002)(2950100002)(7696004)(478600001)(53936002)(5250100002)(2501003)(5660300001)(4326008)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2305; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 07:19:47.9204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2305 Archived-At: X-Mailman-Approved-At: Fri, 14 Jul 2017 00:05:30 -0700 Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 07:19:54 -0000 Wouldn't it make sense to "liaison" also with the ALTO and (perhaps) the TE= AS working group? In these working groups, quite a number of technologies may already exist t= o solve this sort of problem. Michael > -----Original Message----- > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Brian > Trammell (IETF) > Sent: Mittwoch, 12. Juli 2017 08:22 > To: tsv-area@ietf.org > Cc: panrg@irtf.org > Subject: Proposed Path Aware Networking RG >=20 > Greetings, all, >=20 > We'll be having a first meeting of the proposed Path Aware Networking > (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall > 3. Since bringing path awareness to the endpoint has been the focus, at l= east > in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG > seems to be of general interest to the transport area. Olivier Bonaventu= re > will give a review and overview of research to date in this space, and Ad= rian > Perrig will present a fully path-aware Internet architecture, as an illus= tration > of what is possible when path-awareness is promoted to a first-order goal= . >=20 > From our proposed charter > (https://datatracker.ietf.org/group/panrg/about): >=20 > The Internet architecture assumes a division between the end-to-end > functionality of the transport layer and the properties of the path betwe= en > the endpoints. The path is assumed to be invisible, homogeneous, singular= , > with dynamics solely determined by the connectivity of the endpoints and > the Internet control plane. Endpoints have very little information about = the > paths over which their traffic is carried, and no control at all beyond t= he > destination address. >=20 > Increased diversity in access networks, and ubiquitous mobile connectivit= y, > have made this architecture's assumptions about paths less tenable. > Multipath protocols taking advantage of this mobile connectivity begin to > show us a way forward, though: if endpoints cannot control the path, at l= east > they can determine the properties of the path by choosing among paths > available to them. >=20 > This research group aims to support research in bringing path awareness t= o > transport and application layer protocols, and to bring research in this = space > to the attention of the Internet engineering and protocol design communit= y. >=20 > The scope of work within the RG includes, but is not strictly limited to: >=20 > - communication and discovery of information about the properties of a pa= th > on local networks and in internetworks, exploration of trust and risk mo= dels > associated with this information, and algorithms for path selection at > endpoints based on this information. >=20 > - algorithms for making transport-layer scheduling decisions based on > information about path properties. >=20 > - algorithms for reconciling path selection at endpoints with widely depl= oyed > routing protocols and network operations best practices. >=20 > The research group's scope overlaps with existing IETF and IRTF efforts, = and > will collaborate with groups chartered to work on multipath transport > protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected > environments (ICCRG), and alternate routing architectures (e.g. LISP), an= d is > related to the questions raised in the multiple recent BoF sessions that = have > addressed path awareness and multiply-connected networks (e.g. SPUD, > PLUS, BANANA). >=20 > he PAN(P)RG intends to meet at each IETF meeting until a determination is > made whether or not to charter it. Afterward, the RG intends to meet at 1= -3 > IETF meetings per year, and hold one workshop per year, colocated with a > related academic conference. >=20 From nobody Fri Jul 14 00:05:36 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76D11317B4; Wed, 12 Jul 2017 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 RZrEM_Oxalxw; Wed, 12 Jul 2017 13:20:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4B69713175A; Wed, 12 Jul 2017 13:20:31 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6CKH8UE012523; Wed, 12 Jul 2017 21:20:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=upbRBuqs8TCjKbS1HAEjR0tUH1RmwI2jo3mAOZ8n+sc=; b=Wav8D+15xkDxqpJB1k9WelGWjic+b5JAus4fRCQ2B7KW8qpZtKQ6/0HCCsujzFtqU7DW TzFudyzmyhr/I1D1ZXZskYjp5FgZpKQptsbNXf6xG+dIT02Dp9BKfFgQpTdbGxnmp3Id 1adcQuTCMcnkoc5Ee4Dh+iN+IPOrByyCfKKW3c/c7hZ0Vko3tEzAHSeEIQvjwNQqOrx0 RNJxaWxs0bPDl8TSl1m274dxWLElr4q7Gpr8ZjizZWOPqZhvrQJAumpeaapEYYCKQkm6 KvKc7tVoBOmmFDM9FFUhpI2SBlNUX01xgcdYAabjQCbgqojV96BxNSX5MaWzENGsGIBJ eA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bn0p3pcry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2017 21:20:27 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6CKG3lq011983; Wed, 12 Jul 2017 16:20:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bn0p1uwce-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2017 16:20:26 -0400 Received: from USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 16:20:26 -0400 Received: from [169.254.122.215] (172.19.37.76) by USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) with Microsoft SMTP Server id 15.0.1263.5 via Frontend Transport; Wed, 12 Jul 2017 16:20:26 -0400 From: Aaron Falk To: Brian Trammell CC: , Date: Wed, 12 Jul 2017 16:20:25 -0400 Message-ID: <6FB24CB8-CE47-4EA3-8FA9-2DF4754958B6@akamai.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707120327 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707120328 Archived-At: X-Mailman-Approved-At: Fri, 14 Jul 2017 00:05:30 -0700 Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 20:20:41 -0000 This sounds interesting and I’m glad to see a place for this work to be addressed in this community. It does make me sad that PANARG (a proposed RG and kind of a BoF) is up against IDEAS (an actual BoF). Indeed, the Venn diagram of path-aware networking and identity-locator split have some overlap in my mind. YMMV, of course. —aaron On 12 Jul 2017, at 2:21, Brian Trammell (IETF) wrote: > Greetings, all, > > We'll be having a first meeting of the proposed Path Aware Networking > (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress > Hall 3. Since bringing path awareness to the endpoint has been the > focus, at least in part, of a couple of running TSV working groups > (MPTCP, TAPS), this RG seems to be of general interest to the > transport area. Olivier Bonaventure will give a review and overview > of research to date in this space, and Adrian Perrig will present a > fully path-aware Internet architecture, as an illustration of what is > possible when path-awareness is promoted to a first-order goal. > > From our proposed charter > (https://datatracker.ietf.org/group/panrg/about): > > The Internet architecture assumes a division between the end-to-end > functionality of the transport layer and the properties of the path > between the > endpoints. The path is assumed to be invisible, homogeneous, singular, > with > dynamics solely determined by the connectivity of the endpoints and > the Internet > control plane. Endpoints have very little information about the paths > over which > their traffic is carried, and no control at all beyond the destination > address. > > Increased diversity in access networks, and ubiquitous mobile > connectivity, have > made this architecture's assumptions about paths less tenable. > Multipath > protocols taking advantage of this mobile connectivity begin to show > us a way > forward, though: if endpoints cannot control the path, at least they > can > determine the properties of the path by choosing among paths available > to them. > > This research group aims to support research in bringing path > awareness to > transport and application layer protocols, and to bring research in > this space > to the attention of the Internet engineering and protocol design > community. > > The scope of work within the RG includes, but is not strictly limited > to: > > - communication and discovery of information about the properties of a > path on > local networks and in internetworks, exploration of trust and risk > models > associated with this information, and algorithms for path selection > at > endpoints based on this information. > > - algorithms for making transport-layer scheduling decisions based on > information about path properties. > > - algorithms for reconciling path selection at endpoints with widely > deployed > routing protocols and network operations best practices. > > The research group's scope overlaps with existing IETF and IRTF > efforts, and > will collaborate with groups chartered to work on multipath transport > protocols > (MPTCP, QUIC, TSVWG), congestion control in multiply-connected > environments > (ICCRG), and alternate routing architectures (e.g. LISP), and is > related to > the questions raised in the multiple recent BoF sessions that have > addressed > path awareness and multiply-connected networks (e.g. SPUD, PLUS, > BANANA). > > he PAN(P)RG intends to meet at each IETF meeting until a > determination is made whether or not to charter it. Afterward, the RG > intends to > meet at 1-3 IETF meetings per year, and hold one workshop per year, > colocated > with a related academic conference. From nobody Fri Jul 14 00:05:40 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DA2131947 for ; Wed, 12 Jul 2017 14:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 pR7-1JN0HUOA for ; Wed, 12 Jul 2017 14:07:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3696131788 for ; Wed, 12 Jul 2017 14:07:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO DFWEML703-CAH.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFV27293; Wed, 12 Jul 2017 16:07:07 -0500 (CDT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by DFWEML703-CAH.china.huawei.com (10.193.5.177) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 14:07:05 -0700 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Wed, 12 Jul 2017 14:07:03 -0700 From: Linda Dunbar To: Spencer Dawkins at IETF , Bob Briscoe CC: "tsv-area@ietf.org >> tsv-area@ietf.org" , "panrg@irtf.org" Thread-Topic: [Panrg] Proposed Path Aware Networking RG Thread-Index: AQHS+tcxZjtjAVRELkusKPtT/3b8C6JQmywAgAAsCwD//+aOUA== Date: Wed, 12 Jul 2017 21:07:02 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593FAB70@SJCEML702-CHM.china.huawei.com> References: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.171] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6593FAB70SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 14 Jul 2017 00:05:30 -0700 Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:07:12 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6593FAB70SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXNu4oCZdCBJbi1CYW5kIE9BTSBzdXBwb3NlZCB0byBleHBvc2UgdGhlIGFjdHVhbCBQYXRoIElu Zm9ybWF0aW9uPw0KDQpNb3JlIGFuZCBtb3JlIHNlcnZpY2VzIG5lZWQgdG8ga25vdyBuZXR3b3Jr IGRlbGF5ICYgcGF0aCBpbmZvcm1hdGlvbi4gVGhhdCBpcyB3aHkgdGhlcmUgYXJlIHNvIG1hbnkg bmV0d29yayBtb25pdG9yaW5nIGNvbXBhbmllcyBwb3BwaW5nIHVwIGluIG9mZmVyaW5nIGRlbGF5 IGFuZCBvdGhlciBjaGFyYWN0ZXJpc3RpY3Mgb2YgbmV0d29yayB0byBlbmQgcG9pbnRzLg0KDQpI b3dldmVyLCBpdCBoYXMgYmVlbiBkaWZmaWN1bHQgZm9yIG5ldHdvcmsgb3BlcmF0b3JzIHRvIGV4 cG9zZSBpdHMgZXhhY3QgcGF0aHMgZHVlIHRvIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgaXRzIG5l dHdvcmsgdG9wb2xvZ3kuDQoNCkl0IG1ha2VzIG1vcmUgc2Vuc2UgZm9yIGVuZCBwb2ludHMgdG8g aW5xdWlyZSBwc2V1ZG8gcGF0aCBpbmZvcm1hdGlvbiBpbnN0ZWFkIG9mIHJlYWwgcGF0aCBpbmZv cm1hdGlvbiwgYW5kIG1vcmUgcmVhbGlzdGljIGZyb20gbmV0d29ya3PigJkgY29udHJvbGxlciBv ciBtYW5hZ2VtZW50IHN5c3RlbS4NCg0KTXkgdHdvIGNlbnRzDQpMaW5kYSBEdW5iYXINCg0KRnJv bTogdHN2LWFyZWEgW21haWx0bzp0c3YtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgU3BlbmNlciBEYXdraW5zIGF0IElFVEYNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMiwgMjAx NyAxMDozMCBBTQ0KVG86IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0Pg0KQ2M6IHRz di1hcmVhQGlldGYub3JnID4+IHRzdi1hcmVhQGlldGYub3JnIDx0c3YtYXJlYUBpZXRmLm9yZz47 IHBhbnJnQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW1BhbnJnXSBQcm9wb3NlZCBQYXRoIEF3YXJl IE5ldHdvcmtpbmcgUkcNCg0KQnJpYW4sIEJvYiwgYW5kIExhcnMsDQoNCk9uIFdlZCwgSnVsIDEy LCAyMDE3IGF0IDc6NTIgQU0sIEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0 bzppZXRmQGJvYmJyaXNjb2UubmV0Pj4gd3JvdGU6DQpCcmlhbiwNCg0KMS8gVGhlIElSVEYgc291 bmRzIGxpa2UgYSBnb29kIGxhbmRpbmcgcG9pbnQgZm9yIGFsbCB0aGUgcHJldmlvdXMgYXR0ZW1w dHMgdG8gZ2V0IHRoZSBJRVRGIHRvIGFkZCBwYXRoLWF3YXJlbmVzcyBwcm90b2NvbHMuDQoNCkJU VywgdGhpcyBnb2VzIGJhY2sgYSBsb3QgZnVydGhlciB0aGFuIFNQVUQuIEEgZ29vZCBzdW1tYXJ5 IG9mIHByZS0yMDA3IGVmZm9ydHMgaW4gdGhpcyBzcGFjZSBpcyBpbiBhIHNlY3Rpb24gb2YgUGFz aSdzIGRyYWZ0IG9uIHRoaXMgZnJvbSAyMDA3OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2Fyb2xhaHRpLXRzdndnLWNyb3NzbGF5ZXItMDEjc2VjdGlvbi02ICwgd2hpY2ggcmVt aW5kcyB1cyBvZiBUUklHVFJBTiAoMjAwMiksIElOVEVSU0VDICgyMDAzKSwgQUxJQVMgKDIwMDMp IGFuZCBURVJOTEkgKDIwMDYpLg0KDQpbSSB3cm90ZSB0aGlzIGJlZm9yZSBzZWVpbmcgTGFycydz IGVtYWlsIHBvaW50aW5nIHRvIFRFUk5MSV0NCg0KDQoyLyBUaGUgYWR2YW50YWdlcyBvZiBvcGFj aXR5IChpbnZpc2liaWxpdHkpIG9mIHBhdGggY2hhcmFjdGVyaXN0aWNzIHNob3VsZCBhbHNvIGJl IGluIHNjb3BlLg0KDQpJbiBnZW5lcmFsIHRoZSB0b25lIG9mIHRoZSB0ZXh0IHNlZW1zIHRvIGJl ICJhd2FyZW5lc3MgPSBnb29kOyB1bmF3YXJlbmVzcyA9IGJhZCIuIElmIEkgaGF2ZSBkZXRlY3Rl ZCB0aGlzIHRvbmUgY29ycmVjdGx5LCBpdCB3b3VsZCByZXByZXNlbnQgYW4gaW1wbGljaXQgdmFs dWUganVkZ2VtZW50OyB3aGljaCB3b3VsZCBub3QgYmUgYSBnb29kIHN0YXJ0aW5nIHBvaW50IGZv ciByZXNlYXJjaC4NCg0KKiBZb3UndmUgYWxsdWRlZCB0byBwb3RlbnRpYWwgc2VjdXJpdHkgYWR2 YW50YWdlcyBpbiB0aGUgcGhyYXNlICJleHBsb3JhdGlvbiBvZiB0cnVzdCBhbmQgcmlzayBtb2Rl bHMiLg0KDQoqIFRoZXJlIGFyZSBhbHNvIGV2b2x2YWJpbGl0eSBhZHZhbnRhZ2VzLiBJIHJlY2Fs bCBEYXZpZCBDbGFyayAoSSB0aGluaykgc2F5aW5nIHRoYXQgdGhlIHJ1ZGltZW50YXJ5IGludGVy ZmFjZSBiZXR3ZWVuIHRyYW5zcG9ydCBhbmQgbmV0d29yayB3YXMgYSBmZWF0dXJlIG5vdCBhIGJ1 Zy4gQWRtaXR0ZWRseSBpdCdzIGEgcGFpbiBmb3IgdGhlIHRyYW5zcG9ydCB0byBoYXZlIHRvIGRp c2NvdmVyIGF2YWlsYWJsZSBwYXRoIGNhcGFjaXR5LCBwYXRoIGRlbGF5LCBldGMuIEhvd2V2ZXIs IHRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBoYXZlIGJlZW4gdG8gcmVxdWlyZSBhbGwgTDIgdGVjaG5v bG9naWVzIHRvIGJlIGFibGUgdG8gZ2l2ZSBpbmZvcm1hdGlvbiB0aGF0IHdvdWxkIHJlcXVpcmUg dGhlbSB0byBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSB0cmFuc3BvcnQuIFRoYXQgaW4gdHVy biB3b3VsZCBvc3NpZnkgdHJhbnNwb3J0cyBhbmQgTDIgdGVjaG5vbG9naWVzLg0KDQpXZSBtaWdo dCBiZSBzYXlpbmcgdGhhdCB0aGUgSW50ZXJuZXQgaXMgbW92aW5nIGludG8gYSBuZXcgcGhhc2Ug d2hlcmUgcGVyZm9ybWFuY2UgaXMgbm93IG1vcmUgaW1wb3J0YW50IHRoYW4gZXZvbHZhYmlsaXR5 LiBUaGF0J3MgYSBwb2ludCB0byBkZWJhdGUsIGJ1dCBJIGtub3cgeW91LCBhdCBsZWFzdCwgc3Rp bGwgYmVsaWV2ZSB0aGF0IHN0YWNrIGV2b2x1dGlvbiB3aWxsIHJlbWFpbiBpbXBvcnRhbnQuDQoN Cg0KQm9iDQoNCg0KT24gMTIvMDcvMTcgMDc6MjEsIEJyaWFuIFRyYW1tZWxsIChJRVRGKSB3cm90 ZToNCkdyZWV0aW5ncywgYWxsLA0KDQpXZSdsbCBiZSBoYXZpbmcgYSBmaXJzdCBtZWV0aW5nIG9m IHRoZSBwcm9wb3NlZCBQYXRoIEF3YXJlIE5ldHdvcmtpbmcgKFBBTikgUkcgYXQgSUVURiA5OSBp biBQcmFndWUgbmV4dCB3ZWVrLCAxMzozMCBXZWRuZXNkYXkgaW4gQ29uZ3Jlc3MgSGFsbCAzLiBT aW5jZSBicmluZ2luZyBwYXRoIGF3YXJlbmVzcyB0byB0aGUgZW5kcG9pbnQgaGFzIGJlZW4gdGhl IGZvY3VzLCBhdCBsZWFzdCBpbiBwYXJ0LCBvZiBhIGNvdXBsZSBvZiBydW5uaW5nIFRTViB3b3Jr aW5nIGdyb3VwcyAoTVBUQ1AsIFRBUFMpLCB0aGlzIFJHIHNlZW1zIHRvIGJlIG9mIGdlbmVyYWwg aW50ZXJlc3QgdG8gdGhlIHRyYW5zcG9ydCBhcmVhLiAgT2xpdmllciBCb25hdmVudHVyZSB3aWxs IGdpdmUgYSByZXZpZXcgYW5kIG92ZXJ2aWV3IG9mIHJlc2VhcmNoIHRvIGRhdGUgaW4gdGhpcyBz cGFjZSwgYW5kIEFkcmlhbiBQZXJyaWcgd2lsbCBwcmVzZW50IGEgZnVsbHkgcGF0aC1hd2FyZSBJ bnRlcm5ldCBhcmNoaXRlY3R1cmUsIGFzIGFuIGlsbHVzdHJhdGlvbiBvZiB3aGF0IGlzIHBvc3Np YmxlIHdoZW4gcGF0aC1hd2FyZW5lc3MgaXMgcHJvbW90ZWQgdG8gYSBmaXJzdC1vcmRlciBnb2Fs Lg0KDQogRnJvbSBvdXIgcHJvcG9zZWQgY2hhcnRlciAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9ncm91cC9wYW5yZy9hYm91dCk6DQoNClRoZSBJbnRlcm5ldCBhcmNoaXRlY3R1cmUgYXNz dW1lcyBhIGRpdmlzaW9uIGJldHdlZW4gdGhlIGVuZC10by1lbmQNCmZ1bmN0aW9uYWxpdHkgb2Yg dGhlIHRyYW5zcG9ydCBsYXllciBhbmQgdGhlIHByb3BlcnRpZXMgb2YgdGhlIHBhdGggYmV0d2Vl biB0aGUNCmVuZHBvaW50cy4gVGhlIHBhdGggaXMgYXNzdW1lZCB0byBiZSBpbnZpc2libGUsIGhv bW9nZW5lb3VzLCBzaW5ndWxhciwgd2l0aA0KZHluYW1pY3Mgc29sZWx5IGRldGVybWluZWQgYnkg dGhlIGNvbm5lY3Rpdml0eSBvZiB0aGUgZW5kcG9pbnRzIGFuZCB0aGUgSW50ZXJuZXQNCmNvbnRy b2wgcGxhbmUuIEVuZHBvaW50cyBoYXZlIHZlcnkgbGl0dGxlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBwYXRocyBvdmVyIHdoaWNoDQp0aGVpciB0cmFmZmljIGlzIGNhcnJpZWQsIGFuZCBubyBjb250 cm9sIGF0IGFsbCBiZXlvbmQgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MuDQoNCkluY3JlYXNlZCBk aXZlcnNpdHkgaW4gYWNjZXNzIG5ldHdvcmtzLCBhbmQgdWJpcXVpdG91cyBtb2JpbGUgY29ubmVj dGl2aXR5LCBoYXZlDQptYWRlIHRoaXMgYXJjaGl0ZWN0dXJlJ3MgYXNzdW1wdGlvbnMgYWJvdXQg cGF0aHMgbGVzcyB0ZW5hYmxlLiBNdWx0aXBhdGgNCnByb3RvY29scyB0YWtpbmcgYWR2YW50YWdl IG9mIHRoaXMgbW9iaWxlIGNvbm5lY3Rpdml0eSBiZWdpbiB0byBzaG93IHVzIGEgd2F5DQpmb3J3 YXJkLCB0aG91Z2g6IGlmIGVuZHBvaW50cyBjYW5ub3QgY29udHJvbCB0aGUgcGF0aCwgYXQgbGVh c3QgdGhleSBjYW4NCmRldGVybWluZSB0aGUgcHJvcGVydGllcyBvZiB0aGUgcGF0aCBieSBjaG9v c2luZyBhbW9uZyBwYXRocyBhdmFpbGFibGUgdG8gdGhlbS4NCg0KVGhpcyByZXNlYXJjaCBncm91 cCBhaW1zIHRvIHN1cHBvcnQgcmVzZWFyY2ggaW4gYnJpbmdpbmcgcGF0aCBhd2FyZW5lc3MgdG8N CnRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2xzLCBhbmQgdG8gYnJpbmcg cmVzZWFyY2ggaW4gdGhpcyBzcGFjZQ0KdG8gdGhlIGF0dGVudGlvbiBvZiB0aGUgSW50ZXJuZXQg ZW5naW5lZXJpbmcgYW5kIHByb3RvY29sIGRlc2lnbiBjb21tdW5pdHkuDQoNClRoZSBzY29wZSBv ZiB3b3JrIHdpdGhpbiB0aGUgUkcgaW5jbHVkZXMsIGJ1dCBpcyBub3Qgc3RyaWN0bHkgbGltaXRl ZCB0bzoNCg0KLSBjb21tdW5pY2F0aW9uIGFuZCBkaXNjb3Zlcnkgb2YgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHByb3BlcnRpZXMgb2YgYSBwYXRoIG9uDQogIGxvY2FsIG5ldHdvcmtzIGFuZCBpbiBp bnRlcm5ldHdvcmtzLCBleHBsb3JhdGlvbiBvZiB0cnVzdCBhbmQgcmlzayBtb2RlbHMNCiAgYXNz b2NpYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24sIGFuZCBhbGdvcml0aG1zIGZvciBwYXRoIHNl bGVjdGlvbiBhdA0KICBlbmRwb2ludHMgYmFzZWQgb24gdGhpcyBpbmZvcm1hdGlvbi4NCg0KLSBh bGdvcml0aG1zIGZvciBtYWtpbmcgdHJhbnNwb3J0LWxheWVyIHNjaGVkdWxpbmcgZGVjaXNpb25z IGJhc2VkIG9uDQogIGluZm9ybWF0aW9uIGFib3V0IHBhdGggcHJvcGVydGllcy4NCg0KLSBhbGdv cml0aG1zIGZvciByZWNvbmNpbGluZyBwYXRoIHNlbGVjdGlvbiBhdCBlbmRwb2ludHMgd2l0aCB3 aWRlbHkgZGVwbG95ZWQNCiAgcm91dGluZyBwcm90b2NvbHMgYW5kIG5ldHdvcmsgb3BlcmF0aW9u cyBiZXN0IHByYWN0aWNlcy4NCg0KVGhlIHJlc2VhcmNoIGdyb3VwJ3Mgc2NvcGUgb3ZlcmxhcHMg d2l0aCBleGlzdGluZyBJRVRGIGFuZCBJUlRGIGVmZm9ydHMsIGFuZA0Kd2lsbCBjb2xsYWJvcmF0 ZSB3aXRoIGdyb3VwcyBjaGFydGVyZWQgdG8gd29yayBvbiBtdWx0aXBhdGggdHJhbnNwb3J0IHBy b3RvY29scw0KKE1QVENQLCBRVUlDLCBUU1ZXRyksIGNvbmdlc3Rpb24gY29udHJvbCBpbiBtdWx0 aXBseS1jb25uZWN0ZWQgZW52aXJvbm1lbnRzDQooSUNDUkcpLCBhbmQgYWx0ZXJuYXRlIHJvdXRp bmcgYXJjaGl0ZWN0dXJlcyAoZS5nLiBMSVNQKSwgYW5kIGlzIHJlbGF0ZWQgdG8NCnRoZSBxdWVz dGlvbnMgcmFpc2VkIGluIHRoZSBtdWx0aXBsZSByZWNlbnQgQm9GIHNlc3Npb25zIHRoYXQgaGF2 ZSBhZGRyZXNzZWQNCnBhdGggYXdhcmVuZXNzIGFuZCBtdWx0aXBseS1jb25uZWN0ZWQgbmV0d29y a3MgKGUuZy4gU1BVRCwgUExVUywgQkFOQU5BKS4NCg0KaGUgUEFOKFApUkcgaW50ZW5kcyB0byBt ZWV0IGF0IGVhY2ggSUVURiBtZWV0aW5nIHVudGlsIGENCmRldGVybWluYXRpb24gaXMgbWFkZSB3 aGV0aGVyIG9yIG5vdCB0byBjaGFydGVyIGl0LiBBZnRlcndhcmQsIHRoZSBSRyBpbnRlbmRzIHRv DQptZWV0IGF0IDEtMyBJRVRGIG1lZXRpbmdzIHBlciB5ZWFyLCBhbmQgaG9sZCBvbmUgd29ya3No b3AgcGVyIHllYXIsIGNvbG9jYXRlZA0Kd2l0aCBhIHJlbGF0ZWQgYWNhZGVtaWMgY29uZmVyZW5j ZS4NCg0KQnJpYW4sIHRoYW5rIHlvdSBmb3IgdGFraW5nIHRoaXMgb24sIGluIHRoZSBmaXJzdCBw bGFjZS4gV2UndmUgYmVlbiBkYW5jaW5nIGFyb3VuZCB0aGUgdG9waWMgaW4gdGhlIElFVEYgZm9y IGEgd2hpbGUsIGFuZCBpZiBJJ3ZlIGxlYXJuZWQgYW55dGhpbmcgZnJvbSBhdHRlbmRpbmcgdGhh dCBkYW5jZSwgdGhpcyBpc24ndCBlbmdpbmVlcmluZyAoeWV0KSBhbmQgaXNuJ3QgSUVURiB0aW1l c2NhbGUgKHlldCkuIFNvLCB0aGUgSVJURiBzZWVtcyBhcHByb3ByaWF0ZS4NCg0KTGFycyBhbmQg Qm9iLCB0aGFuayB5b3UgZm9yIHRoZSBwb2ludGVycyB0byBwcmlvciBhcnQuIEkgd2FzIGF3YXJl IG9mIHNvbWUgb2YgdGhhdCAoZm9yIGJldHRlciBvciB3b3JzZSwgSSBjby1jaGFpcmVkIHRoZSBU UklHVFJBTiBCb0YsIGJ1dCBjby1jaGFpcmluZyBQSUxDIG1pZ2h0IGhhdmUgbWFkZSB1cCBmb3Ig c29tZSBvZiB0aGF0KSwgYnV0IGNlcnRhaW5seSBub3QgYWxsIG9mIGl0LCBhbmQgbXVjaCBvZiB3 aGF0IHlvdSB0d28gbmFtZWQgaGFwcGVuZWQgd2hpbGUgSSB3YXMgb2ZmIGRvaW5nIFJBSSBzdHVm ZiBhZnRlciBQSUxDIGNvbmNsdWRlZC4NCg0KSSBsb29rIGZvcndhcmQgdG8gdGhlIGZpcnN0IFBB TlJHIHNlc3Npb24gaW4gUHJhZ3VlLCBhbmQgSSdsbCBlbmNvdXJhZ2UgVFNWIGFyZWEgY2hhaXJz IHRvIGNvbnNpZGVyIHdoZXRoZXIgUEFOUkcgc2hvdWxkIGJlIG9uIHRoZWlyIGNvbmZsaWN0IGxp c3RzIGZvciBmdXR1cmUgSUVURiBtZWV0aW5ncy4NCg0KVHJhdmVsIHNhZmVseSwgYW5kIEknbGwg c2VlIG1hbnkgb2YgeW91IG5leHQgd2Vlay4NCg0KU3BlbmNlciwgYXMgVFNWIEFEIGFuZCBhdC1s YXJnZSBJUlNHIG1lbWJlcg0K --_000_4A95BA014132FF49AE685FAB4B9F17F6593FAB70SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SXNu4oCZdCBJbi1CYW5kIE9BTSBzdXBwb3NlZCB0byBleHBvc2UgdGhlIGFjdHVhbCBQYXRoIElu Zm9ybWF0aW9uPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N b3JlIGFuZCBtb3JlIHNlcnZpY2VzIG5lZWQgdG8ga25vdyBuZXR3b3JrIGRlbGF5ICZhbXA7IHBh dGggaW5mb3JtYXRpb24uIFRoYXQgaXMgd2h5IHRoZXJlIGFyZSBzbyBtYW55IG5ldHdvcmsgbW9u aXRvcmluZyBjb21wYW5pZXMgcG9wcGluZyB1cCBpbiBvZmZlcmluZyBkZWxheQ0KIGFuZCBvdGhl ciBjaGFyYWN0ZXJpc3RpY3Mgb2YgbmV0d29yayB0byBlbmQgcG9pbnRzLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGl0IGhhcyBiZWVuIGRpZmZp Y3VsdCBmb3IgbmV0d29yayBvcGVyYXRvcnMgdG8gZXhwb3NlIGl0cyBleGFjdCBwYXRocyBkdWUg dG8gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiBpdHMgbmV0d29yayB0b3BvbG9neS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgbWFrZXMgbW9yZSBzZW5zZSBm b3IgZW5kIHBvaW50cyB0byBpbnF1aXJlIHBzZXVkbyBwYXRoIGluZm9ybWF0aW9uIGluc3RlYWQg b2YgcmVhbCBwYXRoIGluZm9ybWF0aW9uLCBhbmQgbW9yZSByZWFsaXN0aWMgZnJvbSBuZXR3b3Jr c+KAmSBjb250cm9sbGVyIG9yIG1hbmFnZW1lbnQNCiBzeXN0ZW0uIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgdHdvIGNlbnRzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkxpbmRhIER1bmJhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB0c3Yt YXJlYSBbbWFpbHRvOnRzdi1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlNwZW5jZXIgRGF3a2lucyBhdCBJRVRGPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SnVseSAxMiwgMjAxNyAxMDozMCBBTTxicj4NCjxiPlRvOjwvYj4gQm9iIEJyaXNjb2UgJmx0O2ll dGZAYm9iYnJpc2NvZS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0c3YtYXJlYUBpZXRmLm9yZyAm Z3Q7Jmd0OyB0c3YtYXJlYUBpZXRmLm9yZyAmbHQ7dHN2LWFyZWFAaWV0Zi5vcmcmZ3Q7OyBwYW5y Z0BpcnRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1BhbnJnXSBQcm9wb3NlZCBQYXRo IEF3YXJlIE5ldHdvcmtpbmcgUkc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CcmlhbiwgQm9iLCBhbmQgTGFycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBXZWQsIEp1bCAxMiwgMjAxNyBhdCA3OjUyIEFNLCBCb2IgQnJpc2NvZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiIHRhcmdldD0iX2JsYW5rIj5pZXRmQGJv YmJyaXNjb2UubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW4sPGJyPg0KPGJyPg0KMS8gVGhlIElSVEYgc291bmRz IGxpa2UgYSBnb29kIGxhbmRpbmcgcG9pbnQgZm9yIGFsbCB0aGUgcHJldmlvdXMgYXR0ZW1wdHMg dG8gZ2V0IHRoZSBJRVRGIHRvIGFkZCBwYXRoLWF3YXJlbmVzcyBwcm90b2NvbHMuPGJyPg0KPGJy Pg0KQlRXLCB0aGlzIGdvZXMgYmFjayBhIGxvdCBmdXJ0aGVyIHRoYW4gU1BVRC4gQSBnb29kIHN1 bW1hcnkgb2YgcHJlLTIwMDcgZWZmb3J0cyBpbiB0aGlzIHNwYWNlIGlzIGluIGEgc2VjdGlvbiBv ZiBQYXNpJ3MgZHJhZnQgb24gdGhpcyBmcm9tIDIwMDc6DQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc2Fyb2xhaHRpLXRzdndnLWNyb3NzbGF5ZXItMDEjc2VjdGlv bi02IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2Fyb2xhaHRpLXRzdndnLWNyb3NzbGF5ZXItMDEjc2VjdGlvbi02PC9hPiAsIHdoaWNoIHJlbWlu ZHMgdXMgb2YgVFJJR1RSQU4gKDIwMDIpLCBJTlRFUlNFQyAoMjAwMyksIEFMSUFTICgyMDAzKSBh bmQgVEVSTkxJICgyMDA2KS48YnI+DQo8YnI+DQpbSSB3cm90ZSB0aGlzIGJlZm9yZSBzZWVpbmcg TGFycydzIGVtYWlsIHBvaW50aW5nIHRvIFRFUk5MSV08YnI+DQo8YnI+DQo8YnI+DQoyLyBUaGUg YWR2YW50YWdlcyBvZiBvcGFjaXR5IChpbnZpc2liaWxpdHkpIG9mIHBhdGggY2hhcmFjdGVyaXN0 aWNzIHNob3VsZCBhbHNvIGJlIGluIHNjb3BlLjxicj4NCjxicj4NCkluIGdlbmVyYWwgdGhlIHRv bmUgb2YgdGhlIHRleHQgc2VlbXMgdG8gYmUgJnF1b3Q7YXdhcmVuZXNzID0gZ29vZDsgdW5hd2Fy ZW5lc3MgPSBiYWQmcXVvdDsuIElmIEkgaGF2ZSBkZXRlY3RlZCB0aGlzIHRvbmUgY29ycmVjdGx5 LCBpdCB3b3VsZCByZXByZXNlbnQgYW4gaW1wbGljaXQgdmFsdWUganVkZ2VtZW50OyB3aGljaCB3 b3VsZCBub3QgYmUgYSBnb29kIHN0YXJ0aW5nIHBvaW50IGZvciByZXNlYXJjaC48YnI+DQo8YnI+ DQoqIFlvdSd2ZSBhbGx1ZGVkIHRvIHBvdGVudGlhbCBzZWN1cml0eSBhZHZhbnRhZ2VzIGluIHRo ZSBwaHJhc2UgJnF1b3Q7ZXhwbG9yYXRpb24gb2YgdHJ1c3QgYW5kIHJpc2sgbW9kZWxzJnF1b3Q7 Ljxicj4NCjxicj4NCiogVGhlcmUgYXJlIGFsc28gZXZvbHZhYmlsaXR5IGFkdmFudGFnZXMuIEkg cmVjYWxsIERhdmlkIENsYXJrIChJIHRoaW5rKSBzYXlpbmcgdGhhdCB0aGUgcnVkaW1lbnRhcnkg aW50ZXJmYWNlIGJldHdlZW4gdHJhbnNwb3J0IGFuZCBuZXR3b3JrIHdhcyBhIGZlYXR1cmUgbm90 IGEgYnVnLiBBZG1pdHRlZGx5IGl0J3MgYSBwYWluIGZvciB0aGUgdHJhbnNwb3J0IHRvIGhhdmUg dG8gZGlzY292ZXIgYXZhaWxhYmxlIHBhdGggY2FwYWNpdHksIHBhdGgNCiBkZWxheSwgZXRjLiBI b3dldmVyLCB0aGUgYWx0ZXJuYXRpdmUgd291bGQgaGF2ZSBiZWVuIHRvIHJlcXVpcmUgYWxsIEwy IHRlY2hub2xvZ2llcyB0byBiZSBhYmxlIHRvIGdpdmUgaW5mb3JtYXRpb24gdGhhdCB3b3VsZCBy ZXF1aXJlIHRoZW0gdG8gbWFrZSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgdHJhbnNwb3J0LiBUaGF0 IGluIHR1cm4gd291bGQgb3NzaWZ5IHRyYW5zcG9ydHMgYW5kIEwyIHRlY2hub2xvZ2llcy48YnI+ DQo8YnI+DQpXZSBtaWdodCBiZSBzYXlpbmcgdGhhdCB0aGUgSW50ZXJuZXQgaXMgbW92aW5nIGlu dG8gYSBuZXcgcGhhc2Ugd2hlcmUgcGVyZm9ybWFuY2UgaXMgbm93IG1vcmUgaW1wb3J0YW50IHRo YW4gZXZvbHZhYmlsaXR5LiBUaGF0J3MgYSBwb2ludCB0byBkZWJhdGUsIGJ1dCBJIGtub3cgeW91 LCBhdCBsZWFzdCwgc3RpbGwgYmVsaWV2ZSB0aGF0IHN0YWNrIGV2b2x1dGlvbiB3aWxsIHJlbWFp biBpbXBvcnRhbnQuPGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk9uIDEyLzA3LzE3IDA3OjIx LCBCcmlhbiBUcmFtbWVsbCAoSUVURikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZXRpbmdzLCBhbGwsPGJyPg0KPGJyPg0KV2UnbGwg YmUgaGF2aW5nIGEgZmlyc3QgbWVldGluZyBvZiB0aGUgcHJvcG9zZWQgUGF0aCBBd2FyZSBOZXR3 b3JraW5nIChQQU4pIFJHIGF0IElFVEYgOTkgaW4gUHJhZ3VlIG5leHQgd2VlaywgMTM6MzAgV2Vk bmVzZGF5IGluIENvbmdyZXNzIEhhbGwgMy4gU2luY2UgYnJpbmdpbmcgcGF0aCBhd2FyZW5lc3Mg dG8gdGhlIGVuZHBvaW50IGhhcyBiZWVuIHRoZSBmb2N1cywgYXQgbGVhc3QgaW4gcGFydCwgb2Yg YSBjb3VwbGUgb2YgcnVubmluZyBUU1YNCiB3b3JraW5nIGdyb3VwcyAoTVBUQ1AsIFRBUFMpLCB0 aGlzIFJHIHNlZW1zIHRvIGJlIG9mIGdlbmVyYWwgaW50ZXJlc3QgdG8gdGhlIHRyYW5zcG9ydCBh cmVhLiZuYnNwOyBPbGl2aWVyIEJvbmF2ZW50dXJlIHdpbGwgZ2l2ZSBhIHJldmlldyBhbmQgb3Zl cnZpZXcgb2YgcmVzZWFyY2ggdG8gZGF0ZSBpbiB0aGlzIHNwYWNlLCBhbmQgQWRyaWFuIFBlcnJp ZyB3aWxsIHByZXNlbnQgYSBmdWxseSBwYXRoLWF3YXJlIEludGVybmV0IGFyY2hpdGVjdHVyZSwg YXMNCiBhbiBpbGx1c3RyYXRpb24gb2Ygd2hhdCBpcyBwb3NzaWJsZSB3aGVuIHBhdGgtYXdhcmVu ZXNzIGlzIHByb21vdGVkIHRvIGEgZmlyc3Qtb3JkZXIgZ29hbC48YnI+DQo8YnI+DQombmJzcDtG cm9tIG91ciBwcm9wb3NlZCBjaGFydGVyICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2dyb3VwL3BhbnJnL2Fib3V0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9ncm91cC9wYW5yZy9hYm91dDwvYT4pOjxicj4NCjxicj4NClRoZSBJbnRl cm5ldCBhcmNoaXRlY3R1cmUgYXNzdW1lcyBhIGRpdmlzaW9uIGJldHdlZW4gdGhlIGVuZC10by1l bmQ8YnI+DQpmdW5jdGlvbmFsaXR5IG9mIHRoZSB0cmFuc3BvcnQgbGF5ZXIgYW5kIHRoZSBwcm9w ZXJ0aWVzIG9mIHRoZSBwYXRoIGJldHdlZW4gdGhlPGJyPg0KZW5kcG9pbnRzLiBUaGUgcGF0aCBp cyBhc3N1bWVkIHRvIGJlIGludmlzaWJsZSwgaG9tb2dlbmVvdXMsIHNpbmd1bGFyLCB3aXRoPGJy Pg0KZHluYW1pY3Mgc29sZWx5IGRldGVybWluZWQgYnkgdGhlIGNvbm5lY3Rpdml0eSBvZiB0aGUg ZW5kcG9pbnRzIGFuZCB0aGUgSW50ZXJuZXQ8YnI+DQpjb250cm9sIHBsYW5lLiBFbmRwb2ludHMg aGF2ZSB2ZXJ5IGxpdHRsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcGF0aHMgb3ZlciB3aGljaDxi cj4NCnRoZWlyIHRyYWZmaWMgaXMgY2FycmllZCwgYW5kIG5vIGNvbnRyb2wgYXQgYWxsIGJleW9u ZCB0aGUgZGVzdGluYXRpb24gYWRkcmVzcy48YnI+DQo8YnI+DQpJbmNyZWFzZWQgZGl2ZXJzaXR5 IGluIGFjY2VzcyBuZXR3b3JrcywgYW5kIHViaXF1aXRvdXMgbW9iaWxlIGNvbm5lY3Rpdml0eSwg aGF2ZTxicj4NCm1hZGUgdGhpcyBhcmNoaXRlY3R1cmUncyBhc3N1bXB0aW9ucyBhYm91dCBwYXRo cyBsZXNzIHRlbmFibGUuIE11bHRpcGF0aDxicj4NCnByb3RvY29scyB0YWtpbmcgYWR2YW50YWdl IG9mIHRoaXMgbW9iaWxlIGNvbm5lY3Rpdml0eSBiZWdpbiB0byBzaG93IHVzIGEgd2F5PGJyPg0K Zm9yd2FyZCwgdGhvdWdoOiBpZiBlbmRwb2ludHMgY2Fubm90IGNvbnRyb2wgdGhlIHBhdGgsIGF0 IGxlYXN0IHRoZXkgY2FuPGJyPg0KZGV0ZXJtaW5lIHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSBwYXRo IGJ5IGNob29zaW5nIGFtb25nIHBhdGhzIGF2YWlsYWJsZSB0byB0aGVtLjxicj4NCjxicj4NClRo aXMgcmVzZWFyY2ggZ3JvdXAgYWltcyB0byBzdXBwb3J0IHJlc2VhcmNoIGluIGJyaW5naW5nIHBh dGggYXdhcmVuZXNzIHRvPGJyPg0KdHJhbnNwb3J0IGFuZCBhcHBsaWNhdGlvbiBsYXllciBwcm90 b2NvbHMsIGFuZCB0byBicmluZyByZXNlYXJjaCBpbiB0aGlzIHNwYWNlPGJyPg0KdG8gdGhlIGF0 dGVudGlvbiBvZiB0aGUgSW50ZXJuZXQgZW5naW5lZXJpbmcgYW5kIHByb3RvY29sIGRlc2lnbiBj b21tdW5pdHkuPGJyPg0KPGJyPg0KVGhlIHNjb3BlIG9mIHdvcmsgd2l0aGluIHRoZSBSRyBpbmNs dWRlcywgYnV0IGlzIG5vdCBzdHJpY3RseSBsaW1pdGVkIHRvOjxicj4NCjxicj4NCi0gY29tbXVu aWNhdGlvbiBhbmQgZGlzY292ZXJ5IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcm9wZXJ0aWVz IG9mIGEgcGF0aCBvbjxicj4NCiZuYnNwOyBsb2NhbCBuZXR3b3JrcyBhbmQgaW4gaW50ZXJuZXR3 b3JrcywgZXhwbG9yYXRpb24gb2YgdHJ1c3QgYW5kIHJpc2sgbW9kZWxzPGJyPg0KJm5ic3A7IGFz c29jaWF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLCBhbmQgYWxnb3JpdGhtcyBmb3IgcGF0aCBz ZWxlY3Rpb24gYXQ8YnI+DQombmJzcDsgZW5kcG9pbnRzIGJhc2VkIG9uIHRoaXMgaW5mb3JtYXRp b24uPGJyPg0KPGJyPg0KLSBhbGdvcml0aG1zIGZvciBtYWtpbmcgdHJhbnNwb3J0LWxheWVyIHNj aGVkdWxpbmcgZGVjaXNpb25zIGJhc2VkIG9uPGJyPg0KJm5ic3A7IGluZm9ybWF0aW9uIGFib3V0 IHBhdGggcHJvcGVydGllcy48YnI+DQo8YnI+DQotIGFsZ29yaXRobXMgZm9yIHJlY29uY2lsaW5n IHBhdGggc2VsZWN0aW9uIGF0IGVuZHBvaW50cyB3aXRoIHdpZGVseSBkZXBsb3llZDxicj4NCiZu YnNwOyByb3V0aW5nIHByb3RvY29scyBhbmQgbmV0d29yayBvcGVyYXRpb25zIGJlc3QgcHJhY3Rp Y2VzLjxicj4NCjxicj4NClRoZSByZXNlYXJjaCBncm91cCdzIHNjb3BlIG92ZXJsYXBzIHdpdGgg ZXhpc3RpbmcgSUVURiBhbmQgSVJURiBlZmZvcnRzLCBhbmQ8YnI+DQp3aWxsIGNvbGxhYm9yYXRl IHdpdGggZ3JvdXBzIGNoYXJ0ZXJlZCB0byB3b3JrIG9uIG11bHRpcGF0aCB0cmFuc3BvcnQgcHJv dG9jb2xzPGJyPg0KKE1QVENQLCBRVUlDLCBUU1ZXRyksIGNvbmdlc3Rpb24gY29udHJvbCBpbiBt dWx0aXBseS1jb25uZWN0ZWQgZW52aXJvbm1lbnRzPGJyPg0KKElDQ1JHKSwgYW5kIGFsdGVybmF0 ZSByb3V0aW5nIGFyY2hpdGVjdHVyZXMgKGUuZy4gTElTUCksIGFuZCBpcyByZWxhdGVkIHRvPGJy Pg0KdGhlIHF1ZXN0aW9ucyByYWlzZWQgaW4gdGhlIG11bHRpcGxlIHJlY2VudCBCb0Ygc2Vzc2lv bnMgdGhhdCBoYXZlIGFkZHJlc3NlZDxicj4NCnBhdGggYXdhcmVuZXNzIGFuZCBtdWx0aXBseS1j b25uZWN0ZWQgbmV0d29ya3MgKGUuZy4gU1BVRCwgUExVUywgQkFOQU5BKS48YnI+DQo8YnI+DQpo ZSBQQU4oUClSRyBpbnRlbmRzIHRvIG1lZXQgYXQgZWFjaCBJRVRGIG1lZXRpbmcgdW50aWwgYTxi cj4NCmRldGVybWluYXRpb24gaXMgbWFkZSB3aGV0aGVyIG9yIG5vdCB0byBjaGFydGVyIGl0LiBB ZnRlcndhcmQsIHRoZSBSRyBpbnRlbmRzIHRvPGJyPg0KbWVldCBhdCAxLTMgSUVURiBtZWV0aW5n cyBwZXIgeWVhciwgYW5kIGhvbGQgb25lIHdvcmtzaG9wIHBlciB5ZWFyLCBjb2xvY2F0ZWQ8YnI+ DQp3aXRoIGEgcmVsYXRlZCBhY2FkZW1pYyBjb25mZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJyaWFuLCB0aGFuayB5b3UgZm9yIHRha2luZyB0aGlzIG9uLCBpbiB0 aGUgZmlyc3QgcGxhY2UuIFdlJ3ZlIGJlZW4gZGFuY2luZyBhcm91bmQgdGhlIHRvcGljIGluIHRo ZSBJRVRGIGZvciBhIHdoaWxlLCBhbmQgaWYgSSd2ZSBsZWFybmVkIGFueXRoaW5nIGZyb20gYXR0 ZW5kaW5nIHRoYXQgZGFuY2UsIHRoaXMgaXNuJ3QgZW5naW5lZXJpbmcgKHlldCkgYW5kIGlzbid0 IElFVEYgdGltZXNjYWxlICh5ZXQpLiBTbywNCiB0aGUgSVJURiBzZWVtcyBhcHByb3ByaWF0ZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFy cyBhbmQgQm9iLCB0aGFuayB5b3UgZm9yIHRoZSBwb2ludGVycyB0byBwcmlvciBhcnQuIEkgd2Fz IGF3YXJlIG9mIHNvbWUgb2YgdGhhdCAoZm9yIGJldHRlciBvciB3b3JzZSwgSSBjby1jaGFpcmVk IHRoZSBUUklHVFJBTiBCb0YsIGJ1dCBjby1jaGFpcmluZyBQSUxDIG1pZ2h0IGhhdmUgbWFkZSB1 cCBmb3Igc29tZSBvZiB0aGF0KSwgYnV0IGNlcnRhaW5seSBub3QgYWxsIG9mIGl0LCBhbmQgbXVj aCBvZg0KIHdoYXQgeW91IHR3byBuYW1lZCBoYXBwZW5lZCB3aGlsZSBJIHdhcyBvZmYgZG9pbmcg UkFJIHN0dWZmIGFmdGVyIFBJTEMgY29uY2x1ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxvb2sgZm9yd2FyZCB0byB0aGUgZmlyc3Qg UEFOUkcgc2Vzc2lvbiBpbiBQcmFndWUsIGFuZCBJJ2xsIGVuY291cmFnZSBUU1YgYXJlYSBjaGFp cnMgdG8gY29uc2lkZXIgd2hldGhlciBQQU5SRyBzaG91bGQgYmUgb24gdGhlaXIgY29uZmxpY3Qg bGlzdHMgZm9yIGZ1dHVyZSBJRVRGIG1lZXRpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcmF2ZWwgc2FmZWx5LCBhbmQgSSdsbCBzZWUg bWFueSBvZiB5b3UgbmV4dCB3ZWVrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyLCBhcyBUU1YgQUQgYW5kIGF0LWxhcmdlIElSU0cg bWVtYmVyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F6593FAB70SJCEML702CHMchi_-- From nobody Fri Jul 14 00:05:45 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706C5131668; Thu, 13 Jul 2017 14:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 jLk0Gu-DtadD; Thu, 13 Jul 2017 14:11:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 29D4813156F; Thu, 13 Jul 2017 14:11:21 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v6DLA3DK024659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 14:10:06 -0700 (PDT) To: Bob Briscoe , "Brian Trammell (IETF)" , tsv-area@ietf.org Cc: panrg@irtf.org References: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> From: Joe Touch Message-ID: <28ad281d-7a0e-9e37-319a-b4f5276eac6e@isi.edu> Date: Thu, 13 Jul 2017 14:10:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4792555d-fd50-3461-64b1-2d4502935fec@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Fri, 14 Jul 2017 00:05:30 -0700 Subject: Re: [Panrg] Proposed Path Aware Networking RG X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"Path Aware Networking \(Proposed\) Research Group discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 21:11:22 -0000 On 7/12/2017 5:52 AM, Bob Briscoe wrote: > 1/ The IRTF sounds like a good landing point for all the previous > attempts to get the IETF to add path-awareness protocols. > > BTW, this goes back a lot further than SPUD. A good summary of > pre-2007 efforts in this space is in a section of Pasi's draft on this > from 2007: > https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 > , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) > and TERNLI (2006). IMO, those are less "path" than "link" aware. I.e., I see "path aware" as knowing the difference in the *path* properties of two different paths, e.g., BW, latency, jitter. I see "link aware" as dealing more with per-hop loss rates, MAC collisiions, etc. So yes, there are a lot of "dead" bodies from past work here, but IMO that's a lesson - I don't think link-transport interactions are a great idea. I sincerely hope that this new effort is doign in a different direction, rather than rehashing these old efforts... Joe From nobody Wed Jul 19 08:06:28 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88A612F280 for ; Wed, 19 Jul 2017 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1amk1lwOdKIu for ; Wed, 19 Jul 2017 08:06:24 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 3A1C8131D69 for ; Wed, 19 Jul 2017 08:06:12 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 12so59932776wrb.1 for ; Wed, 19 Jul 2017 08:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=0jOUWVgn9mYKkZPRWoaQnZl89/Vg+l/+U6BU1x1sExc=; b=bxmkI7PqXyW/EdRaVAE9qrZoz8zqQfQTGmKIL9pzml87lwn7H0R7fOk7sTCZanA9zp +uACFWG7nOmGhmWemJw4sZ32d9kkKK/SZSkNOtDzPazBea5lJ9jv5P5NNKVNSgPk/0HE aJZthTWJN4oVuIq0FTCc5bggi/D6cXdwe6kRDUeRZsJ7yFI88gWj1QSt3n48vDXILiPE 2RwSR7keVPbefLh5bZdmUWXrFOQs5EAOAPx6YLgziqVVm7i6EULg5pW+xM4YSApG2eVz 5agATl/egTAajm69GLX+XBHhJLPpjxQ7S2ccfqV1IL4jirbsxJ/IEzN5UjTykwu5QQqd aL6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=0jOUWVgn9mYKkZPRWoaQnZl89/Vg+l/+U6BU1x1sExc=; b=mcbiwlk7ZAbUFDKOtlmfZ4V5gLgWnk1xdJjF9NlKV2RPE0l4nRC1QU1LfPizh5hQIr Qf9lXqWg/okEmxd68AHqequnQGyXtU+AhAoaA4CIkCQsDYzY6mXUE29UsEEWKZeURelc yGC+UDU282fcyiAkfk9qBk9Kskt2DNmP76emSllnaYKTsWf/tQWimc+yLywMPranBp8A N+kNCKsQwHZs5oOCQM7/C3fY3L/abaAG4LEPe0CdVdo4ltg+LAk9SEY5vQggszo42K8E 8weaJXbhTxT3Ce3iP0h7QUlVmMvSS8cG5tKg95wi5JzIY6WEkZohFeXSeDtDj1E5Od4V lrXA== X-Gm-Message-State: AIVw111IpSMjPsuZXC6yQffIKkljvM1D0HJLvZKiTa3zFdj/FoLO6YKV imBSIiojbr2x07dmIbA= X-Received: by 10.223.139.152 with SMTP id o24mr4809269wra.178.1500476770382; Wed, 19 Jul 2017 08:06:10 -0700 (PDT) Received: from [172.19.152.187] ([2001:67c:370:128:b4d5:2e28:237a:91dc]) by smtp.gmail.com with ESMTPSA id g83sm171741wmf.29.2017.07.19.08.06.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 08:06:09 -0700 (PDT) From: "Aaron Falk" To: panrg@irtf.org Date: Wed, 19 Jul 2017 17:06:08 +0200 Message-ID: <438E73EE-5690-44DF-ACA1-89026E7A97C1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [PANRG] FARA X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:06:27 -0000 This is the paper I referenced at the mic. Only knowing what I heard at the meeting, FARA seems to have some similarities to SCION. —aaron https://www.isi.edu/newarch/DOCUMENTS/FARA.FDNA03.pdf FARA: Reorganizing the Addressing Architecture David Clark, Robert Braden, Aaron Falk, Venkata Pingali ABSTRACT This paper describes FARA, a new organization of network architecture concepts. FARA (Forwarding directive, Association, and Rendezvous Architecture) defines an abstract model with considerable generality and flexibility, based upon the decoupling of end-system names from network addresses. The paper explores the implications of FARA and the range of architecture instantiations that may be derived from FARA. As an illustration, the paper outlines a particular derived architecture, M-FARA, which features support for generalized mobility and multiple realms of network addressing. From nobody Wed Jul 19 16:37:24 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F7C126C23 for ; Wed, 19 Jul 2017 16:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=nokia.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 Qr9jDS0SQO62 for ; Wed, 19 Jul 2017 16:37:20 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20094.outbound.protection.outlook.com [40.107.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22616128990 for ; Wed, 19 Jul 2017 16:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=63T2xesI8oyN9rEoBYo2h+/b7gmkwvDek10zvTGLQHc=; b=RzaB+hpb7ZRGhlUIFYxbrcZGx8dWH1JKZjLIhOJ0aMWW2koFWICbmCu1hbRmHLKtJdOFXkoXYsgcz0Kz4wWV64b07c5ri/t83Q3jkpATKELjxJqjFuoVu/WIRSHXV970nAm8ZoozTrXoy1HNKI4D6V4zY7POfr2HOAIIw06grE8= Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2663.eurprd07.prod.outlook.com (10.169.215.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 23:37:17 +0000 Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([fe80::79f9:96c:a3c5:3ecc]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([fe80::79f9:96c:a3c5:3ecc%17]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 23:37:17 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: "panrg@irtf.org" CC: IETF ALTO Thread-Topic: ALTO WG meeting tomorrow Thread-Index: AdMA5BwLNQ+qSNL+SJuvF121XEM1pA== Date: Wed, 19 Jul 2017 23:37:17 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.29] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2663; 7:/JvhpgIS+VaIMzxRV4qMGbQFVs5YEw7DwgqxhByhsKu9NJQtxPMEjrSrigJiNUBU+XL4qNqyPRIrQyPMyxh4iMph9vNWcyt8hAzmpx4RiP/ovqQ3OE+InJbw7TG+RZg+V6z0b3GCx7/F4lZT4kTodsZtOZWwTevXiPCvw6MXqf1QSGcQsOBCLBLOaLKeJ/stqVh2wkgotYOYojGDR06lSK8NqeB8j5J8tXCQSDBCGEDraABTznZy5DyYk81QvPM5xSMI+X3MpLhGSONJ8oTfS7BVCvv/WRAByZWJ/d4/Bk4Ig3MepI3C4vEl2bOK+g7BviPeA68K415nLb5XsHY+Q8qEbEl5sCVlLzhH6Mv6ykvxCxm+GiNT/sEe/t4jPhUZSXMQOQ1FsO+AoMHFYFOz1WTAUIX8ri36z99Xi4uZeXjaGuDkMNXrNWJa90rLUMtSAV+N2uHz0rkCzw59TjuLkeI3Ya9fomyL6jeSSPJDfpgWbKt3SASLVNsIjFxXJNZo+tNtWBgzbXUJuyakq5docgAnHTfRr1h0Amy1vcGQxEg8FtIhoebFEh1kcceS1gI9x8mHLK+Gl8iHP0knelut3QvuaSwVdOh/NklqDubfyl0pguSjltFh1QUlDSI1pQ8YUgpRKIGK+LfO0TsWLavKCLASjdKo+3ivFWh+U9IVAGJl2/GuFVDOjy8yg+jawPkeXlbR1APmgbCgQsUgScBURex93O9yR/hGjJZHGziu6eAwfNgJ0s8v4a3RXxvsdIheoxKfEJHi3Q5NYxSFVmsUY/K234/9wB/GdSmi4eVuxfc= x-ms-office365-filtering-correlation-id: bc201b87-e0bb-49ee-983d-08d4ceff17b5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2663; x-ms-traffictypediagnostic: DB6PR0701MB2663: x-exchange-antispam-report-test: UriScan:(151999592597050)(278428928389397)(26388249023172)(236129657087228)(155532106045638)(21748063052155)(21532816269658)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2663; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2663; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(51914003)(3660700001)(2900100001)(9686003)(14454004)(99286003)(110136004)(478600001)(2351001)(54896002)(1730700003)(6306002)(3480700004)(53936002)(8676002)(3280700002)(2906002)(38730400002)(55016002)(5630700001)(8936002)(5640700003)(81166006)(86362001)(6436002)(7696004)(7736002)(66066001)(189998001)(2501003)(4326008)(6116002)(3846002)(50986999)(6506006)(33656002)(5250100002)(6916009)(5660300001)(25786009)(54356999)(74316002)(102836003)(790700001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2663; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB2454B4C6B92CDD9A6C2D78D495A60DB6PR0701MB2454_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 23:37:17.3810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2663 Archived-At: Subject: [PANRG] ALTO WG meeting tomorrow X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 23:37:23 -0000 --_000_DB6PR0701MB2454B4C6B92CDD9A6C2D78D495A60DB6PR0701MB2454_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings all, Thanks for the interesting RG meeting last afternoon. Upon the talk of Olivier Bonaventure, and discussions, I gather that severa= l viewpoints are considered, in particular the one of the user or end host = or application that would like to have a better insight on the path(s) used= to connect to another end host and that does not have the same network ins= ight sa a router. The ALTO WG has been mentioned in the discussion and will have its meeting = Thursday 20th at 13h30 - Karlin III. The ALTO protocol specified in RFC7285 conveys provider-centric abstracted = network topology information to OTT applications that cannot get this infor= mation by other means. The ALTO WG currently is specifying extensions to t= he base protocol addressing some of the challenges discussed this afternoon= . So it may be interesting if you can drop by. Best regards, Sabine --_000_DB6PR0701MB2454B4C6B92CDD9A6C2D78D495A60DB6PR0701MB2454_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings all,

 

Thanks for the interesting RG m= eeting last afternoon.

Upon the talk of Olivier Bonave= nture, and discussions, I gather that several viewpoints are considered, in= particular the one of the user or end host or application that would like = to have a better insight on the path(s) used to connect to another end host and that does not have the same networ= k insight sa a router.  

 

The ALTO WG has been mentioned = in the discussion and will have its meeting Thursday 20th at 13h= 30 – Karlin III.

 

The ALTO protocol specified in = RFC7285 conveys provider-centric abstracted network topology information to= OTT applications that cannot get this information by other means.  Th= e ALTO WG currently is specifying extensions to the base protocol addressing some of the challenges discussed this afte= rnoon. So it may be interesting if you can drop by.

 

Best regards,=

Sabine

 

 

 

 

--_000_DB6PR0701MB2454B4C6B92CDD9A6C2D78D495A60DB6PR0701MB2454_-- From nobody Thu Jul 20 04:31:29 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD0612EBF7 for ; Wed, 19 Jul 2017 05:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KBOYsjzvqfAJ for ; Wed, 19 Jul 2017 05:59:50 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 BDBDA131D11 for ; Wed, 19 Jul 2017 05:59:49 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id g127so233067wmd.0 for ; Wed, 19 Jul 2017 05:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=0jOUWVgn9mYKkZPRWoaQnZl89/Vg+l/+U6BU1x1sExc=; b=hXOCFcgH9Td1waYwC7JjaqbfQsXrDIPjPDojmd5TvRN+Guac2SOMo4FvTyaXXxtBrf kGdETwzuWCESRhwkZxrWiiYft3vybwXVHyeoaGa6VZXFf1bzQ1wyieD2wPOon614C8li +Pr3nWbs0pGHX0zH4WKz7yL8x1z0ClqgChWjSjXiadU3F2TVeHSs5IePMRo+w61BJW6E sP8ybNIK5fQRGP+cVkVpQqjr3ki+j8flYgVfOsIOPImBTU3dJEbHQmmd1VnZ+5lz/u+k PxXZlVu0qW190B3nQGUDd1nGGRlFU+Vh8+MINUfnQZDJ7hPaD6BTMD9d6F8uDfqis6hQ PR+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=0jOUWVgn9mYKkZPRWoaQnZl89/Vg+l/+U6BU1x1sExc=; b=rEyC0gbD+SiVCdVnWPxWtBmZVwcBCt4BGm4+LZ0nCcrRMnjAvHdceWu2yS7Pc+NB5E 7HmjYwfgdghXY7AyBFUEsSeROjVGbS//egBn3/m9O0jQOT51GDx+Rvyr2D6YZ1yc6ISo tk717Hd4R1RvU6OgU0pxjw+WtqUJOl58xv4S/kbH+9Kc8IGUQqosJxgHBLL8RrGhfqVt 6IlsKVCKfLScFntyuus4opYqaAjlodb12rHQZ9OlC+FP9SrlOWwbiYEu657wUAjGHadX GoIfy5wewo6Fw9/o+hArdi7fIANH3+4RHBS1z7mPm/UY3R4tp8kHlu/iZKiVY9tnTCBK /Ynw== X-Gm-Message-State: AIVw110tiQtBtqMXnuTWXTE2DL53QX8npxR7F6sSEl+7irhMhF5uLCv8 /ubpzTQ5CQoYXJWciME= X-Received: by 10.28.91.11 with SMTP id p11mr163354wmb.19.1500469188012; Wed, 19 Jul 2017 05:59:48 -0700 (PDT) Received: from [172.19.153.56] ([2001:67c:370:128:4455:b3f4:b7b:fa6f]) by smtp.gmail.com with ESMTPSA id m15sm349795wrb.85.2017.07.19.05.59.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 05:59:47 -0700 (PDT) From: "Aaron Falk" To: panrg@irtf.org Date: Wed, 19 Jul 2017 14:59:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: X-Mailman-Approved-At: Thu, 20 Jul 2017 04:31:28 -0700 Subject: [PANRG] FARA X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:59:52 -0000 This is the paper I referenced at the mic. Only knowing what I heard at the meeting, FARA seems to have some similarities to SCION. —aaron https://www.isi.edu/newarch/DOCUMENTS/FARA.FDNA03.pdf FARA: Reorganizing the Addressing Architecture David Clark, Robert Braden, Aaron Falk, Venkata Pingali ABSTRACT This paper describes FARA, a new organization of network architecture concepts. FARA (Forwarding directive, Association, and Rendezvous Architecture) defines an abstract model with considerable generality and flexibility, based upon the decoupling of end-system names from network addresses. The paper explores the implications of FARA and the range of architecture instantiations that may be derived from FARA. As an illustration, the paper outlines a particular derived architecture, M-FARA, which features support for generalized mobility and multiple realms of network addressing. From nobody Thu Jul 20 07:21:57 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE212EAF7 for ; Thu, 20 Jul 2017 07:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 cEKdVDAXakrU for ; Thu, 20 Jul 2017 07:21:53 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 5DCBC12704A for ; Thu, 20 Jul 2017 07:21:53 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dYCKs-0001Aq-IB for ; Thu, 20 Jul 2017 16:21:50 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 72662B00568 for ; Thu, 20 Jul 2017 16:21:50 +0200 (CEST) To: panrg@irtf.org From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: Date: Thu, 20 Jul 2017 16:21:50 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1500560510.606066173 Archived-At: Subject: [PANRG] Choice and Tussles X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:21:55 -0000 Hi, I want to second what Aaron said at the mic: IMHO a good approach is that the network provides more information so that the applications/end-systems can make better choices. So giving more/better choices to the users is probably one worthwhile goal. Let's assume the network provides more information about networks paths and their properties that can be utilized by a multi-path transport protocol. Users' choice and providers' choices/policies may get into conflict. For instance, I think that the Shim6 experience showed that one can expect tussles in certain areas. The providers felt that they loose control over their traffic flows and thus their traffic engineering (just my perception, maybe not quite correct). So paying attention to potential tussles and designing the interfaces along the conflicts could be useful or even necessary, but it may not be easy... Regards, Roland From nobody Thu Jul 20 07:27:19 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAFC13188F for ; Thu, 20 Jul 2017 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 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_H5=-1, 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=nokia.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 NQbn361Sp582 for ; Thu, 20 Jul 2017 07:27:16 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40120.outbound.protection.outlook.com [40.107.4.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897DB131761 for ; Thu, 20 Jul 2017 07:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xvjmyoqdoTCu1pSM/zORuUjHPXUxWTzULfuR5hZR234=; b=G1+tCKT4sCB/4ET7IPKVCnyscxm1CkT9KzZOa1M4P05+kxJZZF8NpPOZv491qcPWREqCzqxvpQhV/nsIDypOiHvX6TXma1Ay3Q8gernh/I+/uYhKOT3gce8NBMAv/P6sEzQmskP0tblp/bWFUhi93Dv1aH5Hi7TuAgviyxAYbB4= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2804.eurprd07.prod.outlook.com (10.168.155.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 14:27:13 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 14:27:13 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Roland Bless , "panrg@irtf.org" Thread-Topic: [PANRG] Choice and Tussles Thread-Index: AQHTAWONS1vGlg/vtk+s1nfmUgMDhqJcxMPg Date: Thu, 20 Jul 2017 14:27:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kit.edu; dkim=none (message not signed) header.d=none;kit.edu; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2804; 7:yTeubur+PplqEzmIJVcOm5v1kyGajYMkc+CkEoYMpNwfWKV2LiCr9Z4KNcMXqS73wU9STRkFjn80T0vSHpXt8awfR8S9itsiXOACHShrmuhUaZny+rz/p23w1w84IMJBPz/Nquab8dYFSD7wl3tmM9jJ0cjManADskdaq5yztZictUbXfnyTn75JwIoTQrC6wsyg+qhDcjTRrwi3dYlsNRopqYd8JGa7xTxmnE0dsvRyrcle9x1dQDotTVUUrtGKHRW5GJJSkjYme1AibPvNYVwPjmFJ9npjqaYOdfpd6uEDAwWWrVbmv98NOui3RXcz/omIfbQxfrkAm3LvTcPy0PlPTdwkNPRwps2EqC+ayd5jRkltltt3MJPpmVpsxFZs3oZXynU4rn4U1kz9yD9ysmxkXUkfdQFDDV1D3dAR7iqQ+yH11FTGYDpsqP8c9ci5LPKpafN3YFFReCIpXETpjqF5uxFNjrTQvEioNtUPfZkz1II20V6MsvVCVQKtOROfTTOotAlQt2vJlD/FwpxzftXy7eQIudHdc3gwgxY5eVcJXP/i3zvrNs71FXP2jABudJi7fIfbFy7BAnKJycifIGX2VUrqq2LZZ4blHdupoqxMQTAZZSq3z8hQiseTY7QCxQzdoI26X8NcPHLcPi3AMqTu4tHvN/YhP2yeF+S2r8kvBYj1Tu9KlEY1Pz8NobDH5lu+4nPzos6QlvmgjRCzQybYlgp2nIDU0ZHss+/zYRgtREotrl8/vEFJ+KwONyY5pOEswnXcIsZZGgHsAjADCM5QD4pMMNpnN+GqTeN8PCA= x-ms-office365-filtering-correlation-id: b99a05d2-b50d-47af-041f-08d4cf7b69e0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2804; x-ms-traffictypediagnostic: AM5PR0701MB2804: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2804; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2804; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(39400400002)(51444003)(377454003)(13464003)(2501003)(6306002)(7736002)(2900100001)(305945005)(6506006)(3280700002)(9686003)(478600001)(38730400002)(229853002)(74316002)(2950100002)(33656002)(53936002)(55016002)(86362001)(5250100002)(189998001)(25786009)(966005)(6436002)(2906002)(81166006)(102836003)(99286003)(6116002)(5660300001)(8936002)(3846002)(6246003)(2171002)(14454004)(50986999)(7696004)(54356999)(53546010)(76176999)(3660700001)(8676002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2804; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 14:27:12.8579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2804 Archived-At: Subject: Re: [PANRG] Choice and Tussles X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:27:18 -0000 See RFC 7971 Section 7 for some discussion of related issues - not all may = be protocol-specific. The rest of this RFC could be of interest, too. =20 Michael > -----Original Message----- > From: Panrg [mailto:panrg-bounces@irtf.org] On Behalf Of Roland Bless > Sent: Thursday, July 20, 2017 4:22 PM > To: panrg@irtf.org > Subject: [PANRG] Choice and Tussles >=20 > Hi, >=20 > I want to second what Aaron said at the mic: > IMHO a good approach is that the network provides more information so > that the applications/end-systems can make better choices. > So giving more/better choices to the users is probably one worthwhile goa= l. > Let's assume the network provides more information about networks paths > and their properties that can be utilized by a multi-path transport proto= col. > Users' choice and providers' choices/policies may get into conflict. > For instance, I think that the Shim6 experience showed that one can expec= t > tussles in certain areas. The providers felt that they loose control over= their > traffic flows and thus their traffic engineering (just my perception, may= be > not quite correct). So paying attention to potential tussles and designin= g the > interfaces along the conflicts could be useful or even necessary, but it = may > not be easy... >=20 > Regards, > Roland >=20 > _______________________________________________ > Panrg mailing list > Panrg@irtf.org > https://www.irtf.org/mailman/listinfo/panrg From nobody Thu Jul 20 08:31:34 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFF91318A3 for ; Thu, 20 Jul 2017 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no 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 91GqzHzJ-2bH for ; Thu, 20 Jul 2017 08:31:31 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 5E45D131473 for ; Thu, 20 Jul 2017 08:31:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v193so14295113ywg.2 for ; Thu, 20 Jul 2017 08:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3jE9SuJltwlBMqxuwjj3Pw7O0h6/px7f0eiB0trVGxs=; b=WjlhNLAlmUXWGl4GElDTjF1Nl6Q/WDc78U7fkxq5aS6URf7QrhUkLtevDbVlrmqR2k /8Jmo4HfN/4HOGsQsPluMxDp+/XvsVUqzJIG0MMS/d+RaNv5TSKssdLrbN+01zkj0wu/ 1HAM5I4gso8JDPdZdiQiHTImDnV7a45GxOYMTybFsDKuqYrUI+U0eE8C1ZViav9vaLrM wHIvz1/M2Ui2A3lsSp6HYdRBHWyBN7CMsqNfDdbTGZPn7TJgDMdTq26Hw8Y04sR16nL4 5Ojio0jfjLBiYvJJ/ommbq4n+XG8pTWwk4wUfy32sYVkb2/D33z6m2B9rS1tPJUI36Hb XIhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3jE9SuJltwlBMqxuwjj3Pw7O0h6/px7f0eiB0trVGxs=; b=hiOJ6X1UNCtmzEw3cj9UKQBg5EeYmJcWGSuHHCJQkHcYygDMybM1CaYDq4LFzOUayf mj3TeneJvGLkK2DQe4InsA81nbJwYduCVRPiXhrssIUACg2qn22m5W4bzdOb3G8JvfrN D7/49cjywMhhYnAHswGgMhtPhAlIhn6+51VLJNnZhirfagSSojMpexgtjg2Z5dNpTJc+ cDIBR9DZ2lV66QYEOaFqkbMUY2oc4MlKSeshN9VSJiL3+lk4bS/ApqxsYADBS8yRGqot hatXGF+IgyLsxEEyFG21pM61EcYbxXrrypIFT+rXGZM1hQC5wWGBRn1J4S+zbNVlvDDj TEiA== X-Gm-Message-State: AIVw113BC0kCMnmhNi1v6iotjsF7DljHG0dK1po4KQqdJc1sm9r+mbuG BMg02UWKe19RUtTx6ymuVPfcQ2NwLA== X-Received: by 10.129.201.4 with SMTP id o4mr3907917ywi.2.1500564690538; Thu, 20 Jul 2017 08:31:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.24.207 with HTTP; Thu, 20 Jul 2017 08:30:50 -0700 (PDT) In-Reply-To: <438E73EE-5690-44DF-ACA1-89026E7A97C1@gmail.com> References: <438E73EE-5690-44DF-ACA1-89026E7A97C1@gmail.com> From: Adrian Perrig Date: Thu, 20 Jul 2017 17:30:50 +0200 Message-ID: To: Aaron Falk Cc: panrg@irtf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [PANRG] FARA X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:31:32 -0000 Dear Aaron, Thank you for the pointer, indeed, NIRA and FARA proposed in the Newarch effort bear similarities to SCION. We discuss these points in the Future Internet Architectures Section 1.3 of our book describing the SCION architecture: http://scion-architecture.net/pdf/SCION-book.pdf All the best wishes, Adrian On Wed, Jul 19, 2017 at 5:06 PM, Aaron Falk wrote: > This is the paper I referenced at the mic. Only knowing what I heard at = the > meeting, FARA seems to have some similarities to SCION. > > =E2=80=94aaron > > https://www.isi.edu/newarch/DOCUMENTS/FARA.FDNA03.pdf > > > FARA: Reorganizing the Addressing Architecture > David Clark, Robert Braden, Aaron Falk, Venkata Pingali > > ABSTRACT > This paper describes FARA, a new organization of network > architecture concepts. FARA (Forwarding directive, Association, > and Rendezvous Architecture) defines an abstract > model with considerable generality and flexibility, based upon > the decoupling of end-system names from network addresses. > The paper explores the implications of FARA and the range > of architecture instantiations that may be derived from FARA. > As an illustration, the paper outlines a particular derived architecture, > M-FARA, which features support for generalized > mobility and multiple realms of network addressing. > > _______________________________________________ > Panrg mailing list > Panrg@irtf.org > https://www.irtf.org/mailman/listinfo/panrg From nobody Mon Jul 24 00:59:28 2017 Return-Path: X-Original-To: panrg@ietfa.amsl.com Delivered-To: panrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9346B131C20 for ; Mon, 24 Jul 2017 00:59:26 -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] 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 dDzaseGs2i7e for ; Mon, 24 Jul 2017 00:59:25 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06047127B73 for ; Mon, 24 Jul 2017 00:59:25 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5AC33340E16 for ; Mon, 24 Jul 2017 09:59:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.27310); Mon, 24 Jul 2017 09:59:23 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Mon, 24 Jul 2017 09:59:23 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 24525829 for panrg@irtf.org; Mon, 24 Jul 2017 09:59:23 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_AFBF0568-6D30-462E-A6A2-512FB6E36B68"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 24 Jul 2017 09:59:22 +0200 Message-Id: <2461B3FA-30F8-4BE3-87CF-46E637A05C7A@trammell.ch> To: panrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [PANRG] Post-IETF99: minutes, next steps. X-BeenThere: panrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 07:59:26 -0000 --Apple-Mail=_AFBF0568-6D30-462E-A6A2-512FB6E36B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, I've posted draft minutes of the panrg meeting: https://datatracker.ietf.org/meeting/99/minutes/panrg Many, many thanks to Tommy Pauly for taking notes! Please let us know of = any necessary changes at panrg-chairs@irtf.org. We'll be following up in the coming days on the following topics: - The agenda for our PANRG meeting in Singapore - Potential research group documents: - Mirja K=C3=BChlewind suggested a quick survey on failed attempts at = bringing path- (and link-) awareness to the Internet. - Looking over the minutes, it occurs to me that we should also have a = concrete list of path properties for explorations of availability in = various contexts, trust models, etc; this list could appear in its own = document, or in some other form at the beginning (a wiki?). Please send other potential RG work or expressions of interest in = contributing to either of these documents to the list. Thanks, cheers, Brian (for the chairs) --Apple-Mail=_AFBF0568-6D30-462E-A6A2-512FB6E36B68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZdajaAAoJEIoSt78L6kajfrIP/2JDjo69bbKX+wgVljxCiP48 365lD8ETGro1rugUAbOUIP3kw3f+703LkNmFs4d3/hGyx0Uam0ZUr+tc08Ji3xyG Bg9C9ye4qLneW9wTDZG4TGcn6W5pZ4pjFlwe7oFc115Jt06jdwXDt6WlyHew0CMr oBVfJcrFEjqPJYR32IO8i8lBcSaKgrFqyz+4ybTjjYw35MMTMNKGM3JKlFXgvavg co1XH8aCndv6xAIqnb/fiRIRszG/q4/GPd7bxptKED3MenhEBvz6wwmo19Et8lem dmERukgL//McNFw/jVh/B9RP6V7JCMbKOwTUKxI6BlY8xF57ECoNcUXDHWrBXVbx lav9x+skbao1wB9L1t455iDqXQD8/yOSO5RGHDiD8W5JAoS1gl4l24k4AdGyRQVG Zc8dFO1mpVQdxr5vZIDfFDQD4xayhQNtl4ERu7dKGK3F+HCEdXsxcMsrC/JBDGCO oTGT68H2Tgib2txzAghpEpk2hp6bGL5ZooDu6Qhqm7xOcohi5V5i/qqE6dTb0lNR jwsLZZT0F6C5O6B8DghPacdzitJavin89Gyn7FWsD+IrjXRrLwkd02q62Nm3cHVP R5YwXKKZsvNtqCAIzvBdgCkF5hYxTiNsoLwHKc12So5iTvxiOjTymrAIeQHMFiEi ZKc9CzWiOr1taOzJNYDt =STgJ -----END PGP SIGNATURE----- --Apple-Mail=_AFBF0568-6D30-462E-A6A2-512FB6E36B68--