From nobody Fri Jul 7 13:30:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7EA131442 for ; Fri, 7 Jul 2017 13:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZxYhxl8jLg_I for ; Fri, 7 Jul 2017 13:30:49 -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 6BCAE12EC12 for ; Fri, 7 Jul 2017 13:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3x45pb5SKKz15LlB for ; Fri, 7 Jul 2017 22:30:47 +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 6fF5WcmGpaCW for ; Fri, 7 Jul 2017 22:30:43 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC24CF.dip0.t-ipconnect.de [93.236.36.207]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA for ; Fri, 7 Jul 2017 22:30:43 +0200 (CEST) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: tsvarea Draft Agenda and TSV AD Office Hours Message-Id: <9612773C-3097-47DF-BF6B-9159BF6742CB@tik.ee.ethz.ch> Date: Fri, 7 Jul 2017 22:30:42 +0200 To: tsv-area@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:30:52 -0000 Hi all, we just uploaded the agenda. This time (after the extended session(s) = last time) we only have an one hour slot with one talk and some time for = open mic at the end: https://datatracker.ietf.org/meeting/99/agenda/tsvarea/ The meeting is right away Monday afternoon session III 17:40-18:40 in = the Grand Hilton Ballroom. Further we have our office hour this time already on Sunday: 15:00-16:00 in room Istanbul =20 Feel free to drop by if you have something to discuss with us, or maybe = even send us an email in advance to let us know that you=E2=80=99ll be = coming because this is also just an one hour slot=E2=80=A6 Anyway, see you soon in Prague! Spencer and Mirja =20= From nobody Tue Jul 11 23:21:53 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5812ECC8 for ; Tue, 11 Jul 2017 23:21:52 -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 z0cdEqXQiKJn for ; Tue, 11 Jul 2017 23:21:50 -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 E997512EC19 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 Subject: Proposed Path Aware Networking RG 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: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 06:21:52 -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 00:19:54 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA73B131893 for ; Wed, 12 Jul 2017 00:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 hJgfOiWx6Izl for ; Wed, 12 Jul 2017 00:19:50 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30139.outbound.protection.outlook.com [40.107.3.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7D0131451 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" Subject: RE: Proposed Path Aware Networking RG 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 07:19:53 -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 Wed Jul 12 01:46:59 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1D0131895 for ; Wed, 12 Jul 2017 01:46:57 -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=ham 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 aUKEjdClCP_U for ; Wed, 12 Jul 2017 01:46:56 -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 3B2EC12EC3B 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" Subject: Re: Proposed Path Aware Networking RG 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: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:46:57 -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:53 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C571318AA for ; Wed, 12 Jul 2017 05:52:51 -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=ham 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 iPVGJafqKA4P 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 3BE2413189A 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 Subject: Re: Proposed Path Aware Networking RG 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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:52:52 -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:33 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E780812F4EA 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=unavailable 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 8QiyGvnX4G4B for ; Wed, 12 Jul 2017 08:30:24 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 37294131691 for ; Wed, 12 Jul 2017 08:30:24 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 84so8234829ybe.0 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=VD8sbPuJOLXIzRfRQhABdIsS8bJfyzjV7UbDXumN/oDUZFoo7dS/bNyJuLQ3Pd+7GB rhz8cpRSmAJG45Wng8BT9W6kfzqX4LFsai+GBeJhtS/bff2OSjatZqOLMpa6/iongiBh BzPG3qux4+ULBQY8tf0Q+eo2fvdZ0rLReP2J51emN5YNOxplSOCa50Yv0UaSldPFguAy X36hgpAmSeoMqwbsxRlZPYITG1p/HoFCgv1dPZATM5+rT0wvxWH2YD/nEt1JIif6H6AO viiZQz2+zkrBXFCrdTlYZd5FBZiwp5nbR7BcjX0tl+JAOwub95iso3DdiZI0kecwGOk5 rGrw== X-Gm-Message-State: AIVw112Ii37KLdCffY7YgSJ5soCTb89cQFUUSUNf4VKysIO0B8CNNlJD yfj6fUhecFpBBz/Pf+pgiBEneNHUGw== 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: Subject: Re: [Panrg] Proposed Path Aware Networking RG 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: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 15:30:28 -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 12:23:33 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD41252BA; Wed, 12 Jul 2017 12:23:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9Rkw_JJYdig3; Wed, 12 Jul 2017 12:23:30 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2B91289B0; Wed, 12 Jul 2017 12:23:30 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l21so14002460ywb.1; Wed, 12 Jul 2017 12:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vgvh6VPUQL7mAsMa/EyNAtqRWPOkwz/V4MXzB85y2mA=; b=LHUHs+bw7CFwowLLXJABuWTQpyRo0zOUHKpfnnNEznieHb0Iqi29moDgOVDmXYYSsV DoO7wnSmsSfXB3ag0EbcPdzLSxT78bW0xa7Lspy/+082RGhf4uMzXzm6Fcm/gqpLqIFn 9puUBhQgV2nUM7gVdM3jbWAtshDDmlhDnWvFpstE1kMhyN1IhIdU75uhG2dq7NSA7BwS qRwWws19gJ8cwsYJ9TkFCSRTIIR8PXaE4NBLeTtOqy6Iu4tYBrr8E10ijZUlKhODAnyw cdBNxxkR2Plli/Pxmjayj6xUGtAAt2M4ckw3/cf9c19Xj5ZeiUzDxHQp8USLQ+bUjloC gFeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vgvh6VPUQL7mAsMa/EyNAtqRWPOkwz/V4MXzB85y2mA=; b=DGlzwPWojIo162nFGyl+mOGrsNG2f4ty/ncwzFJDKOZRYlVZFesnPaF3QFZtHZCQ1c uY/1zn+XxziQwnwALVkagwsXAzWifLrMiMxd0guXSuwo0vn/hwYtyl9URdgx+7eHtdxi b5LHhbxWo5ylbbmjHyBd+G2VAAqWMIpSnuR5r3ie1g2c6OqUY5e8Z+TonyboJGIY8qr5 oi+I/WGKsnWdlyDGw5UeTEx9FfEqvDl9wAfdkEoUWVNlwBtSCcogXvb3/Qro4rQh9ReZ sQxBEazJLm29ud2nhORsBj7Y1WDuPBfUJVmaOi7aHvJgwcu6/OVRk/VEDtSAsSw/t3kL irjQ== X-Gm-Message-State: AIVw110b7q3oy2ZgvNGWxn7mucCr/oKxy4arUrT4oCgOxs2rDwXIs3iF S5UxBxZiAzrmbH+XjtmZ3oqbO12ZcMMd X-Received: by 10.129.76.214 with SMTP id z205mr91848ywa.273.1499887409359; Wed, 12 Jul 2017 12:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 12 Jul 2017 12:23:28 -0700 (PDT) From: Spencer Dawkins at IETF Date: Wed, 12 Jul 2017 14:23:28 -0500 Message-ID: Subject: Transport attention to 6lo draft on fragmentation To: "tsv-area@ietf.org >> tsv-area@ietf.org" Cc: 6lo-chairs@ietf.org, Mirja Kuehlewind , Suresh Krishnan Content-Type: multipart/alternative; boundary="001a113f1d103cf38b055423c0e9" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:23:32 -0000 --001a113f1d103cf38b055423c0e9 Content-Type: text/plain; charset="UTF-8" Dear Transporters, Gab Montenegro, co-chair for 6lo, let me know that 6lo is considering adoption of a draft about how 6lowpan forwards fragments. The draft is https://datatracker.ietf.org/doc/draft-thubert-6lo- forwarding-fragments. Gab asked about getting TSV eyes on this draft, to help inform the working groups conversation about adoption. 6lo is scheduled for 15:50-17:50 on Tuesday Afternoon (session II), opposite MPTCP, but if you're available, informed, and opinionated, Gab says the working group has time to discuss adoption at the end of their agenda, and welcomes input. Thanks! Spencer, who also plans to attend, but is not the guiding light in TSV for fragmentation issues ... --001a113f1d103cf38b055423c0e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Transporters,

Gab Montenegro, co-c= hair for 6lo, let me know that 6lo is considering adoption of a draft about= how 6lowpan forwards fragments.=C2=A0

The draft i= s=C2=A0https://datatr= acker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments.

Gab asked about getting TSV eyes on this draft, to h= elp inform the working groups conversation about adoption.

6lo is scheduled for 15:50-17:50 on Tuesday Afternoon (session II)= , opposite MPTCP, but if you're available, informed, and opinionated, G= ab says the working group has time to discuss adoption at the end of their = agenda, and welcomes input.

Thanks!

=
Spencer, who also plans to attend, but is not the guiding light = in TSV for fragmentation issues ...
--001a113f1d103cf38b055423c0e9-- From nobody Wed Jul 12 13:20:42 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@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: , Subject: Re: Proposed Path Aware Networking RG 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing 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 Wed Jul 12 14:07:14 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DB3131788 for ; Wed, 12 Jul 2017 14:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 V6cA7Wjz3KhQ for ; Wed, 12 Jul 2017 14:07:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985D9131946 for ; Wed, 12 Jul 2017 14:07:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQZ60829; Wed, 12 Jul 2017 21:07:08 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 22:07:07 +0100 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" Subject: RE: [Panrg] Proposed Path Aware Networking RG 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59668F7D.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5b98329685a9f892db7f0453771171f2 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:07:13 -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 Wed Jul 12 15:07:03 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC9C129B36 for ; Wed, 12 Jul 2017 15:06:56 -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 KBfLLLe4U_e7 for ; Wed, 12 Jul 2017 15:06:52 -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 6E66F12ECB5 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 Subject: Re: [Panrg] Proposed Path Aware Networking RG 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: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 22:06:56 -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:00 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E8131A75 for ; Thu, 13 Jul 2017 06:41:58 -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=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 OTI5SSZHdw8Q 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 B4FC5131699 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\)) Subject: Re: [Panrg] Proposed Path Aware Networking RG 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: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 13:41:59 -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 Thu Jul 13 14:11:23 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@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) Subject: Re: Proposed Path Aware Networking RG 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing 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 Sun Jul 16 22:39:32 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2595C12EC0D for ; Sun, 16 Jul 2017 22:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 KC6XwDZL3Wp3 for ; Sun, 16 Jul 2017 22:39:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5B2129B2E for ; Sun, 16 Jul 2017 22:39:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRI23254; Mon, 17 Jul 2017 05:39:26 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 06:39:25 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 17 Jul 2017 13:39:06 +0800 From: Qin Wu To: "tsv-area@ietf.org" CC: "Zhenghui (Marvin)" Subject: Proposal for revising RFC4445 or make RFC4445bis Thread-Topic: Proposal for revising RFC4445 or make RFC4445bis Thread-Index: AdL+upKrZfLlANeyShyCdff5urW2EA== Date: Mon, 17 Jul 2017 05:39:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.72.246] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9FE9CEnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.596C4D8E.0090, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d502c856e0990d835409648c57e273f0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:39:30 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A9FE9CEnkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsbDoNCg0KV2UgbGlrZSB0byBnZXQgYSBzZW5zZSBvZiB0aGlzIGlkZWEsIG1vcmUgdGhh biAxMCB5ZWFycyBhZ28sIGF0IHRoZSB0aW1lIG9mIFJGQzQ0NDUgd3JpdGluZywNCg0KVGhlIHBv cHVsYXJpdHkgb2YgZGVsaXZlcnkgb2Ygc3RyZWFtaW5nIG1lZGlhIG92ZXIgcGFja2V0IHN3dGlj aGVkIG5ldHdvcmsgaGFzIGp1c3QgYmVnYW4sDQoNCm5vdCBhbGwgaW1wbGVtZW50YXRpb25zIHN1 cHBvcnQgUW9TIG1ldGhvZHMgdG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVyeS4gTWFueSBzZXJ2aWNl DQoNCmRlbGl2ZXJ5IHN5c3RlbXMgbWF5IGNvbXBvc2UgdGhlIG5ldHdvcmsgd2l0aCBRb1Mgc3Vw cG9ydCBvciB3aXRob3V0IFFvUyBzdXBwb3J0LiBUaGlzIGFkZCBkaWZmaWN1bHR5IG9uIGNoYXJh Y3Rlcml6aW5nIGR5bmFtaWMgYmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsuDQoNCg0KDQoxMCB5ZWFy cyBoYXZlIHBhc3NlZCwgd2Ugc2VlIG1vc3Qgb2Ygd2lkZWx5IGRlcGxveWVkIGltcGxlbWVudGlv bnMgaGF2ZSBhZG9wdGVkIHZhcmlvdXMgZGlmZmVyZW50IFFvUyBtZWNoYW5pc21zDQoNCnN1Y2gg YXMgZGlmZnNlcnYgSW50c2VydiwgVHJhZmZpYyBFbmdpbmVlcmluZywgcHJvdmlkaW5nIFFvUyBn dWFyYW50ZWUgdG8gaW1wcm92ZSBkZWxpdmVyeSBvZiBtZWRpYSBzdHJlYW1pbmcsDQoNCmVzcGVj aWFsbHkgZm9yIHRpbWUgc2VuZXN0aXZlIG9yIGxvc3Mgc2Vuc3RpdmUgYXBwbGljYXRpb24gYmVj b21lIGEgbXVzdDsgVGhlcmVmb3JlIHdlIHNlZSBhIGxvdCBvZiB2YWx1ZSBvZiBNREkgZGVmaW5l ZCBpbiBSRkM0NDQ1IHNpbmNlIGl0IHByb3ZpZGUgcyBhIGhhbmR5IGRpYWdub3N0aWMgdG9vbCBm b3Igb3BlcmF0b3JzIGFuZCBzZXJ2aWNlIHByb3ZpZGVycyB0byBtZWFzdXJlIHRoZSBwZWZvcm1h bmNlIG9mIHRoZSBuZXR3b3JrIGNhcnJ5aW5nIHN0cmVhbWluZyBtZWRpYSBhbmQgcXVpY2tseSBp ZGVudGlmeSBmYXVsdCBpbiB0aGUgbmV0d29yay4NCg0KDQoNClRvZGF5IHdlIGFsc28gc2VlIG1h bnkgc2VydmljZSBwcm92aWRlcnMgYmVnYWluIHRvIG9mZmVyIG9uIGRlbWFuZCBzdHJlYW1pbmcg bWVkaWEgc2VydmljZSwgbWFueSBvcGVyYXRvciBkZXBsb3llZCBDRE4gaW4gdGhlIGxhc3QgbWls ZSB0byBwcm92aWRlIGJldHRlciBTTEEsIG9yIHByb3ZpZGUgaHlicmlkIFRWIHNlcnZpY2UsIGlu IGFkZGl0aW9uIG1vcmUgYW5kIG1vcmUgcmVhbCB0aW1lIGFwcGxpY2F0aW9uIG5vdCBsaW1pdGVk IHRvIElQVFYgYXBwbGljYXRpb24sIFZPSVAgYXBwbGljYXRpb24gaGF2ZSBiZWVuIGRldmVsb3Bl ZCxuZXR3b3JrIG1vbml0b3JpbmcgYW5kIG5ldHdvcmsgdHJvdWJsZXNob290aW5nIGJlZ2FuIG1v cmUgYW5kIG1vcmUgY29tcGxpY2F0ZWQgYW5kIGNvc3R5LiBXZSBoZWFyIGEgbG90IG9mIG9wZXJh dG9ycyBnZXQgaHVydGVkIGFuZCB3YW50IHRvIGhhdmUgYSBjb21tb24gdG9vbCB0byBoZWxwIHRo ZW0gdG8gbWVhc3VyZSBwZXJmb3JtYW5jZSBpbiB0aGlzIGtpbmQgb2YgbmV0d29ya3MgYW5kIHBy b3ZpZGVyIGJldHRlciB0cm91Ymxlc2hvb3RpbmcuDQoNCg0KDQpBbm90aGVyIG9ic2VydmF0aW9u IGlzIHRvZGF5IG1vcmUgYW5kIG1vcmUgaW1wbGVtZW50YXRpb25zIGhhdmUgYWRvcHRlZCBwYWNr ZXQgbG9zcyByZXBhaXIgbWV0aG9kcyB0byBpbXByb3ZlIG1lZGlhIGRlbGl2ZXJ5Lg0KDQpIb3dl dmVyIE1ESSBkZWZpbmVkIGluIFJGQzQ0NDUgZG9lc24ndCB0YWtlIGludG8gYWNvdW50IG9mIHZh cmlvdXMgZGlmZmVyZW50IHBhY2tldCBsb3NzIHJlcGFpciBtZWNoYW5pbXMsIGluIGFkZGl0aW9u LCBSRkM0NDQ1IGlzIG9ubHkgZGVzaWduZWQgZm9yIG1vbml0b3JpbmcgTVBFRyBUcmFuc3BvcnQg U3RyZWFtIChUUykgcGFja2V0cyBvdmVyIFVEUCBhbmQgZmFsbCBzaG9ydCB0byBhZGRyZXNzaW5n IG5lZWRzIGluIGh5YnJpZCBzZW5hcmlvcyBvciBvbiBkZW1hbmQgc3RyZWFtaW5nIG1lZGlhIHNj ZW5hcmlvcy4NCg0KDQoNCkluIGFkZGl0aW9uLCB3ZSBzZWUgYXQgdGhlIHRpbWUgb2YgUkZDNDQ0 NSBwdWJsaWNhdGlvbiwgSUVTRyBkb2Vzbid0IHJlY29tbWVuZCB0aGlzIHN0YW5kYXJkLCBtb3N0 bHkgYmVjb3MgUkZDNDQ0NSBkb2Vzbid0IGRlZmluZSBjb21wbGV0ZSBNZXRyaWMgYW5kIGNsYXJp ZnkgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIGV4aXN0aW5nIElFVEYgd29yayBzdWNoIGFzIFJGQzM2 MTEgYW5kIFJGQzM5MzMsIEkgYW0gd29uZGVyaW5nIGlmIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHJl dmlzZSBSRkM0NDQ1IHRvIGFkZHJlc3MgSUVTRyBjb25jZXJuIHRvZGF5IGFuZCBpbiBhZGRpdGlv biBmaWxsIG5ldyBuZWVkcyBpbiB0b2RheSdzIHNlcnZpY2UgZGVwbG95bWVudC4NCg0KQ29tbWVu dHMgYW5kIHN1Z2dlc3Rpb25zPw0KDQoNCg0KLVFpbg0K --_000_B8F9A780D330094D99AF023C5877DABA9A9FE9CEnkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, All:

We like to get a sense of this idea, more than 10 years ago, at the time= of RFC4445 writing,

The popularity of delivery of streaming media over packet swtiched netwo= rk has just began,

not all implementations support QoS methods to improve media delivery. M= any service

delivery systems may compose the network with QoS support or without QoS= support. This add difficulty on characterizing dynamic behavior of the net= work.

 

10 years have passed, we see most of widely deployed implementions have = adopted various different QoS mechanisms

such as diffserv Intserv, Traffic Engineering, providing QoS guarantee t= o improve delivery of media streaming,

especially for time senestive or loss senstive application become a must= ; Therefore we see a lot of value of MDI defined in RFC4445 since it provid= e s a handy diagnostic tool for operators and service providers to measure = the peformance of the network carrying streaming media and quickly identify fault in the network.

 

Today we also see many service providers begain to offer on de= mand streaming media service, many operator deployed CDN in the last mile t= o provide better SLA, or provide hybrid TV service, in addition more and mo= re real time application not limited to IPTV application, VOIP application have been developed,network monitoring and n= etwork troubleshooting began more and more complicated and costy. We h= ear a lot of operators get hurted and want to have a common tool to help th= em to measure performance in this kind of networks and provider better troubleshooting.

 

Another observation is today more and more implementations have adopted = packet loss repair methods to improve media delivery.

However MDI defined in RFC4445 doesn't take into acount of various diffe= rent packet loss repair mechanims, in addition, RFC4445 is only designed fo= r monitoring MPEG Transport Stream (TS) packets over UDP and fall short to = addressing needs in hybrid senarios or on demand streaming media scenarios.

 

In addition, we see at the time of RFC4445 publication, IESG doesn't rec= ommend this standard, mostly becos RFC4445 doesn't define complete Metric a= nd clarify the relationship with existing IETF work such as RFC3611 and RFC= 3933, I am wondering if it is a good idea to revise RFC4445 to address IESG concern today and in addition = fill new needs in today's service deployment.

Comments and suggestions?

 

-Qin

--_000_B8F9A780D330094D99AF023C5877DABA9A9FE9CEnkgeml513mbxchi_-- From nobody Mon Jul 17 04:02:01 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B054131B24 for ; Mon, 17 Jul 2017 04:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 DT1OT9iZRnJx for ; Mon, 17 Jul 2017 04:01:59 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D4C53131B01 for ; Mon, 17 Jul 2017 04:01:58 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l21so45738476ywb.1 for ; Mon, 17 Jul 2017 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ub0mJBW4ZbcYMyHhCcgf7rquaYoJj500+RE6fnSG1Vo=; b=fJvKNkLAYraSgXZWQLgWKRJndZZ9GNhQ6IqU+s8BoLEC4kOhQhc302tMlgUK9iS7Uh 21zscxNdZBoUQxejI5wBLcC5BsccB4vj5aBX7kdutydsaGQNNgjMCTcDnMmcptrl/Mxl fsgjULtYc8C6aEOuTaPpi55jxW0oKBRNrG3YXcG52/KFb+7LDEGPbtY+kJM9LSrPrzkk njkfjU1U4cb/4c9J08KuQmC6diQKnqFNiuTH+GbfefAPQM96611xKh4IRYwKpUkrzry6 L1++4VphEqSmB3a9IqokRBqMVu67yyV7tVD3hoR5hIidKgHDK1hiKn6yrhMjOgQZMRVi mJQg== 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=Ub0mJBW4ZbcYMyHhCcgf7rquaYoJj500+RE6fnSG1Vo=; b=QYSPLODRQ2QBbEA4xJvgGQyB48Bwl1y+TESs96IVHi+eLpUsRi6NBhvmUhfTBvEAQb xYMwk3ytQPwE8gKrdXr0kFNXY/thak8a+l3UjacjHJsAmdloKxvAznBUf7vghSzdGBc5 R1+Ipxd62nY6KaVOUiWfEyr6aR7BvyZlqTHwIEJ8RD3EL/FVW3tT6bmU4Sn71XR1gp2M +02y2oW0QLJ/SdK/adEsAlXFW9zAeVsyz0XBRqEnAHKryqUFE/HM70cwVuKImW5pxVTH lWKXRpuyMLKADZi5nfgbQa0V5se32YvWJ6pIY8PnvWEHkc9ZNP2pNjCBcqYuY0DlQP5W y4TQ== X-Gm-Message-State: AIVw110/uZpN7F4LVKIwPr84iVdJgOeH8t+Q0MM3cRgJxtXuoPCWfZ8m ch76LhZ4ezxLvrsLrGEFktZ11MJqCaaL X-Received: by 10.129.78.198 with SMTP id c189mr6188189ywb.62.1500289318071; Mon, 17 Jul 2017 04:01:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.29.15 with HTTP; Mon, 17 Jul 2017 04:01:57 -0700 (PDT) In-Reply-To: References: From: "Ali C. Begen" Date: Mon, 17 Jul 2017 19:01:57 +0800 Message-ID: Subject: Re: Proposal for revising RFC4445 or make RFC4445bis To: Qin Wu Cc: "tsv-area@ietf.org" , "Zhenghui (Marvin)" Content-Type: multipart/alternative; boundary="001a114dd1dedd474805548153f3" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:02:01 -0000 --001a114dd1dedd474805548153f3 Content-Type: text/plain; charset="UTF-8" I am really curious about who is using MDI anymore. Can you share data if you have it? RTCP XR is still extensively used and for non-RTP, it is a mixed of several things. -acbegen On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > Hi, All: > > We like to get a sense of this idea, more than 10 years ago, at the time > of RFC4445 writing, > > The popularity of delivery of streaming media over packet swtiched network > has just began, > > not all implementations support QoS methods to improve media delivery. > Many service > > delivery systems may compose the network with QoS support or without QoS > support. This add difficulty on characterizing dynamic behavior of the > network. > > > > 10 years have passed, we see most of widely deployed implementions have > adopted various different QoS mechanisms > > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee to > improve delivery of media streaming, > > especially for time senestive or loss senstive application become a must; > Therefore we see a lot of value of MDI defined in RFC4445 since it provide > s a handy diagnostic tool for operators and service providers to measure > the peformance of the network carrying streaming media and quickly identify > fault in the network. > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and more > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurted > and want to have a common tool to help them to measure performance in this > kind of networks and provider better troubleshooting. > > > > Another observation is today more and more implementations have adopted > packet loss repair methods to improve media delivery. > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC3611 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > Comments and suggestions? > > > > -Qin > --001a114dd1dedd474805548153f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am really curious about who is using MDI anymore. Can yo= u share data if you have it? RTCP XR is still extensively used and for non-= RTP, it is a mixed of several things.

-acbegen

On Mon, Jul 17,= 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.com> wrote:

Hi, All:

We like to get a sense of this idea, more than 10 years ago, at the time= of RFC4445 writing,

The popularity of delivery of streaming media over packet swtiched netwo= rk has just began,

not all implementations support QoS methods to improve media delivery. M= any service

delivery systems may compose the network with QoS support or without QoS= support. This add difficulty on characterizing dynamic behavior of the net= work.

=C2=A0

10 years have passed, we see most of widely deployed implementions have = adopted various different QoS mechanisms

such as diffserv Intserv, Traffic Engineering, providing QoS guarantee t= o improve delivery of media streaming,

especially for time senestive or loss senstive application become a must= ; Therefore we see a lot of value of MDI defined in RFC4445 since it provid= e s a handy diagnostic tool for operators and service providers to measure = the peformance of the network carrying streaming media and quickly identify fault in the network.

=C2=A0

Today we also see many=C2=A0service providers=C2=A0begain to offer on de= mand streaming media service, many operator deployed CDN in the last mile t= o provide better SLA, or provide hybrid TV service, in addition more and mo= re real time application not limited to IPTV application, VOIP application have been developed,network monitoring and n= etwork troubleshooting began more and more complicated and costy.=C2=A0We h= ear a lot of operators get hurted and want to have a common tool to help th= em to measure performance in this kind of networks and provider better troubleshooting.

=C2=A0

Another observation is today more and more implementations have adopted = packet loss repair methods to improve media delivery.

However MDI defined in RFC4445 doesn't take into acount of various d= ifferent packet loss repair mechanims, in addition, RFC4445 is only designe= d for monitoring MPEG Transport Stream (TS) packets over UDP and fall short= to addressing needs in hybrid senarios or on demand streaming media scenarios.

=C2=A0

In addition, we see at the time of RFC4445 publication, IESG doesn't= recommend this standard, mostly becos RFC4445 doesn't define complete = Metric and clarify the relationship with existing IETF work such as RFC3611= and RFC3933, I am wondering if it is a good idea to revise RFC4445 to address IESG concern today and in addition = fill new needs in today's service deployment.

Comments and suggestions?

=C2=A0

-Qin


--001a114dd1dedd474805548153f3-- From nobody Mon Jul 17 04:18:40 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BB2120725 for ; Mon, 17 Jul 2017 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 CRB8M3frMlfn for ; Mon, 17 Jul 2017 04:18:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7370213189C for ; Mon, 17 Jul 2017 04:18:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRJ47907; Mon, 17 Jul 2017 11:18:33 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 12:18:32 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 17 Jul 2017 19:18:22 +0800 From: Qin Wu To: "ali.begen@networked.media" CC: "tsv-area@ietf.org" , "Zhenghui (Marvin)" Subject: =?gb2312?B?tPC4tDogIFByb3Bvc2FsIGZvciByZXZpc2luZyBSRkM0NDQ1IG9yIG1ha2Ug?= =?gb2312?Q?RFC4445bis?= Thread-Topic: Proposal for revising RFC4445 or make RFC4445bis Thread-Index: AQHS/u5mwKtRh+stH020AcFKz7T5QA== Date: Mon, 17 Jul 2017 11:18:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan596c9cfb19495cff46eQinWudeiPhone_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.596C9D09.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c685ff89d593f79f209d29d4d65016ac Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:18:39 -0000 --_000_etPan596c9cfb19495cff46eQinWudeiPhone_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2UgaGF2ZSBjdXN0b21lcnMgdXNpbmcgTURJIHRvIGFkZHJlc3MgbmV3IG5lZWRzLCBzdWNoIGFz IHdpZmkgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgTURJIGZhbGxzIHNob3J0IHdoZW4gbWVhc3Vy aW5nIGRlbGl2ZXJ5IG9mIHN0cmVhbWluZyBtZWRpYSBvdmVyIHRjcCwgdGhhdCBpcyB3aHkgd2Ug dGhpbmsgaXQgc2hvdWxkIGJlIGV4dGVuZGVkLiBZZXMsIHJ0Y3AgWFIgaGFzIGl0cyB2YWx1ZS4g QnV0IEkgdGhpbmsgdGhleSBjb3VsZCBiZSBjb21wbGltZW50YXJ5Lg0KDQpTZW50IGZyb20gSFVB V0VJIEFueU9mZmljZQ0Kt6K8/sjLo7ogQWxpIEMuIEJlZ2VuDQrK1bz+yMujuiBRaW4gV3U7DQqz rcvNo7ogdHN2LWFyZWFAaWV0Zi5vcmc7INaju9Q7DQrW98zio7ogUmU6IFByb3Bvc2FsIGZvciBy ZXZpc2luZyBSRkM0NDQ1IG9yIG1ha2UgUkZDNDQ0NWJpcw0KyrG85KO6IDIwMTctMDctMTcgMTM6 MDI6MDcNCg0KDQpJIGFtIHJlYWxseSBjdXJpb3VzIGFib3V0IHdobyBpcyB1c2luZyBNREkgYW55 bW9yZS4gQ2FuIHlvdSBzaGFyZSBkYXRhIGlmIHlvdSBoYXZlIGl0PyBSVENQIFhSIGlzIHN0aWxs IGV4dGVuc2l2ZWx5IHVzZWQgYW5kIGZvciBub24tUlRQLCBpdCBpcyBhIG1peGVkIG9mIHNldmVy YWwgdGhpbmdzLg0KDQotYWNiZWdlbg0KDQpPbiBNb24sIEp1bCAxNywgMjAxNyBhdCAxOjM5IFBN LCBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj4g d3JvdGU6DQoNCkhpLCBBbGw6DQoNCldlIGxpa2UgdG8gZ2V0IGEgc2Vuc2Ugb2YgdGhpcyBpZGVh LCBtb3JlIHRoYW4gMTAgeWVhcnMgYWdvLCBhdCB0aGUgdGltZSBvZiBSRkM0NDQ1IHdyaXRpbmcs DQoNClRoZSBwb3B1bGFyaXR5IG9mIGRlbGl2ZXJ5IG9mIHN0cmVhbWluZyBtZWRpYSBvdmVyIHBh Y2tldCBzd3RpY2hlZCBuZXR3b3JrIGhhcyBqdXN0IGJlZ2FuLA0KDQpub3QgYWxsIGltcGxlbWVu dGF0aW9ucyBzdXBwb3J0IFFvUyBtZXRob2RzIHRvIGltcHJvdmUgbWVkaWEgZGVsaXZlcnkuIE1h bnkgc2VydmljZQ0KDQpkZWxpdmVyeSBzeXN0ZW1zIG1heSBjb21wb3NlIHRoZSBuZXR3b3JrIHdp dGggUW9TIHN1cHBvcnQgb3Igd2l0aG91dCBRb1Mgc3VwcG9ydC4gVGhpcyBhZGQgZGlmZmljdWx0 eSBvbiBjaGFyYWN0ZXJpemluZyBkeW5hbWljIGJlaGF2aW9yIG9mIHRoZSBuZXR3b3JrLg0KDQoN Cg0KMTAgeWVhcnMgaGF2ZSBwYXNzZWQsIHdlIHNlZSBtb3N0IG9mIHdpZGVseSBkZXBsb3llZCBp bXBsZW1lbnRpb25zIGhhdmUgYWRvcHRlZCB2YXJpb3VzIGRpZmZlcmVudCBRb1MgbWVjaGFuaXNt cw0KDQpzdWNoIGFzIGRpZmZzZXJ2IEludHNlcnYsIFRyYWZmaWMgRW5naW5lZXJpbmcsIHByb3Zp ZGluZyBRb1MgZ3VhcmFudGVlIHRvIGltcHJvdmUgZGVsaXZlcnkgb2YgbWVkaWEgc3RyZWFtaW5n LA0KDQplc3BlY2lhbGx5IGZvciB0aW1lIHNlbmVzdGl2ZSBvciBsb3NzIHNlbnN0aXZlIGFwcGxp Y2F0aW9uIGJlY29tZSBhIG11c3Q7IFRoZXJlZm9yZSB3ZSBzZWUgYSBsb3Qgb2YgdmFsdWUgb2Yg TURJIGRlZmluZWQgaW4gUkZDNDQ0NSBzaW5jZSBpdCBwcm92aWRlIHMgYSBoYW5keSBkaWFnbm9z dGljIHRvb2wgZm9yIG9wZXJhdG9ycyBhbmQgc2VydmljZSBwcm92aWRlcnMgdG8gbWVhc3VyZSB0 aGUgcGVmb3JtYW5jZSBvZiB0aGUgbmV0d29yayBjYXJyeWluZyBzdHJlYW1pbmcgbWVkaWEgYW5k IHF1aWNrbHkgaWRlbnRpZnkgZmF1bHQgaW4gdGhlIG5ldHdvcmsuDQoNCg0KDQpUb2RheSB3ZSBh bHNvIHNlZSBtYW55IHNlcnZpY2UgcHJvdmlkZXJzIGJlZ2FpbiB0byBvZmZlciBvbiBkZW1hbmQg c3RyZWFtaW5nIG1lZGlhIHNlcnZpY2UsIG1hbnkgb3BlcmF0b3IgZGVwbG95ZWQgQ0ROIGluIHRo ZSBsYXN0IG1pbGUgdG8gcHJvdmlkZSBiZXR0ZXIgU0xBLCBvciBwcm92aWRlIGh5YnJpZCBUViBz ZXJ2aWNlLCBpbiBhZGRpdGlvbiBtb3JlIGFuZCBtb3JlIHJlYWwgdGltZSBhcHBsaWNhdGlvbiBu b3QgbGltaXRlZCB0byBJUFRWIGFwcGxpY2F0aW9uLCBWT0lQIGFwcGxpY2F0aW9uIGhhdmUgYmVl biBkZXZlbG9wZWQsbmV0d29yayBtb25pdG9yaW5nIGFuZCBuZXR3b3JrIHRyb3VibGVzaG9vdGlu ZyBiZWdhbiBtb3JlIGFuZCBtb3JlIGNvbXBsaWNhdGVkIGFuZCBjb3N0eS4gV2UgaGVhciBhIGxv dCBvZiBvcGVyYXRvcnMgZ2V0IGh1cnRlZCBhbmQgd2FudCB0byBoYXZlIGEgY29tbW9uIHRvb2wg dG8gaGVscCB0aGVtIHRvIG1lYXN1cmUgcGVyZm9ybWFuY2UgaW4gdGhpcyBraW5kIG9mIG5ldHdv cmtzIGFuZCBwcm92aWRlciBiZXR0ZXIgdHJvdWJsZXNob290aW5nLg0KDQoNCg0KQW5vdGhlciBv YnNlcnZhdGlvbiBpcyB0b2RheSBtb3JlIGFuZCBtb3JlIGltcGxlbWVudGF0aW9ucyBoYXZlIGFk b3B0ZWQgcGFja2V0IGxvc3MgcmVwYWlyIG1ldGhvZHMgdG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVy eS4NCg0KSG93ZXZlciBNREkgZGVmaW5lZCBpbiBSRkM0NDQ1IGRvZXNuJ3QgdGFrZSBpbnRvIGFj b3VudCBvZiB2YXJpb3VzIGRpZmZlcmVudCBwYWNrZXQgbG9zcyByZXBhaXIgbWVjaGFuaW1zLCBp biBhZGRpdGlvbiwgUkZDNDQ0NSBpcyBvbmx5IGRlc2lnbmVkIGZvciBtb25pdG9yaW5nIE1QRUcg VHJhbnNwb3J0IFN0cmVhbSAoVFMpIHBhY2tldHMgb3ZlciBVRFAgYW5kIGZhbGwgc2hvcnQgdG8g YWRkcmVzc2luZyBuZWVkcyBpbiBoeWJyaWQgc2VuYXJpb3Mgb3Igb24gZGVtYW5kIHN0cmVhbWlu ZyBtZWRpYSBzY2VuYXJpb3MuDQoNCg0KDQpJbiBhZGRpdGlvbiwgd2Ugc2VlIGF0IHRoZSB0aW1l IG9mIFJGQzQ0NDUgcHVibGljYXRpb24sIElFU0cgZG9lc24ndCByZWNvbW1lbmQgdGhpcyBzdGFu ZGFyZCwgbW9zdGx5IGJlY29zIFJGQzQ0NDUgZG9lc24ndCBkZWZpbmUgY29tcGxldGUgTWV0cmlj IGFuZCBjbGFyaWZ5IHRoZSByZWxhdGlvbnNoaXAgd2l0aCBleGlzdGluZyBJRVRGIHdvcmsgc3Vj aCBhcyBSRkMzNjExIGFuZCBSRkMzOTMzLCBJIGFtIHdvbmRlcmluZyBpZiBpdCBpcyBhIGdvb2Qg aWRlYSB0byByZXZpc2UgUkZDNDQ0NSB0byBhZGRyZXNzIElFU0cgY29uY2VybiB0b2RheSBhbmQg aW4gYWRkaXRpb24gZmlsbCBuZXcgbmVlZHMgaW4gdG9kYXkncyBzZXJ2aWNlIGRlcGxveW1lbnQu DQoNCkNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucz8NCg0KDQoNCi1RaW4NCg0K --_000_etPan596c9cfb19495cff46eQinWudeiPhone_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
We have customers using MDI to address&n= bsp;new needs, such as wifi performance measu= rement MDI falls short when measuring deliver= y of streaming media over tcp, that is&n= bsp;why we think it should be extended. = Yes, rtcp XR has its value. But I t= hink they could be complimentary.

Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BA Ali C. Begen
=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu;
=B3=AD=CB=CD=A3=BA tsv-area@ietf.org; =D6=A3=BB=D4;
=D6=F7=CC=E2=A3=BA Re: Proposal for revising RFC4445 or make RF= C4445bis
=CA=B1=BC=E4=A3=BA 2017-07-17 13:02:07


I am really curious about who is using MDI anymore. Can yo= u share data if you have it? RTCP XR is still extensively used and for non-= RTP, it is a mixed of several things.

-acbegen

On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.= com> wrote:

Hi, All:

We like to get a sense of this idea, more than 10 years ago, at the time= of RFC4445 writing,

The popularity of delivery of streaming media over packet swtiched netwo= rk has just began,

not all implementations support QoS methods to improve media delivery. M= any service

delivery systems may compose the network with QoS support or without QoS= support. This add difficulty on characterizing dynamic behavior of the net= work.

 

10 years have passed, we see most of widely deployed implementions have = adopted various different QoS mechanisms

such as diffserv Intserv, Traffic Engineering, providing QoS guarantee t= o improve delivery of media streaming,

especially for time senestive or loss senstive application become a must= ; Therefore we see a lot of value of MDI defined in RFC4445 since it provid= e s a handy diagnostic tool for operators and service providers to measure = the peformance of the network carrying streaming media and quickly identify fault in the network.

 

Today we also see many service providers begain to offer on de= mand streaming media service, many operator deployed CDN in the last mile t= o provide better SLA, or provide hybrid TV service, in addition more and mo= re real time application not limited to IPTV application, VOIP application have been developed,network monitoring and n= etwork troubleshooting began more and more complicated and costy. We h= ear a lot of operators get hurted and want to have a common tool to help th= em to measure performance in this kind of networks and provider better troubleshooting.

 

Another observation is today more and more implementations have adopted = packet loss repair methods to improve media delivery.

However MDI defined in RFC4445 doesn't take into acount of various diffe= rent packet loss repair mechanims, in addition, RFC4445 is only designed fo= r monitoring MPEG Transport Stream (TS) packets over UDP and fall short to = addressing needs in hybrid senarios or on demand streaming media scenarios.

 

In addition, we see at the time of RFC4445 publication, IESG doesn't rec= ommend this standard, mostly becos RFC4445 doesn't define complete Metric a= nd clarify the relationship with existing IETF work such as RFC3611 and RFC= 3933, I am wondering if it is a good idea to revise RFC4445 to address IESG concern today and in addition = fill new needs in today's service deployment.

Comments and suggestions?

 

-Qin


--_000_etPan596c9cfb19495cff46eQinWudeiPhone_-- From nobody Mon Jul 17 04:31:15 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE5131B2F for ; Mon, 17 Jul 2017 04:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 hsrLLpHDVyJC for ; Mon, 17 Jul 2017 04:31:12 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E051288B8 for ; Mon, 17 Jul 2017 04:31:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id a12so45984422ywh.3 for ; Mon, 17 Jul 2017 04:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0NQYFYgSuetLa0CINUZJjxVHJJL1IwLreq6+ZAsn9P8=; b=zbB5PmRotDKyuUv5qIEXJ0FjB/eX2uMhctqt5g4Cv79eYnyiko/RsYCQdq2BfZwMjb mIgjjnnnnexJD+1PqZq1/0aly9oDBO0sFeyGzoYII+JJ7iWrl8sEjryS43TfOabxThJ8 aloLyO1qcdJNnlZIkDOPw5lvt5SF+YMa6FPZVopC68BIbuuRIH+t65rej/au9hPBPDk2 KQqe8HVPcQorkW73JibOwpFqP2ya3ZqWxZ9pEMe2pVX6mZDRcnXNfbcubluU4J+b//CX tCgEXa9uYwRcSh7NDvmqzY26TOnguLlMwmxsdqD1Rgu2219++JVB8MSBrQ8HuJvBMDQ7 RSrA== 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=0NQYFYgSuetLa0CINUZJjxVHJJL1IwLreq6+ZAsn9P8=; b=L+KPX/kAsvslpetrW4N49HADF4Ss9sepa/JdkoHZ63AIA5FILhJzzpGBMWB0kZnOd8 sjTIRx8IFknnOyNWPrSSCjlZCGKHNEfkZszDINce9gLLt4611JlPjxBprtCDXb85fg5X oM48OWGQ9noy8vW7dIz3pUohET9T/u3xEl9BSGm3klGdOYUUP6CYO5l7/U50F6XqTTvT oEn8pDBLv3y692ejNp0TnMS7ToKkO9NARjKnJcH/mf2+bDKdSTkkXZxeHrGFneHg7RAk fkcuKel0P8LW4b59Ss2bdB1OpnRiRa2SJ0OAKZSR/vq8dFXA58RCMvcMbAybNxjHxGp9 z4fg== X-Gm-Message-State: AIVw110431pN5WAuk5JuK1simMAxvEndCtQLccKuk7QBU8uI2RvN0ozW mqAhNPy08YWO9kbkseW6/sfovLY8pTjJ X-Received: by 10.13.204.200 with SMTP id o191mr16820289ywd.14.1500291071398; Mon, 17 Jul 2017 04:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.29.15 with HTTP; Mon, 17 Jul 2017 04:31:10 -0700 (PDT) In-Reply-To: References: From: "Ali C. Begen" Date: Mon, 17 Jul 2017 19:31:10 +0800 Message-ID: Subject: =?UTF-8?Q?Re=3A_=E7=AD=94=E5=A4=8D=3A_Proposal_for_revising_RFC4445_or_make_RF?= =?UTF-8?Q?C4445bis?= To: Qin Wu Cc: "tsv-area@ietf.org" , "Zhenghui (Marvin)" Content-Type: multipart/alternative; boundary="001a114f1c7a5f2df2055481bc1d" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:31:14 -0000 --001a114f1c7a5f2df2055481bc1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You wanna use MDI to measure media delivery over TCP? On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > We have customers using MDI to address new needs, such as > wifi performance measurement MDI falls short when measuring delivery of > streaming media over tcp, that is why we think it > should be extended. Yes, rtcp XR has its value. But I think > they could be complimentary. > > Sent from HUAWEI AnyOffice > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Ali C. Begen > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *Qin Wu; > *=E6=8A=84=E9=80=81=EF=BC=9A *tsv-area@ietf.org; =E9=83=91=E8=BE=89; > *=E4=B8=BB=E9=A2=98=EF=BC=9A *Re: Proposal for revising RFC4445 or make R= FC4445bis > *=E6=97=B6=E9=97=B4=EF=BC=9A *2017-07-17 13:02:07 > > > I am really curious about who is using MDI anymore. Can you share data if > you have it? RTCP XR is still extensively used and for non-RTP, it is a > mixed of several things. > > -acbegen > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > >> Hi, All: >> >> We like to get a sense of this idea, more than 10 years ago, at the time >> of RFC4445 writing, >> >> The popularity of delivery of streaming media over packet swtiched >> network has just began, >> >> not all implementations support QoS methods to improve media delivery. >> Many service >> >> delivery systems may compose the network with QoS support or without QoS >> support. This add difficulty on characterizing dynamic behavior of the >> network. >> >> >> >> 10 years have passed, we see most of widely deployed implementions have >> adopted various different QoS mechanisms >> >> such as diffserv Intserv, Traffic Engineering, providing QoS guarantee t= o >> improve delivery of media streaming, >> >> especially for time senestive or loss senstive application become a must= ; >> Therefore we see a lot of value of MDI defined in RFC4445 since it provi= de >> s a handy diagnostic tool for operators and service providers to measure >> the peformance of the network carrying streaming media and quickly ident= ify >> fault in the network. >> >> >> >> Today we also see many service providers begain to offer on demand >> streaming media service, many operator deployed CDN in the last mile to >> provide better SLA, or provide hybrid TV service, in addition more and m= ore >> real time application not limited to IPTV application, VOIP application >> have been developed,network monitoring and network troubleshooting began >> more and more complicated and costy. We hear a lot of operators get hurt= ed >> and want to have a common tool to help them to measure performance in th= is >> kind of networks and provider better troubleshooting. >> >> >> >> Another observation is today more and more implementations have adopted >> packet loss repair methods to improve media delivery. >> >> However MDI defined in RFC4445 doesn't take into acount of various >> different packet loss repair mechanims, in addition, RFC4445 is only >> designed for monitoring MPEG Transport Stream (TS) packets over UDP and >> fall short to addressing needs in hybrid senarios or on demand streaming >> media scenarios. >> >> >> >> In addition, we see at the time of RFC4445 publication, IESG doesn't >> recommend this standard, mostly becos RFC4445 doesn't define complete >> Metric and clarify the relationship with existing IETF work such as RFC3= 611 >> and RFC3933, I am wondering if it is a good idea to revise RFC4445 to >> address IESG concern today and in addition fill new needs in today's >> service deployment. >> >> Comments and suggestions? >> >> >> >> -Qin >> > > --001a114f1c7a5f2df2055481bc1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You wanna use MDI to measure media delivery over TCP?

On Mon, Jul 17, = 2017 at 7:18 PM, Qin Wu <bill.wu@huawei.com> wrote:
We=C2=A0have=C2=A0customers=C2=A0using=C2=A0MDI=C2=A0to=C2=A0addr= ess=C2=A0new=C2=A0needs,=C2=A0such=C2=A0as=C2=A0wifi=C2=A0performance= =C2=A0measurement=C2=A0MDI=C2=A0falls=C2=A0short=C2=A0when=C2=A0m= easuring=C2=A0delivery=C2=A0of=C2=A0streaming=C2=A0media=C2=A0over=C2= =A0tcp,=C2=A0that=C2=A0is=C2=A0why=C2=A0we=C2=A0think=C2=A0it=C2=A0should=C2=A0be=C2=A0extended.=C2=A0Yes,=C2=A0rtcp=C2=A0XR=C2=A0has= =C2=A0its=C2=A0value.=C2=A0But=C2=A0I=C2=A0think=C2=A0they=C2=A0could= =C2=A0be=C2=A0complimentary.

Sent=C2=A0from=C2=A0HUAWEI=C2=A0AnyOffice
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu;
=E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89;
=E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 o= r make RFC4445bis
=E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07


I am really curious about who is using MDI anymore. Can yo= u share data if you have it? RTCP XR is still extensively used and for non-= RTP, it is a mixed of several things.

-acbegen

On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.= com> wrote:

Hi, All:

We like to get a sense of this idea, more than 10 years ago, at the time= of RFC4445 writing,

The popularity of delivery of streaming media over packet swtiched netwo= rk has just began,

not all implementations support QoS methods to improve media delivery. M= any service

delivery systems may compose the network with QoS support or without QoS= support. This add difficulty on characterizing dynamic behavior of the net= work.

=C2=A0

10 years have passed, we see most of widely deployed implementions have = adopted various different QoS mechanisms

such as diffserv Intserv, Traffic Engineering, providing QoS guarantee t= o improve delivery of media streaming,

especially for time senestive or loss senstive application become a must= ; Therefore we see a lot of value of MDI defined in RFC4445 since it provid= e s a handy diagnostic tool for operators and service providers to measure = the peformance of the network carrying streaming media and quickly identify fault in the network.

=C2=A0

Today we also see many=C2=A0service providers=C2=A0begain to offer on de= mand streaming media service, many operator deployed CDN in the last mile t= o provide better SLA, or provide hybrid TV service, in addition more and mo= re real time application not limited to IPTV application, VOIP application have been developed,network monitoring and n= etwork troubleshooting began more and more complicated and costy.=C2=A0We h= ear a lot of operators get hurted and want to have a common tool to help th= em to measure performance in this kind of networks and provider better troubleshooting.

=C2=A0

Another observation is today more and more implementations have adopted = packet loss repair methods to improve media delivery.

However MDI defined in RFC4445 doesn't take into acount of various d= ifferent packet loss repair mechanims, in addition, RFC4445 is only designe= d for monitoring MPEG Transport Stream (TS) packets over UDP and fall short= to addressing needs in hybrid senarios or on demand streaming media scenarios.

=C2=A0

In addition, we see at the time of RFC4445 publication, IESG doesn't= recommend this standard, mostly becos RFC4445 doesn't define complete = Metric and clarify the relationship with existing IETF work such as RFC3611= and RFC3933, I am wondering if it is a good idea to revise RFC4445 to address IESG concern today and in addition = fill new needs in today's service deployment.

Comments and suggestions?

=C2=A0

-Qin



--001a114f1c7a5f2df2055481bc1d-- From nobody Mon Jul 17 04:45:24 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F051131B3F for ; Mon, 17 Jul 2017 04:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 MOtrQIVsqgwT for ; Mon, 17 Jul 2017 04:45:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE33131B33 for ; Mon, 17 Jul 2017 04:45:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR49674; Mon, 17 Jul 2017 11:45:18 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 12:45:17 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 17 Jul 2017 19:45:09 +0800 From: "Huangyihong (Rachel)" To: "Ali C. Begen" , Qin Wu CC: "tsv-area@ietf.org" Subject: =?utf-8?B?cmU6IOetlOWkjTogUHJvcG9zYWwgZm9yIHJldmlzaW5nIFJGQzQ0NDUgb3Ig?= =?utf-8?Q?make_RFC4445bis?= Thread-Topic: =?utf-8?B?562U5aSNOiBQcm9wb3NhbCBmb3IgcmV2aXNpbmcgUkZDNDQ0NSBvciBtYWtl?= =?utf-8?Q?_RFC4445bis?= Thread-Index: AdL+8f0+CUrlHRheTJm91RGDIsO2Gg== Date: Mon, 17 Jul 2017 11:45:08 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.170.93] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.596CA34E.0093, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cba16b03bce309639b1a2ee2a955aac0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:45:23 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpLA0KDQpUaGF04oCZcyBvbmUgcGFydCB0aGF0IE1ESSBjb3VsZCBub3QgZG8sIGFuZCB3 ZSBob3BlIHNvbWUgbmV3IG1ldHJpY3MgY291bGQgYmUgdXNlZCwgd2hpY2ggaXMgdGhlIGludGVu dGlvbiBvZiB0aGlzIHdvcmsuDQoNCkFzIGZvciB0aGUgUlRDUCBYUiBtZXRyaWNzLCBpdOKAmXMg bm90IHF1aXRlIHJlYWxpc3RpYyBpbiBtaWRkbGUgZGV2aWNlcyBsaWtlIHJvdXRlcnMsIHRvIGlt cGxlbWVudCB0aGVtLCBlLmcuLCBwb3N0LXJlcGFpciBtZXRyaWNzLCB3aGljaCB3aWxsIG5lZWQg dGhlIGRldmljZXMgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byBkZWNvZGUgYW5kIGFwcGx5IEZFQyBy ZXBhaXIgbWVjaGFuaXNtcy4gU28gdGhhdOKAmXMgd2h5IHdlIG5lZWQgc29tZSB3YXlzIGxpa2Ug TURJLCBlYXN5IHRvIGNhbGN1bGF0ZSBhbmQgYmUgaW1wbGVtZW50ZWQgaW4gdGhlIG5ldHdvcmsg d2l0aG91dCBoYXZpbmcgdG8gYmUgYSBSVFAgZW50aXR5IG9yIFRDUCBwcm94eS4NCg0KQlIsDQpS YWNoZWwNCg0K5Y+R5Lu25Lq6OiB0c3YtYXJlYSBbbWFpbHRvOnRzdi1hcmVhLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBBbGkgQy4gQmVnZW4NCuWPkemAgeaXtumXtDogMjAxN+W5tDfmnIgxN+aX pSAxOTozMQ0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuaKhOmAgTog dHN2LWFyZWFAaWV0Zi5vcmcNCuS4u+mimDogUmU6IOetlOWkjTogUHJvcG9zYWwgZm9yIHJldmlz aW5nIFJGQzQ0NDUgb3IgbWFrZSBSRkM0NDQ1YmlzDQoNCllvdSB3YW5uYSB1c2UgTURJIHRvIG1l YXN1cmUgbWVkaWEgZGVsaXZlcnkgb3ZlciBUQ1A/DQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0 IDc6MTggUE0sIFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdl aS5jb20+PiB3cm90ZToNCldlIGhhdmUgY3VzdG9tZXJzIHVzaW5nIE1ESSB0byBhZGRyZXNzIG5l dyBuZWVkcywgc3VjaCBhcyB3aWZpIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IE1ESSBmYWxscyBz aG9ydCB3aGVuIG1lYXN1cmluZyBkZWxpdmVyeSBvZiBzdHJlYW1pbmcgbWVkaWEgb3ZlciB0Y3As IHRoYXQgaXMgd2h5IHdlIHRoaW5rIGl0IHNob3VsZCBiZSBleHRlbmRlZC4gWWVzLCBydGNwIFhS IGhhcyBpdHMgdmFsdWUuIEJ1dCBJIHRoaW5rIHRoZXkgY291bGQgYmUgY29tcGxpbWVudGFyeS4N Cg0KU2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UNCuWPkeS7tuS6uu+8miBBbGkgQy4gQmVnZW4N CuaUtuS7tuS6uu+8miBRaW4gV3U7DQrmioTpgIHvvJogdHN2LWFyZWFAaWV0Zi5vcmc8bWFpbHRv OnRzdi1hcmVhQGlldGYub3JnPjsg6YOR6L6JOw0K5Li76aKY77yaIFJlOiBQcm9wb3NhbCBmb3Ig cmV2aXNpbmcgUkZDNDQ0NSBvciBtYWtlIFJGQzQ0NDViaXMNCuaXtumXtO+8miAyMDE3LTA3LTE3 IDEzOjAyOjA3DQoNCkkgYW0gcmVhbGx5IGN1cmlvdXMgYWJvdXQgd2hvIGlzIHVzaW5nIE1ESSBh bnltb3JlLiBDYW4geW91IHNoYXJlIGRhdGEgaWYgeW91IGhhdmUgaXQ/IFJUQ1AgWFIgaXMgc3Rp bGwgZXh0ZW5zaXZlbHkgdXNlZCBhbmQgZm9yIG5vbi1SVFAsIGl0IGlzIGEgbWl4ZWQgb2Ygc2V2 ZXJhbCB0aGluZ3MuDQoNCi1hY2JlZ2VuDQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDE6Mzkg UE0sIFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+ PiB3cm90ZToNCg0KSGksIEFsbDoNCg0KV2UgbGlrZSB0byBnZXQgYSBzZW5zZSBvZiB0aGlzIGlk ZWEsIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28sIGF0IHRoZSB0aW1lIG9mIFJGQzQ0NDUgd3JpdGlu ZywNCg0KVGhlIHBvcHVsYXJpdHkgb2YgZGVsaXZlcnkgb2Ygc3RyZWFtaW5nIG1lZGlhIG92ZXIg cGFja2V0IHN3dGljaGVkIG5ldHdvcmsgaGFzIGp1c3QgYmVnYW4sDQoNCm5vdCBhbGwgaW1wbGVt ZW50YXRpb25zIHN1cHBvcnQgUW9TIG1ldGhvZHMgdG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVyeS4g TWFueSBzZXJ2aWNlDQoNCmRlbGl2ZXJ5IHN5c3RlbXMgbWF5IGNvbXBvc2UgdGhlIG5ldHdvcmsg d2l0aCBRb1Mgc3VwcG9ydCBvciB3aXRob3V0IFFvUyBzdXBwb3J0LiBUaGlzIGFkZCBkaWZmaWN1 bHR5IG9uIGNoYXJhY3Rlcml6aW5nIGR5bmFtaWMgYmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsuDQoN Cg0KDQoxMCB5ZWFycyBoYXZlIHBhc3NlZCwgd2Ugc2VlIG1vc3Qgb2Ygd2lkZWx5IGRlcGxveWVk IGltcGxlbWVudGlvbnMgaGF2ZSBhZG9wdGVkIHZhcmlvdXMgZGlmZmVyZW50IFFvUyBtZWNoYW5p c21zDQoNCnN1Y2ggYXMgZGlmZnNlcnYgSW50c2VydiwgVHJhZmZpYyBFbmdpbmVlcmluZywgcHJv dmlkaW5nIFFvUyBndWFyYW50ZWUgdG8gaW1wcm92ZSBkZWxpdmVyeSBvZiBtZWRpYSBzdHJlYW1p bmcsDQoNCmVzcGVjaWFsbHkgZm9yIHRpbWUgc2VuZXN0aXZlIG9yIGxvc3Mgc2Vuc3RpdmUgYXBw bGljYXRpb24gYmVjb21lIGEgbXVzdDsgVGhlcmVmb3JlIHdlIHNlZSBhIGxvdCBvZiB2YWx1ZSBv ZiBNREkgZGVmaW5lZCBpbiBSRkM0NDQ1IHNpbmNlIGl0IHByb3ZpZGUgcyBhIGhhbmR5IGRpYWdu b3N0aWMgdG9vbCBmb3Igb3BlcmF0b3JzIGFuZCBzZXJ2aWNlIHByb3ZpZGVycyB0byBtZWFzdXJl IHRoZSBwZWZvcm1hbmNlIG9mIHRoZSBuZXR3b3JrIGNhcnJ5aW5nIHN0cmVhbWluZyBtZWRpYSBh bmQgcXVpY2tseSBpZGVudGlmeSBmYXVsdCBpbiB0aGUgbmV0d29yay4NCg0KDQoNClRvZGF5IHdl IGFsc28gc2VlIG1hbnkgc2VydmljZSBwcm92aWRlcnMgYmVnYWluIHRvIG9mZmVyIG9uIGRlbWFu ZCBzdHJlYW1pbmcgbWVkaWEgc2VydmljZSwgbWFueSBvcGVyYXRvciBkZXBsb3llZCBDRE4gaW4g dGhlIGxhc3QgbWlsZSB0byBwcm92aWRlIGJldHRlciBTTEEsIG9yIHByb3ZpZGUgaHlicmlkIFRW IHNlcnZpY2UsIGluIGFkZGl0aW9uIG1vcmUgYW5kIG1vcmUgcmVhbCB0aW1lIGFwcGxpY2F0aW9u IG5vdCBsaW1pdGVkIHRvIElQVFYgYXBwbGljYXRpb24sIFZPSVAgYXBwbGljYXRpb24gaGF2ZSBi ZWVuIGRldmVsb3BlZCxuZXR3b3JrIG1vbml0b3JpbmcgYW5kIG5ldHdvcmsgdHJvdWJsZXNob290 aW5nIGJlZ2FuIG1vcmUgYW5kIG1vcmUgY29tcGxpY2F0ZWQgYW5kIGNvc3R5LiBXZSBoZWFyIGEg bG90IG9mIG9wZXJhdG9ycyBnZXQgaHVydGVkIGFuZCB3YW50IHRvIGhhdmUgYSBjb21tb24gdG9v bCB0byBoZWxwIHRoZW0gdG8gbWVhc3VyZSBwZXJmb3JtYW5jZSBpbiB0aGlzIGtpbmQgb2YgbmV0 d29ya3MgYW5kIHByb3ZpZGVyIGJldHRlciB0cm91Ymxlc2hvb3RpbmcuDQoNCg0KDQpBbm90aGVy IG9ic2VydmF0aW9uIGlzIHRvZGF5IG1vcmUgYW5kIG1vcmUgaW1wbGVtZW50YXRpb25zIGhhdmUg YWRvcHRlZCBwYWNrZXQgbG9zcyByZXBhaXIgbWV0aG9kcyB0byBpbXByb3ZlIG1lZGlhIGRlbGl2 ZXJ5Lg0KDQpIb3dldmVyIE1ESSBkZWZpbmVkIGluIFJGQzQ0NDUgZG9lc24ndCB0YWtlIGludG8g YWNvdW50IG9mIHZhcmlvdXMgZGlmZmVyZW50IHBhY2tldCBsb3NzIHJlcGFpciBtZWNoYW5pbXMs IGluIGFkZGl0aW9uLCBSRkM0NDQ1IGlzIG9ubHkgZGVzaWduZWQgZm9yIG1vbml0b3JpbmcgTVBF RyBUcmFuc3BvcnQgU3RyZWFtIChUUykgcGFja2V0cyBvdmVyIFVEUCBhbmQgZmFsbCBzaG9ydCB0 byBhZGRyZXNzaW5nIG5lZWRzIGluIGh5YnJpZCBzZW5hcmlvcyBvciBvbiBkZW1hbmQgc3RyZWFt aW5nIG1lZGlhIHNjZW5hcmlvcy4NCg0KDQoNCkluIGFkZGl0aW9uLCB3ZSBzZWUgYXQgdGhlIHRp bWUgb2YgUkZDNDQ0NSBwdWJsaWNhdGlvbiwgSUVTRyBkb2Vzbid0IHJlY29tbWVuZCB0aGlzIHN0 YW5kYXJkLCBtb3N0bHkgYmVjb3MgUkZDNDQ0NSBkb2Vzbid0IGRlZmluZSBjb21wbGV0ZSBNZXRy aWMgYW5kIGNsYXJpZnkgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIGV4aXN0aW5nIElFVEYgd29yayBz dWNoIGFzIFJGQzM2MTEgYW5kIFJGQzM5MzMsIEkgYW0gd29uZGVyaW5nIGlmIGl0IGlzIGEgZ29v ZCBpZGVhIHRvIHJldmlzZSBSRkM0NDQ1IHRvIGFkZHJlc3MgSUVTRyBjb25jZXJuIHRvZGF5IGFu ZCBpbiBhZGRpdGlvbiBmaWxsIG5ldyBuZWVkcyBpbiB0b2RheSdzIHNlcnZpY2UgZGVwbG95bWVu dC4NCg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zPw0KDQoNCg0KLVFpbg0KDQoNCg== --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5tLTQwNzAwMjU0MDEy ODcxMjI1MjNob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6bV8tNDA3MDAyNTQwMTI4NzEyMjUyM2hv ZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQWxpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF04oCZcyBvbmUgcGFy dCB0aGF0IE1ESSBjb3VsZCBub3QgZG8sIGFuZCB3ZSBob3BlIHNvbWUgbmV3IG1ldHJpY3MgY291 bGQgYmUgdXNlZCwgd2hpY2ggaXMgdGhlIGludGVudGlvbiBvZiB0aGlzIHdvcmsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFzIGZvciB0aGUgUlRDUCBYUiBtZXRyaWNzLCBpdOKAmXMgbm90IHF1aXRlIHJlYWxpc3Rp YyBpbiBtaWRkbGUgZGV2aWNlcyBsaWtlIHJvdXRlcnMsIHRvIGltcGxlbWVudCB0aGVtLCBlLmcu LCBwb3N0LXJlcGFpciBtZXRyaWNzLCB3aGljaCB3aWxsIG5lZWQNCiB0aGUgZGV2aWNlcyB0byBo YXZlIHRoZSBhYmlsaXR5IHRvIGRlY29kZSBhbmQgYXBwbHkgRkVDIHJlcGFpciBtZWNoYW5pc21z LiBTbyB0aGF04oCZcyB3aHkgd2UgbmVlZCBzb21lIHdheXMgbGlrZSBNREksIGVhc3kgdG8gY2Fs Y3VsYXRlIGFuZCBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgbmV0d29yayB3aXRob3V0IGhhdmluZyB0 byBiZSBhIFJUUCBlbnRpdHkgb3IgVENQIHByb3h5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJhY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gdHN2LWFyZWEg W21haWx0bzp0c3YtYXJlYS1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+QWxpIEMuIEJlZ2VuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xNzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTk6MzE8YnI+DQo8L3NwYW4+PGI+ 5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmA gTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHRzdi1h cmVhQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0i RU4tVVMiPjogUHJvcG9zYWwgZm9yIHJldmlzaW5nIFJGQzQ0NDUgb3IgbWFrZSBSRkM0NDQ1Ymlz PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSB3YW5uYSB1c2UgTURJIHRvIG1l YXN1cmUgbWVkaWEgZGVsaXZlcnkgb3ZlciBUQ1A/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gTW9uLCBKdWwgMTcsIDIwMTcgYXQgNzoxOCBQTSwgUWluIFd1ICZs dDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+Ymls bC53dUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPldlJm5ic3A7aGF2ZSZuYnNwO2N1c3RvbWVycyZuYnNwO3VzaW5nJm5ic3A7TURJJm5i c3A7dG8mbmJzcDthZGRyZXNzJm5ic3A7bmV3Jm5ic3A7bmVlZHMsJm5ic3A7c3VjaCZuYnNwO2Fz Jm5ic3A7d2lmaSZuYnNwO3BlcmZvcm1hbmNlJm5ic3A7bWVhc3VyZW1lbnQmbmJzcDtNREkmbmJz cDtmYWxscyZuYnNwO3Nob3J0Jm5ic3A7d2hlbiZuYnNwO21lYXN1cmluZyZuYnNwO2RlbGl2ZXJ5 Jm5ic3A7b2YmbmJzcDtzdHJlYW1pbmcmbmJzcDttZWRpYSZuYnNwO292ZXImbmJzcDt0Y3AsJm5i c3A7dGhhdCZuYnNwO2lzJm5ic3A7d2h5Jm5ic3A7d2UmbmJzcDt0aGluayZuYnNwO2l0Jm5ic3A7 c2hvdWxkJm5ic3A7YmUmbmJzcDtleHRlbmRlZC4mbmJzcDtZZXMsJm5ic3A7cnRjcCZuYnNwO1hS Jm5ic3A7aGFzJm5ic3A7aXRzJm5ic3A7dmFsdWUuJm5ic3A7QnV0Jm5ic3A7SSZuYnNwO3RoaW5r Jm5ic3A7dGhleSZuYnNwO2NvdWxkJm5ic3A7YmUmbmJzcDtjb21wbGltZW50YXJ5Ljxicj4NCjxi cj4NClNlbnQmbmJzcDtmcm9tJm5ic3A7SFVBV0VJJm5ic3A7QW55T2ZmaWNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzo2LjBwdCAwY20gMGNtIDBjbSIgbmFtZT0iQW55T2Zm aWNlLUJhY2tncm91bmQtSW1hZ2UiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij7l j5Hku7bkurrvvJoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij5BbGkgQy4gQmVnZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5pS25Lu25Lq677yaDQo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UWluIFd1OyA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ 5oqE6YCB77yaDQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+PGEgaHJlZj0ibWFpbHRvOnRzdi1hcmVhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dHN2LWFyZWFAaWV0Zi5vcmc8L2E+Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij7pg5Hovok8c3BhbiBsYW5nPSJFTi1VUyI+OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPuS4u+mimO+8 mg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PlJlOiBQcm9wb3NhbCBmb3IgcmV2aXNpbmcgUkZDNDQ0NSBvciBtYWtlIFJGQzQ0NDViaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+5pe26Ze077yaDQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+MjAxNy0wNy0xNyAxMzowMjowNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdDtsaW5lLWhlaWdodDoxNS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SSBhbSByZWFsbHkgY3VyaW91cyBhYm91dCB3aG8gaXMgdXNpbmcgTURJIGFu eW1vcmUuIENhbiB5b3Ugc2hhcmUgZGF0YSBpZiB5b3UgaGF2ZSBpdD8gUlRDUCBYUiBpcyBzdGls bCBleHRlbnNpdmVseSB1c2VkIGFuZCBmb3Igbm9uLVJUUCwgaXQgaXMgYSBtaXhlZCBvZiBzZXZl cmFsIHRoaW5ncy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi1h Y2JlZ2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5P biBNb24sIEp1bCAxNywgMjAxNyBhdCAxOjM5IFBNLCBRaW4gV3UgJmx0OzxhIGhyZWY9Im1haWx0 bzpiaWxsLnd1QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5iaWxsLnd1QGh1YXdlaS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLCBB bGw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5XZSBsaWtlIHRvIGdldCBhIHNlbnNlIG9mIHRoaXMgaWRlYSwgbW9yZSB0 aGFuIDEwIHllYXJzIGFnbywgYXQgdGhlIHRpbWUgb2YgUkZDNDQ0NSB3cml0aW5nLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VGhlIHBvcHVsYXJpdHkgb2YgZGVsaXZlcnkgb2Ygc3RyZWFtaW5nIG1lZGlhIG92ZXIgcGFj a2V0IHN3dGljaGVkIG5ldHdvcmsgaGFzIGp1c3QgYmVnYW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ub3QgYWxsIGlt cGxlbWVudGF0aW9ucyBzdXBwb3J0IFFvUyBtZXRob2RzIHRvIGltcHJvdmUgbWVkaWEgZGVsaXZl cnkuIE1hbnkgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ZGVsaXZlcnkgc3lzdGVtcyBtYXkgY29tcG9zZSB0 aGUgbmV0d29yayB3aXRoIFFvUyBzdXBwb3J0IG9yIHdpdGhvdXQgUW9TIHN1cHBvcnQuIFRoaXMg YWRkIGRpZmZpY3VsdHkgb24gY2hhcmFjdGVyaXppbmcgZHluYW1pYyBiZWhhdmlvciBvZiB0aGUg bmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTAgeWVhcnMgaGF2ZSBwYXNzZWQs IHdlIHNlZSBtb3N0IG9mIHdpZGVseSBkZXBsb3llZCBpbXBsZW1lbnRpb25zIGhhdmUgYWRvcHRl ZCB2YXJpb3VzIGRpZmZlcmVudCBRb1MgbWVjaGFuaXNtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+c3VjaCBhcyBkaWZm c2VydiBJbnRzZXJ2LCBUcmFmZmljIEVuZ2luZWVyaW5nLCBwcm92aWRpbmcgUW9TIGd1YXJhbnRl ZSB0byBpbXByb3ZlIGRlbGl2ZXJ5IG9mIG1lZGlhIHN0cmVhbWluZyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmVzcGVj aWFsbHkgZm9yIHRpbWUgc2VuZXN0aXZlIG9yIGxvc3Mgc2Vuc3RpdmUgYXBwbGljYXRpb24gYmVj b21lIGEgbXVzdDsgVGhlcmVmb3JlIHdlIHNlZSBhIGxvdCBvZiB2YWx1ZSBvZiBNREkgZGVmaW5l ZCBpbiBSRkM0NDQ1IHNpbmNlIGl0IHByb3ZpZGUgcyBhIGhhbmR5IGRpYWdub3N0aWMNCiB0b29s IGZvciBvcGVyYXRvcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIHRvIG1lYXN1cmUgdGhlIHBlZm9y bWFuY2Ugb2YgdGhlIG5ldHdvcmsgY2Fycnlpbmcgc3RyZWFtaW5nIG1lZGlhIGFuZCBxdWlja2x5 IGlkZW50aWZ5IGZhdWx0IGluIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5Ub2RheSB3ZSBhbHNvIHNlZSBtYW55Jm5ic3A7c2VydmljZSBwcm92aWRlcnMmbmJzcDtiZWdh aW4gdG8gb2ZmZXIgb24gZGVtYW5kIHN0cmVhbWluZyBtZWRpYSBzZXJ2aWNlLCBtYW55IG9wZXJh dG9yIGRlcGxveWVkIENETiBpbiB0aGUgbGFzdCBtaWxlIHRvIHByb3ZpZGUgYmV0dGVyIFNMQSwg b3IgcHJvdmlkZQ0KIGh5YnJpZCBUViBzZXJ2aWNlLCBpbiBhZGRpdGlvbiBtb3JlIGFuZCBtb3Jl IHJlYWwgdGltZSBhcHBsaWNhdGlvbiBub3QgbGltaXRlZCB0byBJUFRWIGFwcGxpY2F0aW9uLCBW T0lQIGFwcGxpY2F0aW9uIGhhdmUgYmVlbiBkZXZlbG9wZWQsbmV0d29yayBtb25pdG9yaW5nIGFu ZCBuZXR3b3JrIHRyb3VibGVzaG9vdGluZyBiZWdhbiBtb3JlIGFuZCBtb3JlIGNvbXBsaWNhdGVk IGFuZCBjb3N0eS4mbmJzcDtXZSBoZWFyIGEgbG90IG9mIG9wZXJhdG9ycyBnZXQNCiBodXJ0ZWQg YW5kIHdhbnQgdG8gaGF2ZSBhIGNvbW1vbiB0b29sIHRvIGhlbHAgdGhlbSB0byBtZWFzdXJlIHBl cmZvcm1hbmNlIGluIHRoaXMga2luZCBvZiBuZXR3b3JrcyBhbmQgcHJvdmlkZXIgYmV0dGVyIHRy b3VibGVzaG9vdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QW5vdGhlciBvYnNlcnZh dGlvbiBpcyB0b2RheSBtb3JlIGFuZCBtb3JlIGltcGxlbWVudGF0aW9ucyBoYXZlIGFkb3B0ZWQg cGFja2V0IGxvc3MgcmVwYWlyIG1ldGhvZHMgdG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVyeS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkhvd2V2ZXIgTURJIGRlZmluZWQgaW4gUkZDNDQ0NSBkb2Vzbid0IHRha2UgaW50byBh Y291bnQgb2YgdmFyaW91cyBkaWZmZXJlbnQgcGFja2V0IGxvc3MgcmVwYWlyIG1lY2hhbmltcywg aW4gYWRkaXRpb24sIFJGQzQ0NDUgaXMgb25seSBkZXNpZ25lZCBmb3IgbW9uaXRvcmluZyBNUEVH IFRyYW5zcG9ydA0KIFN0cmVhbSAoVFMpIHBhY2tldHMgb3ZlciBVRFAgYW5kIGZhbGwgc2hvcnQg dG8gYWRkcmVzc2luZyBuZWVkcyBpbiBoeWJyaWQgc2VuYXJpb3Mgb3Igb24gZGVtYW5kIHN0cmVh bWluZyBtZWRpYSBzY2VuYXJpb3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluIGFkZGl0 aW9uLCB3ZSBzZWUgYXQgdGhlIHRpbWUgb2YgUkZDNDQ0NSBwdWJsaWNhdGlvbiwgSUVTRyBkb2Vz bid0IHJlY29tbWVuZCB0aGlzIHN0YW5kYXJkLCBtb3N0bHkgYmVjb3MgUkZDNDQ0NSBkb2Vzbid0 IGRlZmluZSBjb21wbGV0ZSBNZXRyaWMgYW5kIGNsYXJpZnkgdGhlIHJlbGF0aW9uc2hpcA0KIHdp dGggZXhpc3RpbmcgSUVURiB3b3JrIHN1Y2ggYXMgUkZDMzYxMSBhbmQgUkZDMzkzMywgSSBhbSB3 b25kZXJpbmcgaWYgaXQgaXMgYSBnb29kIGlkZWEgdG8gcmV2aXNlIFJGQzQ0NDUgdG8gYWRkcmVz cyBJRVNHIGNvbmNlcm4gdG9kYXkgYW5kIGluIGFkZGl0aW9uIGZpbGwgbmV3IG5lZWRzIGluIHRv ZGF5J3Mgc2VydmljZSBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67nkgeml513mbxchi_-- From nobody Mon Jul 17 05:16:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3DB131B48 for ; Mon, 17 Jul 2017 05:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 H842lG2tzV3i for ; Mon, 17 Jul 2017 05:16:42 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 F1A75131B14 for ; Mon, 17 Jul 2017 05:16:41 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id j80so35131082ybg.2 for ; Mon, 17 Jul 2017 05:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8mYngY3dIfXxXmuIqHnNd0uy3FvPg9dJA/Nx0XZeXqQ=; b=XIAHNGGKTi+YxMjKHiKPm/xBU29rYLfFiQ6pWX/AHQteOZe9qMGF4YxvIuw0AJg/G7 G4L/MbxwZ4+2xBRQd/5Bxv75NOGd8oZpju7z2P8JpysITcQ3F2odAd/Jlk3NUlzyVwLg 0qfyxSHIceR++L9UvZA/wzNJgvR0PAfexwcYITzrloJp2llYpk8kRJPCFdrIJTZ+H0Gk VUa6J4DNTLVUGChvy2xvaF1Y2wDwdoICtjSqjfdAQgnBNJ+7NzYXH9dag08nUTjn8EBH RugvY6eKR/9y/jWjO/Go+dFMy7sGf0m6lHiUhHQVCFTx47WSWg8WtAfTj4iYTXylZ/8X wirA== 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=8mYngY3dIfXxXmuIqHnNd0uy3FvPg9dJA/Nx0XZeXqQ=; b=SNTqELCzDCWwh98jdZ3/2zjOvdMkHd+Gq8hvVoPZj/O291bb4FcRH3Cqf07qtBduVM +s8If2Nh6aFmUdggtm86Ijz7XQsvGh58XaN8J2ARJwtmNy3zvVtBpm/KbT8bafPk47l3 I5yM6tV7K3qiIwoPLbfgWcBpVtgbUrt/xvlI8aQJ9VX2wLSkb5xpIKYZ/NURG43drXJY SJKwBUoMKGbJdx46H3DTstlZbA9yz+AAY704u+T+urPXzJgDl2Stili3gBCPlnHIOS7Y GmeDM0FXRBuYttmOmRcrNIl01XvmfNK5egvBQnhWCKKSDYXOnYLjWtWn/fu9ffPFyDgJ jG2g== X-Gm-Message-State: AIVw111m+EGF6BNkzE8Po5JETF6KkdkVpYw6eF5+dCOzuq+NNdlF+uZh PTFYA0+2dbhpzbUGnN409vS3AHN/pRyU X-Received: by 10.37.32.193 with SMTP id g184mr16769072ybg.4.1500293801134; Mon, 17 Jul 2017 05:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.29.15 with HTTP; Mon, 17 Jul 2017 05:16:40 -0700 (PDT) In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> From: "Ali C. Begen" Date: Mon, 17 Jul 2017 20:16:40 +0800 Message-ID: Subject: =?UTF-8?Q?Re=3A_=E7=AD=94=E5=A4=8D=3A_Proposal_for_revising_RFC4445_or_make_RF?= =?UTF-8?Q?C4445bis?= To: "Huangyihong (Rachel)" Cc: Qin Wu , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary="001a1143e0d81373780554825f8d" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:16:44 -0000 --001a1143e0d81373780554825f8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, I believe you wanna come up with some metrics for streaming video over http and want to extend MDI for that. Well, MDI was not designed for that at all, so extending it in that direction is not a good idea. Further, there is already tons of work other organizations have done to collect metrics for streaming over HTTP. Just look at what others did already, mpeg, dash-if, SVA and now almost all the existing work is being collected and becoming a single common spec out of CTA. I honestly don't think this WG should work on this given the amount of existing and ongoing work. -acbegen On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) < rachel.huang@huawei.com> wrote: > Hi Ali, > > > > That=E2=80=99s one part that MDI could not do, and we hope some new metri= cs could > be used, which is the intention of this work. > > > > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middle de= vices > like routers, to implement them, e.g., post-repair metrics, which will ne= ed > the devices to have the ability to decode and apply FEC repair mechanisms= . > So that=E2=80=99s why we need some ways like MDI, easy to calculate and b= e > implemented in the network without having to be a RTP entity or TCP proxy= . > > > > BR, > > Rachel > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* tsv-area [mailto:tsv-area-bounces@ietf.org= ] *=E4=BB=A3=E8=A1=A8 *Ali C. Begen > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2017=E5=B9=B47=E6=9C=8817=E6=97= =A5 19:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Qin Wu > *=E6=8A=84=E9=80=81:* tsv-area@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: =E7=AD=94=E5=A4=8D: Proposal for revising RFC44= 45 or make RFC4445bis > > > > You wanna use MDI to measure media delivery over TCP? > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > > We have customers using MDI to address new needs, such as > wifi performance measurement MDI falls short when measuring delivery of > streaming media over tcp, that is why we think it > should be extended. Yes, rtcp XR has its value. But I think > they could be complimentary. > > Sent from HUAWEI AnyOffice > > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Ali C. Begen > > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *Qin Wu; > > *=E6=8A=84=E9=80=81=EF=BC=9A *tsv-area@ietf.org; =E9=83=91=E8=BE=89; > > *=E4=B8=BB=E9=A2=98=EF=BC=9A *Re: Proposal for revising RFC4445 or make R= FC4445bis > > *=E6=97=B6=E9=97=B4=EF=BC=9A *2017-07-17 13:02:07 > > > > I am really curious about who is using MDI anymore. Can you share data if > you have it? RTCP XR is still extensively used and for non-RTP, it is a > mixed of several things. > > > > -acbegen > > > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > > Hi, All: > > We like to get a sense of this idea, more than 10 years ago, at the time > of RFC4445 writing, > > The popularity of delivery of streaming media over packet swtiched networ= k > has just began, > > not all implementations support QoS methods to improve media delivery. > Many service > > delivery systems may compose the network with QoS support or without QoS > support. This add difficulty on characterizing dynamic behavior of the > network. > > > > 10 years have passed, we see most of widely deployed implementions have > adopted various different QoS mechanisms > > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee to > improve delivery of media streaming, > > especially for time senestive or loss senstive application become a must; > Therefore we see a lot of value of MDI defined in RFC4445 since it provid= e > s a handy diagnostic tool for operators and service providers to measure > the peformance of the network carrying streaming media and quickly identi= fy > fault in the network. > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and mo= re > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurte= d > and want to have a common tool to help them to measure performance in thi= s > kind of networks and provider better troubleshooting. > > > > Another observation is today more and more implementations have adopted > packet loss repair methods to improve media delivery. > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC36= 11 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > Comments and suggestions? > > > > -Qin > > > > > --001a1143e0d81373780554825f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I believe you wanna come up with some metrics for st= reaming video over http and want to extend MDI for that. Well, MDI was not = designed for that at all, so extending it in that direction is not a good i= dea. Further, there is already tons of work other organizations have done t= o collect metrics for streaming over HTTP. Just look at what others did alr= eady, mpeg, dash-if, SVA and now almost all the existing work is being coll= ected and becoming a single common spec out of CTA. I honestly don't th= ink this WG should work on this given the amount of existing and ongoing wo= rk.

-acbegen

<= div class=3D"gmail_quote">On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rac= hel) <rachel.huang@huawei.com> wrote:

Hi Ali,<= /span>

=C2=A0

That=E2=80=99s one par= t that MDI could not do, and we hope some new metrics could be used, which = is the intention of this work.

=C2=A0

As for the RTCP XR met= rics, it=E2=80=99s not quite realistic in middle devices like routers, to i= mplement them, e.g., post-repair metrics, which will need the devices to have the ability to decode and apply FEC repair mechanisms.= So that=E2=80=99s why we need some ways like MDI, easy to calculate and be= implemented in the network without having to be a RTP entity or TCP proxy.=

=C2=A0

BR,

Rachel

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA= :tsv-area-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Ali C. Begen
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017= =E5=B9=B47=E6=9C= =8817=E6=97=A5 19:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
=E6=8A=84=E9=80=81: tsv-area@iet= f.org
=E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for re= vising RFC4445 or make RFC4445bis

=C2=A0

You wanna use MDI to measure me= dia delivery over TCP?

=C2=A0

On Mon, Jul 17, 2017 at 7:18 PM= , Qin Wu <bill.w= u@huawei.com> wrote:

We=C2=A0have=C2=A0customers=C2= =A0using=C2=A0MDI=C2=A0to=C2=A0address=C2=A0new=C2=A0needs,=C2=A0such= =C2=A0as=C2=A0wifi=C2=A0performance=C2=A0measurement=C2=A0MDI=C2= =A0falls=C2=A0short=C2=A0when=C2=A0measuring=C2=A0delivery=C2=A0of=C2= =A0streaming=C2=A0media=C2=A0over=C2=A0tcp,=C2=A0that=C2=A0is=C2= =A0why=C2=A0we=C2=A0think=C2=A0it=C2=A0should=C2=A0be=C2=A0extended.= =C2=A0Yes,=C2=A0rtcp=C2=A0XR=C2=A0has=C2=A0its=C2=A0value.=C2=A0But=C2= =A0I=C2=A0think=C2=A0they=C2=A0could=C2=A0be=C2=A0complimentary.

Sent=C2=A0from=C2=A0HUAWEI=C2=A0AnyOffice

=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen<= /u>

=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; <= u>

=E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89;

=E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for= revising RFC4445 or make RFC4445bis

=E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02= :07

=C2=A0

I am really curious about who i= s using MDI anymore. Can you share data if you have it? RTCP XR is still ex= tensively used and for non-RTP, it is a mixed of several things.

=C2=A0

-acbegen

=C2=A0

On Mon, Jul 17, 2017 at 1:39 PM= , Qin Wu <bill.w= u@huawei.com> wrote:

Hi, All:

We like to get a sense of this idea, more tha= n 10 years ago, at the time of RFC4445 writing,

The popularity of delivery of streaming media= over packet swtiched network has just began,

not all implementations support QoS methods t= o improve media delivery. Many service

delivery systems may compose the network with= QoS support or without QoS support. This add difficulty on characterizing = dynamic behavior of the network.

=C2=A0

10 years have passed, we see most of widely d= eployed implementions have adopted various different QoS mechanisms<= u>

such as diffserv Intserv, Traffic Engineering= , providing QoS guarantee to improve delivery of media streaming,=

especially for time senestive or loss senstiv= e application become a must; Therefore we see a lot of value of MDI defined= in RFC4445 since it provide s a handy diagnostic tool for operators and service providers to measure the peformance of the = network carrying streaming media and quickly identify fault in the network.=

=C2=A0

Today we also see many=C2=A0service providers= =C2=A0begain to offer on demand streaming media service, many operator depl= oyed CDN in the last mile to provide better SLA, or provide hybrid TV service, in addition more and more real time application not lim= ited to IPTV application, VOIP application have been developed,network moni= toring and network troubleshooting began more and more complicated and cost= y.=C2=A0We hear a lot of operators get hurted and want to have a common tool to help them to measure performance = in this kind of networks and provider better troubleshooting.=

=C2=A0

Another observation is today more and more im= plementations have adopted packet loss repair methods to improve media deli= very.

However MDI defined in RFC4445 doesn't ta= ke into acount of various different packet loss repair mechanims, in additi= on, RFC4445 is only designed for monitoring MPEG Transport Stream (TS) packets over UDP and fall short to addressing needs in hybrid = senarios or on demand streaming media scenarios.

=C2=A0

In addition, we see at the time of RFC4445 pu= blication, IESG doesn't recommend this standard, mostly becos RFC4445 d= oesn't define complete Metric and clarify the relationship with existing IETF work such as RFC3611 and RFC3933, I am wondering if it = is a good idea to revise RFC4445 to address IESG concern today and in addit= ion fill new needs in today's service deployment.<= /p>

Comments and suggestions?

=C2=A0

-Qin

=C2=A0

=C2=A0


--001a1143e0d81373780554825f8d-- From nobody Mon Jul 17 05:27:06 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8A131B50 for ; Mon, 17 Jul 2017 05:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 AHsQRd6CY_Wd for ; Mon, 17 Jul 2017 05:27:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED226131B35 for ; Mon, 17 Jul 2017 05:27:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRJ60665; Mon, 17 Jul 2017 12:26:59 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 13:26:56 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 17 Jul 2017 20:26:44 +0800 From: "Huangyihong (Rachel)" To: "Ali C. Begen" CC: Qin Wu , "tsv-area@ietf.org" Subject: =?utf-8?B?UmU6IOetlOWkjTogUHJvcG9zYWwgZm9yIHJldmlzaW5nIFJGQzQ0NDUgb3Ig?= =?utf-8?Q?make_RFC4445bis?= Thread-Topic: =?utf-8?B?562U5aSNOiBQcm9wb3NhbCBmb3IgcmV2aXNpbmcgUkZDNDQ0NSBvciBtYWtl?= =?utf-8?Q?_RFC4445bis?= Thread-Index: AdL+97x85wLwKQlVQ5ua2OUGISz/aw== Date: Mon, 17 Jul 2017 12:26:43 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDF0C@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.170.93] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDF0Cnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.596CAD14.0094, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8557f3809b2b31298a2ab2264f4d62c2 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:27:05 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDF0Cnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk91ciB3b3JrIG1haW5seSBmb2N1c2VzIG9uIFRDUCBiYXNlZCBtZXRyaWNzIGZvciBz dHJlYW1zLCBub3QgZ29pbmcgdG8gY29sbGVjdCBtZXRyaWNzIGluIGFwcGxpY2F0aW9uIGxheWVy IChIVFRQIG9yIGFib3ZlKS4gQnV0IHllcywgd2XigJlsbCBkbyBzb21lIGdhcCBhbmFseXNpcyB0 byBtYWtlIHN1cmUgd2XigJlyZSBub3QgZG9pbmcgc29tZXRoaW5nIHRoYXQgYWxyZWFkeSBleGl0 Lg0KDQpCUiwNClJhY2hlbA0KDQrlj5Hku7bkuro6IEFsaSBDLiBCZWdlbiBbbWFpbHRvOmFsaS5i ZWdlbkBuZXR3b3JrZWQubWVkaWFdDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ35pyIMTfml6UgMjA6 MTcNCuaUtuS7tuS6ujogSHVhbmd5aWhvbmcgKFJhY2hlbCkgPHJhY2hlbC5odWFuZ0BodWF3ZWku Y29tPg0K5oqE6YCBOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IHRzdi1hcmVhQGlldGYu b3JnDQrkuLvpopg6IFJlOiDnrZTlpI06IFByb3Bvc2FsIGZvciByZXZpc2luZyBSRkM0NDQ1IG9y IG1ha2UgUkZDNDQ0NWJpcw0KDQpXZWxsLCBJIGJlbGlldmUgeW91IHdhbm5hIGNvbWUgdXAgd2l0 aCBzb21lIG1ldHJpY3MgZm9yIHN0cmVhbWluZyB2aWRlbyBvdmVyIGh0dHAgYW5kIHdhbnQgdG8g ZXh0ZW5kIE1ESSBmb3IgdGhhdC4gV2VsbCwgTURJIHdhcyBub3QgZGVzaWduZWQgZm9yIHRoYXQg YXQgYWxsLCBzbyBleHRlbmRpbmcgaXQgaW4gdGhhdCBkaXJlY3Rpb24gaXMgbm90IGEgZ29vZCBp ZGVhLiBGdXJ0aGVyLCB0aGVyZSBpcyBhbHJlYWR5IHRvbnMgb2Ygd29yayBvdGhlciBvcmdhbml6 YXRpb25zIGhhdmUgZG9uZSB0byBjb2xsZWN0IG1ldHJpY3MgZm9yIHN0cmVhbWluZyBvdmVyIEhU VFAuIEp1c3QgbG9vayBhdCB3aGF0IG90aGVycyBkaWQgYWxyZWFkeSwgbXBlZywgZGFzaC1pZiwg U1ZBIGFuZCBub3cgYWxtb3N0IGFsbCB0aGUgZXhpc3Rpbmcgd29yayBpcyBiZWluZyBjb2xsZWN0 ZWQgYW5kIGJlY29taW5nIGEgc2luZ2xlIGNvbW1vbiBzcGVjIG91dCBvZiBDVEEuIEkgaG9uZXN0 bHkgZG9uJ3QgdGhpbmsgdGhpcyBXRyBzaG91bGQgd29yayBvbiB0aGlzIGdpdmVuIHRoZSBhbW91 bnQgb2YgZXhpc3RpbmcgYW5kIG9uZ29pbmcgd29yay4NCg0KLWFjYmVnZW4NCg0KT24gTW9uLCBK dWwgMTcsIDIwMTcgYXQgNzo0NSBQTSwgSHVhbmd5aWhvbmcgKFJhY2hlbCkgPHJhY2hlbC5odWFu Z0BodWF3ZWkuY29tPG1haWx0bzpyYWNoZWwuaHVhbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkg QWxpLA0KDQpUaGF04oCZcyBvbmUgcGFydCB0aGF0IE1ESSBjb3VsZCBub3QgZG8sIGFuZCB3ZSBo b3BlIHNvbWUgbmV3IG1ldHJpY3MgY291bGQgYmUgdXNlZCwgd2hpY2ggaXMgdGhlIGludGVudGlv biBvZiB0aGlzIHdvcmsuDQoNCkFzIGZvciB0aGUgUlRDUCBYUiBtZXRyaWNzLCBpdOKAmXMgbm90 IHF1aXRlIHJlYWxpc3RpYyBpbiBtaWRkbGUgZGV2aWNlcyBsaWtlIHJvdXRlcnMsIHRvIGltcGxl bWVudCB0aGVtLCBlLmcuLCBwb3N0LXJlcGFpciBtZXRyaWNzLCB3aGljaCB3aWxsIG5lZWQgdGhl IGRldmljZXMgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byBkZWNvZGUgYW5kIGFwcGx5IEZFQyByZXBh aXIgbWVjaGFuaXNtcy4gU28gdGhhdOKAmXMgd2h5IHdlIG5lZWQgc29tZSB3YXlzIGxpa2UgTURJ LCBlYXN5IHRvIGNhbGN1bGF0ZSBhbmQgYmUgaW1wbGVtZW50ZWQgaW4gdGhlIG5ldHdvcmsgd2l0 aG91dCBoYXZpbmcgdG8gYmUgYSBSVFAgZW50aXR5IG9yIFRDUCBwcm94eS4NCg0KQlIsDQpSYWNo ZWwNCg0K5Y+R5Lu25Lq6OiB0c3YtYXJlYSBbbWFpbHRvOnRzdi1hcmVhLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnRzdi1hcmVhLWJvdW5jZXNAaWV0Zi5vcmc+XSDku6PooaggQWxpIEMuIEJlZ2Vu DQrlj5HpgIHml7bpl7Q6IDIwMTflubQ35pyIMTfml6UgMTk6MzENCuaUtuS7tuS6ujogUWluIFd1 IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+DQrmioTpgIE6 IHRzdi1hcmVhQGlldGYub3JnPG1haWx0bzp0c3YtYXJlYUBpZXRmLm9yZz4NCuS4u+mimDogUmU6 IOetlOWkjTogUHJvcG9zYWwgZm9yIHJldmlzaW5nIFJGQzQ0NDUgb3IgbWFrZSBSRkM0NDQ1Ymlz DQoNCllvdSB3YW5uYSB1c2UgTURJIHRvIG1lYXN1cmUgbWVkaWEgZGVsaXZlcnkgb3ZlciBUQ1A/ DQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDc6MTggUE0sIFFpbiBXdSA8YmlsbC53dUBodWF3 ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PiB3cm90ZToNCldlIGhhdmUgY3VzdG9t ZXJzIHVzaW5nIE1ESSB0byBhZGRyZXNzIG5ldyBuZWVkcywgc3VjaCBhcyB3aWZpIHBlcmZvcm1h bmNlIG1lYXN1cmVtZW50IE1ESSBmYWxscyBzaG9ydCB3aGVuIG1lYXN1cmluZyBkZWxpdmVyeSBv ZiBzdHJlYW1pbmcgbWVkaWEgb3ZlciB0Y3AsIHRoYXQgaXMgd2h5IHdlIHRoaW5rIGl0IHNob3Vs ZCBiZSBleHRlbmRlZC4gWWVzLCBydGNwIFhSIGhhcyBpdHMgdmFsdWUuIEJ1dCBJIHRoaW5rIHRo ZXkgY291bGQgYmUgY29tcGxpbWVudGFyeS4NCg0KU2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UN CuWPkeS7tuS6uu+8miBBbGkgQy4gQmVnZW4NCuaUtuS7tuS6uu+8miBRaW4gV3U7DQrmioTpgIHv vJogdHN2LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOnRzdi1hcmVhQGlldGYub3JnPjsg6YOR6L6JOw0K 5Li76aKY77yaIFJlOiBQcm9wb3NhbCBmb3IgcmV2aXNpbmcgUkZDNDQ0NSBvciBtYWtlIFJGQzQ0 NDViaXMNCuaXtumXtO+8miAyMDE3LTA3LTE3IDEzOjAyOjA3DQoNCkkgYW0gcmVhbGx5IGN1cmlv dXMgYWJvdXQgd2hvIGlzIHVzaW5nIE1ESSBhbnltb3JlLiBDYW4geW91IHNoYXJlIGRhdGEgaWYg eW91IGhhdmUgaXQ/IFJUQ1AgWFIgaXMgc3RpbGwgZXh0ZW5zaXZlbHkgdXNlZCBhbmQgZm9yIG5v bi1SVFAsIGl0IGlzIGEgbWl4ZWQgb2Ygc2V2ZXJhbCB0aGluZ3MuDQoNCi1hY2JlZ2VuDQoNCk9u IE1vbiwgSnVsIDE3LCAyMDE3IGF0IDE6MzkgUE0sIFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29t PG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGksIEFsbDoNCg0KV2UgbGlr ZSB0byBnZXQgYSBzZW5zZSBvZiB0aGlzIGlkZWEsIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28sIGF0 IHRoZSB0aW1lIG9mIFJGQzQ0NDUgd3JpdGluZywNCg0KVGhlIHBvcHVsYXJpdHkgb2YgZGVsaXZl cnkgb2Ygc3RyZWFtaW5nIG1lZGlhIG92ZXIgcGFja2V0IHN3dGljaGVkIG5ldHdvcmsgaGFzIGp1 c3QgYmVnYW4sDQoNCm5vdCBhbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgUW9TIG1ldGhvZHMg dG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVyeS4gTWFueSBzZXJ2aWNlDQoNCmRlbGl2ZXJ5IHN5c3Rl bXMgbWF5IGNvbXBvc2UgdGhlIG5ldHdvcmsgd2l0aCBRb1Mgc3VwcG9ydCBvciB3aXRob3V0IFFv UyBzdXBwb3J0LiBUaGlzIGFkZCBkaWZmaWN1bHR5IG9uIGNoYXJhY3Rlcml6aW5nIGR5bmFtaWMg YmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsuDQoNCg0KDQoxMCB5ZWFycyBoYXZlIHBhc3NlZCwgd2Ug c2VlIG1vc3Qgb2Ygd2lkZWx5IGRlcGxveWVkIGltcGxlbWVudGlvbnMgaGF2ZSBhZG9wdGVkIHZh cmlvdXMgZGlmZmVyZW50IFFvUyBtZWNoYW5pc21zDQoNCnN1Y2ggYXMgZGlmZnNlcnYgSW50c2Vy diwgVHJhZmZpYyBFbmdpbmVlcmluZywgcHJvdmlkaW5nIFFvUyBndWFyYW50ZWUgdG8gaW1wcm92 ZSBkZWxpdmVyeSBvZiBtZWRpYSBzdHJlYW1pbmcsDQoNCmVzcGVjaWFsbHkgZm9yIHRpbWUgc2Vu ZXN0aXZlIG9yIGxvc3Mgc2Vuc3RpdmUgYXBwbGljYXRpb24gYmVjb21lIGEgbXVzdDsgVGhlcmVm b3JlIHdlIHNlZSBhIGxvdCBvZiB2YWx1ZSBvZiBNREkgZGVmaW5lZCBpbiBSRkM0NDQ1IHNpbmNl IGl0IHByb3ZpZGUgcyBhIGhhbmR5IGRpYWdub3N0aWMgdG9vbCBmb3Igb3BlcmF0b3JzIGFuZCBz ZXJ2aWNlIHByb3ZpZGVycyB0byBtZWFzdXJlIHRoZSBwZWZvcm1hbmNlIG9mIHRoZSBuZXR3b3Jr IGNhcnJ5aW5nIHN0cmVhbWluZyBtZWRpYSBhbmQgcXVpY2tseSBpZGVudGlmeSBmYXVsdCBpbiB0 aGUgbmV0d29yay4NCg0KDQoNClRvZGF5IHdlIGFsc28gc2VlIG1hbnkgc2VydmljZSBwcm92aWRl cnMgYmVnYWluIHRvIG9mZmVyIG9uIGRlbWFuZCBzdHJlYW1pbmcgbWVkaWEgc2VydmljZSwgbWFu eSBvcGVyYXRvciBkZXBsb3llZCBDRE4gaW4gdGhlIGxhc3QgbWlsZSB0byBwcm92aWRlIGJldHRl ciBTTEEsIG9yIHByb3ZpZGUgaHlicmlkIFRWIHNlcnZpY2UsIGluIGFkZGl0aW9uIG1vcmUgYW5k IG1vcmUgcmVhbCB0aW1lIGFwcGxpY2F0aW9uIG5vdCBsaW1pdGVkIHRvIElQVFYgYXBwbGljYXRp b24sIFZPSVAgYXBwbGljYXRpb24gaGF2ZSBiZWVuIGRldmVsb3BlZCxuZXR3b3JrIG1vbml0b3Jp bmcgYW5kIG5ldHdvcmsgdHJvdWJsZXNob290aW5nIGJlZ2FuIG1vcmUgYW5kIG1vcmUgY29tcGxp Y2F0ZWQgYW5kIGNvc3R5LiBXZSBoZWFyIGEgbG90IG9mIG9wZXJhdG9ycyBnZXQgaHVydGVkIGFu ZCB3YW50IHRvIGhhdmUgYSBjb21tb24gdG9vbCB0byBoZWxwIHRoZW0gdG8gbWVhc3VyZSBwZXJm b3JtYW5jZSBpbiB0aGlzIGtpbmQgb2YgbmV0d29ya3MgYW5kIHByb3ZpZGVyIGJldHRlciB0cm91 Ymxlc2hvb3RpbmcuDQoNCg0KDQpBbm90aGVyIG9ic2VydmF0aW9uIGlzIHRvZGF5IG1vcmUgYW5k IG1vcmUgaW1wbGVtZW50YXRpb25zIGhhdmUgYWRvcHRlZCBwYWNrZXQgbG9zcyByZXBhaXIgbWV0 aG9kcyB0byBpbXByb3ZlIG1lZGlhIGRlbGl2ZXJ5Lg0KDQpIb3dldmVyIE1ESSBkZWZpbmVkIGlu IFJGQzQ0NDUgZG9lc24ndCB0YWtlIGludG8gYWNvdW50IG9mIHZhcmlvdXMgZGlmZmVyZW50IHBh Y2tldCBsb3NzIHJlcGFpciBtZWNoYW5pbXMsIGluIGFkZGl0aW9uLCBSRkM0NDQ1IGlzIG9ubHkg ZGVzaWduZWQgZm9yIG1vbml0b3JpbmcgTVBFRyBUcmFuc3BvcnQgU3RyZWFtIChUUykgcGFja2V0 cyBvdmVyIFVEUCBhbmQgZmFsbCBzaG9ydCB0byBhZGRyZXNzaW5nIG5lZWRzIGluIGh5YnJpZCBz ZW5hcmlvcyBvciBvbiBkZW1hbmQgc3RyZWFtaW5nIG1lZGlhIHNjZW5hcmlvcy4NCg0KDQoNCklu IGFkZGl0aW9uLCB3ZSBzZWUgYXQgdGhlIHRpbWUgb2YgUkZDNDQ0NSBwdWJsaWNhdGlvbiwgSUVT RyBkb2Vzbid0IHJlY29tbWVuZCB0aGlzIHN0YW5kYXJkLCBtb3N0bHkgYmVjb3MgUkZDNDQ0NSBk b2Vzbid0IGRlZmluZSBjb21wbGV0ZSBNZXRyaWMgYW5kIGNsYXJpZnkgdGhlIHJlbGF0aW9uc2hp cCB3aXRoIGV4aXN0aW5nIElFVEYgd29yayBzdWNoIGFzIFJGQzM2MTEgYW5kIFJGQzM5MzMsIEkg YW0gd29uZGVyaW5nIGlmIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHJldmlzZSBSRkM0NDQ1IHRvIGFk ZHJlc3MgSUVTRyBjb25jZXJuIHRvZGF5IGFuZCBpbiBhZGRpdGlvbiBmaWxsIG5ldyBuZWVkcyBp biB0b2RheSdzIHNlcnZpY2UgZGVwbG95bWVudC4NCg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z Pw0KDQoNCg0KLVFpbg0KDQoNCg0K --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDF0Cnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/p m4Xpu5E7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEDlvq7ova/pm4Xpu5EiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PdXIgd29yayBtYWlubHkgZm9jdXNlcyBvbiBUQ1AgYmFz ZWQgbWV0cmljcyBmb3Igc3RyZWFtcywgbm90IGdvaW5nIHRvIGNvbGxlY3QgbWV0cmljcyBpbiBh cHBsaWNhdGlvbiBsYXllciAoSFRUUCBvciBhYm92ZSkuIEJ1dCB5ZXMsIHdl4oCZbGwgZG8gc29t ZQ0KIGdhcCBhbmFseXNpcyB0byBtYWtlIHN1cmUgd2XigJlyZSBub3QgZG9pbmcgc29tZXRoaW5n IHRoYXQgYWxyZWFkeSBleGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlJhY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gQWxpIEMuIEJlZ2VuIFttYWlsdG86 YWxpLmJlZ2VuQG5ldHdvcmtlZC5tZWRpYV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDE3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7mnIg8c3BhbiBsYW5n PSJFTi1VUyI+MTc8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIwOjE3PGJyPg0KPC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IEh1YW5neWlob25nIChSYWNoZWwpICZsdDtyYWNoZWwuaHVhbmdAaHVhd2VpLmNv bSZndDs8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7OyB0 c3YtYXJlYUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogPC9zcGFuPuetlOWkjTxzcGFuIGxh bmc9IkVOLVVTIj46IFByb3Bvc2FsIGZvciByZXZpc2luZyBSRkM0NDQ1IG9yIG1ha2UgUkZDNDQ0 NWJpczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZWxsLCBJIGJlbGlldmUgeW91 IHdhbm5hIGNvbWUgdXAgd2l0aCBzb21lIG1ldHJpY3MgZm9yIHN0cmVhbWluZyB2aWRlbyBvdmVy IGh0dHAgYW5kIHdhbnQgdG8gZXh0ZW5kIE1ESSBmb3IgdGhhdC4gV2VsbCwgTURJIHdhcyBub3Qg ZGVzaWduZWQgZm9yIHRoYXQgYXQgYWxsLCBzbyBleHRlbmRpbmcgaXQgaW4gdGhhdCBkaXJlY3Rp b24gaXMgbm90IGEgZ29vZCBpZGVhLiBGdXJ0aGVyLA0KIHRoZXJlIGlzIGFscmVhZHkgdG9ucyBv ZiB3b3JrIG90aGVyIG9yZ2FuaXphdGlvbnMgaGF2ZSBkb25lIHRvIGNvbGxlY3QgbWV0cmljcyBm b3Igc3RyZWFtaW5nIG92ZXIgSFRUUC4gSnVzdCBsb29rIGF0IHdoYXQgb3RoZXJzIGRpZCBhbHJl YWR5LCBtcGVnLCBkYXNoLWlmLCBTVkEgYW5kIG5vdyBhbG1vc3QgYWxsIHRoZSBleGlzdGluZyB3 b3JrIGlzIGJlaW5nIGNvbGxlY3RlZCBhbmQgYmVjb21pbmcgYSBzaW5nbGUgY29tbW9uIHNwZWMg b3V0IG9mDQogQ1RBLiBJIGhvbmVzdGx5IGRvbid0IHRoaW5rIHRoaXMgV0cgc2hvdWxkIHdvcmsg b24gdGhpcyBnaXZlbiB0aGUgYW1vdW50IG9mIGV4aXN0aW5nIGFuZCBvbmdvaW5nIHdvcmsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LWFjYmVnZW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgSnVsIDE3LCAy MDE3IGF0IDc6NDUgUE0sIEh1YW5neWlob25nIChSYWNoZWwpICZsdDs8YSBocmVmPSJtYWlsdG86 cmFjaGVsLmh1YW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5yYWNoZWwuaHVhbmdAaHVh d2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgQWxpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYXTigJlzIG9uZSBwYXJ0IHRoYXQgTURJIGNvdWxk IG5vdCBkbywgYW5kIHdlIGhvcGUgc29tZSBuZXcgbWV0cmljcyBjb3VsZCBiZSB1c2VkLCB3aGlj aA0KIGlzIHRoZSBpbnRlbnRpb24gb2YgdGhpcyB3b3JrLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzIGZvciB0aGUg UlRDUCBYUiBtZXRyaWNzLCBpdOKAmXMgbm90IHF1aXRlIHJlYWxpc3RpYyBpbiBtaWRkbGUgZGV2 aWNlcyBsaWtlIHJvdXRlcnMsIHRvDQogaW1wbGVtZW50IHRoZW0sIGUuZy4sIHBvc3QtcmVwYWly IG1ldHJpY3MsIHdoaWNoIHdpbGwgbmVlZCB0aGUgZGV2aWNlcyB0byBoYXZlIHRoZSBhYmlsaXR5 IHRvIGRlY29kZSBhbmQgYXBwbHkgRkVDIHJlcGFpciBtZWNoYW5pc21zLiBTbyB0aGF04oCZcyB3 aHkgd2UgbmVlZCBzb21lIHdheXMgbGlrZSBNREksIGVhc3kgdG8gY2FsY3VsYXRlIGFuZCBiZSBp bXBsZW1lbnRlZCBpbiB0aGUgbmV0d29yayB3aXRob3V0IGhhdmluZyB0byBiZSBhIFJUUCBlbnRp dHkNCiBvciBUQ1AgcHJveHkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QlIsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmFjaGVsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7lj5Hku7bkuro8L3Nw YW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+DQogdHN2LWFyZWEgW21haWx0bzo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzp0c3YtYXJlYS1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+dHN2LWFyZWEtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5dDQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuS7o+ihqDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BbGkgQy4gQmVn ZW48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuWPkemAgeaX tumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gMjAxNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj43PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7m l6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIDE5OjMxPGJyPg0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+IFFpbiBXdSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVm PSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+YmlsbC53dUBodWF3ZWkuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPuaKhOmAgTwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOnRzdi1hcmVhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+dHN2LWFyZWFAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+IFJlOg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7nrZTlpI08L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjogUHJvcG9zYWwgZm9yIHJldmlzaW5nIFJGQzQ0NDUgb3IgbWFrZSBSRkM0 NDQ1YmlzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ugd2FubmEgdXNlIE1ESSB0byBtZWFzdXJlIG1lZGlhIGRl bGl2ZXJ5IG92ZXIgVENQPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBNb24sIEp1bCAxNywgMjAxNyBhdCA3OjE4IFBNLCBRaW4gV3UgJmx0OzxhIGhyZWY9 Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5iaWxsLnd1QGh1YXdl aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UmbmJzcDtoYXZlJm5ic3A7Y3Vz dG9tZXJzJm5ic3A7dXNpbmcmbmJzcDtNREkmbmJzcDt0byZuYnNwO2FkZHJlc3MmbmJzcDtuZXcm bmJzcDtuZWVkcywmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDt3aWZpJm5ic3A7cGVyZm9ybWFuY2Um bmJzcDttZWFzdXJlbWVudCZuYnNwO01ESSZuYnNwO2ZhbGxzJm5ic3A7c2hvcnQmbmJzcDt3aGVu Jm5ic3A7bWVhc3VyaW5nJm5ic3A7ZGVsaXZlcnkmbmJzcDtvZiZuYnNwO3N0cmVhbWluZyZuYnNw O21lZGlhJm5ic3A7b3ZlciZuYnNwO3RjcCwmbmJzcDt0aGF0Jm5ic3A7aXMmbmJzcDt3aHkmbmJz cDt3ZSZuYnNwO3RoaW5rJm5ic3A7aXQmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO2V4dGVuZGVk LiZuYnNwO1llcywmbmJzcDtydGNwJm5ic3A7WFImbmJzcDtoYXMmbmJzcDtpdHMmbmJzcDt2YWx1 ZS4mbmJzcDtCdXQmbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt0aGV5Jm5ic3A7Y291bGQmbmJzcDti ZSZuYnNwO2NvbXBsaW1lbnRhcnkuPGJyPg0KPGJyPg0KU2VudCZuYnNwO2Zyb20mbmJzcDtIVUFX RUkmbmJzcDtBbnlPZmZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjYu MHB0IDBjbSAwY20gMGNtIiBuYW1lPSJBbnlPZmZpY2UtQmFja2dyb3VuZC1JbWFnZSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdCI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5Y+R5Lu25Lq677yaIDwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BbGkgQy4gQmVnZW48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQiPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQiPuaUtuS7tuS6uu+8miA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UWluIFd1Ow0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij7mioTpgIHvvJogPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0ibWFpbHRvOnRzdi1hcmVhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQiPnRzdi1hcmVhQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij47DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPumDkei+iTxzcGFuIGxhbmc9IkVOLVVTIj47IDwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQiPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPuS4u+mimO+8miA8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+UmU6IFByb3Bvc2FsIGZvciBy ZXZpc2luZyBSRkM0NDQ1IG9yIG1ha2UgUkZDNDQ0NWJpczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdCI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdCI+5pe26Ze077yaIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4yMDE3LTA3LTE3IDEzOjAyOjA3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7 bGluZS1oZWlnaHQ6MTUuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gcmVhbGx5IGN1cmlvdXMg YWJvdXQgd2hvIGlzIHVzaW5nIE1ESSBhbnltb3JlLiBDYW4geW91IHNoYXJlIGRhdGEgaWYgeW91 IGhhdmUgaXQ/IFJUQ1AgWFIgaXMgc3RpbGwgZXh0ZW5zaXZlbHkgdXNlZCBhbmQgZm9yIG5vbi1S VFAsIGl0IGlzIGEgbWl4ZWQgb2Ygc2V2ZXJhbA0KIHRoaW5ncy4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi1hY2JlZ2VuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBKdWwgMTcsIDIwMTcgYXQg MTozOSBQTSwgUWluIFd1ICZsdDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmlsbC53dUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+SGksIEFsbDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2Ug bGlrZSB0byBnZXQgYSBzZW5zZSBvZiB0aGlzIGlkZWEsIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28s IGF0IHRoZSB0aW1lIG9mIFJGQzQ0NDUgd3JpdGluZyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+VGhlIHBvcHVsYXJpdHkgb2YgZGVsaXZlcnkgb2Ygc3RyZWFtaW5nIG1lZGlh IG92ZXIgcGFja2V0IHN3dGljaGVkIG5ldHdvcmsgaGFzIGp1c3QgYmVnYW4sPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPm5vdCBhbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQg UW9TIG1ldGhvZHMgdG8gaW1wcm92ZSBtZWRpYSBkZWxpdmVyeS4gTWFueSBzZXJ2aWNlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmRlbGl2ZXJ5IHN5c3RlbXMgbWF5IGNvbXBv c2UgdGhlIG5ldHdvcmsgd2l0aCBRb1Mgc3VwcG9ydCBvciB3aXRob3V0IFFvUyBzdXBwb3J0LiBU aGlzIGFkZCBkaWZmaWN1bHR5IG9uIGNoYXJhY3Rlcml6aW5nIGR5bmFtaWMgYmVoYXZpb3Igb2Yg dGhlIG5ldHdvcmsuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4xMCB5ZWFycyBoYXZlIHBhc3NlZCwg d2Ugc2VlIG1vc3Qgb2Ygd2lkZWx5IGRlcGxveWVkIGltcGxlbWVudGlvbnMgaGF2ZSBhZG9wdGVk IHZhcmlvdXMgZGlmZmVyZW50IFFvUyBtZWNoYW5pc21zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPnN1Y2ggYXMgZGlmZnNlcnYgSW50c2VydiwgVHJhZmZpYyBFbmdpbmVlcmlu ZywgcHJvdmlkaW5nIFFvUyBndWFyYW50ZWUgdG8gaW1wcm92ZSBkZWxpdmVyeSBvZiBtZWRpYSBz dHJlYW1pbmcsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmVzcGVjaWFsbHkg Zm9yIHRpbWUgc2VuZXN0aXZlIG9yIGxvc3Mgc2Vuc3RpdmUgYXBwbGljYXRpb24gYmVjb21lIGEg bXVzdDsgVGhlcmVmb3JlIHdlIHNlZSBhIGxvdCBvZiB2YWx1ZSBvZiBNREkgZGVmaW5lZCBpbiBS RkM0NDQ1IHNpbmNlIGl0IHByb3ZpZGUgcyBhIGhhbmR5IGRpYWdub3N0aWMNCiB0b29sIGZvciBv cGVyYXRvcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIHRvIG1lYXN1cmUgdGhlIHBlZm9ybWFuY2Ug b2YgdGhlIG5ldHdvcmsgY2Fycnlpbmcgc3RyZWFtaW5nIG1lZGlhIGFuZCBxdWlja2x5IGlkZW50 aWZ5IGZhdWx0IGluIHRoZSBuZXR3b3JrLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG9kYXkgd2Ug YWxzbyBzZWUgbWFueSZuYnNwO3NlcnZpY2UgcHJvdmlkZXJzJm5ic3A7YmVnYWluIHRvIG9mZmVy IG9uIGRlbWFuZCBzdHJlYW1pbmcgbWVkaWEgc2VydmljZSwgbWFueSBvcGVyYXRvciBkZXBsb3ll ZCBDRE4gaW4gdGhlIGxhc3QgbWlsZSB0byBwcm92aWRlIGJldHRlciBTTEEsIG9yIHByb3ZpZGUN CiBoeWJyaWQgVFYgc2VydmljZSwgaW4gYWRkaXRpb24gbW9yZSBhbmQgbW9yZSByZWFsIHRpbWUg YXBwbGljYXRpb24gbm90IGxpbWl0ZWQgdG8gSVBUViBhcHBsaWNhdGlvbiwgVk9JUCBhcHBsaWNh dGlvbiBoYXZlIGJlZW4gZGV2ZWxvcGVkLG5ldHdvcmsgbW9uaXRvcmluZyBhbmQgbmV0d29yayB0 cm91Ymxlc2hvb3RpbmcgYmVnYW4gbW9yZSBhbmQgbW9yZSBjb21wbGljYXRlZCBhbmQgY29zdHku Jm5ic3A7V2UgaGVhciBhIGxvdCBvZiBvcGVyYXRvcnMgZ2V0DQogaHVydGVkIGFuZCB3YW50IHRv IGhhdmUgYSBjb21tb24gdG9vbCB0byBoZWxwIHRoZW0gdG8gbWVhc3VyZSBwZXJmb3JtYW5jZSBp biB0aGlzIGtpbmQgb2YgbmV0d29ya3MgYW5kIHByb3ZpZGVyIGJldHRlciB0cm91Ymxlc2hvb3Rp bmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Bbm90aGVyIG9ic2VydmF0aW9uIGlzIHRvZGF5IG1v cmUgYW5kIG1vcmUgaW1wbGVtZW50YXRpb25zIGhhdmUgYWRvcHRlZCBwYWNrZXQgbG9zcyByZXBh aXIgbWV0aG9kcyB0byBpbXByb3ZlIG1lZGlhIGRlbGl2ZXJ5Ljwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5Ib3dldmVyIE1ESSBkZWZpbmVkIGluIFJGQzQ0NDUgZG9lc24ndCB0 YWtlIGludG8gYWNvdW50IG9mIHZhcmlvdXMgZGlmZmVyZW50IHBhY2tldCBsb3NzIHJlcGFpciBt ZWNoYW5pbXMsIGluIGFkZGl0aW9uLCBSRkM0NDQ1IGlzIG9ubHkgZGVzaWduZWQgZm9yIG1vbml0 b3JpbmcgTVBFRyBUcmFuc3BvcnQNCiBTdHJlYW0gKFRTKSBwYWNrZXRzIG92ZXIgVURQIGFuZCBm YWxsIHNob3J0IHRvIGFkZHJlc3NpbmcgbmVlZHMgaW4gaHlicmlkIHNlbmFyaW9zIG9yIG9uIGRl bWFuZCBzdHJlYW1pbmcgbWVkaWEgc2NlbmFyaW9zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4g YWRkaXRpb24sIHdlIHNlZSBhdCB0aGUgdGltZSBvZiBSRkM0NDQ1IHB1YmxpY2F0aW9uLCBJRVNH IGRvZXNuJ3QgcmVjb21tZW5kIHRoaXMgc3RhbmRhcmQsIG1vc3RseSBiZWNvcyBSRkM0NDQ1IGRv ZXNuJ3QgZGVmaW5lIGNvbXBsZXRlIE1ldHJpYyBhbmQgY2xhcmlmeSB0aGUgcmVsYXRpb25zaGlw DQogd2l0aCBleGlzdGluZyBJRVRGIHdvcmsgc3VjaCBhcyBSRkMzNjExIGFuZCBSRkMzOTMzLCBJ IGFtIHdvbmRlcmluZyBpZiBpdCBpcyBhIGdvb2QgaWRlYSB0byByZXZpc2UgUkZDNDQ0NSB0byBh ZGRyZXNzIElFU0cgY29uY2VybiB0b2RheSBhbmQgaW4gYWRkaXRpb24gZmlsbCBuZXcgbmVlZHMg aW4gdG9kYXkncyBzZXJ2aWNlIGRlcGxveW1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucz88L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4 ODg4Ij4tUWluPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C4FDF0Cnkgeml513mbxchi_-- From nobody Mon Jul 17 05:43:24 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414EF131898 for ; Mon, 17 Jul 2017 05:43:23 -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 EWxP2cnj_pWW for ; Mon, 17 Jul 2017 05:43:12 -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 3349313146E for ; Mon, 17 Jul 2017 05:43:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xB2yQ3qZcz15M8Z; Mon, 17 Jul 2017 14:43:10 +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 ckBfml0TlmwZ; Mon, 17 Jul 2017 14:43:09 +0200 (CEST) X-MtScore: NO score=0 Received: from dhcp-80db.meeting.ietf.org (dhcp-80db.meeting.ietf.org [31.133.128.219]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 17 Jul 2017 14:43:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Proposal for revising RFC4445 or make RFC4445bis From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 17 Jul 2017 14:43:06 +0200 Cc: "Huangyihong (Rachel)" , "tsv-area@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> To: "Ali C. Begen" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:43:23 -0000 This is the area list, not a wg; we are not working on any document. The = purpose of announcing this work here is to figure if there is any = interested in this work and if so where it should be done. > Am 17.07.2017 um 14:16 schrieb Ali C. Begen = : >=20 > Well, I believe you wanna come up with some metrics for streaming = video over http and want to extend MDI for that. Well, MDI was not = designed for that at all, so extending it in that direction is not a = good idea. Further, there is already tons of work other organizations = have done to collect metrics for streaming over HTTP. Just look at what = others did already, mpeg, dash-if, SVA and now almost all the existing = work is being collected and becoming a single common spec out of CTA. I = honestly don't think this WG should work on this given the amount of = existing and ongoing work. >=20 > -acbegen >=20 > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) = wrote: > Hi Ali, >=20 > =20 >=20 > That=E2=80=99s one part that MDI could not do, and we hope some new = metrics could be used, which is the intention of this work. >=20 > =20 >=20 > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middle = devices like routers, to implement them, e.g., post-repair metrics, = which will need the devices to have the ability to decode and apply FEC = repair mechanisms. So that=E2=80=99s why we need some ways like MDI, = easy to calculate and be implemented in the network without having to be = a RTP entity or TCP proxy. >=20 > =20 >=20 > BR, >=20 > Rachel >=20 > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area = [mailto:tsv-area-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Ali C. Begen > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97=A5= 19:31 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > =E6=8A=84=E9=80=81: tsv-area@ietf.org > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising = RFC4445 or make RFC4445bis >=20 > =20 >=20 > You wanna use MDI to measure media delivery over TCP? >=20 > =20 >=20 > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: >=20 > We have customers using MDI to address new needs, such as wifi = performance measurement MDI falls short when measuring delivery of = streaming media over tcp, that is why we think it should be extended. = Yes, rtcp XR has its value. But I think they could be complimentary. >=20 > Sent from HUAWEI AnyOffice >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen >=20 > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; >=20 > =E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89; >=20 > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or make = RFC4445bis >=20 > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07 >=20 > =20 >=20 > I am really curious about who is using MDI anymore. Can you share data = if you have it? RTCP XR is still extensively used and for non-RTP, it is = a mixed of several things. >=20 > =20 >=20 > -acbegen >=20 > =20 >=20 > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: >=20 > Hi, All: >=20 > We like to get a sense of this idea, more than 10 years ago, at the = time of RFC4445 writing, >=20 > The popularity of delivery of streaming media over packet swtiched = network has just began, >=20 > not all implementations support QoS methods to improve media delivery. = Many service >=20 > delivery systems may compose the network with QoS support or without = QoS support. This add difficulty on characterizing dynamic behavior of = the network. >=20 > =20 >=20 > 10 years have passed, we see most of widely deployed implementions = have adopted various different QoS mechanisms >=20 > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee = to improve delivery of media streaming, >=20 > especially for time senestive or loss senstive application become a = must; Therefore we see a lot of value of MDI defined in RFC4445 since it = provide s a handy diagnostic tool for operators and service providers to = measure the peformance of the network carrying streaming media and = quickly identify fault in the network. >=20 > =20 >=20 > Today we also see many service providers begain to offer on demand = streaming media service, many operator deployed CDN in the last mile to = provide better SLA, or provide hybrid TV service, in addition more and = more real time application not limited to IPTV application, VOIP = application have been developed,network monitoring and network = troubleshooting began more and more complicated and costy. We hear a lot = of operators get hurted and want to have a common tool to help them to = measure performance in this kind of networks and provider better = troubleshooting. >=20 > =20 >=20 > Another observation is today more and more implementations have = adopted packet loss repair methods to improve media delivery. >=20 > However MDI defined in RFC4445 doesn't take into acount of various = different packet loss repair mechanims, in addition, RFC4445 is only = designed for monitoring MPEG Transport Stream (TS) packets over UDP and = fall short to addressing needs in hybrid senarios or on demand streaming = media scenarios. >=20 > =20 >=20 > In addition, we see at the time of RFC4445 publication, IESG doesn't = recommend this standard, mostly becos RFC4445 doesn't define complete = Metric and clarify the relationship with existing IETF work such as = RFC3611 and RFC3933, I am wondering if it is a good idea to revise = RFC4445 to address IESG concern today and in addition fill new needs in = today's service deployment. >=20 > Comments and suggestions? >=20 > =20 >=20 > -Qin >=20 > =20 >=20 > =20 >=20 >=20 From nobody Mon Jul 17 05:51:14 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5D3131839 for ; Mon, 17 Jul 2017 05:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 846qotCFxGL7 for ; Mon, 17 Jul 2017 05:51:01 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 0390B131B5D for ; Mon, 17 Jul 2017 05:51:01 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id w187so16701231ybc.0 for ; Mon, 17 Jul 2017 05:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2a9YE7GTmupKkbsSIKaCNT+HKn393qQL7mabb9xyD5A=; b=A/YCZ0db+SLAEAW3QVG09mYygBIgRQoJG1PAlJgi1IiL8urrRGWnjijZ8HCKzerOTE lXWV6qos/BOFHd+GnA8XH33wWarbiJ6IaBrQbPs+XgidfA8floELkP1JH77mYFsLiDO5 Enr38o4jAP0/fbbWcJSUUXPmhGdpCFh+/89P9HSzZ0810g2dr7WkBTnsBQgA83B1+2b6 F7jTPp0SU10NM5EB+HCSya3Wu4mNcd3SnWLwXFJ/WlQbz5AIWsjzbIie8Qq675pD+eU5 DTMSIVtCjI55LmrVBtpzIuT8dmOwcV1TAGD3UJiUvmCYww19G/rvcwdR7BxU1cqNmrhy ApKQ== 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=2a9YE7GTmupKkbsSIKaCNT+HKn393qQL7mabb9xyD5A=; b=YyFL99qjGfXde8+VvilGI+5k6bZNcbLH5+F3mpcpWc4ocTWdEvX/yQuNza9ljQUHhF 0xf9EJkte2tKeBIJ09aqxVKeEHab5TE/8Lpc5v+9a84pfEXfrAh2PYH3vsdf9VBrrBG6 PLiBGd176A/xpinWI5BAdhLUXwcDeFokTgPUVz0JgklhZzhf+GrTZ4bvoMCnBWOPmJJv fpFuNRqBGtKQu+0EgINUn1DYHKaOxtgp2EIFMa+5LSnNCoLjcqf+OGqgNFbJDHBzWSH1 4wR6zMFYDAhGMt8ONROFpmbLdJW9mjHZQ09mH8a3HA5jIS6Lr+Xw+WXQBRRN0YWeApD5 R8Qg== X-Gm-Message-State: AIVw1105unt9aBU1RWKz22KBjHPnbUtALLfnPyLMBz2i4H68xMVYr6XT 0af8e/SYCE/ytVvqG/ZoYzvCMuGKwENh X-Received: by 10.37.94.85 with SMTP id s82mr18056184ybb.251.1500295860195; Mon, 17 Jul 2017 05:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.29.15 with HTTP; Mon, 17 Jul 2017 05:50:59 -0700 (PDT) In-Reply-To: <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> From: "Ali C. Begen" Date: Mon, 17 Jul 2017 20:50:59 +0800 Message-ID: Subject: Re: Proposal for revising RFC4445 or make RFC4445bis To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "Huangyihong (Rachel)" , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary="001a11425b90ce6816055482d9f1" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:51:04 -0000 --001a11425b90ce6816055482d9f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > This is the area list, not a wg; we are not working on any document. The > purpose of announcing this work here is to figure if there is any > interested in this work and if so where it should be done. > I know this is an area list, my comment was not specific to any wg. Streaming with TCP has a lot more to do at the app layer (actually in the application itself) rather than the transport layer. So, this topic does not belong in here at all IMO. -acbegen > > > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen = : > > > > Well, I believe you wanna come up with some metrics for streaming video > over http and want to extend MDI for that. Well, MDI was not designed for > that at all, so extending it in that direction is not a good idea. Furthe= r, > there is already tons of work other organizations have done to collect > metrics for streaming over HTTP. Just look at what others did already, > mpeg, dash-if, SVA and now almost all the existing work is being collecte= d > and becoming a single common spec out of CTA. I honestly don't think this > WG should work on this given the amount of existing and ongoing work. > > > > -acbegen > > > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) < > rachel.huang@huawei.com> wrote: > > Hi Ali, > > > > > > > > That=E2=80=99s one part that MDI could not do, and we hope some new met= rics > could be used, which is the intention of this work. > > > > > > > > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middle = devices > like routers, to implement them, e.g., post-repair metrics, which will ne= ed > the devices to have the ability to decode and apply FEC repair mechanisms= . > So that=E2=80=99s why we need some ways like MDI, easy to calculate and b= e > implemented in the network without having to be a RTP entity or TCP proxy= . > > > > > > > > BR, > > > > Rachel > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.org= ] =E4=BB=A3=E8=A1=A8 Ali C. Begen > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97= =A5 19:31 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > > =E6=8A=84=E9=80=81: tsv-area@ietf.org > > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising RFC44= 45 or make RFC4445bis > > > > > > > > You wanna use MDI to measure media delivery over TCP? > > > > > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > > > > We have customers using MDI to address new needs, such as wifi > performance measurement MDI falls short when measuring delivery of > streaming media over tcp, that is why we think it should be extended. Yes= , > rtcp XR has its value. But I think they could be complimentary. > > > > Sent from HUAWEI AnyOffice > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; > > > > =E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89; > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or make R= FC4445bis > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07 > > > > > > > > I am really curious about who is using MDI anymore. Can you share data > if you have it? RTCP XR is still extensively used and for non-RTP, it is = a > mixed of several things. > > > > > > > > -acbegen > > > > > > > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > > > > Hi, All: > > > > We like to get a sense of this idea, more than 10 years ago, at the tim= e > of RFC4445 writing, > > > > The popularity of delivery of streaming media over packet swtiched > network has just began, > > > > not all implementations support QoS methods to improve media delivery. > Many service > > > > delivery systems may compose the network with QoS support or without Qo= S > support. This add difficulty on characterizing dynamic behavior of the > network. > > > > > > > > 10 years have passed, we see most of widely deployed implementions have > adopted various different QoS mechanisms > > > > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee > to improve delivery of media streaming, > > > > especially for time senestive or loss senstive application become a > must; Therefore we see a lot of value of MDI defined in RFC4445 since it > provide s a handy diagnostic tool for operators and service providers to > measure the peformance of the network carrying streaming media and quickl= y > identify fault in the network. > > > > > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and mo= re > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurte= d > and want to have a common tool to help them to measure performance in thi= s > kind of networks and provider better troubleshooting. > > > > > > > > Another observation is today more and more implementations have adopted > packet loss repair methods to improve media delivery. > > > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC36= 11 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > > > Comments and suggestions? > > > > > > > > -Qin > > > > > > > > > > > > > > --001a11425b90ce6816055482d9f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind <m= irja.kuehlewind@tik.ee.ethz.ch> wrote:
This is the area list, not a wg; we are no= t working on any document. The purpose of announcing this work here is to f= igure if there is any interested in this work and if so where it should be = done.

I know this is an area list, my c= omment was not specific to any wg. Streaming with TCP has a lot more to do = at the app layer (actually in the application itself) rather than the trans= port layer. So, this topic does not belong in here at all IMO.

-acbegen
=C2=A0


> Am 17.07.2017 um 14:16 schrieb Ali C. Begen <ali.begen@networked.me= dia>:
>
> Well, I believe you wanna come up with some metrics for streaming vide= o over http and want to extend MDI for that. Well, MDI was not designed for= that at all, so extending it in that direction is not a good idea. Further= , there is already tons of work other organizations have done to collect me= trics for streaming over HTTP. Just look at what others did already, mpeg, = dash-if, SVA and now almost all the existing work is being collected and be= coming a single common spec out of CTA. I honestly don't think this WG = should work on this given the amount of existing and ongoing work.
>
> -acbegen
>
> On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:
> Hi Ali,
>
>
>
> That=E2=80=99s one part that MDI could not do, and we hope some new me= trics could be used, which is the intention of this work.
>
>
>
> As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middle= devices like routers, to implement them, e.g., post-repair metrics, which = will need the devices to have the ability to decode and apply FEC repair me= chanisms. So that=E2=80=99s why we need some ways like MDI, easy to calcula= te and be implemented in the network without having to be a RTP entity or T= CP proxy.
>
>
>
> BR,
>
> Rachel
>
>
>
> =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.org] =E4=BB=A3=E8=A1=A8= Ali C. Begen
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97= =A5 19:31
> =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
> =E6=8A=84=E9=80=81: tsv-area@ietf= .org
> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising RFC4= 445 or make RFC4445bis
>
>
>
> You wanna use MDI to measure media delivery over TCP?
>
>
>
> On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu <bill.wu@huawei.com> wrote:
>
> We have customers using MDI to address new needs, such as wifi perform= ance measurement MDI falls short when measuring delivery of streaming media= over tcp, that is why we think it should be extended. Yes, rtcp XR has its= value. But I think they could be complimentary.
>
> Sent from HUAWEI AnyOffice
>
> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen
>
> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu;
>
> =E6=8A=84=E9=80=81=EF=BC=9A tsv-a= rea@ietf.org; =E9=83=91=E8=BE=89;
>
> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or make = RFC4445bis
>
> =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07
>
>
>
> I am really curious about who is using MDI anymore. Can you share data= if you have it? RTCP XR is still extensively used and for non-RTP, it is a= mixed of several things.
>
>
>
> -acbegen
>
>
>
> On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.com> wrote:
>
> Hi, All:
>
> We like to get a sense of this idea, more than 10 years ago, at the ti= me of RFC4445 writing,
>
> The popularity of delivery of streaming media over packet swtiched net= work has just began,
>
> not all implementations support QoS methods to improve media delivery.= Many service
>
> delivery systems may compose the network with QoS support or without Q= oS support. This add difficulty on characterizing dynamic behavior of the n= etwork.
>
>
>
> 10 years have passed, we see most of widely deployed implementions hav= e adopted various different QoS mechanisms
>
> such as diffserv Intserv, Traffic Engineering, providing QoS guarantee= to improve delivery of media streaming,
>
> especially for time senestive or loss senstive application become a mu= st; Therefore we see a lot of value of MDI defined in RFC4445 since it prov= ide s a handy diagnostic tool for operators and service providers to measur= e the peformance of the network carrying streaming media and quickly identi= fy fault in the network.
>
>
>
> Today we also see many service providers begain to offer on demand str= eaming media service, many operator deployed CDN in the last mile to provid= e better SLA, or provide hybrid TV service, in addition more and more real = time application not limited to IPTV application, VOIP application have bee= n developed,network monitoring and network troubleshooting began more and m= ore complicated and costy. We hear a lot of operators get hurted and want t= o have a common tool to help them to measure performance in this kind of ne= tworks and provider better troubleshooting.
>
>
>
> Another observation is today more and more implementations have adopte= d packet loss repair methods to improve media delivery.
>
> However MDI defined in RFC4445 doesn't take into acount of various= different packet loss repair mechanims, in addition, RFC4445 is only desig= ned for monitoring MPEG Transport Stream (TS) packets over UDP and fall sho= rt to addressing needs in hybrid senarios or on demand streaming media scen= arios.
>
>
>
> In addition, we see at the time of RFC4445 publication, IESG doesn'= ;t recommend this standard, mostly becos RFC4445 doesn't define complet= e Metric and clarify the relationship with existing IETF work such as RFC36= 11 and RFC3933, I am wondering if it is a good idea to revise RFC4445 to ad= dress IESG concern today and in addition fill new needs in today's serv= ice deployment.
>
> Comments and suggestions?
>
>
>
> -Qin
>
>
>
>
>
>


--001a11425b90ce6816055482d9f1-- From nobody Mon Jul 17 05:54:34 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796D13192B for ; Mon, 17 Jul 2017 05:54:33 -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=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 v4leIvnqaCDH for ; Mon, 17 Jul 2017 05:54:30 -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 B51AB12EB8C for ; Mon, 17 Jul 2017 05:54:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xB3CT3rj0z15M8k; Mon, 17 Jul 2017 14:54:29 +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 A8EY119TMuZn; Mon, 17 Jul 2017 14:54:28 +0200 (CEST) X-MtScore: NO score=0 Received: from dhcp-80db.meeting.ietf.org (dhcp-80db.meeting.ietf.org [31.133.128.219]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 17 Jul 2017 14:54:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Proposal for revising RFC4445 or make RFC4445bis From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 17 Jul 2017 14:54:26 +0200 Cc: "Huangyihong (Rachel)" , "tsv-area@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8FB9DA49-55A2-46DE-A56A-FACD7C5114D7@tik.ee.ethz.ch> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> To: "Ali C. Begen" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:54:33 -0000 I believe the problem that is addressed with this proposals is actually = assessing streaming quality from the outside/network if you don=E2=80=99t = have access to do the measurement on the endpoint in the app. Not saying = that we need or should do this work but that=E2=80=99s why this might be = relevant to transport as well as apps. > Am 17.07.2017 um 14:50 schrieb Ali C. Begen = : >=20 >=20 >=20 > On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind = wrote: > This is the area list, not a wg; we are not working on any document. = The purpose of announcing this work here is to figure if there is any = interested in this work and if so where it should be done. >=20 > I know this is an area list, my comment was not specific to any wg. = Streaming with TCP has a lot more to do at the app layer (actually in = the application itself) rather than the transport layer. So, this topic = does not belong in here at all IMO. >=20 > -acbegen > =20 >=20 >=20 > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen = : > > > > Well, I believe you wanna come up with some metrics for streaming = video over http and want to extend MDI for that. Well, MDI was not = designed for that at all, so extending it in that direction is not a = good idea. Further, there is already tons of work other organizations = have done to collect metrics for streaming over HTTP. Just look at what = others did already, mpeg, dash-if, SVA and now almost all the existing = work is being collected and becoming a single common spec out of CTA. I = honestly don't think this WG should work on this given the amount of = existing and ongoing work. > > > > -acbegen > > > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) = wrote: > > Hi Ali, > > > > > > > > That=E2=80=99s one part that MDI could not do, and we hope some new = metrics could be used, which is the intention of this work. > > > > > > > > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in = middle devices like routers, to implement them, e.g., post-repair = metrics, which will need the devices to have the ability to decode and = apply FEC repair mechanisms. So that=E2=80=99s why we need some ways = like MDI, easy to calculate and be implemented in the network without = having to be a RTP entity or TCP proxy. > > > > > > > > BR, > > > > Rachel > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area = [mailto:tsv-area-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Ali C. Begen > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97=A5= 19:31 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > > =E6=8A=84=E9=80=81: tsv-area@ietf.org > > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising = RFC4445 or make RFC4445bis > > > > > > > > You wanna use MDI to measure media delivery over TCP? > > > > > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > > > > We have customers using MDI to address new needs, such as wifi = performance measurement MDI falls short when measuring delivery of = streaming media over tcp, that is why we think it should be extended. = Yes, rtcp XR has its value. But I think they could be complimentary. > > > > Sent from HUAWEI AnyOffice > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; > > > > =E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89; > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or = make RFC4445bis > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07 > > > > > > > > I am really curious about who is using MDI anymore. Can you share = data if you have it? RTCP XR is still extensively used and for non-RTP, = it is a mixed of several things. > > > > > > > > -acbegen > > > > > > > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > > > > Hi, All: > > > > We like to get a sense of this idea, more than 10 years ago, at the = time of RFC4445 writing, > > > > The popularity of delivery of streaming media over packet swtiched = network has just began, > > > > not all implementations support QoS methods to improve media = delivery. Many service > > > > delivery systems may compose the network with QoS support or without = QoS support. This add difficulty on characterizing dynamic behavior of = the network. > > > > > > > > 10 years have passed, we see most of widely deployed implementions = have adopted various different QoS mechanisms > > > > such as diffserv Intserv, Traffic Engineering, providing QoS = guarantee to improve delivery of media streaming, > > > > especially for time senestive or loss senstive application become a = must; Therefore we see a lot of value of MDI defined in RFC4445 since it = provide s a handy diagnostic tool for operators and service providers to = measure the peformance of the network carrying streaming media and = quickly identify fault in the network. > > > > > > > > Today we also see many service providers begain to offer on demand = streaming media service, many operator deployed CDN in the last mile to = provide better SLA, or provide hybrid TV service, in addition more and = more real time application not limited to IPTV application, VOIP = application have been developed,network monitoring and network = troubleshooting began more and more complicated and costy. We hear a lot = of operators get hurted and want to have a common tool to help them to = measure performance in this kind of networks and provider better = troubleshooting. > > > > > > > > Another observation is today more and more implementations have = adopted packet loss repair methods to improve media delivery. > > > > However MDI defined in RFC4445 doesn't take into acount of various = different packet loss repair mechanims, in addition, RFC4445 is only = designed for monitoring MPEG Transport Stream (TS) packets over UDP and = fall short to addressing needs in hybrid senarios or on demand streaming = media scenarios. > > > > > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't = recommend this standard, mostly becos RFC4445 doesn't define complete = Metric and clarify the relationship with existing IETF work such as = RFC3611 and RFC3933, I am wondering if it is a good idea to revise = RFC4445 to address IESG concern today and in addition fill new needs in = today's service deployment. > > > > Comments and suggestions? > > > > > > > > -Qin > > > > > > > > > > > > >=20 >=20 From nobody Mon Jul 17 06:03:25 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66D0131B6E for ; Mon, 17 Jul 2017 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 ESnswDsIyc30 for ; Mon, 17 Jul 2017 06:03:09 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 8540E131B72 for ; Mon, 17 Jul 2017 06:03:08 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v193so46977588ywg.2 for ; Mon, 17 Jul 2017 06:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8m0RZRwI4WyVLutMcO9mpeqf/dJiVlRQNiEUbZUvhw4=; b=OHGuc92ZI2nvQKMr/DwaojGZrjKmqMFR2FiISaJwTRWnGmPWZVgxBLQwGk5rsRVcX8 lbIKvZbkkXsSQzXumhMn4hJZzRkVfdawakkVDEt4Qv/YEfFW7M1wmvUcnV4/F0FcWXnh hWZd7PJbCAtW/KU+HmJpStadVrG9q8fng9QUoZcJS6mWgbna0xF3o5Pt9tbyKMaGNXjS /CQio2btUF5nCXPxw8KnPMH80iHwtNONMPqZ0pj+M+xVHT4FpsEou7wrSMojgs/2jVj3 pAX3D2MajTu4p2ZYiraEhJ5ZPZ0lUsLg6WOQNJ+rnlX13D8gpc1lKRvgHUzNDYEXkQKB 7V3A== 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=8m0RZRwI4WyVLutMcO9mpeqf/dJiVlRQNiEUbZUvhw4=; b=IKmnkuftkAMiDkzdqbQWvtTzhFNqwd5mYNkhWAWAdvaMNTe33d6LjSIuSs7fgInX0g y1tqzgdJt704vidrsTHbVQdS8toSt96NAM/4VUXXyapy1ddMopV3RiGp8NSr5GqDkMS3 /2aOuvrsIkxMk1B0xvzl9mRcmk1P8RGkhZ/KEx45eUwhh1fLeqybn2V/y+lFyuF2bvr1 SM9vj6Uaf0kN4xupEDWQRs9eg6+I3L9LJeQBB0DipOlCJaAXBi5LS0U8VwjXsTxzMiDJ GoCsLlf3xlXHG13bR0bSDwdPvOFcW4LDstVmIGGl5//AFoSKV5sLdYhqrXNTLLhhkgWw fSSA== X-Gm-Message-State: AIVw113rPiZW7b6onb6dVJuey8F56G/M9R6yeRRMBEqo7R5T39am1b1d SOkcaBBueNA6VcI41D0261kf3lXgDDU1 X-Received: by 10.129.78.198 with SMTP id c189mr6591580ywb.62.1500296587741; Mon, 17 Jul 2017 06:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.29.15 with HTTP; Mon, 17 Jul 2017 06:03:07 -0700 (PDT) In-Reply-To: <8FB9DA49-55A2-46DE-A56A-FACD7C5114D7@tik.ee.ethz.ch> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> <8FB9DA49-55A2-46DE-A56A-FACD7C5114D7@tik.ee.ethz.ch> From: "Ali C. Begen" Date: Mon, 17 Jul 2017 21:03:07 +0800 Message-ID: Subject: Re: Proposal for revising RFC4445 or make RFC4445bis To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "Huangyihong (Rachel)" , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd1de2ba37805548305a7" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:03:13 -0000 --001a114dd1de2ba37805548305a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, with most streams becoming encrypted, in-network monitoring have to be mostly heuristics based. Whether that is something to be specified, this list can discuss it I think. On Mon, Jul 17, 2017 at 8:54 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > I believe the problem that is addressed with this proposals is actually > assessing streaming quality from the outside/network if you don=E2=80=99t= have > access to do the measurement on the endpoint in the app. Not saying that = we > need or should do this work but that=E2=80=99s why this might be relevant= to > transport as well as apps. > > > > Am 17.07.2017 um 14:50 schrieb Ali C. Begen = : > > > > > > > > On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > This is the area list, not a wg; we are not working on any document. Th= e > purpose of announcing this work here is to figure if there is any > interested in this work and if so where it should be done. > > > > I know this is an area list, my comment was not specific to any wg. > Streaming with TCP has a lot more to do at the app layer (actually in the > application itself) rather than the transport layer. So, this topic does > not belong in here at all IMO. > > > > -acbegen > > > > > > > > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen >: > > > > > > Well, I believe you wanna come up with some metrics for streaming > video over http and want to extend MDI for that. Well, MDI was not design= ed > for that at all, so extending it in that direction is not a good idea. > Further, there is already tons of work other organizations have done to > collect metrics for streaming over HTTP. Just look at what others did > already, mpeg, dash-if, SVA and now almost all the existing work is being > collected and becoming a single common spec out of CTA. I honestly don't > think this WG should work on this given the amount of existing and ongoin= g > work. > > > > > > -acbegen > > > > > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) < > rachel.huang@huawei.com> wrote: > > > Hi Ali, > > > > > > > > > > > > That=E2=80=99s one part that MDI could not do, and we hope some new m= etrics > could be used, which is the intention of this work. > > > > > > > > > > > > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middl= e devices > like routers, to implement them, e.g., post-repair metrics, which will ne= ed > the devices to have the ability to decode and apply FEC repair mechanisms= . > So that=E2=80=99s why we need some ways like MDI, easy to calculate and b= e > implemented in the network without having to be a RTP entity or TCP proxy= . > > > > > > > > > > > > BR, > > > > > > Rachel > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Ali C. Begen > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97= =A5 19:31 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > > > =E6=8A=84=E9=80=81: tsv-area@ietf.org > > > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising RFC= 4445 or make RFC4445bis > > > > > > > > > > > > You wanna use MDI to measure media delivery over TCP? > > > > > > > > > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > > > > > > We have customers using MDI to address new needs, such as wifi > performance measurement MDI falls short when measuring delivery of > streaming media over tcp, that is why we think it should be extended. Yes= , > rtcp XR has its value. But I think they could be complimentary. > > > > > > Sent from HUAWEI AnyOffice > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen > > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; > > > > > > =E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89; > > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or make= RFC4445bis > > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07 > > > > > > > > > > > > I am really curious about who is using MDI anymore. Can you share dat= a > if you have it? RTCP XR is still extensively used and for non-RTP, it is = a > mixed of several things. > > > > > > > > > > > > -acbegen > > > > > > > > > > > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > > > > > > Hi, All: > > > > > > We like to get a sense of this idea, more than 10 years ago, at the > time of RFC4445 writing, > > > > > > The popularity of delivery of streaming media over packet swtiched > network has just began, > > > > > > not all implementations support QoS methods to improve media delivery= . > Many service > > > > > > delivery systems may compose the network with QoS support or without > QoS support. This add difficulty on characterizing dynamic behavior of th= e > network. > > > > > > > > > > > > 10 years have passed, we see most of widely deployed implementions > have adopted various different QoS mechanisms > > > > > > such as diffserv Intserv, Traffic Engineering, providing QoS guarante= e > to improve delivery of media streaming, > > > > > > especially for time senestive or loss senstive application become a > must; Therefore we see a lot of value of MDI defined in RFC4445 since it > provide s a handy diagnostic tool for operators and service providers to > measure the peformance of the network carrying streaming media and quickl= y > identify fault in the network. > > > > > > > > > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and mo= re > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurte= d > and want to have a common tool to help them to measure performance in thi= s > kind of networks and provider better troubleshooting. > > > > > > > > > > > > Another observation is today more and more implementations have > adopted packet loss repair methods to improve media delivery. > > > > > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > > > > > > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC36= 11 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > > > > > Comments and suggestions? > > > > > > > > > > > > -Qin > > > > > > > > > > > > > > > > > > > > > > > > --001a114dd1de2ba37805548305a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, with most streams becoming encrypted, in-network mon= itoring have to be mostly heuristics based. Whether that is something to be= specified, this list can discuss it I think.

On Mon, Jul 17, 2017 at 8:54 PM, Mirja K= =C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
I believe the problem that is ad= dressed with this proposals is actually assessing streaming quality from th= e outside/network if you don=E2=80=99t have access to do the measurement on= the endpoint in the app. Not saying that we need or should do this work bu= t that=E2=80=99s why this might be relevant to transport as well as apps.


> Am 17.07.2017 um 14:50 schrieb Ali C. Begen <ali.begen@networked.me= dia>:
>
>
>
> On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch= > wrote:
> This is the area list, not a wg; we are not working on any document. T= he purpose of announcing this work here is to figure if there is any intere= sted in this work and if so where it should be done.
>
> I know this is an area list, my comment was not specific to any wg. St= reaming with TCP has a lot more to do at the app layer (actually in the app= lication itself) rather than the transport layer. So, this topic does not b= elong in here at all IMO.
>
> -acbegen
>
>
>
> > Am 17.07.2017 um 14:16 schrieb Ali C. Begen <ali.begen@network= ed.media>:
> >
> > Well, I believe you wanna come up with some metrics for streaming= video over http and want to extend MDI for that. Well, MDI was not designe= d for that at all, so extending it in that direction is not a good idea. Fu= rther, there is already tons of work other organizations have done to colle= ct metrics for streaming over HTTP. Just look at what others did already, m= peg, dash-if, SVA and now almost all the existing work is being collected a= nd becoming a single common spec out of CTA. I honestly don't think thi= s WG should work on this given the amount of existing and ongoing work.
> >
> > -acbegen
> >
> > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:<= br> > > Hi Ali,
> >
> >
> >
> > That=E2=80=99s one part that MDI could not do, and we hope some n= ew metrics could be used, which is the intention of this work.
> >
> >
> >
> > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in m= iddle devices like routers, to implement them, e.g., post-repair metrics, w= hich will need the devices to have the ability to decode and apply FEC repa= ir mechanisms. So that=E2=80=99s why we need some ways like MDI, easy to ca= lculate and be implemented in the network without having to be a RTP entity= or TCP proxy.
> >
> >
> >
> > BR,
> >
> > Rachel
> >
> >
> >
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Ali C. Begen
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817= =E6=97=A5 19:31
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
> > =E6=8A=84=E9=80=81: tsv-area= @ietf.org
> > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising= RFC4445 or make RFC4445bis
> >
> >
> >
> > You wanna use MDI to measure media delivery over TCP?
> >
> >
> >
> > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu <bill.wu@huawei.com> wrote:
> >
> > We have customers using MDI to address new needs, such as wifi pe= rformance measurement MDI falls short when measuring delivery of streaming = media over tcp, that is why we think it should be extended. Yes, rtcp XR ha= s its value. But I think they could be complimentary.
> >
> > Sent from HUAWEI AnyOffice
> >
> > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen
> >
> > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu;
> >
> > =E6=8A=84=E9=80=81=EF=BC=9A = tsv-area@ietf.org; =E9=83=91=E8=BE=89;
> >
> > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or = make RFC4445bis
> >
> > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07
> >
> >
> >
> > I am really curious about who is using MDI anymore. Can you share= data if you have it? RTCP XR is still extensively used and for non-RTP, it= is a mixed of several things.
> >
> >
> >
> > -acbegen
> >
> >
> >
> > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.com> wrote:
> >
> > Hi, All:
> >
> > We like to get a sense of this idea, more than 10 years ago, at t= he time of RFC4445 writing,
> >
> > The popularity of delivery of streaming media over packet swtiche= d network has just began,
> >
> > not all implementations support QoS methods to improve media deli= very. Many service
> >
> > delivery systems may compose the network with QoS support or with= out QoS support. This add difficulty on characterizing dynamic behavior of = the network.
> >
> >
> >
> > 10 years have passed, we see most of widely deployed implemention= s have adopted various different QoS mechanisms
> >
> > such as diffserv Intserv, Traffic Engineering, providing QoS guar= antee to improve delivery of media streaming,
> >
> > especially for time senestive or loss senstive application become= a must; Therefore we see a lot of value of MDI defined in RFC4445 since it= provide s a handy diagnostic tool for operators and service providers to m= easure the peformance of the network carrying streaming media and quickly i= dentify fault in the network.
> >
> >
> >
> > Today we also see many service providers begain to offer on deman= d streaming media service, many operator deployed CDN in the last mile to p= rovide better SLA, or provide hybrid TV service, in addition more and more = real time application not limited to IPTV application, VOIP application hav= e been developed,network monitoring and network troubleshooting began more = and more complicated and costy. We hear a lot of operators get hurted and w= ant to have a common tool to help them to measure performance in this kind = of networks and provider better troubleshooting.
> >
> >
> >
> > Another observation is today more and more implementations have a= dopted packet loss repair methods to improve media delivery.
> >
> > However MDI defined in RFC4445 doesn't take into acount of va= rious different packet loss repair mechanims, in addition, RFC4445 is only = designed for monitoring MPEG Transport Stream (TS) packets over UDP and fal= l short to addressing needs in hybrid senarios or on demand streaming media= scenarios.
> >
> >
> >
> > In addition, we see at the time of RFC4445 publication, IESG does= n't recommend this standard, mostly becos RFC4445 doesn't define co= mplete Metric and clarify the relationship with existing IETF work such as = RFC3611 and RFC3933, I am wondering if it is a good idea to revise RFC4445 = to address IESG concern today and in addition fill new needs in today's= service deployment.
> >
> > Comments and suggestions?
> >
> >
> >
> > -Qin
> >
> >
> >
> >
> >
> >
>
>


--001a114dd1de2ba37805548305a7-- From nobody Mon Jul 17 06:04:25 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31480131B83 for ; Mon, 17 Jul 2017 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 SL7VXocfFvrW for ; Mon, 17 Jul 2017 06:04:19 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 A9829131B79 for ; Mon, 17 Jul 2017 06:04:17 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id w187so16821910ybc.0 for ; Mon, 17 Jul 2017 06:04:17 -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=ZrIYphsKJXKpS+PhYzOefC6KVR/itR0sdMZ8a76sOq8=; b=l3lh1p5Nb1J5GtFoHg0NeVhdRQedojT6MMWJDSEoC9+48A6Pyj+6GLQGPhF0MNRH+G H+zxtyqfbLqqRlfTLRAoVMrDc3KF7yQlsMhSpk5McFXCDKq2FL07YaT4y3x0KO2VHIYS 9Uf1iJ4tGAeNF0VoLgf2bnO7BK3Y61RcTQWkElv43qoFJ2t9iaETl7DXsxElhUoOryVY ThpT8dFMJb0Y6tG/ojh8l5oWTgy+Wpip5Uu86Yg3H2B0/qbiCT+m3KCO+DVq6z+pPJg8 2q20qwCb3rheiKWoaf4pg9K8lzxpB/RKCkq4bOsf6Ie0oIvXOzVVoKfYrjpziffkBaoR hTHw== 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=ZrIYphsKJXKpS+PhYzOefC6KVR/itR0sdMZ8a76sOq8=; b=j8wkaUuRZFoQnX/1KULOD+2un37CepbKU+cEum5r0cAvQtWDLryiCtFPqdoFjI7Vpq eFXaCJ1qLEsltT9fjcFsHaiqUU09CUZU6GqXsnhRpwrCcTt0AftFf+lbRYlb9FxxxHrr SWEfqtzZ/OJpapMOJuWp7s9pLyy5boRxICfLDlghle2fEKSfFt3P4klev9Q5PL1bna/f vtgEONplSOsGhfTHxWxlMMs/RG34ilJZrnmuHsEK9TtjN3hvt2Aq4WHjg/JF4OT60sqK jz1dqe0hUgFzhl+D4KJasTuSRYK8Kknv8BanMFk4kxObvbOtnD0ka09A/YotYl108IN/ WK3g== X-Gm-Message-State: AIVw113xEXbtya2XMD+P2IH30tnq8sciNOFJtYsjVVEr7ygMEv65lGX1 w069fEAzHmp9soLdEhy4pMYPhm+2bQ== X-Received: by 10.37.98.87 with SMTP id w84mr17651375ybb.83.1500296656580; Mon, 17 Jul 2017 06:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.101 with HTTP; Mon, 17 Jul 2017 06:04:16 -0700 (PDT) In-Reply-To: <8FB9DA49-55A2-46DE-A56A-FACD7C5114D7@tik.ee.ethz.ch> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4FDE67@nkgeml513-mbx.china.huawei.com> <714875C9-4AF9-41CA-8F26-B4D48CE20892@tik.ee.ethz.ch> <8FB9DA49-55A2-46DE-A56A-FACD7C5114D7@tik.ee.ethz.ch> From: Spencer Dawkins at IETF Date: Mon, 17 Jul 2017 15:04:16 +0200 Message-ID: Subject: Re: Proposal for revising RFC4445 or make RFC4445bis To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "Ali C. Begen" , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary="001a1142e95445f86605548309c8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:04:22 -0000 --001a1142e95445f86605548309c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ... On Mon, Jul 17, 2017 at 2:54 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > I believe the problem that is addressed with this proposals is actually > assessing streaming quality from the outside/network if you don=E2=80=99t= have > access to do the measurement on the endpoint in the app. Not saying that = we > need or should do this work but that=E2=80=99s why this might be relevant= to > transport as well as apps. > ... and thanks to you all, for the feedback :-) Spencer > > > > Am 17.07.2017 um 14:50 schrieb Ali C. Begen = : > > > > > > > > On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > This is the area list, not a wg; we are not working on any document. Th= e > purpose of announcing this work here is to figure if there is any > interested in this work and if so where it should be done. > > > > I know this is an area list, my comment was not specific to any wg. > Streaming with TCP has a lot more to do at the app layer (actually in the > application itself) rather than the transport layer. So, this topic does > not belong in here at all IMO. > > > > -acbegen > > > > > > > > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen >: > > > > > > Well, I believe you wanna come up with some metrics for streaming > video over http and want to extend MDI for that. Well, MDI was not design= ed > for that at all, so extending it in that direction is not a good idea. > Further, there is already tons of work other organizations have done to > collect metrics for streaming over HTTP. Just look at what others did > already, mpeg, dash-if, SVA and now almost all the existing work is being > collected and becoming a single common spec out of CTA. I honestly don't > think this WG should work on this given the amount of existing and ongoin= g > work. > > > > > > -acbegen > > > > > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) < > rachel.huang@huawei.com> wrote: > > > Hi Ali, > > > > > > > > > > > > That=E2=80=99s one part that MDI could not do, and we hope some new m= etrics > could be used, which is the intention of this work. > > > > > > > > > > > > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in middl= e devices > like routers, to implement them, e.g., post-repair metrics, which will ne= ed > the devices to have the ability to decode and apply FEC repair mechanisms= . > So that=E2=80=99s why we need some ways like MDI, easy to calculate and b= e > implemented in the network without having to be a RTP entity or TCP proxy= . > > > > > > > > > > > > BR, > > > > > > Rachel > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Ali C. Begen > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817=E6=97= =A5 19:31 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > > > =E6=8A=84=E9=80=81: tsv-area@ietf.org > > > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising RFC= 4445 or make RFC4445bis > > > > > > > > > > > > You wanna use MDI to measure media delivery over TCP? > > > > > > > > > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu wrote: > > > > > > We have customers using MDI to address new needs, such as wifi > performance measurement MDI falls short when measuring delivery of > streaming media over tcp, that is why we think it should be extended. Yes= , > rtcp XR has its value. But I think they could be complimentary. > > > > > > Sent from HUAWEI AnyOffice > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen > > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu; > > > > > > =E6=8A=84=E9=80=81=EF=BC=9A tsv-area@ietf.org; =E9=83=91=E8=BE=89; > > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or make= RFC4445bis > > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07 > > > > > > > > > > > > I am really curious about who is using MDI anymore. Can you share dat= a > if you have it? RTCP XR is still extensively used and for non-RTP, it is = a > mixed of several things. > > > > > > > > > > > > -acbegen > > > > > > > > > > > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu wrote: > > > > > > Hi, All: > > > > > > We like to get a sense of this idea, more than 10 years ago, at the > time of RFC4445 writing, > > > > > > The popularity of delivery of streaming media over packet swtiched > network has just began, > > > > > > not all implementations support QoS methods to improve media delivery= . > Many service > > > > > > delivery systems may compose the network with QoS support or without > QoS support. This add difficulty on characterizing dynamic behavior of th= e > network. > > > > > > > > > > > > 10 years have passed, we see most of widely deployed implementions > have adopted various different QoS mechanisms > > > > > > such as diffserv Intserv, Traffic Engineering, providing QoS guarante= e > to improve delivery of media streaming, > > > > > > especially for time senestive or loss senstive application become a > must; Therefore we see a lot of value of MDI defined in RFC4445 since it > provide s a handy diagnostic tool for operators and service providers to > measure the peformance of the network carrying streaming media and quickl= y > identify fault in the network. > > > > > > > > > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and mo= re > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurte= d > and want to have a common tool to help them to measure performance in thi= s > kind of networks and provider better troubleshooting. > > > > > > > > > > > > Another observation is today more and more implementations have > adopted packet loss repair methods to improve media delivery. > > > > > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > > > > > > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC36= 11 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > > > > > Comments and suggestions? > > > > > > > > > > > > -Qin > > > > > > > > > > > > > > > > > > > > > > > > --001a1142e95445f86605548309c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
...=C2=A0

On Mon, Jul 17, 2017 at 2:54 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
I believe the problem that is addressed with this proposal= s is actually assessing streaming quality from the outside/network if you d= on=E2=80=99t have access to do the measurement on the endpoint in the app. = Not saying that we need or should do this work but that=E2=80=99s why this = might be relevant to transport as well as apps.

... and thanks to you all, for the feedback :-)

Spencer
=C2=A0


> Am 17.07.2017 um 14:50 schrieb Ali C. Begen <ali.begen@networked.me= dia>:
>
>
>
> On Mon, Jul 17, 2017 at 8:43 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch= > wrote:
> This is the area list, not a wg; we are not working on any document. T= he purpose of announcing this work here is to figure if there is any intere= sted in this work and if so where it should be done.
>
> I know this is an area list, my comment was not specific to any wg. St= reaming with TCP has a lot more to do at the app layer (actually in the app= lication itself) rather than the transport layer. So, this topic does not b= elong in here at all IMO.
>
> -acbegen
>
>
>
> > Am 17.07.2017 um 14:16 schrieb Ali C. Begen <ali.begen@network= ed.media>:
> >
> > Well, I believe you wanna come up with some metrics for streaming= video over http and want to extend MDI for that. Well, MDI was not designe= d for that at all, so extending it in that direction is not a good idea. Fu= rther, there is already tons of work other organizations have done to colle= ct metrics for streaming over HTTP. Just look at what others did already, m= peg, dash-if, SVA and now almost all the existing work is being collected a= nd becoming a single common spec out of CTA. I honestly don't think thi= s WG should work on this given the amount of existing and ongoing work.
> >
> > -acbegen
> >
> > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:<= br> > > Hi Ali,
> >
> >
> >
> > That=E2=80=99s one part that MDI could not do, and we hope some n= ew metrics could be used, which is the intention of this work.
> >
> >
> >
> > As for the RTCP XR metrics, it=E2=80=99s not quite realistic in m= iddle devices like routers, to implement them, e.g., post-repair metrics, w= hich will need the devices to have the ability to decode and apply FEC repa= ir mechanisms. So that=E2=80=99s why we need some ways like MDI, easy to ca= lculate and be implemented in the network without having to be a RTP entity= or TCP proxy.
> >
> >
> >
> > BR,
> >
> > Rachel
> >
> >
> >
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: tsv-area [mailto:tsv-area-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Ali C. Begen
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=8817= =E6=97=A5 19:31
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
> > =E6=8A=84=E9=80=81: tsv-area= @ietf.org
> > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Proposal for revising= RFC4445 or make RFC4445bis
> >
> >
> >
> > You wanna use MDI to measure media delivery over TCP?
> >
> >
> >
> > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu <bill.wu@huawei.com> wrote:
> >
> > We have customers using MDI to address new needs, such as wifi pe= rformance measurement MDI falls short when measuring delivery of streaming = media over tcp, that is why we think it should be extended. Yes, rtcp XR ha= s its value. But I think they could be complimentary.
> >
> > Sent from HUAWEI AnyOffice
> >
> > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Ali C. Begen
> >
> > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu;
> >
> > =E6=8A=84=E9=80=81=EF=BC=9A = tsv-area@ietf.org; =E9=83=91=E8=BE=89;
> >
> > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: Proposal for revising RFC4445 or = make RFC4445bis
> >
> > =E6=97=B6=E9=97=B4=EF=BC=9A 2017-07-17 13:02:07
> >
> >
> >
> > I am really curious about who is using MDI anymore. Can you share= data if you have it? RTCP XR is still extensively used and for non-RTP, it= is a mixed of several things.
> >
> >
> >
> > -acbegen
> >
> >
> >
> > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <bill.wu@huawei.com> wrote:
> >
> > Hi, All:
> >
> > We like to get a sense of this idea, more than 10 years ago, at t= he time of RFC4445 writing,
> >
> > The popularity of delivery of streaming media over packet swtiche= d network has just began,
> >
> > not all implementations support QoS methods to improve media deli= very. Many service
> >
> > delivery systems may compose the network with QoS support or with= out QoS support. This add difficulty on characterizing dynamic behavior of = the network.
> >
> >
> >
> > 10 years have passed, we see most of widely deployed implemention= s have adopted various different QoS mechanisms
> >
> > such as diffserv Intserv, Traffic Engineering, providing QoS guar= antee to improve delivery of media streaming,
> >
> > especially for time senestive or loss senstive application become= a must; Therefore we see a lot of value of MDI defined in RFC4445 since it= provide s a handy diagnostic tool for operators and service providers to m= easure the peformance of the network carrying streaming media and quickly i= dentify fault in the network.
> >
> >
> >
> > Today we also see many service providers begain to offer on deman= d streaming media service, many operator deployed CDN in the last mile to p= rovide better SLA, or provide hybrid TV service, in addition more and more = real time application not limited to IPTV application, VOIP application hav= e been developed,network monitoring and network troubleshooting began more = and more complicated and costy. We hear a lot of operators get hurted and w= ant to have a common tool to help them to measure performance in this kind = of networks and provider better troubleshooting.
> >
> >
> >
> > Another observation is today more and more implementations have a= dopted packet loss repair methods to improve media delivery.
> >
> > However MDI defined in RFC4445 doesn't take into acount of va= rious different packet loss repair mechanims, in addition, RFC4445 is only = designed for monitoring MPEG Transport Stream (TS) packets over UDP and fal= l short to addressing needs in hybrid senarios or on demand streaming media= scenarios.
> >
> >
> >
> > In addition, we see at the time of RFC4445 publication, IESG does= n't recommend this standard, mostly becos RFC4445 doesn't define co= mplete Metric and clarify the relationship with existing IETF work such as = RFC3611 and RFC3933, I am wondering if it is a good idea to revise RFC4445 = to address IESG concern today and in addition fill new needs in today's= service deployment.
> >
> > Comments and suggestions?
> >
> >
> >
> > -Qin
> >
> >
> >
> >
> >
> >
>
>


--001a1142e95445f86605548309c8-- From nobody Tue Jul 18 15:22:15 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC7128DE5 for ; Tue, 18 Jul 2017 15:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 QTxmIyoDf9EJ for ; Tue, 18 Jul 2017 15:22:12 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 E9EDE126B71 for ; Tue, 18 Jul 2017 15:22:11 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w4so47757302wrb.2 for ; Tue, 18 Jul 2017 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=eLDhDxMhlqBhA8R4eRxL4scO1mhO2hRM5DuIia0Z4uM=; b=Vx1cOKt3HJp+7jGEQcsf92R4t8T94Szu/s2yVrDSUpYVUxNi7n8Vu0tHmimuSjoXRM 6wLj/6DLM8Ro686D2qRt6RWB+/qjNG688UlQ16h7v3G7SPArNM6R26NkUsTsjiiVHn+H db/Q4YmUoDxBgg6UeSYJrUtfvzi8vo0vYxTRwLC0NWQfurRJU4Qtaco5rXt0SFvN/LXV DwfCXhSF7NMvAsLAYEQgata7S7c8rLV0/jc7aRX4wlm7ir7Ww0CB+uS1oCe5BweuwF4u WcYypt+EDkMJ3HiGNfF1GxuxXp6cr5vRebZgtezbje0e/riMOllIJp+m4VymA9YftOvd Rmiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=eLDhDxMhlqBhA8R4eRxL4scO1mhO2hRM5DuIia0Z4uM=; b=iUEH2hAjgepm7xs4QWtghCsXtUcNZGWTYEMnUNmzABGVXlXpl8uK+7qkUOasmEkHFF DlFw06D3ycwIcdEqnGEeyHJjrVucOLrhW1KxW0dBORAShtHqBN057BT0G6V9IHL18gsK vYumSARJQkvVUtaZYy4c5BDE8u85h65/iK2rCIlrgWOiyLASnvDOGQqkwl5hT0bUbcE2 OlO07cvlJSkQOn8kJRXoLhJVQ0D9mQhmRdY2T2jV932s55kexaMWbtGoLjQfm8TAtJjI ck3U+S667+WfC0uTeew8UaHK7dBAgC0UTjtKovz1eCxli4T7w01CSt0GqueTPwyE1l/W fZfw== X-Gm-Message-State: AIVw112y5gambrunwLLgw1AVx4jA+XFjRkuyqV7H0MvH7VN+NwwtmWSf 31NsQ8Pz01NMyF7faA/Nd1pdv/1Wt170SzIr1lKJQoOMsQs1xvHiVwt/qm85lMpWN7dq9J/+wcc = X-Received: by 10.28.139.145 with SMTP id n139mr3652583wmd.53.1500416530214; Tue, 18 Jul 2017 15:22:10 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y12sm5272348wrb.39.2017.07.18.15.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 15:22:09 -0700 (PDT) To: Internet Area , tsv-area@ietf.org From: Olivier Bonaventure Subject: Middleboxes to aid the deployment of MPTCP Message-ID: Date: Wed, 19 Jul 2017 00:22:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:22:14 -0000 Hello, The design of Multipath TCP (RFC6824) has been heavily influenced by various types of interferences caused by middleboxes. These problems have been solved and the protocol is deployed at a large scale by several smartphone vendors. One of the remaining items of the charter of the MPTCP working group is to "...explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled." One of the use cases for those MPTCP-aware middleboxes are the smartphones equipped with WiFi and cellular interfaces. Today, there are very few servers that support Multipath TCP and smartphones would benefit from using MPTCP over the cellular and WiFi network to a middlebox that would convert MPTCP into TCP and vice-versa. The working group has discussed this issue several times and today we have presented a new design that supports the creation of such functions to convert MPTCP connections into TCP connections and vice versa. The design was done with MPTCP in mind, but the proposed solution could be more generic and applied to other use cases than MPTCP. The draft that describes the new design is available via: https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt Mirja Kuehlewind suggested to send the document on the int-area and tsv-area mailing lists to see whether other working groups could be interested by this approach. I'm available this week in Prague if someone wants to discuss. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Tue Jul 18 15:28:32 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672A8128BA2; Tue, 18 Jul 2017 15:28:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 TTbRWB389TEJ; Tue, 18 Jul 2017 15:28:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 15E79128990; Tue, 18 Jul 2017 15:28:30 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6IMRrJ8012313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 15:27:55 -0700 (PDT) Subject: Re: Transport attention to 6lo draft on fragmentation To: Spencer Dawkins at IETF , "tsv-area@ietf.org >> tsv-area@ietf.org" Cc: 6lo-chairs@ietf.org, Mirja Kuehlewind , Suresh Krishnan References: From: Joe Touch Message-ID: <9940fb85-9dd4-a59d-9597-fd84c36b93e5@isi.edu> Date: Tue, 18 Jul 2017 15:27:51 -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: Content-Type: multipart/alternative; boundary="------------32AB1E9518C55CFD1E46E3BA" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:28:31 -0000 This is a multi-part message in MIME format. --------------32AB1E9518C55CFD1E46E3BA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Some quick notes: RFC1191 is for IPv4. The RFC for IPv6 PMTUD has just been revised (8201), and includes clarified and corrected terms for the various types of MTU that need to be considered. It might also be useful to look at draft-ietf-intarea-tunnels and its terminology for MTU values, esp. at the link layer and considering link fragmentation and reassembly. RFC5405 similarly is out of date. The authors may want to consult https://www.isi.edu/touch/tools/rfc-what-i-mean.html (it won't catch citing RFC8201 instead of RFC1191 because the former is IPv6 vs the latter for IPv4, rather than "obsoleting" the other). The issue of overlapping fragments should be addressed (permitted or prohibited). The issue of needing to have the IPv6 header should be more clear about this also necessarily including any HBH EHs, because it would be inappropriate to route solely on the base IPv6 header if there are applicable HBH EHs that need to be considered. I'm not sure about the conclusion of the security considerations - esp. given the MAC mechanism in the preceding section, which appears to create an attack vector (AFAICT). FWIW. Joe On 7/12/2017 12:23 PM, Spencer Dawkins at IETF wrote: > Dear Transporters, > > Gab Montenegro, co-chair for 6lo, let me know that 6lo is considering > adoption of a draft about how 6lowpan forwards fragments. > > The draft > is https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments > . > > Gab asked about getting TSV eyes on this draft, to help inform the > working groups conversation about adoption. > > 6lo is scheduled for 15:50-17:50 on Tuesday Afternoon (session II), > opposite MPTCP, but if you're available, informed, and opinionated, > Gab says the working group has time to discuss adoption at the end of > their agenda, and welcomes input. > > Thanks! > > Spencer, who also plans to attend, but is not the guiding light in TSV > for fragmentation issues ... --------------32AB1E9518C55CFD1E46E3BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Some quick notes:

RFC1191 is for IPv4. The RFC for IPv6 PMTUD has just been revised (8201), and includes clarified and corrected terms for the various types of MTU that need to be considered.

It might also be useful to look at draft-ietf-intarea-tunnels and its terminology for MTU values, esp. at the link layer and considering link fragmentation and reassembly.

RFC5405 similarly is out of date. The authors may want to consult https://www.isi.edu/touch/tools/rfc-what-i-mean.html

(it won't catch citing RFC8201 instead of RFC1191 because the former is IPv6 vs the latter for IPv4, rather than "obsoleting" the other).

The issue of overlapping fragments should be addressed (permitted or prohibited).

The issue of needing to have the IPv6 header should be more clear about this also necessarily including any HBH EHs, because it would be inappropriate to route solely on the base IPv6 header if there are applicable HBH EHs that need to be considered.

I'm not sure about the conclusion of the security considerations - esp. given the MAC mechanism in the preceding section, which appears to create an attack vector (AFAICT).

FWIW.

Joe


On 7/12/2017 12:23 PM, Spencer Dawkins at IETF wrote:
Dear Transporters,

Gab Montenegro, co-chair for 6lo, let me know that 6lo is considering adoption of a draft about how 6lowpan forwards fragments. 


Gab asked about getting TSV eyes on this draft, to help inform the working groups conversation about adoption.

6lo is scheduled for 15:50-17:50 on Tuesday Afternoon (session II), opposite MPTCP, but if you're available, informed, and opinionated, Gab says the working group has time to discuss adoption at the end of their agenda, and welcomes input.

Thanks!

Spencer, who also plans to attend, but is not the guiding light in TSV for fragmentation issues ...

--------------32AB1E9518C55CFD1E46E3BA-- From nobody Tue Jul 18 15:32:36 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8D129B2A; Tue, 18 Jul 2017 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 gxoRpWKOg9T7; Tue, 18 Jul 2017 15:32:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 B3E21129AD7; Tue, 18 Jul 2017 15:32:26 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6IMVl5m013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 15:31:50 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: From: Joe Touch Message-ID: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> Date: Tue, 18 Jul 2017 15:31:45 -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: Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:32:29 -0000 Hi, all, I've noted this before, but to share with other areas: Although I'm not averse to middleboxes as optional optimizations, I find the proposed mechanisms aren't quite optional -- they inject option information into the SYN data. That information would poison a connection to a legacy receiver if (more to the point, when) that info isn't removed by a proxy upstream of the receiver. TCP must be E2E and fall back to legacy endpoints without a reconnection attempt, as required by RFC793. These aren't generic solutions; they're attacks on a TCP connection, IMO. Joe On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: > The working group has discussed this issue several times and today we > have presented a new design that supports the creation of such > functions to convert MPTCP connections into TCP connections and vice > versa. The design was done with MPTCP in mind, but the proposed > solution could be more generic and applied to other use cases than > MPTCP. The draft that describes the new design is available via: > > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt > > > Mirja Kuehlewind suggested to send the document on the int-area and > tsv-area mailing lists to see whether other working groups could be > interested by this approach. From nobody Tue Jul 18 15:43:25 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC64126BFD for ; Tue, 18 Jul 2017 15:43:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 leOo6Zo53mE3 for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 974D0126B71 for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v105so19142557wrb.0 for ; Tue, 18 Jul 2017 15:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KLSif0XK7/faqBxRJcEtryxQWP/AV+5zl+sUVqtRQ2k=; b=h9tL9dH+scvnnLOmlieh/gnx1Zthve/NVkoWSyp4GturHbvzUUKHi7qkWXNUj8J8z2 nt/7hspRwzEYcgHqOESQek9/R6lWQb0v2xGg2dguUGfLjo4CTzEovuEEoag1am5U+lkM 1HRJGlQSGCqHL/is4zYe33pAwEt1pI24YX/RspcZvZO/NI58V+vaUhUbO6iYMBUZqQXz p4J4gt09BclUd9AiOHLrf00a/0FbUgr7peNRGPtJrY0snfJXdyHoQIu6jMFc31fLGJZB g+YhK+h4PeJfqHJz1x6H+Cxp8EXyN8s9X7yLfHMeGRAlHW4NMaids0lzk62oSzvkfqAi MIEQ== 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=KLSif0XK7/faqBxRJcEtryxQWP/AV+5zl+sUVqtRQ2k=; b=gOIWkNxvymcjlCC8OSkcns8tVEyIeJjbR2ZHDhW8qdbOk4/WPz3qU0fnbdUDe3O+7S jQlLumY9MojC0euO9TGwKm3LK/ZdDlR1A/ZAPJlpbknPF6GboQbcYr4yJmfVSGC5JYeu SKxl3pMxK9jBfwyc79TMqkwlpm8LHKI22kBKNY0U7yXePUbzTOQoi3A88kSqSz9X7T5r Mxb3gfyWwFH7uWNVFs42BjufIxuvXcrVxsDbi2T42I3IUbqRbSK6a0344vIq2cH0LP78 /sQd8pCurdDOaJQ42a0xctFdjzv5wUFgS2marSD+FBL9f1TqTB7e6CpeahoedoXO87jH Bfng== X-Gm-Message-State: AIVw1126TRqXvd6RpN+3m1O5F/yvXkJJY4Ugi//1p5cDrFaGgxUJlSyQ 88ITVNVM10EEGcQG0yIgxi4jxKYO2lOp X-Received: by 10.223.135.112 with SMTP id 45mr2475782wrz.133.1500417795030; Tue, 18 Jul 2017 15:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Tue, 18 Jul 2017 15:43:14 -0700 (PDT) In-Reply-To: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Tom Herbert Date: Tue, 18 Jul 2017 15:43:14 -0700 Message-ID: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: Joe Touch Cc: Olivier Bonaventure , Internet Area , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:43:20 -0000 On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: > Hi, all, > > I've noted this before, but to share with other areas: > > Although I'm not averse to middleboxes as optional optimizations, I find > the proposed mechanisms aren't quite optional -- they inject option > information into the SYN data. That information would poison a > connection to a legacy receiver if (more to the point, when) that info > isn't removed by a proxy upstream of the receiver. > > TCP must be E2E and fall back to legacy endpoints without a reconnection > attempt, as required by RFC793. > > These aren't generic solutions; they're attacks on a TCP connection, IMO. > I agree. This seems be akin to stateful firewalls model that impose artificial requirements on networking (like every TCP packet for a connection must got through some middlebox or the connection is dropped). We need to move things back to E2E semantics for transport protocols-- nodes that try to maintain transport state in the network should be considered the problem not the solution! Tom > Joe > > > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: >> The working group has discussed this issue several times and today we >> have presented a new design that supports the creation of such >> functions to convert MPTCP connections into TCP connections and vice >> versa. The design was done with MPTCP in mind, but the proposed >> solution could be more generic and applied to other use cases than >> MPTCP. The draft that describes the new design is available via: >> >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt >> >> >> Mirja Kuehlewind suggested to send the document on the int-area and >> tsv-area mailing lists to see whether other working groups could be >> interested by this approach. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jul 18 15:50:07 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23013170E; Tue, 18 Jul 2017 15:49:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 CPLLlJxf5jqp; Tue, 18 Jul 2017 15:49:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 112AB126C23; Tue, 18 Jul 2017 15:49:58 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6IMnhqp002758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 15:49:44 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: Tom Herbert Cc: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Joe Touch Message-ID: Date: Tue, 18 Jul 2017 15:49:41 -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: Content-Type: multipart/alternative; boundary="------------04A9FF8E2835E89144EEC472" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:49:59 -0000 This is a multi-part message in MIME format. --------------04A9FF8E2835E89144EEC472 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/18/2017 3:43 PM, Tom Herbert wrote: >> TCP must be E2E and fall back to legacy endpoints without a reconnection >> attempt, as required by RFC793. >> >> These aren't generic solutions; they're attacks on a TCP connection, IMO. >> > I agree. This seems be akin to stateful firewalls model that impose > artificial requirements on networking (like every TCP packet for a > connection must got through some middlebox or the connection is > dropped). We need to move things back to E2E semantics for transport > protocols-- nodes that try to maintain transport state in the network > should be considered the problem not the solution! I'm a little less concerned with state in the network (link layers have state too - both hard and soft). My primary concern is this as an attack on TCP - or its equivalence to an attack. I though the point of true TCP and lower layer security was to prevent such attacks. Perhaps that's why I consider TLS and TCPcrypt to be so badly misnamed. They don't protect *TCP* at all. Joe --------------04A9FF8E2835E89144EEC472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/18/2017 3:43 PM, Tom Herbert wrote:
TCP must be E2E and fall back to legacy endpoints without a reconnection
attempt, as required by RFC793.

These aren't generic solutions; they're attacks on a TCP connection, IMO.


I agree. This seems be akin to stateful firewalls model that impose
artificial requirements on networking (like every TCP packet for a
connection must got through some middlebox or the connection is
dropped). We need to move things back to E2E semantics for transport
protocols-- nodes that try to maintain transport state in the network
should be considered the problem not the solution!
I'm a little less concerned with state in the network (link layers have state too - both hard and soft).

My primary concern is this as an attack on TCP - or its equivalence to an attack. I though the point of true TCP and lower layer security was to prevent such attacks.

Perhaps that's why I consider TLS and TCPcrypt to be so badly misnamed. They don't protect *TCP* at all.

Joe

--------------04A9FF8E2835E89144EEC472-- From nobody Tue Jul 18 16:06:09 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F699126BF3 for ; Tue, 18 Jul 2017 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=tessares-net.20150623.gappssmtp.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 07mGznPaBiEq for ; Tue, 18 Jul 2017 16:05:59 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 5C9E4126BFD for ; Tue, 18 Jul 2017 16:05:59 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y43so49807311wrd.3 for ; Tue, 18 Jul 2017 16:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p/4sX0C814XIEWHiDv2dbTr9hXswMCG+v7fCwOzFiz0=; b=rdr4M6AiO2EfN2m/hNAlnRqwaSb+qDwpICjxaV2stK7/XLUIBRfyXEniCkC5Je8Hma UteWDoWcmF+QDNgU211X8MJ37zON3C8p7Copnk1rnnY8HtgcOxPcahqU+HCKGDwe4KuM KgLJ+qF5D6KaCiWzMUUJOvdhYtYl4lalW0I+LSocP5vVVQiq3y+1wjIudY1ZHdCqZEWE KihrwqGg4dBG5o2uSj8Yl1UK3sRAo9usm7W1tb0kTtMp9dmSP0j3Fpt+LuFTH69pHGMV igURH99eWupnVRAA5VqnBG+Eqc4HPWvvDysWs0AGa0Pm0D+ES9DBYIYUfx7gKrXnaXrS D6pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=p/4sX0C814XIEWHiDv2dbTr9hXswMCG+v7fCwOzFiz0=; b=YFgZ5Duk7IjmjuecxKNVUgSxUQikrdiV/1Gc3KKAR2BnzMf9MZgOJ+YzbU+dpxbLwk lqMTCYEzRNp7HVw2fIP0d9Dg+h3YyXIY0jT/AEwUPyqahl1GOX6JeaJeeWRtwiDT/AIk XgVmMJQolFONa37pdObXoYxZE13UwXpBF4Wcft0FgcPDrMWDIWiP+vwbQpLmSA3B5nnb 6AdZ8Jclxr6dI93bZN0t6mUGhtZytR3VaCE0y/NesxiQu5IM/HAQkeG/aIdn1dR5LtND LHYYjUoXEl5lAH0o6gU4kfyeNVjn6VMz3zHncztqvU742A+DrpGsBft93QEPZHB/11nl cMKg== X-Gm-Message-State: AIVw110IcgEfO+KfzXqewk4orLXFwJzwrbe4nik180Q2kWo3ZVd921wO EC/ostgvkBwTzWPsGCKr+4+wghh5It1i3i9fstp62wU02L09zQgNsFfwNQXlW3yiPyJ9KdtCQnQ = X-Received: by 10.28.17.11 with SMTP id 11mr3170628wmr.109.1500419157720; Tue, 18 Jul 2017 16:05:57 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y84sm14811790wmg.12.2017.07.18.16.05.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 16:05:57 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> From: Olivier Bonaventure Message-ID: <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> Date: Wed, 19 Jul 2017 01:05:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:06:01 -0000 Joe, > > I've noted this before, but to share with other areas: You noted this about previous documents. The document that I mentioned describes a new design that answers several of the comments that you raised on the mptcp mailing list. > Although I'm not averse to middleboxes as optional optimizations, I find > the proposed mechanisms aren't quite optional -- they inject option > information into the SYN data. That information would poison a > connection to a legacy receiver if (more to the point, when) that info > isn't removed by a proxy upstream of the receiver. This paragraph refers to earlier documents discussed in the MPTCP working group. The new design does not inject option information into the SYN data. It works like an application layer protocol that sends messages in the SYN by using the TFO option. There is no risk of poisoning. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Tue Jul 18 16:13:17 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6112EC39; Tue, 18 Jul 2017 16:13:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 rwRw2oYd2L-F; Tue, 18 Jul 2017 16:13:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 D0674129B47; Tue, 18 Jul 2017 16:13:08 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6INCSj3025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jul 2017 16:12:28 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> From: Joe Touch Message-ID: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> Date: Tue, 18 Jul 2017 16:12:26 -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: <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> Content-Type: multipart/alternative; boundary="------------86318F3B0ED2952B9BA6D8F1" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:13:10 -0000 This is a multi-part message in MIME format. --------------86318F3B0ED2952B9BA6D8F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/18/2017 4:05 PM, Olivier Bonaventure wrote: >> Although I'm not averse to middleboxes as optional optimizations, I find >> the proposed mechanisms aren't quite optional -- they inject option >> information into the SYN data. That information would poison a >> connection to a legacy receiver if (more to the point, when) that info >> isn't removed by a proxy upstream of the receiver. > > This paragraph refers to earlier documents discussed in the MPTCP > working group. The new design does not inject option information into > the SYN data. It works like an application layer protocol that sends > messages > in the SYN by using the TFO option. There is no risk of poisoning. OK, in that case: - I'm still not averse to middleboxes that accelerate or enhance TCP - IMO, TCP always needs to be able to fall back (which should be true now) - but I remain concerned with "injection piggybacking" - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all Joe --------------86318F3B0ED2952B9BA6D8F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/18/2017 4:05 PM, Olivier Bonaventure wrote:
Although I'm not averse to middleboxes as optional optimizations, I find
the proposed mechanisms aren't quite optional -- they inject option
information into the SYN data. That information would poison a
connection to a legacy receiver if (more to the point, when) that info
isn't removed by a proxy upstream of the receiver.

This paragraph refers to earlier documents discussed in the MPTCP
working group. The new design does not inject option information into
the SYN data. It works like an application layer protocol that sends messages
in the SYN by using the TFO option. There is no risk of poisoning.

OK, in that case:
- I'm still not averse to middleboxes that accelerate or enhance TCP
- IMO, TCP always needs to be able to fall back (which should be true now)
- but I remain concerned with "injection piggybacking"
    - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection
    - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all

Joe
--------------86318F3B0ED2952B9BA6D8F1-- From nobody Tue Jul 18 23:37:50 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F71131897; Tue, 18 Jul 2017 23:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Xo5JAcyP7n_6; Tue, 18 Jul 2017 23:37:30 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC111317BB; Tue, 18 Jul 2017 23:37:27 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B57C4C05FF; Wed, 19 Jul 2017 08:37:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 7DC101A00A3; Wed, 19 Jul 2017 08:37:25 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 08:37:25 +0200 From: To: Tom Herbert , Joe Touch CC: "tsv-area@ietf.org" , Internet Area Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTABRXhChVBRjgCUaG1BH6WGredaJaCZWAgAADNgCAAKLIUA== Date: Wed, 19 Jul 2017 06:37:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:37:35 -0000 Hi Tom, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Tom Herb= ert > Envoy=E9=A0: mercredi 19 juillet 2017 00:43 > =C0=A0: Joe Touch > Cc=A0: tsv-area@ietf.org; Internet Area > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 > On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: > > Hi, all, > > > > I've noted this before, but to share with other areas: > > > > Although I'm not averse to middleboxes as optional optimizations, I fin= d > > the proposed mechanisms aren't quite optional -- they inject option > > information into the SYN data. That information would poison a > > connection to a legacy receiver if (more to the point, when) that info > > isn't removed by a proxy upstream of the receiver. > > > > TCP must be E2E and fall back to legacy endpoints without a reconnectio= n > > attempt, as required by RFC793. > > > > These aren't generic solutions; they're attacks on a TCP connection, > IMO. > > > I agree. This seems be akin to stateful firewalls model that impose > artificial requirements on networking (like every TCP packet for a > connection must got through some middlebox or the connection is > dropped). We need to move things back to E2E semantics for transport > protocols-- nodes that try to maintain transport state in the network > should be considered the problem not the solution! >=20 [Med] We would love to avoid requiring adding a function in the network to = assist devices to make use of their multiple interfaces/paths. Nevertheless= , the situation is that servers do not support MPTCP.=20 The proposed solution allows to: * elect some flows to benefit from network-assisted MPTCP while avoiding se= ssion failures. * Policies are configured to identify traffic that won't be forwarded via a= proxy * 0-RTT proxying * MPTCP can be used e2e if both end points are MPTCP-capable (that is, the = proxy is withdrawn from the path). * No interference with TCP options to be negotiated between endpoints. Do you have in mind such use cases when you referred to the "stateful firew= alls model"? > Tom >=20 > > Joe > > > > > > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: > >> The working group has discussed this issue several times and today we > >> have presented a new design that supports the creation of such > >> functions to convert MPTCP connections into TCP connections and vice > >> versa. The design was done with MPTCP in mind, but the proposed > >> solution could be more generic and applied to other use cases than > >> MPTCP. The draft that describes the new design is available via: > >> > >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp- > converters-01.txt > >> > >> > >> Mirja Kuehlewind suggested to send the document on the int-area and > >> tsv-area mailing lists to see whether other working groups could be > >> interested by this approach. > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jul 18 23:39:58 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BAD12FB9C; Tue, 18 Jul 2017 23:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 pCkUXxDrytP8; Tue, 18 Jul 2017 23:39:54 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169B912ECB4; Tue, 18 Jul 2017 23:39:54 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BACA620712; Wed, 19 Jul 2017 08:39:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 7D45D200B2; Wed, 19 Jul 2017 08:39:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 08:39:52 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTABRXhChVBRjgCUaG1BH6WGredaJaCZWAgAAJjQCAAAHRAIAAlzNA Date: Wed, 19 Jul 2017 06:39:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00EA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> In-Reply-To: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:39:56 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSW50 LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpv ZSBUb3VjaA0KRW52b3nDqSA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAwMToxMg0Kw4AgOiBP bGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtYXJlYUBpZXRmLm9yZw0KT2Jq ZXQgOiBSZTogW0ludC1hcmVhXSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2Yg TVBUQ1ANCg0KDQoNCg0KT24gNy8xOC8yMDE3IDQ6MDUgUE0sIE9saXZpZXIgQm9uYXZlbnR1cmUg d3JvdGU6DQpBbHRob3VnaCBJJ20gbm90IGF2ZXJzZSB0byBtaWRkbGVib3hlcyBhcyBvcHRpb25h bCBvcHRpbWl6YXRpb25zLCBJIGZpbmQNCnRoZSBwcm9wb3NlZCBtZWNoYW5pc21zIGFyZW4ndCBx dWl0ZSBvcHRpb25hbCAtLSB0aGV5IGluamVjdCBvcHRpb24NCmluZm9ybWF0aW9uIGludG8gdGhl IFNZTiBkYXRhLiBUaGF0IGluZm9ybWF0aW9uIHdvdWxkIHBvaXNvbiBhDQpjb25uZWN0aW9uIHRv IGEgbGVnYWN5IHJlY2VpdmVyIGlmIChtb3JlIHRvIHRoZSBwb2ludCwgd2hlbikgdGhhdCBpbmZv DQppc24ndCByZW1vdmVkIGJ5IGEgcHJveHkgdXBzdHJlYW0gb2YgdGhlIHJlY2VpdmVyLg0KDQpU aGlzIHBhcmFncmFwaCByZWZlcnMgdG8gZWFybGllciBkb2N1bWVudHMgZGlzY3Vzc2VkIGluIHRo ZSBNUFRDUA0Kd29ya2luZyBncm91cC4gVGhlIG5ldyBkZXNpZ24gZG9lcyBub3QgaW5qZWN0IG9w dGlvbiBpbmZvcm1hdGlvbiBpbnRvDQp0aGUgU1lOIGRhdGEuIEl0IHdvcmtzIGxpa2UgYW4gYXBw bGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgdGhhdCBzZW5kcyBtZXNzYWdlcw0KaW4gdGhlIFNZTiBi eSB1c2luZyB0aGUgVEZPIG9wdGlvbi4gVGhlcmUgaXMgbm8gcmlzayBvZiBwb2lzb25pbmcuDQoN Ck9LLCBpbiB0aGF0IGNhc2U6DQotIEknbSBzdGlsbCBub3QgYXZlcnNlIHRvIG1pZGRsZWJveGVz IHRoYXQgYWNjZWxlcmF0ZSBvciBlbmhhbmNlIFRDUA0KW01lZF0gVGhlIHByb3Bvc2FsIGxldmVy YWdlcyBvbiBleGlzdGluZyBJRVRGIFJGQ3MgYW5kIEJDUHMgdG8gYXNzaXN0IGVzdGFibGlzaGlu ZyBjb21tdW5pY2F0aW9ucyBvdmVyIG11bHRpcGxlIHBhdGhzIGV2ZW4gaWYgdGhlIHJlbW90ZSBz ZXJ2ZXIgaXMgbm90IE1QVENQLWNhcGFibGUuIEJUVywgd2UgaW50ZWdyYXRlZCBhbG1vc3QgYWxs IHRoZSBzdWdnZXN0aW9ucyB5b3UgbWFkZSBwcmV2aW91c2x5IChlLmcuLCB1c2UgYSBkZWRpY2F0 ZWQgc2VydmljZSBwb3J0LCBmaWd1cmUgb3V0IGhvdyB0byB1c2UgVEZPIHRvIGdldCBURk8gcGVy Zm9ybWFuY2UpLg0KDQoNCi0gSU1PLCBUQ1AgYWx3YXlzIG5lZWRzIHRvIGJlIGFibGUgdG8gZmFs bCBiYWNrICh3aGljaCBzaG91bGQgYmUgdHJ1ZSBub3cpDQpbTWVkXSBXZSBhcmUgbm90IGludGVy ZmVyaW5nIHdpdGggdGhpcy4NCg0KLSBidXQgSSByZW1haW4gY29uY2VybmVkIHdpdGggImluamVj dGlvbiBwaWdneWJhY2tpbmciDQogICAgLSBldmVuIGlmIHRoaXMgaXMgcmVzdHJpY3RlZCB0byBv cHRpb24gc3BhY2UsIGl0IGluY3JlYXNlcyB0aGUgcmlzayBvZiBkYW1hZ2luZyBhbiBvdGhlcndp c2Ugd29ya2luZyBjb25uZWN0aW9uDQpbTWVkXSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB5b3VyIHJl ZmVyZW5jZSB0byB0aGUgb3B0aW9uIHNwYWNlLg0KDQogICAgLSBpdCBmbGllcyBpbiB0aGUgZmFj ZSBvZiBUQ1AgYmVpbmcgRTJFLCBhbmQgd29uJ3Qgd29yayB3aXRoIFRDUC1BTyBvciBJUHNlYywg d2hpY2ggSU1PIG1lYW5zIGl0IGNhbid0IGJlIGNvbnNpZGVyZWQgcGFydCBvZiAiVENQIiBhdCBh bGwNCltNZWRdIFR3byBjb21tZW50cyBoZXJlOg0KDQrCtyAgICAgICAgIEl0IHNlZW1zIHRoYXQg eW91IGFzc3VtZSBhbGwgdGhlIHRyYWZmaWMgd2lsbCBiZSBzeXN0ZW1hdGljYWxseSByZWxheWVk IHRvIGEgcHJveHkuIFRoaXMgaXMgbm90IHRoZSBhc3N1bXB0aW9uIHdlIGhhdmUgaW4gdGhlIG1w dGNwIFdHLg0KDQrCtyAgICAgICAgIFRoZSBtZWNoYW5pc21zIHlvdSBtZW50aW9uZWQgYXJlIGtu b3duIHRvIGhhdmUgaXNzdWVzIHdpdGggTkFUOyBleHRlbnNpb25zIGV4aXN0IHRvIHNvZnRlbiBz b21lIG9mIHRoZW0uIEkgZG9u4oCZdCBzZWUgYSBuZXcgaXNzdWUgb3V0IHRoZXJlIHdoZW4gaXQg Y29tZSB0byBhbiBuZXR3b3JrLWFzc2lzdGVkIE1QVENQIHByb3h5Lg0KDQoNCkpvZQ0K --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDgzODE1MTY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDYyMTEzOTIwIC0xNjEwNjk4NDggNjc4OTUyOTkg Njc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4 OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSm9lLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKb2UgVG91Y2g8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDAxOjEyPGJyPg0KPGI+w4Am bmJzcDs6PC9iPiBPbGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtYXJlYUBp ZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtJbnQtYXJlYV0gTWlkZGxlYm94 ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzE4LzIwMTcg NDowNSBQTSwgT2xpdmllciBCb25hdmVudHVyZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGhvdWdoIEknbSBub3QgYXZlcnNlIHRvIG1p ZGRsZWJveGVzIGFzIG9wdGlvbmFsIG9wdGltaXphdGlvbnMsIEkgZmluZA0KPGJyPg0KdGhlIHBy b3Bvc2VkIG1lY2hhbmlzbXMgYXJlbid0IHF1aXRlIG9wdGlvbmFsIC0tIHRoZXkgaW5qZWN0IG9w dGlvbiA8YnI+DQppbmZvcm1hdGlvbiBpbnRvIHRoZSBTWU4gZGF0YS4gVGhhdCBpbmZvcm1hdGlv biB3b3VsZCBwb2lzb24gYSA8YnI+DQpjb25uZWN0aW9uIHRvIGEgbGVnYWN5IHJlY2VpdmVyIGlm IChtb3JlIHRvIHRoZSBwb2ludCwgd2hlbikgdGhhdCBpbmZvIDxicj4NCmlzbid0IHJlbW92ZWQg YnkgYSBwcm94eSB1cHN0cmVhbSBvZiB0aGUgcmVjZWl2ZXIuIDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBwYXJhZ3JhcGggcmVm ZXJzIHRvIGVhcmxpZXIgZG9jdW1lbnRzIGRpc2N1c3NlZCBpbiB0aGUgTVBUQ1AgPGJyPg0Kd29y a2luZyBncm91cC4gVGhlIG5ldyBkZXNpZ24gZG9lcyBub3QgaW5qZWN0IG9wdGlvbiBpbmZvcm1h dGlvbiBpbnRvIDxicj4NCnRoZSBTWU4gZGF0YS4gSXQgd29ya3MgbGlrZSBhbiBhcHBsaWNhdGlv biBsYXllciBwcm90b2NvbCB0aGF0IHNlbmRzIG1lc3NhZ2VzIDxicj4NCmluIHRoZSBTWU4gYnkg dXNpbmcgdGhlIFRGTyBvcHRpb24uIFRoZXJlIGlzIG5vIHJpc2sgb2YgcG9pc29uaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNw YW4gbGFuZz0iRU4tVVMiPk9LLCBpbiB0aGF0IGNhc2U6PGJyPg0KLSBJJ20gc3RpbGwgbm90IGF2 ZXJzZSB0byBtaWRkbGVib3hlcyB0aGF0IGFjY2VsZXJhdGUgb3IgZW5oYW5jZSBUQ1A8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5bTWVkXSBUaGUgcHJvcG9zYWwgbGV2ZXJhZ2VzIG9uIGV4aXN0aW5nIElFVEYgUkZDcyBh bmQgQkNQcyB0byBhc3Npc3QgZXN0YWJsaXNoaW5nIGNvbW11bmljYXRpb25zIG92ZXIgbXVsdGlw bGUgcGF0aHMgZXZlbiBpZiB0aGUgcmVtb3RlIHNlcnZlciBpcyBub3QgTVBUQ1AtY2FwYWJsZS4N CiBCVFcsIHdlIGludGVncmF0ZWQgYWxtb3N0IGFsbCB0aGUgc3VnZ2VzdGlvbnMgeW91IG1hZGUg cHJldmlvdXNseSAoZS5nLiwgdXNlIGEgZGVkaWNhdGVkIHNlcnZpY2UgcG9ydCwgZmlndXJlIG91 dCBob3cgdG8gdXNlIFRGTyB0byBnZXQgVEZPIHBlcmZvcm1hbmNlKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQotIElNTywgVENQIGFsd2F5cyBuZWVkcyB0byBiZSBh YmxlIHRvIGZhbGwgYmFjayAod2hpY2ggc2hvdWxkIGJlIHRydWUgbm93KTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN ZWRdIFdlIGFyZSBub3QgaW50ZXJmZXJpbmcgd2l0aCB0aGlzLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCi0gYnV0 IEkgcmVtYWluIGNvbmNlcm5lZCB3aXRoICZxdW90O2luamVjdGlvbiBwaWdneWJhY2tpbmcmcXVv dDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLSBldmVuIGlmIHRoaXMgaXMgcmVzdHJpY3RlZCB0 byBvcHRpb24gc3BhY2UsIGl0IGluY3JlYXNlcyB0aGUgcmlzayBvZiBkYW1hZ2luZyBhbiBvdGhl cndpc2Ugd29ya2luZyBjb25uZWN0aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBkb27igJl0IHVuZGVy c3RhbmQgeW91ciByZWZlcmVuY2UgdG8gdGhlIG9wdGlvbiBzcGFjZS4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgLSBpdCBmbGllcyBpbiB0aGUgZmFjZSBvZiBUQ1AgYmVpbmcgRTJF LCBhbmQgd29uJ3Qgd29yayB3aXRoIFRDUC1BTyBvciBJUHNlYywgd2hpY2ggSU1PIG1lYW5zIGl0 IGNhbid0IGJlIGNvbnNpZGVyZWQgcGFydCBvZiAmcXVvdDtUQ1AmcXVvdDsgYXQgYWxsPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+W01lZF0gVHdvIGNvbW1lbnRzIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JdCBzZWVtcyB0aGF0IHlvdSBhc3N1bWUg YWxsIHRoZSB0cmFmZmljIHdpbGwgYmUgc3lzdGVtYXRpY2FsbHkgcmVsYXllZCB0byBhIHByb3h5 LiBUaGlzIGlzIG5vdCB0aGUgYXNzdW1wdGlvbiB3ZSBoYXZlIGluIHRoZSBtcHRjcCBXRy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZSBtZWNoYW5pc21zIHlvdSBtZW50aW9uZWQgYXJlIGtub3duIHRvIGhhdmUgaXNzdWVzIHdpdGgg TkFUOyBleHRlbnNpb25zIGV4aXN0IHRvIHNvZnRlbiBzb21lIG9mIHRoZW0uIEkgZG9u4oCZdCBz ZWUgYSBuZXcgaXNzdWUgb3V0IHRoZXJlIHdoZW4NCiBpdCBjb21lIHRvIGFuIG5ldHdvcmstYXNz aXN0ZWQgTVBUQ1AgcHJveHkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpKb2U8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A00EA84OPEXCLILMA3corp_-- From nobody Wed Jul 19 00:41:40 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7E12ECC3 for ; Wed, 19 Jul 2017 00:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=tessares-net.20150623.gappssmtp.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 6UYJcxspOutY for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC16131C01 for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id k71so1294414wrc.2 for ; Wed, 19 Jul 2017 00:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=hXCNlJtFbcbD2PziR6CDsBIv3o6wnbpynxS6InSqHg0=; b=cwaWJ2t6J0fX2bemGLdBQVjlePapcRTC4GPrbYOx5k/WqmFDVnwTvH1qNrcEWyZz3s +9xKUpEe4P4trj5yABc/xK8yTK8W8P3EH6aPLQtoQhxwabGAlxrw7HtCnsU8OiSxfiLs fXjLeqfND5l3v0lxWO9hRM10aLIRRr0ttM0YaQw+6Q3gW76vXqjadysT63D7qNLXFe3p Mp6yncCkUYJWApP2DHCiDh0iVK0uS0pWnZik4QvWYRTYMSOsxDJVVF17vCLP2OcjyyBk 19kPQ6yIxBxfZ0w6mSlh2J928O8/TPqMtYPyjN1Q/ziVDyPyuU9dD4dj84t6XvQsHhn3 q6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hXCNlJtFbcbD2PziR6CDsBIv3o6wnbpynxS6InSqHg0=; b=g1qcbbbavw6PAvpHys4R7FYOp/PB9aqnvcDmE8lgajH654baQyvtvv22zjU6Xqrp5z xcpkloAfcVmrIl+/PJsVoZ8fkjfWskCV8nDLXvStBkbm9NC/jFNzyRpyb/Xj0vgVby9c LvvIDDH2K0LGSJCSkqnTFWWU2mV4EiLf6BOIv9hU6qc96NOysTIApk5qGQ560GX1CJ8p O18NWQVslAAzhihBxWjOSP2JlglXx9mL02AeJBFVRC+5dUFnMPWvz42caePAuVQs/Q41 7GYNBFWMgYF57MYEDPR6cxLs31+nlZ1AidJJMIpLy2MbnFNoAZklyWkXJdOE7Wfl8Pbz 4dzA== X-Gm-Message-State: AIVw110x0rT/f3BQ/WtscxLbouggcACp6lJE2IumCfrMcmbzOvoA/tCE +Hdpy1qf4iBlP7jeci40PiDHgnG3pYpF5HbDwvh49aVGCtS2atVyt/3VvIy2jWSESROxWWqlVr8 = X-Received: by 10.223.158.139 with SMTP id a11mr3504363wrf.131.1500450079601; Wed, 19 Jul 2017 00:41:19 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id 33sm2922628wrr.58.2017.07.19.00.41.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 00:41:19 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> From: Olivier Bonaventure Message-ID: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> Date: Wed, 19 Jul 2017 09:41:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:41:23 -0000 Joe, >>> Although I'm not averse to middleboxes as optional optimizations, I find >>> the proposed mechanisms aren't quite optional -- they inject option >>> information into the SYN data. That information would poison a >>> connection to a legacy receiver if (more to the point, when) that info >>> isn't removed by a proxy upstream of the receiver. >> >> This paragraph refers to earlier documents discussed in the MPTCP >> working group. The new design does not inject option information into >> the SYN data. It works like an application layer protocol that sends >> messages >> in the SYN by using the TFO option. There is no risk of poisoning. > > OK, in that case: > - I'm still not averse to middleboxes that accelerate or enhance TCP We agree > - IMO, TCP always needs to be able to fall back (which should be true now) This is not a concern with the proposed design > - but I remain concerned with "injection piggybacking" To which section of the draft are you referring to ? Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 01:30:36 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBDF131C1E for ; Wed, 19 Jul 2017 01:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2G4g6HNN1AzZ for ; Wed, 19 Jul 2017 01:30:28 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 E205A131C2F for ; Wed, 19 Jul 2017 01:30:26 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id w187so14017842ybc.0 for ; Wed, 19 Jul 2017 01:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mYqUZGjHZkoM/LOdAORK6HIaWuumwZfevA84XNhFzlc=; b=izvb9eeXaqUUO13th9cKtR0yu00YTWaZ/lWV+gTPQHvcNC3AMlncnCRjLs5N6+3sxe yf1g5MPld5bnxCq0eClBNGIsOji4F5sS1vXeCnQaFZJmLYi1/m9XkN6OkXCPJJ2gscat OPhR/TYu+C9s5BY8wD/80P0HJewSTSyUB1bygXPrDbbwoK3+z52Molk4VVnSwjAV0l01 iDYuJXJUOVq/ifa4+r37D6JjsacaSRGfd4IxxD4AI1SKLPQkjxNREpmE5WhR7/nC/Swg XMoeIdwVDwhkR94ekOHHI5Kpb6Ilbq4AHl7KVN5dQwdov0eg2PydwOZaFhBNrzjxIb9F rZCA== 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=mYqUZGjHZkoM/LOdAORK6HIaWuumwZfevA84XNhFzlc=; b=h/ZTTHAqUP5bQqe+RDGzXY3KW3Jg63i20Mdo31UGPp1cXCpALj+0n8Pv7zhAa054t9 7qsBUd8uq5Ox4Y+bnSZtwzpaVRF1YyqGvVfgt1b5B2Vm75NcJEioeHPApZr9s9I4uxdg j2AQ84UKDRc8IO1x14KVM/cty7Mnamku4BsPIP5igSTrw6SXO7T14LRdURAJcO6LVQ8k /3KHKg1WZGprNZloZsMH8qc6bIatvu2VFagNpJwaupHrV2P9+Qa1ytrtn5HG2sPBbGQL DzALEoubd+J2VZQLXfGCEWeGD/db3khbST5du7QtiUZ7zkcQffWRpbtvttdliiyCPWIs Y6xA== X-Gm-Message-State: AIVw111Z81IQTdDKMuOxKmslwEllPkxB2prPOptwTLERclvnaCmGIulj PFVM41N68bOyUOlUfi3gNwzjftxHkqtl X-Received: by 10.37.48.139 with SMTP id w133mr1252080ybw.84.1500453025912; Wed, 19 Jul 2017 01:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Wed, 19 Jul 2017 01:30:05 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Erik Kline Date: Wed, 19 Jul 2017 10:30:05 +0200 Message-ID: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com Cc: Tom Herbert , Joe Touch , Internet Area , "tsv-area@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11488df6a360070554a7710e" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:30:30 -0000 --001a11488df6a360070554a7710e Content-Type: text/plain; charset="UTF-8" > [Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support MPTCP. If server infrastructures aren't supporting MPTCP, maybe that's the thing that needs to be looked at...if in fact it can be helped. --001a11488df6a360070554a7710e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgVDwaoGW6MlQVILRwJ5Rtww5BroWyCNg9 wGNIrdkBHvMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE5 MDgzMDI2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAI/Fe4+1HfoH2s8VkGcqcM+CX7TEIPp3SUO6szKbj4DO/VviiE4U m0RS0Xz7SLUcrTGfX0vJ+Xm9Lx9WIdclFFI+PMATGEkv0LGSEkP1cf2q1tCHxk3muEM3f5lBkt5e Gp5ndaWeLWiWkm2MC1IuVg/nZukRYnzoUKQMzCAcB0WA26Dk85zHVMIOGAIV3KNT+TUs83O2jkbm fMftmK0T/eAmdQmndxkGRzeWjcVzElD+PSSn9wz3h/ZheQ2ggSz+hX3QAFGhLxL0X1KPN/w/jCX3 aCRlBei0qflrpq3NDGjbDFEbRI19wpWpUc2NXutILFPj57FfCbxuXhSx8I7b7+Q= --001a11488df6a360070554a7710e-- From nobody Wed Jul 19 01:46:56 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10DB131C2F; Wed, 19 Jul 2017 01:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 HSWdxzapeEhq; Wed, 19 Jul 2017 01:46:41 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40400131C38; Wed, 19 Jul 2017 01:46:41 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E1A5CC0715; Wed, 19 Jul 2017 10:46:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id B3F4F800BC; Wed, 19 Jul 2017 10:46:39 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 10:46:39 +0200 From: To: Erik Kline CC: Tom Herbert , Joe Touch , "Internet Area" , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAGlI/K5LY2P7TE6q+ZKxS6zSn6Ja0ebg Date: Wed, 19 Jul 2017 08:46:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:46:43 -0000 SGkgRXJpaywNCg0KVGhhdCdzIHRoZSBpbnR1aXRpdmUgYXBwcm9hY2ggdG8gZm9sbG93IGJ1dCB1 bmZvcnR1bmF0ZWx5IHRoZSBzaXR1YXRpb24gaXMgbm90IHRoYXQgb2J2aW91cyB0byBnZXQgaW50 by4gDQoNCk5ldHdvcmsgcHJvdmlkZXJzIGRvIG5vdCBoYXZlIGEgY29udHJvbCBvbiB0aGUgc2Vy dmVycyBhbmQgdGhlIHRlcm1pbmFscyB0aGF0IGFyZSBlbmFibGVkIGJ5IGN1c3RvbWVycyBiZWhp bmQgdGhlIENQRS4gU28gbWFraW5nIHVzZSBvZiBNUFRDUCB0byBncmFiIG1vcmUgcmVzb3VyY2Vz ICh3aGVuIGF2YWlsYWJsZSkgb3IgdG8gcHJvdmlkZSBiZXR0ZXIgcmVzaWxpZW5jeSAod2hlbiBh IG5ldHdvcmsgYXR0YWNobWVudCBpcyBsb3N0KSB3aWxsIHJlcXVpcmUgYm90aCBlbmRwb2ludHMg dG8gYmUgTVBUQ1AtY2FwYWJsZS4gDQoNCldlIGFyZSBpbiBhIHNpdHVhdGlvbiB3aGVyZSBjdXN0 b21lcnMgYXJlIHByb3ZpZGVkIHdpdGggbXVsdGlwbGUgYWNjZXNzZXMgYnV0IHRoZXNlIGN1c3Rv bWVycyBkbyBvbmx5IGhhdmUgdGhlIFFvRSBhcyBpZiB0aGV5IGFyZSBzaW5nbGUtY29ubmVjdGVk LiANCg0KVGhlIG5ldHdvcmstYXNzaXN0ZWQgTVBUQ1AgaXMgYSBmZWF0dXJlIHRvIGhhdmUgaW1t ZWRpYXRlbHkgdGhlIGJlbmVmaXRzIG9mIE1QVENQIHdpdGhvdXQgcmVxdWlyaW5nIHRoYXQgYWxs IHRlcm1pbmFscyBhbmQgc2VydmVycyBhcmUgTVBUQ1AtY2FwYWJsZS4NCg0KVGhlIGRlc2lnbiB3 ZSBhcmUgYWR2b2NhdGluZyBmb3IgYWxsb3dzIGZvciB0aGUgdXNlIG9mIE1QVENQIGFsb25nIHRo ZSBwYXRoIHdoZW4gYm90aCBlbmRwb2ludHMgYXJlIE1QVENQLWNhcGFibGUgYW5kIHRvIGJ5cGFz cyB0aGUgcHJveHkgd2hlbiBpdCBtYWtlcyBzZW5zZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEVyaWsgS2xpbmUgW21haWx0bzpla0Bn b29nbGUuY29tXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAxMDozMA0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+IENjwqA6IFRvbSBIZXJiZXJ0OyBK b2UgVG91Y2g7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+IE9iamV0wqA6IFJl OiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBvZiBNUFRDUA0K PiANCj4gPiBbTWVkXSBXZSB3b3VsZCBsb3ZlIHRvIGF2b2lkIHJlcXVpcmluZyBhZGRpbmcgYSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yaw0KPiB0byBhc3Npc3QgZGV2aWNlcyB0byBtYWtlIHVzZSBv ZiB0aGVpciBtdWx0aXBsZSBpbnRlcmZhY2VzL3BhdGhzLg0KPiBOZXZlcnRoZWxlc3MsIHRoZSBz aXR1YXRpb24gaXMgdGhhdCBzZXJ2ZXJzIGRvIG5vdCBzdXBwb3J0IE1QVENQLg0KPiANCj4gSWYg c2VydmVyIGluZnJhc3RydWN0dXJlcyBhcmVuJ3Qgc3VwcG9ydGluZyBNUFRDUCwgbWF5YmUgdGhh dCdzIHRoZQ0KPiB0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGxvb2tlZCBhdC4uLmlmIGluIGZhY3Qg aXQgY2FuIGJlIGhlbHBlZC4NCg== From nobody Wed Jul 19 08:45:17 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED04B1317BE for ; Wed, 19 Jul 2017 08:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 jXIxxge6yUFO for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 42A32131A50 for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id v105so30121290wrb.0 for ; Wed, 19 Jul 2017 08:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CCA8uCf1rl17RLz3Jmv/5hgHdHMez4gHC7u9VG6r6FA=; b=o3MfY53N9FllsxqODB7YnckSKJ31dSVLdVzRw/A/2LA7VMOsiSr3F1GrLx7qQFs5bL DI3Vykz9vqS4uS2jE43VvvE7XLThb3K5pA9gmYsCO/JRKNuR5SnJQyp0AhL+mbCn7P2g qTjUl+IanBnE/dI4uDNibMGgEtnvsnyzB1gJ8MzdxiVNVzAnDR0qbZ3YGMOj55xfi0tV JmaIU/WQsu92dG7ksZeQZQOYFeeziGrwrCEGv5PWwpAlZUfyi8jYYF/lopA88f6Qa0kb xdknf491pbvy8gPXJ2lgI5WQ3uDZg2H23g7ETlnfyf1tDwt20p1jjYy7WCDlvLWQe/xG VOzQ== 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=CCA8uCf1rl17RLz3Jmv/5hgHdHMez4gHC7u9VG6r6FA=; b=WyLrnoF/QR29rkOvg9Oj38H4/7Kd59o53GXzLyprhkOH5BWslaXIrKJ6+XOBCvDpus 60VcEEEj1NsZtFQxZpkVY1+RPo6VlXRXwlUlRlgo4/D0QU24iEB01N5FlfRVuQ2awDqo BYJHxqXN7Cjy+njEwDOCIkzUfK2Fq7zN9rrVMhLFZHLyXvTC95sdnC0ilTgbq7fbMUg+ zEo2ERob7EVmlVgQENX0s598eeqD3X/8FWsUQ2tG5OjwMf7659gl5I1imaNXX+BGbqAK GbB5zauVwOCpsiUSwISCCj2N4xKk5TkoRcbc3XKq/Ys0lr2V4Nf64YV2hmKbEurnStdz yvVg== X-Gm-Message-State: AIVw113XW0bOTWl550s9Dnfr9k8ShayT8lzxXDfgwtxIS28UUhvVQDig e2R/Dxp+t985Y3bgWVJK5yZqXR62pNaS X-Received: by 10.223.169.2 with SMTP id u2mr713962wrc.288.1500479104427; Wed, 19 Jul 2017 08:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Wed, 19 Jul 2017 08:45:03 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Wed, 19 Jul 2017 08:45:03 -0700 Message-ID: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com Cc: Joe Touch , "tsv-area@ietf.org" , Internet Area Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:45:09 -0000 On Tue, Jul 18, 2017 at 11:37 PM, wrote: > Hi Tom, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Tom Herbe= rt >> Envoy=C3=A9 : mercredi 19 juillet 2017 00:43 >> =C3=80 : Joe Touch >> Cc : tsv-area@ietf.org; Internet Area >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP >> >> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: >> > Hi, all, >> > >> > I've noted this before, but to share with other areas: >> > >> > Although I'm not averse to middleboxes as optional optimizations, I fi= nd >> > the proposed mechanisms aren't quite optional -- they inject option >> > information into the SYN data. That information would poison a >> > connection to a legacy receiver if (more to the point, when) that info >> > isn't removed by a proxy upstream of the receiver. >> > >> > TCP must be E2E and fall back to legacy endpoints without a reconnecti= on >> > attempt, as required by RFC793. >> > >> > These aren't generic solutions; they're attacks on a TCP connection, >> IMO. >> > >> I agree. This seems be akin to stateful firewalls model that impose >> artificial requirements on networking (like every TCP packet for a >> connection must got through some middlebox or the connection is >> dropped). We need to move things back to E2E semantics for transport >> protocols-- nodes that try to maintain transport state in the network >> should be considered the problem not the solution! >> > > [Med] We would love to avoid requiring adding a function in the network t= o assist devices to make use of their multiple interfaces/paths. Neverthele= ss, the situation is that servers do not support MPTCP. > > The proposed solution allows to: > * elect some flows to benefit from network-assisted MPTCP while avoiding = session failures. > * Policies are configured to identify traffic that won't be forwarded via= a proxy > * 0-RTT proxying > * MPTCP can be used e2e if both end points are MPTCP-capable (that is, th= e proxy is withdrawn from the path). > * No interference with TCP options to be negotiated between endpoints. > > Do you have in mind such use cases when you referred to the "stateful fir= ewalls model"? One of the problems with stateful firewalls (as well as transparent proxies) is that they require all packets for a flow to consistently traverse the same middlebox device. The middlebox is not addressed by the packet, so the assumed requirement is that packets for the flow go though the same network node by virtue of routing. For a firewall in a single-homed site to the Internet this works because the firewall is the only egress/ingress point to the network. If a site is multi-homed, then the hope is that routing of packets in both directions will go through the same point. But there is absolutely no requirement that network layer packets for a flow are always routed the same way, and if routing does change and packets need to flow through different points the session breaks. If I'm reading the draft correctly, then it has the same property of maintaining transport state in the network so it implies the same requirement that all packets for a flow follow the same path. Personally, would find it ironic that a a protocol to allow muli-path transport would require the network layer to be single path. Tom > >> Tom >> >> > Joe >> > >> > >> > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote: >> >> The working group has discussed this issue several times and today we >> >> have presented a new design that supports the creation of such >> >> functions to convert MPTCP connections into TCP connections and vice >> >> versa. The design was done with MPTCP in mind, but the proposed >> >> solution could be more generic and applied to other use cases than >> >> MPTCP. The draft that describes the new design is available via: >> >> >> >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp- >> converters-01.txt >> >> >> >> >> >> Mirja Kuehlewind suggested to send the document on the int-area and >> >> tsv-area mailing lists to see whether other working groups could be >> >> interested by this approach. >> > >> > _______________________________________________ >> > Int-area mailing list >> > Int-area@ietf.org >> > https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 08:51:38 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7F131D70 for ; Wed, 19 Jul 2017 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 Q-hN7aGkPbRF for ; Wed, 19 Jul 2017 08:51:25 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 327D3131D7A for ; Wed, 19 Jul 2017 08:51:22 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w191so3068051wmw.1 for ; Wed, 19 Jul 2017 08:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=jKGpZYcY7iTAx2yaxO2eSqt0zH5KGrRhRYdgpFRuJHAznwTRqYSAGx2mdeEimbg3cy uhMDGQR7P5Eu9qD0NJIwbbh25bE79QXTNxeAdg6qe7A1+NC8xMYxWoaQi2EPqgaKzbun nHco5lVsrwiV2+2U7W7oUCNIP/l/RtFf8RIe0hIvdFft/hU01jAjevR+rI3YCXlpD9ou 8OkURRh8Ow5uoER1CIfUKl7w89EVKboi7aCvTFCbQS28SmIvvx7Fhjq/pLS5UnMMsuJ/ 0TD2zmZtPPI0NHsOYL9KPXgGbib5nf5clNaYeqIU7DIk9b6QZl8WJ1DCNKgyeF2LMeqz 7NNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qsHtHCz0luExy7y+wpnfzy3w3KCLVr58LUahyTINlpw=; b=SW/XBsTnqr1Hpb46eyHURytiNBAM+k8RrHI4LMP99E9Z+mqiOAo0lqY4jMH0eF6wy1 HDHWo4p/A11KaWnd57ZaWPLr3blHOqskF9sQ+kxuEUcLYxZtJ/FiOFriNZcsVl6pOhoM zfkuU8ByAoxRjO7T3OpVKj8NIZuwmRLid9QI5wsVabHLYGUjnKAeRHP/414eFd7Nv3hq ScfoNpVcsuht18U4/MG4uSvQvwT/CosUSVGm64sDQYL09vw4QoYSThguaiOYHiGQtTDW X4Svx/ncIq3zDvpFljjjuDlDqanliRqDah0ybYTS9pL+HW/gFDqOaJTjS6fxeF1OeBHB 7XcA== X-Gm-Message-State: AIVw113fZKTNDo0GmQYYEw1GBx8Vt+w7nKrb5jRPuTQ6Kd4WzD5JgKGj BoBkv6BnzoIs6W2/45k6pNdSn+W3p1QI6NEslO3kxWj/enGddGuwEHw2TtidQ3ZKBuJvZWCV2Qw = X-Received: by 10.28.172.4 with SMTP id v4mr335707wme.72.1500479479745; Wed, 19 Jul 2017 08:51:19 -0700 (PDT) Received: from dhcp-88fc.meeting.ietf.org ([2001:67c:370:128:8ce6:5c6:330:a26f]) by smtp.gmail.com with ESMTPSA id l22sm253442wmi.48.2017.07.19.08.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 08:51:18 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: Tom Herbert , mohamed.boucadair@orange.com Cc: Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Olivier Bonaventure Message-ID: <70ccfd9e-e6eb-6f84-856f-fb5912fc0517@tessares.net> Date: Wed, 19 Jul 2017 17:51:17 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:51:27 -0000 Tom, >> >> Do you have in mind such use cases when you referred to the "stateful firewalls model"? > > One of the problems with stateful firewalls (as well as transparent > proxies) is that they require all packets for a flow to consistently > traverse the same middlebox device. The middlebox is not addressed by > the packet, so the assumed requirement is that packets for the flow go > though the same network node by virtue of routing. The proposed converter has one IP address and a reserved port number. Packets follow norm routing path towards this address. > For a firewall in a > single-homed site to the Internet this works because the firewall is > the only egress/ingress point to the network. If a site is > multi-homed, then the hope is that routing of packets in both > directions will go through the same point. But there is absolutely no > requirement that network layer packets for a flow are always routed > the same way, and if routing does change and packets need to flow > through different points the session breaks. > > If I'm reading the draft correctly, then it has the same property of > maintaining transport state in the network so it implies the same > requirement that all packets for a flow follow the same path. > Personally, would find it ironic that a a protocol to allow muli-path > transport would require the network layer to be single path. The motivation for the proposed converters is that the destination does not support MPTCP. To enable the client to leverage the benefits of MPTCP (e.g. in the access networks) the MPTCP connection is terminated on the converter. The client uses the different paths between it and the converter. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 08:57:39 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78209127B60; Wed, 19 Jul 2017 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5TkdEgjWHDi5; Wed, 19 Jul 2017 08:57:35 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E2F127601; Wed, 19 Jul 2017 08:57:35 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E7E45C07E1; Wed, 19 Jul 2017 17:57:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id C05EDC0086; Wed, 19 Jul 2017 17:57:33 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 17:57:33 +0200 From: To: Tom Herbert CC: Joe Touch , "tsv-area@ietf.org" , Internet Area Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAKX+HMhC89cYFk6ZnEbwm//X0qJbSyGw Date: Wed, 19 Jul 2017 15:57:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F1D8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:57:37 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJi ZXJ0bGFuZC5jb21dDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE3OjQ1 DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogSm9lIFRvdWNoOyB0 c3YtYXJlYUBpZXRmLm9yZzsgSW50ZXJuZXQgQXJlYQ0KPiBPYmpldMKgOiBSZTogW0ludC1hcmVh XSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2YgTVBUQ1ANCj4gDQo+IE9uIFR1 ZSwgSnVsIDE4LCAyMDE3IGF0IDExOjM3IFBNLCAgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+IHdyb3RlOg0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiA+PiBEZSA6IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBUb20NCj4gSGVyYmVydA0KPiA+PiBFbnZvecOpIDogbWVyY3JlZGkg MTkganVpbGxldCAyMDE3IDAwOjQzDQo+ID4+IMOAIDogSm9lIFRvdWNoDQo+ID4+IENjIDogdHN2 LWFyZWFAaWV0Zi5vcmc7IEludGVybmV0IEFyZWENCj4gPj4gT2JqZXQgOiBSZTogW0ludC1hcmVh XSBNaWRkbGVib3hlcyB0byBhaWQgdGhlIGRlcGxveW1lbnQgb2YgTVBUQ1ANCj4gPj4NCj4gPj4g T24gVHVlLCBKdWwgMTgsIDIwMTcgYXQgMzozMSBQTSwgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1 PiB3cm90ZToNCj4gPj4gPiBIaSwgYWxsLA0KPiA+PiA+DQo+ID4+ID4gSSd2ZSBub3RlZCB0aGlz IGJlZm9yZSwgYnV0IHRvIHNoYXJlIHdpdGggb3RoZXIgYXJlYXM6DQo+ID4+ID4NCj4gPj4gPiBB bHRob3VnaCBJJ20gbm90IGF2ZXJzZSB0byBtaWRkbGVib3hlcyBhcyBvcHRpb25hbCBvcHRpbWl6 YXRpb25zLCBJDQo+IGZpbmQNCj4gPj4gPiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtcyBhcmVuJ3Qg cXVpdGUgb3B0aW9uYWwgLS0gdGhleSBpbmplY3Qgb3B0aW9uDQo+ID4+ID4gaW5mb3JtYXRpb24g aW50byB0aGUgU1lOIGRhdGEuIFRoYXQgaW5mb3JtYXRpb24gd291bGQgcG9pc29uIGENCj4gPj4g PiBjb25uZWN0aW9uIHRvIGEgbGVnYWN5IHJlY2VpdmVyIGlmIChtb3JlIHRvIHRoZSBwb2ludCwg d2hlbikgdGhhdA0KPiBpbmZvDQo+ID4+ID4gaXNuJ3QgcmVtb3ZlZCBieSBhIHByb3h5IHVwc3Ry ZWFtIG9mIHRoZSByZWNlaXZlci4NCj4gPj4gPg0KPiA+PiA+IFRDUCBtdXN0IGJlIEUyRSBhbmQg ZmFsbCBiYWNrIHRvIGxlZ2FjeSBlbmRwb2ludHMgd2l0aG91dCBhDQo+IHJlY29ubmVjdGlvbg0K PiA+PiA+IGF0dGVtcHQsIGFzIHJlcXVpcmVkIGJ5IFJGQzc5My4NCj4gPj4gPg0KPiA+PiA+IFRo ZXNlIGFyZW4ndCBnZW5lcmljIHNvbHV0aW9uczsgdGhleSdyZSBhdHRhY2tzIG9uIGEgVENQIGNv bm5lY3Rpb24sDQo+ID4+IElNTy4NCj4gPj4gPg0KPiA+PiBJIGFncmVlLiBUaGlzIHNlZW1zIGJl IGFraW4gdG8gc3RhdGVmdWwgZmlyZXdhbGxzIG1vZGVsIHRoYXQgaW1wb3NlDQo+ID4+IGFydGlm aWNpYWwgcmVxdWlyZW1lbnRzIG9uIG5ldHdvcmtpbmcgKGxpa2UgZXZlcnkgVENQIHBhY2tldCBm b3IgYQ0KPiA+PiBjb25uZWN0aW9uIG11c3QgZ290IHRocm91Z2ggc29tZSBtaWRkbGVib3ggb3Ig dGhlIGNvbm5lY3Rpb24gaXMNCj4gPj4gZHJvcHBlZCkuIFdlIG5lZWQgdG8gbW92ZSB0aGluZ3Mg YmFjayB0byBFMkUgc2VtYW50aWNzIGZvciB0cmFuc3BvcnQNCj4gPj4gcHJvdG9jb2xzLS0gbm9k ZXMgdGhhdCB0cnkgdG8gbWFpbnRhaW4gdHJhbnNwb3J0IHN0YXRlIGluIHRoZSBuZXR3b3JrDQo+ ID4+IHNob3VsZCBiZSBjb25zaWRlcmVkIHRoZSBwcm9ibGVtIG5vdCB0aGUgc29sdXRpb24hDQo+ ID4+DQo+ID4NCj4gPiBbTWVkXSBXZSB3b3VsZCBsb3ZlIHRvIGF2b2lkIHJlcXVpcmluZyBhZGRp bmcgYSBmdW5jdGlvbiBpbiB0aGUgbmV0d29yaw0KPiB0byBhc3Npc3QgZGV2aWNlcyB0byBtYWtl IHVzZSBvZiB0aGVpciBtdWx0aXBsZSBpbnRlcmZhY2VzL3BhdGhzLg0KPiBOZXZlcnRoZWxlc3Ms IHRoZSBzaXR1YXRpb24gaXMgdGhhdCBzZXJ2ZXJzIGRvIG5vdCBzdXBwb3J0IE1QVENQLg0KPiA+ DQo+ID4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGFsbG93cyB0bzoNCj4gPiAqIGVsZWN0IHNvbWUg Zmxvd3MgdG8gYmVuZWZpdCBmcm9tIG5ldHdvcmstYXNzaXN0ZWQgTVBUQ1Agd2hpbGUgYXZvaWRp bmcNCj4gc2Vzc2lvbiBmYWlsdXJlcy4NCj4gPiAqIFBvbGljaWVzIGFyZSBjb25maWd1cmVkIHRv IGlkZW50aWZ5IHRyYWZmaWMgdGhhdCB3b24ndCBiZSBmb3J3YXJkZWQNCj4gdmlhIGEgcHJveHkN Cj4gPiAqIDAtUlRUIHByb3h5aW5nDQo+ID4gKiBNUFRDUCBjYW4gYmUgdXNlZCBlMmUgaWYgYm90 aCBlbmQgcG9pbnRzIGFyZSBNUFRDUC1jYXBhYmxlICh0aGF0IGlzLA0KPiB0aGUgcHJveHkgaXMg d2l0aGRyYXduIGZyb20gdGhlIHBhdGgpLg0KPiA+ICogTm8gaW50ZXJmZXJlbmNlIHdpdGggVENQ IG9wdGlvbnMgdG8gYmUgbmVnb3RpYXRlZCBiZXR3ZWVuIGVuZHBvaW50cy4NCj4gPg0KPiA+IERv IHlvdSBoYXZlIGluIG1pbmQgc3VjaCB1c2UgY2FzZXMgd2hlbiB5b3UgcmVmZXJyZWQgdG8gdGhl ICJzdGF0ZWZ1bA0KPiBmaXJld2FsbHMgbW9kZWwiPw0KPiANCj4gT25lIG9mIHRoZSBwcm9ibGVt cyB3aXRoIHN0YXRlZnVsIGZpcmV3YWxscyAoYXMgd2VsbCBhcyB0cmFuc3BhcmVudA0KPiBwcm94 aWVzKSBpcyB0aGF0IHRoZXkgcmVxdWlyZSBhbGwgcGFja2V0cyBmb3IgYSBmbG93IHRvIGNvbnNp c3RlbnRseQ0KPiB0cmF2ZXJzZSB0aGUgc2FtZSBtaWRkbGVib3ggZGV2aWNlLiBUaGUgbWlkZGxl Ym94IGlzIG5vdCBhZGRyZXNzZWQgYnkNCj4gdGhlIHBhY2tldCwNCg0KW01lZF0gVGhpcyBpcyBu b3QgdGhlIGFjdHVhbCBwcm9wb3NhbC4gVGhlIHByb3h5IGlzIGV4cGxpY2l0bHkgY29uZmlndXJl ZCBzbyB0aGF0IGFsbCBwYWNrZXRzIGFyZSBzZW50IHRvIGl0IGRpcmVjdGx5LiBUaGF0IGlzLCB0 aGUgZGVzdGluYXRpb24gYWRkcmVzcyBvZiBvdXRnb2luZyBwYWNrZXRzIHdpbGwgYmUgc2V0IHRv IHRoZSBvbmUgb2YgdGhhdCBwcm94eS4gIA0KDQogc28gdGhlIGFzc3VtZWQgcmVxdWlyZW1lbnQg aXMgdGhhdCBwYWNrZXRzIGZvciB0aGUgZmxvdyBnbw0KPiB0aG91Z2ggdGhlIHNhbWUgbmV0d29y ayBub2RlIGJ5IHZpcnR1ZSBvZiByb3V0aW5nLiBGb3IgYSBmaXJld2FsbCBpbiBhDQo+IHNpbmds ZS1ob21lZCBzaXRlIHRvIHRoZSBJbnRlcm5ldCB0aGlzIHdvcmtzIGJlY2F1c2UgdGhlIGZpcmV3 YWxsIGlzDQo+IHRoZSBvbmx5IGVncmVzcy9pbmdyZXNzIHBvaW50IHRvIHRoZSBuZXR3b3JrLiBJ ZiBhIHNpdGUgaXMNCj4gbXVsdGktaG9tZWQsIHRoZW4gdGhlIGhvcGUgaXMgdGhhdCByb3V0aW5n IG9mIHBhY2tldHMgaW4gYm90aA0KPiBkaXJlY3Rpb25zIHdpbGwgZ28gdGhyb3VnaCB0aGUgc2Ft ZSBwb2ludC4gQnV0IHRoZXJlIGlzIGFic29sdXRlbHkgbm8NCj4gcmVxdWlyZW1lbnQgdGhhdCBu ZXR3b3JrIGxheWVyIHBhY2tldHMgZm9yIGEgZmxvdyBhcmUgYWx3YXlzIHJvdXRlZA0KPiB0aGUg c2FtZSB3YXksIGFuZCBpZiByb3V0aW5nIGRvZXMgY2hhbmdlIGFuZCBwYWNrZXRzIG5lZWQgdG8g Zmxvdw0KPiB0aHJvdWdoIGRpZmZlcmVudCBwb2ludHMgdGhlIHNlc3Npb24gYnJlYWtzLg0KPiAN Cg0KW01lZF0gSSBmdWxseSBhZ3JlZSB3aXRoIHlvdS4gQnV0LCB3ZSBhcmUgbm90IGluIGEgdHJh bnNwYXJlbnQvaW1wbGljaXQgbW9kZS4gDQoNCj4gSWYgSSdtIHJlYWRpbmcgdGhlIGRyYWZ0IGNv cnJlY3RseSwgdGhlbiBpdCBoYXMgdGhlIHNhbWUgcHJvcGVydHkgb2YNCj4gbWFpbnRhaW5pbmcg dHJhbnNwb3J0IHN0YXRlIGluIHRoZSBuZXR3b3JrIHNvIGl0IGltcGxpZXMgdGhlIHNhbWUNCj4g cmVxdWlyZW1lbnQgdGhhdCBhbGwgcGFja2V0cyBmb3IgYSBmbG93IGZvbGxvdyB0aGUgc2FtZSBw YXRoLg0KDQpbTWVkXSBXZSBkb24ndCBoYXZlIHN1Y2ggcmVxdWlyZW1lbnQuICBUaGUgcHJveHkg aXMgbm90IHN1cHBvc2VkIHRvIGJlIG9uIG9uZSBvZiB0aGUgZGVmYXVsdCBmb3J3YXJkaW5nIHBh dGhzOyBhbGwgd2hhdCB3ZSByZXF1aXJlIGlzIHRoYXQgaXQgaXMgcmVhY2hhYmxlIHVzaW5nIGFu eSBvZiB0aGUgYXZhaWxhYmxlIHBhdGhzLiBTdWJmbG93cyBjYW4gYmUgcGxhY2VkIHVzaW5nIGFu eSBvciBhbGwgb2YgdGhlIGF2YWlsYWJsZSBwYXRocy4NCg0KPiBQZXJzb25hbGx5LCAgd291bGQg ZmluZCBpdCBpcm9uaWMgdGhhdCBhIGEgcHJvdG9jb2wgdG8gYWxsb3cgbXVsaS1wYXRoDQo+IHRy YW5zcG9ydCB3b3VsZCByZXF1aXJlIHRoZSBuZXR3b3JrIGxheWVyIHRvIGJlIHNpbmdsZSBwYXRo Lg0KPg0KDQpbTWVkXSBTb3JyeSwgYnV0IHdlIGRvbuKAmXQgaGF2ZSBzdWNoIGNvbnN0cmFpbnQv cmVxdWlyZW1lbnQuIFNlZSBteSBleHBsYW5hdGlvbiBhYm92ZS4NCg0KIA0KPiBUb20NCj4gDQo+ ID4NCj4gPj4gVG9tDQo+ID4+DQo+ID4+ID4gSm9lDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IE9u IDcvMTgvMjAxNyAzOjIyIFBNLCBPbGl2aWVyIEJvbmF2ZW50dXJlIHdyb3RlOg0KPiA+PiA+PiBU aGUgd29ya2luZyBncm91cCBoYXMgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgc2V2ZXJhbCB0aW1lcyBh bmQgdG9kYXkNCj4gd2UNCj4gPj4gPj4gaGF2ZSBwcmVzZW50ZWQgYSBuZXcgZGVzaWduIHRoYXQg c3VwcG9ydHMgdGhlIGNyZWF0aW9uIG9mIHN1Y2gNCj4gPj4gPj4gZnVuY3Rpb25zIHRvIGNvbnZl cnQgTVBUQ1AgY29ubmVjdGlvbnMgaW50byBUQ1AgY29ubmVjdGlvbnMgYW5kIHZpY2UNCj4gPj4g Pj4gdmVyc2EuIFRoZSBkZXNpZ24gd2FzIGRvbmUgd2l0aCBNUFRDUCBpbiBtaW5kLCBidXQgdGhl IHByb3Bvc2VkDQo+ID4+ID4+IHNvbHV0aW9uIGNvdWxkIGJlIG1vcmUgZ2VuZXJpYyBhbmQgYXBw bGllZCB0byBvdGhlciB1c2UgY2FzZXMgdGhhbg0KPiA+PiA+PiBNUFRDUC4gVGhlIGRyYWZ0IHRo YXQgZGVzY3JpYmVzIHRoZSBuZXcgZGVzaWduIGlzIGF2YWlsYWJsZSB2aWE6DQo+ID4+ID4+DQo+ ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25hdmVu dHVyZS1tcHRjcC0NCj4gPj4gY29udmVydGVycy0wMS50eHQNCj4gPj4gPj4NCj4gPj4gPj4NCj4g Pj4gPj4gTWlyamEgS3VlaGxld2luZCBzdWdnZXN0ZWQgdG8gc2VuZCB0aGUgZG9jdW1lbnQgb24g dGhlIGludC1hcmVhIGFuZA0KPiA+PiA+PiB0c3YtYXJlYSBtYWlsaW5nIGxpc3RzIHRvIHNlZSB3 aGV0aGVyIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGNvdWxkIGJlDQo+ID4+ID4+IGludGVyZXN0ZWQg YnkgdGhpcyBhcHByb2FjaC4NCj4gPj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQo+ ID4+ID4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ludC1hcmVhDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEludC1hcmVhIG1haWxpbmcgbGlzdA0KPiA+ PiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ludC1hcmVhDQo= From nobody Wed Jul 19 09:03:00 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA33127B60 for ; Wed, 19 Jul 2017 09:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 VgDjIbfEthrc for ; Wed, 19 Jul 2017 09:02:51 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 B9F6812F3CB for ; Wed, 19 Jul 2017 09:02:50 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id f21so3991656wrf.5 for ; Wed, 19 Jul 2017 09:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JyZUUwhZ0FxLQ/3kOfnewTNjAFXbiveoVhSGFtFTswM=; b=WZJhXUUXsISQqtT+IFwX7ZW97aaJpRgvy8tdjeKh0YHo/tzjC0Te7HxUnaiiaw0Mhc eFaM2EvmZnpxm8owlW2zzbCgdMoa2g1jxAbBFQGi3NVtXRAkPYrRhl2TF9dNdz9XsM+g ZgTOGwF6YjMyH+vGtf6iQi9Zh2U8RScH2DAhjZQYkVsR+C2m33620uvzCby/hGPR1/Lm p5dsyQyCcV6PEo429G/Lg2oQE4zenoSGObFl4cEm6NSTt3XTFowzzJu0j1JqcfEsurTS qcnzANBCF47YIoyrVt7m8XMsPfv+VWxaz2sX8CkY1vxnQwvcoUillY47JyLFzJ7k9asG YQ3w== 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=JyZUUwhZ0FxLQ/3kOfnewTNjAFXbiveoVhSGFtFTswM=; b=WesKhq0sWZ6sjttbekWiKoMhwKaEjU2Elzrwpewf83W15v9s48K+Zy7ikgVJT2sMlb j18ztE3yXp7xFGMIz3pFkFGAmS+LLhYuoMoJDHSHsOl1zbVbaXNnBsnRnF42ZYBEF01Q eFNq+dOuxrIkyaRLODhvv9lmiSCd8WKuSFCwiKmueX5hmyPHfVkXPlB2EhXlTDS7YcAw DcaDIiynHtITsmBSOVQ0FpKzOrl7ivE3THADCkbYgJQNphPQMuMUGSV0TXcVa37bCWg4 pVKkyWfWak0sU8UF1eALaw6yLR2/tNyrJgmZnmQiL9lcx7LuJr8AFTGJ6dsScXPwT7bM SImw== X-Gm-Message-State: AIVw112TZ5rl3wx/0xPtw78fAT9Z3rRRy9FYtj8FCF9sPe6H658ygyeH 2g+4UdA41HqB74skvpLh5ijiOhCiLJpL X-Received: by 10.223.169.2 with SMTP id u2mr751918wrc.288.1500480169275; Wed, 19 Jul 2017 09:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Wed, 19 Jul 2017 09:02:48 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Wed, 19 Jul 2017 09:02:48 -0700 Message-ID: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com Cc: Erik Kline , Joe Touch , Internet Area , "tsv-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:02:53 -0000 On Wed, Jul 19, 2017 at 1:46 AM, wrote: > Hi Erik, > > That's the intuitive approach to follow but unfortunately the situation i= s not that obvious to get into. > I can give a little background on the Linux situation. There have been several attempts to get MPTCP into the stack over the past few years. Each time the patches were rejected primary because of complexity and invasiveness. I believe in the initial attempt there were something like 7,000 LOC change to tcp and that was whittled down to 5K on the next attempt IIRC. It is not impossible to get the code in the stack, but it's going to take more work to minimize code change and convince the maintainer the complexity is justified. > Network providers do not have a control on the servers and the terminals = that are enabled by customers behind the CPE. So making use of MPTCP to gra= b more resources (when available) or to provide better resiliency (when a n= etwork attachment is lost) will require both endpoints to be MPTCP-capable. > Network providers don't control CPE is either. I know iOS has support for MPTCP, AFAIK Android does not (Erik is that correct?). If Android were shipping it that would be a strong datapoint towards getting support in Linux. Tom From nobody Wed Jul 19 09:16:33 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A794D12F3CB for ; Wed, 19 Jul 2017 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tessares-net.20150623.gappssmtp.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 FZhb0RNnz6mA for ; Wed, 19 Jul 2017 09:16:30 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 B1F05124234 for ; Wed, 19 Jul 2017 09:16:29 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w191so3730121wmw.1 for ; Wed, 19 Jul 2017 09:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=4Zr9Pw64c4LhWyCniChWA+DG8V1RKcFhhysjmiAwyF0=; b=lQ0T4cR3LKFTgv/3K6Xbdl3xKOcS0jMkij81s7myYUeO28+eZqUvtT3rzHfmPS/wBU cojlngniA7Sv4emRaeuOl0fjcEIwvi/OXf6smMzGQb0J8WPbfFmaLoUZzyrx0JeTTdHu JxWTSgstSrcJPdsIUZsc5SP1tSyK+Cydt1/toiB1akZHKW5OIQ83mRqn1vuv8bfgffL5 zZjGQHhL6ZFwud9hPgDNCJO7FwCkeDU5dyX2xLEIlKGS+3OUKLhTgHzlaaelzA/nzmRm fY4l3MOzvmiU4/Q5eja+1BG2SMTgOtm5ODelpCZhIoKerUe2g+xZl7ptpnGSGdhyVnIh bpDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4Zr9Pw64c4LhWyCniChWA+DG8V1RKcFhhysjmiAwyF0=; b=t+EwAX+3IruaEGz1OngIZxpNVn4SOIELx3TQ2RwK/dG4drsDFSqD9mYz2MlgEgwn+t AkNW9AbvkbLfaziZbYBB249xnW7JV0XJwGkYXUlrJBV2VGxYEbAGMX0sjeyb/3Ie4tUF jKzMk9fLEALqYjUP/zk1fLEO9o1QY18PAuNBm2mv+k9/QsHFhs6zW5NJozQLsG3lU44C thjesDMnshy65x9FHKCEBR3iICMsmjrD+ifli57fnrfsUa42/pMo0n/mb5IhCmWVBHcH MOetE3ZJyp4bm2Hkh3CodtBpi9rZqpwXYxnpdroZSWv+DZAI4ADkDyR8e5nDuTacWbWg 1qUA== X-Gm-Message-State: AIVw113hRenFKfxz65UZrzWMYnenrGcB9qySp9tgpWCRQ12WJ8/FX3rh SeMWz7tCps3goInE9ZCAk90hjlj+8FSdOPrnXL4AhNkHIzb3HQxqafKRn7fcXEK0+GY2TFUcDvE = X-Received: by 10.28.61.4 with SMTP id k4mr358451wma.146.1500480988265; Wed, 19 Jul 2017 09:16:28 -0700 (PDT) Received: from dhcp-88fc.meeting.ietf.org ([2001:67c:370:128:114e:6216:c2ae:75f]) by smtp.gmail.com with ESMTPSA id l8sm352543wmd.15.2017.07.19.09.16.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 09:16:27 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: Tom Herbert , mohamed.boucadair@orange.com Cc: "tsv-area@ietf.org" , Internet Area References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Olivier Bonaventure Message-ID: <2a6031ec-2c07-7bf6-8853-7980a183f5d1@tessares.net> Date: Wed, 19 Jul 2017 18:16:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:16:32 -0000 Tom, > Network providers don't control CPE is either. I know iOS has support > for MPTCP, AFAIK Android does not (Erik is that correct?). If Android > were shipping it that would be a strong datapoint towards getting > support in Linux. In South Korea, at least 8 popular models of Android smartphones from at least two different vendors are shipped to endusers with MPTCP included in their kernel even if MPTCP is not yet part of the mainline Linux kernel. This deployment is described in https://www.ietfjournal.org/multipath-tcp-deployments/ In June, when Apple announced that they would allow any app to use MPTCP in iOS11, they also mentioned that they would help to push MPTCP upstream in the Linux kernel. This will obvisouly require non-trivial engineering efforts. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 09:33:10 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E732412F3CB; Wed, 19 Jul 2017 09:33:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 vceVDXadn9xu; Wed, 19 Jul 2017 09:33:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 DE962127077; Wed, 19 Jul 2017 09:33:06 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JGWbHS020438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:32:37 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Joe Touch Message-ID: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> Date: Wed, 19 Jul 2017 09:32:35 -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: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> Content-Type: multipart/alternative; boundary="------------9D917349341C7457A2BBA51D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:33:08 -0000 This is a multi-part message in MIME format. --------------9D917349341C7457A2BBA51D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >> - IMO, TCP always needs to be able to fall back (which should be true >> now) > > This is not a concern with the proposed design Prove that is true if/when TCP-AO is enabled. Joe --------------9D917349341C7457A2BBA51D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
- IMO, TCP always needs to be able to fall back (which should be true now)

This is not a concern with the proposed design
Prove that is true if/when TCP-AO is enabled.
Joe
--------------9D917349341C7457A2BBA51D-- From nobody Wed Jul 19 09:36:18 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D3A131AA9; Wed, 19 Jul 2017 09:36:09 -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 HYQC9aEho4xJ; Wed, 19 Jul 2017 09:36:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 9FDD3131A50; Wed, 19 Jul 2017 09:36:07 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JGZYXr020887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:35:35 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Erik Kline Cc: Tom Herbert , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 09:35:32 -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: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:36:09 -0000 On 7/19/2017 1:46 AM, mohamed.boucadair@orange.com wrote: > So making use of MPTCP to grab more resources (when available) or to provide better resiliency (when a network attachment is lost) will require both endpoints to be MPTCP-capable. That is both correct and appropriate. Doing tricks to demonstrate that an attacker (i.e., something that modifies TCP segments on path) can do otherwise should not be considered a viable alternative. Joe From nobody Wed Jul 19 09:43:47 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCB131472; Wed, 19 Jul 2017 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 NtntyiVKVI94; Wed, 19 Jul 2017 09:43:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 3DDF9129482; Wed, 19 Jul 2017 09:43:40 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JGh2Gb025051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 09:43:03 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 09:43:01 -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: <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:43:41 -0000 On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > Joe, > >> - but I remain concerned with "injection piggybacking" > > To which section of the draft are you referring to ? It starts in the arch discussion in Sec 2: As shown in Figure 3, the Converter places its supplied information inside the handshake packets. That's what I refer to as "injection piggybacking" With TCP, the Converter protocol places the destination address and port number of the final Server in the payload of the SYN. And that is the part that violates RFC793 semantics when that SYN reaches the final destination rather than the server-side proxy. To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things. Joe From nobody Wed Jul 19 11:35:03 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775C01300CE; Wed, 19 Jul 2017 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 GEKlHsBbmmhj; Wed, 19 Jul 2017 11:34:59 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209FC12711E; Wed, 19 Jul 2017 11:34:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 7B6DEC055A; Wed, 19 Jul 2017 20:34:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 438B31A00BC; Wed, 19 Jul 2017 20:34:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:34:56 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAKy8ppsRiqt+CEm7nfWl0LOnS6JbeSxQ Date: Wed, 19 Jul 2017 18:34:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> In-Reply-To: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:35:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lLA0KDQpBcyBtZW50aW9uZWQgaW4gYSBwcmV2aW91cyBtZXNzYWdlIGluIHRoaXMgdGhyZWFk LCBUQ1AtQU8gZXh0ZW5zaW9ucyAoNjk3OCkgdG8gcGFzcyBOQVRzIHdpbGwgYmUgcmVxdWlyZWQg b3RoZXJ3aXNlIFRDUC1BTyB3aWxsIGZhaWwgYmVjYXVzZSBvZjoNCg0KLSAgICBNYW5pcHVsYXRp bmcgbXVsdGlwbGUgYWRkcmVzc2VzDQoNCi0gICAgQXQgbGVhc3Qgb25lIG9mIHRoZSBzb3VyY2Ug SVAgYWRkcmVzc2VzIHdpbGwgYmUgcmV3cml0dGVuLg0KDQpUaGUgcHJveHkgZGVzaWduIGRvZXMg bm90IGluZHVjZSBhIG5ldyBpc3N1ZSBmb3IgVENQLUFPLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUg OiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUgSm9lIFRvdWNoDQpFbnZvecOpIDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE4OjMzDQrD gCA6IE9saXZpZXIgQm9uYXZlbnR1cmU7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3Jn DQpPYmpldCA6IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVu dCBvZiBNUFRDUA0KDQoNCg0KDQpPbiA3LzE5LzIwMTcgMTI6NDEgQU0sIE9saXZpZXIgQm9uYXZl bnR1cmUgd3JvdGU6DQotIElNTywgVENQIGFsd2F5cyBuZWVkcyB0byBiZSBhYmxlIHRvIGZhbGwg YmFjayAod2hpY2ggc2hvdWxkIGJlIHRydWUgbm93KQ0KDQpUaGlzIGlzIG5vdCBhIGNvbmNlcm4g d2l0aCB0aGUgcHJvcG9zZWQgZGVzaWduDQpQcm92ZSB0aGF0IGlzIHRydWUgaWYvd2hlbiBUQ1At QU8gaXMgZW5hYmxlZC4NCkpvZQ0K --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ1MDI3MjQ3MzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMzNzYwMDg4MCAtMTE1MDI3NjU5MiA2Nzg5NTI5 OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2 Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZS IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Sm9lLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgbWVudGlvbmVkIGluIGEgcHJldmlv dXMgbWVzc2FnZSBpbiB0aGlzIHRocmVhZCwgVENQLUFPIGV4dGVuc2lvbnMgKDY5NzgpIHRvIHBh c3MgTkFUcyB3aWxsIGJlIHJlcXVpcmVkIG90aGVyd2lzZSBUQ1AtQU8gd2lsbCBmYWlsIGJlY2F1 c2Ugb2Y6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWFuaXB1 bGF0aW5nIG11bHRpcGxlIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkF0IGxlYXN0IG9uZSBvZiB0aGUgc291cmNlIElQIGFkZHJlc3NlcyB3aWxs IGJlIHJld3JpdHRlbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaGUgcHJveHkgZGVzaWduIGRvZXMgbm90IGluZHVjZSBhIG5ldyBpc3N1ZSBm b3IgVENQLUFPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g SW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFy dCBkZTwvYj4gSm9lIFRvdWNoPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDE5 IGp1aWxsZXQgMjAxNyAxODozMzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gT2xpdmllciBCb25hdmVu dHVyZTsgSW50ZXJuZXQgQXJlYTsgdHN2LWFyZWFAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBv ZiBNUFRDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gNy8xOS8yMDE3IDEyOjQxIEFNLCBPbGl2aWVyIEJvbmF2ZW50 dXJlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBJTU8sIFRDUCBhbHdheXMgbmVlZHMgdG8gYmUgYWJsZSB0byBmYWxsIGJhY2sgKHdoaWNo IHNob3VsZCBiZSB0cnVlIG5vdykNCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBpcyBub3QgYSBjb25jZXJuIHdpdGggdGhlIHBy b3Bvc2VkIGRlc2lnbiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlByb3ZlIHRoYXQgaXMgdHJ1ZSBpZi93aGVuIFRDUC1BTyBpcyBlbmFibGVkLjxi cj4NCkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_787AE7BB302AE849A7480A190F8B93300A00F38COPEXCLILMA3corp_-- From nobody Wed Jul 19 11:39:29 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07782131B9B; Wed, 19 Jul 2017 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 XkPVu6wUoXsA; Wed, 19 Jul 2017 11:39:26 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5CD131B3E; Wed, 19 Jul 2017 11:39:26 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2A4BFC055A; Wed, 19 Jul 2017 20:39:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E3C6720071; Wed, 19 Jul 2017 20:39:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:39:24 +0200 From: To: Joe Touch , Erik Kline CC: Tom Herbert , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAK0hByPMqBya7E2aRTfcerPMC6JbeiqA Date: Wed, 19 Jul 2017 18:39:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:39:28 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5l ZHVdDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTkganVpbGxldCAyMDE3IDE4OjM2DQo+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEVyaWsgS2xpbmUNCj4gQ2PCoDogVG9tIEhlcmJl cnQ7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbSW50 LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVudCBvZiBNUFRDUA0KPiANCj4g DQo+IA0KPiBPbiA3LzE5LzIwMTcgMTo0NiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSB3cm90ZToNCj4gPiBTbyBtYWtpbmcgdXNlIG9mIE1QVENQIHRvIGdyYWIgbW9yZSByZXNvdXJj ZXMgKHdoZW4gYXZhaWxhYmxlKSBvciB0bw0KPiBwcm92aWRlIGJldHRlciByZXNpbGllbmN5ICh3 aGVuIGEgbmV0d29yayBhdHRhY2htZW50IGlzIGxvc3QpIHdpbGwgcmVxdWlyZQ0KPiBib3RoIGVu ZHBvaW50cyB0byBiZSBNUFRDUC1jYXBhYmxlLg0KPiBUaGF0IGlzIGJvdGggY29ycmVjdCBhbmQg YXBwcm9wcmlhdGUuDQo+IA0KW01lZF0gT0suIA0KDQo+IERvaW5nIHRyaWNrcyB0byBkZW1vbnN0 cmF0ZSB0aGF0IGFuIGF0dGFja2VyIChpLmUuLCBzb21ldGhpbmcgdGhhdA0KPiBtb2RpZmllcyBU Q1Agc2VnbWVudHMgb24gcGF0aCkgY2FuIGRvIG90aGVyd2lzZSBzaG91bGQgbm90IGJlIGNvbnNp ZGVyZWQNCj4gYSB2aWFibGUgYWx0ZXJuYXRpdmUuDQoNCltNZWRdIFdlIGFyZSBkZWZpbmluZyBh biBhcHBsaWNhdGlvbiBwcm94eSB0aGF0IGFzc2lzdCB0aGUgdXNlciB0byBtYXhpbWl6ZSB0aGUg dXNlIG9mIGl0cyBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMuIFRoZSBwcm94eSByZWxpZXMg b24gSUVURiBkZWZpbmVkIEJDUHMgKGRlZmluZWQgYnkgYmVoYXZlIGFuZCB0c3Z3ZykgdG8gcmVs YXkgVENQIHBhY2tldHMuIA0KDQo+IEpvZQ0K From nobody Wed Jul 19 11:43:22 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564D6127180; Wed, 19 Jul 2017 11:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FJMYxFPhfnyW; Wed, 19 Jul 2017 11:43:19 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1511267BB; Wed, 19 Jul 2017 11:43:18 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 6171AC051F; Wed, 19 Jul 2017 20:43:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2F83B20071; Wed, 19 Jul 2017 20:43:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:43:16 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAK4x0P3r/ocVwkudgYRoNLkuu6Jbe2Nw Date: Wed, 19 Jul 2017 18:43:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:43:20 -0000 Re-,=20 I don't understand your argument here, especially because you are the one w= ho proposed me the following (check mptcp archives, April 20, 2017) which w= e endorsed in the latest version of the specification: "If that were the case, you'd simply be defining a new application service = and asking for a TCP port number." Are you saying that you suggested us a bad design choice? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touc= h > Envoy=E9=A0: mercredi 19 juillet 2017 18:43 > =C0=A0: Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 >=20 >=20 > On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > > Joe, > > > >> - but I remain concerned with "injection piggybacking" > > > > To which section of the draft are you referring to ? > It starts in the arch discussion in Sec 2: >=20 > As shown in Figure 3, the Converter places its supplied information > inside the handshake packets. >=20 > That's what I refer to as "injection piggybacking" >=20 > With TCP, the Converter protocol places the destination address and > port number of the final Server in the payload of the SYN. >=20 > And that is the part that violates RFC793 semantics when that SYN reaches > the final destination rather than the server-side proxy. >=20 > To be clear, I'm not interested in further trying to "fix" this mechanism > so it can work. It can't and it shouldn't IMO. Let's use our cycles for > more productive things. >=20 > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 12:37:44 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549AE1242F7 for ; Wed, 19 Jul 2017 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=tessares-net.20150623.gappssmtp.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 vxSSBfYojiOi for ; Wed, 19 Jul 2017 12:37:35 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 DFDA8129AF6 for ; Wed, 19 Jul 2017 12:37:33 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id f21so6017801wrf.5 for ; Wed, 19 Jul 2017 12:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=vPqMfgVCxfY8vHbvyYLT82fAhudiThTCtJG/VzXmjP0=; b=ejgtwwsmZYhOwL84Xf01chTfOpbFSM4N/0VKgGEsx3XXfuANmnr7VYof3U/GRU6p1M ipBK6U1u94Pz8H/xbYRLqmUrP3JEvemnp9bjxomrZWY+S4aJL3K192wKj4UAEeB79Itb 7iG2IeQ6/kHyupdRFVQ9y+7CKQtbJjkj6T/3IjpgaTMlbtvWW837MKvCKwdPtSyEPbpQ tpU5n2DlOOt8JvmLpD0/F0EW5UG64mw0wVD/lQAMzcbNIS7o5u4sOUJYJ20d3kGPUaf9 83Pqn77AGemZFY6JSINtjhnVgttK9Rv7Le4nJ39IWanctfWxLshtg+H+ULA6zMjLAbh4 CzIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vPqMfgVCxfY8vHbvyYLT82fAhudiThTCtJG/VzXmjP0=; b=SGh4Di6W2D+ae4w7m7xWyR1TNjZdMZv3hVSzu/2+VQFPsm5XvMPziQ4hhL11Lu7Dyd Z0IXUNQxlXtvG1R1QnQH8s5M0UEy7RwwGPuBOXmkuwet7xG1M5zF2EhhOCEtPR2+WAZ9 KwHhJXXja5NYqh5yOClEVoJPgqszu7Y1U51gvVdNelA8aRZA43G7+7S3qn9sJNkU16fa fbi8uNPYjzqJoEstkWWS6VKPuZwtv1sbatk4t4cDaFdum7YqJKsXyM0oGLga3JWG3CdY VrXgMR6diWTCsgeqduarTOiZRJjGFFtIG+hcfc3SgWFme7D3utrZVG38VpK01FymIBrZ jcSw== X-Gm-Message-State: AIVw112N4cenm4Q8WlHd8rhOorokAOOiQHCuKmg9d783JLQfIjtvqRRY mXw96LgDHfLED9raRveCISF1eEYc8yqzwsbu3OzUtwtTehLc/i+h2yUHHMcildbpQTQqrGGO7vk = X-Received: by 10.223.132.133 with SMTP id 5mr4867209wrg.132.1500493052218; Wed, 19 Jul 2017 12:37:32 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id u1sm1002921wrd.73.2017.07.19.12.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:37:16 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> From: Olivier Bonaventure Message-ID: Date: Wed, 19 Jul 2017 21:37:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:37:36 -0000 On 19/07/17 18:32, Joe Touch wrote: > > > On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>> - IMO, TCP always needs to be able to fall back (which should be true >>> now) >> >> This is not a concern with the proposed design > Prove that is true if/when TCP-AO is enabled. I don't think that TCP-AO is a use case for the proposed converters. If an application requests TCP-AO, then it indicates that it expects authentication until the server. I do not see a benefit of having authentication on a subset of the path. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:40:17 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104E4126DC2 for ; Wed, 19 Jul 2017 12:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=tessares-net.20150623.gappssmtp.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 nlA0qIpinEOh for ; Wed, 19 Jul 2017 12:40:08 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 B8B46128A32 for ; Wed, 19 Jul 2017 12:40:07 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y43so62516463wrd.3 for ; Wed, 19 Jul 2017 12:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=nsZ+ULuz1U1kJ33q2amkvJMg5X6gmoPOu8FdJn5U2LY=; b=wATenLkTT+ty8apghpOSRWE33xBrUU7t1fLzup82CK38ntEt+sBiHWtsH2WwQ42Gk3 zHHIX6FWYMqaKV1VnwwmyAB8K49b/xhLfndoNwkn2PDyTOYg+/aAtjeCbCB+Whay6UYW 2SqdIcHgsvLkSnb2f+xpv/KNqIjFsnoUP5mcZSvQVjSVHcRqrORKQ5AgFD4n6yoTQ+dn 0sc9cH2GJMDRZV4Q1SmaHG7j6rCuSsTzUNnqQL8orXComN4wn4g9lJrgTelDc67UjsTG abhRyH1oxSLeooWsBvN2INTEsVmK9+EVcROvB9PLGdnPEd+Dl5WL+6V6kcYNNQNOQl3k RxqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=nsZ+ULuz1U1kJ33q2amkvJMg5X6gmoPOu8FdJn5U2LY=; b=LREzPTnLvyb6j2fmcQHdPfd+i9OB8QVUNJ1qV4PHQp8Gy2x6BWR1zeFCrLSJylITaI NaXi2DxzSgTgTncn4U8rqwRGzkTJkmbabCCzCDCUcNqpFLCHtovBwqGl+CLyuhT8WyPj zg+ecbQOZB670GPm21LdMBIjkQ9Eh7GQGpmrwP2PhqLHt+gPRSrk81ZXqzp3ItJxfKRi TQPAQVjttTCYVtJ4pT5TWKfogWhfkUsgowljaWSeOU4c1ZZPuwic3pSyQaF8JzFxOa6l 4pjb7HAceOF4/ttq5+l7yRwQq4GlcHCj2AJ44MrM00o4qctKzFqVrdeusH+rU7J0j86q pb2w== X-Gm-Message-State: AIVw112G7tTYefpEW8uWzubF/Mmv+BPWOMp6kqu5AtUvhvk0juHsh0ZE eaOWEcGdqI9B4OlU35bhRrGHdT9qXKlhAd4wLYbWAFk1eVtAchbhofGoHnybOm7TiCwHSALl/H4 = X-Received: by 10.223.171.200 with SMTP id s66mr3990025wrc.38.1500493206072; Wed, 19 Jul 2017 12:40:06 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id u66sm1481462wrb.77.2017.07.19.12.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:40:05 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> From: Olivier Bonaventure Message-ID: <00d13338-0471-2830-d659-7c28c784671f@tessares.net> Date: Wed, 19 Jul 2017 21:40:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:40:10 -0000 Joe, > > To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things. I agree that we disagree on this point. As I said in the draft, I would like to thank you once again for your comments that have been very helpful in improving the draft compared to earlier iterations. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:43:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563CE126DC2; Wed, 19 Jul 2017 12:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 LIOp5AhXftEM; Wed, 19 Jul 2017 12:43:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 3C91D128A32; Wed, 19 Jul 2017 12:43:46 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJhMlL008389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:43:23 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 12:43:21 -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: <787AE7BB302AE849A7480A190F8B93300A00F38C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------1A07C61261265D9BBD079C2D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:43:47 -0000 This is a multi-part message in MIME format. --------------1A07C61261265D9BBD079C2D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:34 AM, mohamed.boucadair@orange.com wrote: > > Joe, > > > > As mentioned in a previous message in this thread, TCP-AO extensions > (6978) to pass NATs will be required otherwise TCP-AO will fail > because of: > > - Manipulating multiple addresses > > - At least one of the source IP addresses will be rewritten. > TCP-AO-NAT is experimental. It also has nothing to do with whether the TCP options are covered - that's determined by the MKT on a per-connection basis, and is opaque to on-path devices. An on-path device that manipulates TCP options would break TCP-AO-NAT if the MKT covers the options. Joe --------------1A07C61261265D9BBD079C2D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/19/2017 11:34 AM, mohamed.boucadair@orange.com wrote:

Joe,

 

As mentioned in a previous message in this thread, TCP-AO extensions (6978) to pass NATs will be required otherwise TCP-AO will fail because of:

-    Manipulating multiple addresses

-    At least one of the source IP addresses will be rewritten.

TCP-AO-NAT is experimental.

It also has nothing to do with whether the TCP options are covered - that's determined by the MKT on a per-connection basis, and is opaque to on-path devices.

An on-path device that manipulates TCP options would break TCP-AO-NAT if the MKT covers the options.

Joe
--------------1A07C61261265D9BBD079C2D-- From nobody Wed Jul 19 12:45:58 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85369131468; Wed, 19 Jul 2017 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BGANJt30ejID; Wed, 19 Jul 2017 12:45:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 5058C126DC2; Wed, 19 Jul 2017 12:45:54 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJj3At008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:45:04 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Erik Kline Cc: Tom Herbert , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 12:45:01 -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: <787AE7BB302AE849A7480A190F8B93300A00F3A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------62814551B0BA39CB381CD993" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:45:56 -0000 This is a multi-part message in MIME format. --------------62814551B0BA39CB381CD993 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:39 AM, mohamed.boucadair@orange.com wrote: >> Doing tricks to demonstrate that an attacker (i.e., something that >> modifies TCP segments on path) can do otherwise should not be considered >> a viable alternative. > [Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets. Application proxies don't relay TCP segments. They don't even see TCP segments. And they can't work unless the client opens a connection to the proxy; if the client opens a connection to the server, then intercepting and modifying the TCP segments in-flight is called an attack on TCP. Joe --------------62814551B0BA39CB381CD993 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/19/2017 11:39 AM, mohamed.boucadair@orange.com wrote:
Doing tricks to demonstrate that an attacker (i.e., something that
modifies TCP segments on path) can do otherwise should not be considered
a viable alternative.

[Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets.
Application proxies don't relay TCP segments. They don't even see TCP segments.

And they can't work unless the client opens a connection to the proxy; if the client opens a connection to the server, then intercepting and modifying the TCP segments in-flight is called an attack on TCP.

Joe
--------------62814551B0BA39CB381CD993-- From nobody Wed Jul 19 12:46:22 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DCD126DC2; Wed, 19 Jul 2017 12:46:21 -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 jf965BnTbTvj; Wed, 19 Jul 2017 12:46:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 6C29D131BBE; Wed, 19 Jul 2017 12:46:16 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJjwJV009101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:45:59 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> Date: Wed, 19 Jul 2017 12:45:57 -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: <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:46:21 -0000 On 7/19/2017 11:43 AM, mohamed.boucadair@orange.com wrote: > I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification: > > "If that were the case, you'd simply be defining a new application service and asking for a TCP port number." > > Are you saying that you suggested us a bad design choice? The text I saw talks about SYN packets. If this is at the application layer - and doesn't hijack TCP connections to other IP addresses - then it's fine, but then the ID is very badly in need of revision. I'm working off the text I saw. Joe From nobody Wed Jul 19 12:47:56 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6186C126DC2; Wed, 19 Jul 2017 12:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 T4-2_iB2a97c; Wed, 19 Jul 2017 12:47:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 646451200FC; Wed, 19 Jul 2017 12:47:46 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJlRi0009848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:47:28 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> From: Joe Touch Message-ID: <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> Date: Wed, 19 Jul 2017 12:47:25 -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: Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:47:47 -0000 On 7/19/2017 12:37 PM, Olivier Bonaventure wrote: > On 19/07/17 18:32, Joe Touch wrote: >> >> >> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>> - IMO, TCP always needs to be able to fall back (which should be >>>> true now) >>> >>> This is not a concern with the proposed design >> Prove that is true if/when TCP-AO is enabled. > > I don't think that TCP-AO is a use case for the proposed converters. You don't get to decide that. If you use TCP, then TCP-AO could be enabled on the client. Joe From nobody Wed Jul 19 12:52:08 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1D131B56 for ; Wed, 19 Jul 2017 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 4PS3_hjTI-HC for ; Wed, 19 Jul 2017 12:52:00 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 9DF2E12EC06 for ; Wed, 19 Jul 2017 12:51:59 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w126so7742756wme.0 for ; Wed, 19 Jul 2017 12:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=H7DT39MxiQSwehgq/oJNw72QDXszrZCPClqOC8kM2Y8=; b=ZSed486LibhlRTGC1zXudF2DcY9hDNc5wg9kyAkNQfFRkptfiSZNIIjw4NHgnwJt3b GDnnNLulqWlp1OEr9LpJ7RUH8CmfpU8Eh4VXZ4nEXEFKzioSuwGehDIsLsze0p5kfi74 mRAqf8xzvZDxV5+/isqFn8w5dwhyKQyrT+L6JKI4gUvqQGTvrlCvG7jdPoJmZvwsNLaH efwEJVTKmeXDxisHh7/SORGxB377KtQ/u6qM4UHUcBJn+HdC3m7mjOd/O6RWTm1a6kmS 1vro2//fzDZD98yuqBLMXqHjFyvlnf32wByS+d97zcS12kiMbcmmo6dfmBGCIYgTMre6 VWyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=H7DT39MxiQSwehgq/oJNw72QDXszrZCPClqOC8kM2Y8=; b=L2OrAWfVRo0RuWOTqxn2zjOmB1beIJvuJkVm1seJn+mAs/I/dDIDV/GXs2Eyuc2TOM qyAdNWM4DjdGZVCUq5NtybozfTVa88QT9xP63lvvCr1gzV6BKmkmQEnwRbtvE4OqBXor BbIPII7NUowdjavNBLbQuGLUYpHsoqqBvw3PQ6FZD6TswAlvNGCcCfTY9P3grMt1qMLH 0zGiyYXgp76rhw+sKbXdMETyhnBk8be9C2rBWNozukW2imntL9Zt7OpFW2TV7EvqbH8Q JHAI8PnXUu0p7Tl+wcR4yqm2Jq307vfND7Ui3efoDmsmTU4WRb5ihDIvE/asAuP17n34 25wg== X-Gm-Message-State: AIVw112M3DxEItz3OQkopJYIduDfXwvXOVvQdUsgHyUj6kBJ/Zzb1cwc 5wMgDhaPxCxFtznrnANaAqA6m2WcC3gSfp3oHeXMwFAbngc6FrN99pSeW1HLkF0O1UZvSmzYl0E = X-Received: by 10.28.95.137 with SMTP id t131mr723996wmb.102.1500493917962; Wed, 19 Jul 2017 12:51:57 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id y84sm651310wmg.12.2017.07.19.12.51.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 12:51:57 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> From: Olivier Bonaventure Message-ID: Date: Wed, 19 Jul 2017 21:51:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:52:02 -0000 Joe, >>> >>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>>> - IMO, TCP always needs to be able to fall back (which should be >>>>> true now) >>>> >>>> This is not a concern with the proposed design >>> Prove that is true if/when TCP-AO is enabled. >> >> I don't think that TCP-AO is a use case for the proposed converters. > > You don't get to decide that. If you use TCP, then TCP-AO could be > enabled on the client. The converter is not intended to be used for all TCP connections. In the draft we explain how an MPTCP endpoint can bypass the converter if the destination server supports MPTCP. For TCP-AO, my recommendation would be that the default policy of the client would be to never use the converter if TCP-AO is requested by the application. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Jul 19 12:58:19 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF26129789; Wed, 19 Jul 2017 12:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 KUHH0gUxysP1; Wed, 19 Jul 2017 12:58:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 8195D120724; Wed, 19 Jul 2017 12:58:17 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJvlvm015068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:57:47 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> From: Joe Touch Message-ID: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> Date: Wed, 19 Jul 2017 12:57:46 -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: Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:58:18 -0000 On 7/19/2017 12:51 PM, Olivier Bonaventure wrote: > Joe, >>>> >>>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: >>>>>> - IMO, TCP always needs to be able to fall back (which should be >>>>>> true now) >>>>> >>>>> This is not a concern with the proposed design >>>> Prove that is true if/when TCP-AO is enabled. >>> >>> I don't think that TCP-AO is a use case for the proposed converters. >> >> You don't get to decide that. If you use TCP, then TCP-AO could be >> enabled on the client. > > The converter is not intended to be used for all TCP connections. In > the draft we explain how an MPTCP endpoint can bypass the converter if > the destination server supports MPTCP. For TCP-AO, my recommendation > would be that the default policy of the client would be to never use > the converter if TCP-AO is requested by the application. How do you know you're using the converter? Is the initial connection to that converter? Or does the converter hijack (the latter is the implication of the text, AFAICT). Joe From nobody Wed Jul 19 22:39:14 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20DE12783A; Wed, 19 Jul 2017 22:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 k5m1KJ2MEoQH; Wed, 19 Jul 2017 22:39:05 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A732126B6E; Wed, 19 Jul 2017 22:39:05 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id CBF5640522; Thu, 20 Jul 2017 07:39:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7ECBA1C00B1; Thu, 20 Jul 2017 07:39:03 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 07:39:03 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAMej/WwR69lLRUy6PvQRGBZ9W6JcMrmw Date: Thu, 20 Jul 2017 05:39:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> In-Reply-To: <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:39:07 -0000 SGkgSm9lLCANCg0KVGhlIHRleHQgY2FuIGFsd2F5cyBiZSB3b3JrZWQgb3V0LiBUaGlzIGlzIG5v dCBhbiBJRVRGIExDIDopDQoNClRoZSBtYWluIHBvaW50IGlzIHRoYXQgd2UgYXJlIGZvbGxvd2lu ZyB5b3VyIHN1Z2dlc3Rpb24gdG8gZGVmaW5lIHRoZSBzb2x1dGlvbiBhcyBhbiBhcHBsaWNhdGlv biBwcm94eSB1c2luZyBhIGRlZGljYXRlZCBwb3J0IG51bWJlci4gDQoNCkNoZWVycywNCk1lZA0K DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0 bzp0b3VjaEBpc2kuZWR1XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDE5IGp1aWxsZXQgMjAxNyAy MTo0Ng0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBPbGl2aWVyIEJvbmF2ZW50 dXJlOyBJbnRlcm5ldCBBcmVhOyB0c3YtDQo+IGFyZWFAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6 IFtJbnQtYXJlYV0gTWlkZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+ IA0KPiANCj4gDQo+IE9uIDcvMTkvMjAxNyAxMTo0MyBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSB3cm90ZToNCj4gPiBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudCBoZXJl LCBlc3BlY2lhbGx5IGJlY2F1c2UgeW91IGFyZSB0aGUNCj4gb25lIHdobyBwcm9wb3NlZCBtZSB0 aGUgZm9sbG93aW5nIChjaGVjayBtcHRjcCBhcmNoaXZlcywgQXByaWwgMjAsIDIwMTcpDQo+IHdo aWNoIHdlIGVuZG9yc2VkIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNhdGlv bjoNCj4gPg0KPiA+ICJJZiB0aGF0IHdlcmUgdGhlIGNhc2UsIHlvdSdkIHNpbXBseSBiZSBkZWZp bmluZyBhIG5ldyBhcHBsaWNhdGlvbg0KPiBzZXJ2aWNlIGFuZCBhc2tpbmcgZm9yIGEgVENQIHBv cnQgbnVtYmVyLiINCj4gPg0KPiA+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IHN1Z2dlc3RlZCB1 cyBhIGJhZCBkZXNpZ24gY2hvaWNlPw0KPiBUaGUgdGV4dCBJIHNhdyB0YWxrcyBhYm91dCBTWU4g cGFja2V0cy4NCj4gDQo+IElmIHRoaXMgaXMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIC0gYW5k IGRvZXNuJ3QgaGlqYWNrIFRDUCBjb25uZWN0aW9ucw0KPiB0byBvdGhlciBJUCBhZGRyZXNzZXMg LSB0aGVuIGl0J3MgZmluZSwgYnV0IHRoZW4gdGhlIElEIGlzIHZlcnkgYmFkbHkgaW4NCj4gbmVl ZCBvZiByZXZpc2lvbi4gSSdtIHdvcmtpbmcgb2ZmIHRoZSB0ZXh0IEkgc2F3Lg0KPiANCj4gSm9l DQoNCg== From nobody Wed Jul 19 22:44:03 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF01124D85; Wed, 19 Jul 2017 22:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oZvvwO5G3uKn; Wed, 19 Jul 2017 22:43:52 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE82124217; Wed, 19 Jul 2017 22:43:52 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id AF329C0503; Thu, 20 Jul 2017 07:43:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 76D6F1A00C4; Thu, 20 Jul 2017 07:43:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 07:43:50 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAMZ+/WwR69lLRUy6PvQRGBZ9W6JbbJyAgAABRICAAAGgAIAAw/oQ Date: Thu, 20 Jul 2017 05:43:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> In-Reply-To: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:43:54 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touc= h > Envoy=E9=A0: mercredi 19 juillet 2017 21:58 > =C0=A0: Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet=A0: Re: [Int-area] Middleboxes to aid the deployment of MPTCP >=20 >=20 >=20 > On 7/19/2017 12:51 PM, Olivier Bonaventure wrote: > > Joe, > >>>> > >>>> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote: > >>>>>> - IMO, TCP always needs to be able to fall back (which should be > >>>>>> true now) > >>>>> > >>>>> This is not a concern with the proposed design > >>>> Prove that is true if/when TCP-AO is enabled. > >>> > >>> I don't think that TCP-AO is a use case for the proposed converters. > >> > >> You don't get to decide that. If you use TCP, then TCP-AO could be > >> enabled on the client. > > > > The converter is not intended to be used for all TCP connections. In > > the draft we explain how an MPTCP endpoint can bypass the converter if > > the destination server supports MPTCP. For TCP-AO, my recommendation > > would be that the default policy of the client would be to never use > > the converter if TCP-AO is requested by the application. >=20 > How do you know you're using the converter? [Med] The converter is explicilty configured (e.g., locally configured or y= means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07).=20 Is the initial connection to > that converter? [Med] When a connection is eligible to network-assisted MPTCP, the first su= bflow will be established via the converter. Subsequent flows will be estab= lished with that proxy involved. Packets are sent with destination IP addre= ss set to the one of the converter.=20 Or does the converter hijack (the latter is the > implication of the text, AFAICT). >=20 > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 19 23:19:15 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DF8124217 for ; Wed, 19 Jul 2017 23:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 p0NQXi9ctqR6 for ; Wed, 19 Jul 2017 23:19:07 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 B167F12783A for ; Wed, 19 Jul 2017 23:19:06 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id k69so15394649wmc.1 for ; Wed, 19 Jul 2017 23:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=apj3CGXPkH6i1uOYB8ogAiPiobAisoUrp1NWOzGVzXM=; b=K3wUBf6N9281U9nu0Q5CgT/335I9AtZe/mVQanmpMIZu9dodAkGDEr7y9DQAjMwO7k ANIv7nMge0xWPkUJtih0MA4Apf/ZoA0cHWq/MOVgspDcCeqtRUPi5BOcWASMjgHz5jFc oHgXLbKBN4rKdVgM8UiiVGO/S413Ltwme4k1jAIH4IyYhSF3bF1/qHYU8I5TcNB/dLe2 btXTzw4nVef36pzV+jA1QVaEmtdEBXvLMwj7RlSUoxsZtPpfd03++ZuDYmsT71JMplFX FiDtj8GLP/4oLtbhbne4oQRaR/oyn1Uv3iFNE0h+d6w+nluK9FjBc3u3riruxa7Y1yhK uR7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=apj3CGXPkH6i1uOYB8ogAiPiobAisoUrp1NWOzGVzXM=; b=UqdCAkrw719CXr2bwW8I2gcuTUuvjVZJBYhRcXXqWfP8TCJeA2ycSLywNXFGFeqovD bkxZ36FZeQZujZiuMTqSY7WiGNGPuvHwl3yaJKlpwc4zlKyNBe45DHbevO45mVZwQ84K agst12tYSZv/jcYGvGCLo5AMOo0pwyupS3JyyWa9QGML5xiiAZcn44L9V+73VL31a6hs co5N+UPLTSG+B4i8Yn/H/31B4x7q8+pIbrZYpfwLT7ZeJC3Zr3pLNYbIeSQOfR1wRf5o AhYToiyFCUf59P+2Cxlpd3Ol8WjiI2YqtNCDaeRRkl7wKpgH4nnlQ53BeiVt6f8y61Gg foMg== X-Gm-Message-State: AIVw112Rl3X0oGRQ2hY55OAeYK/uxkXX7zdlBJlX8/brFjayoOHG1YGx 2dKMZK38wijDR40vihcduhlno8AO7ATaQDwoX7svo+1BgePuIZjgpV9HaiN38DcgoRL9wlpnV8Y = X-Received: by 10.28.212.7 with SMTP id l7mr1523103wmg.31.1500531544928; Wed, 19 Jul 2017 23:19:04 -0700 (PDT) Received: from mbpobo.local ([80.188.36.206]) by smtp.gmail.com with ESMTPSA id j137sm2270634wmf.43.2017.07.19.23.19.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 23:19:04 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Joe Touch , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> From: Olivier Bonaventure Message-ID: <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> Date: Thu, 20 Jul 2017 08:19:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:19:09 -0000 Joe, >>>> >>>> I don't think that TCP-AO is a use case for the proposed converters. >>> >>> You don't get to decide that. If you use TCP, then TCP-AO could be >>> enabled on the client. >> >> The converter is not intended to be used for all TCP connections. In >> the draft we explain how an MPTCP endpoint can bypass the converter if >> the destination server supports MPTCP. For TCP-AO, my recommendation >> would be that the default policy of the client would be to never use >> the converter if TCP-AO is requested by the application. > > How do you know you're using the converter? Is the initial connection to > that converter? Or does the converter hijack (the latter is the > implication of the text, AFAICT). Consider a simple implementation using LD_PRELOAD to overload the connect system call on Linux. When the application issues connect, it has already set the required socket options that apply for this new connection. The converter implementation uses the destination address of the connect system call to create the TLV message and sets the TFO socket option to send it during its own connect with the converter. If the application had requested TFO, then the converter library simply uses the regular connect call and everything is fine. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Thu Jul 20 07:37:59 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917D8131C67; Thu, 20 Jul 2017 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 AL9OtI9lF34V; Thu, 20 Jul 2017 07:37:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 9B793131C66; Thu, 20 Jul 2017 07:37:50 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEbM0C008791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:37:33 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> Date: Thu, 20 Jul 2017 07:37:20 -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: <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:37:51 -0000 On 7/19/2017 10:39 PM, mohamed.boucadair@orange.com wrote: > Hi Joe, > > The text can always be worked out. This is not an IETF LC :) Agreed - I was explaining that the current text - and many of the responses in this chain, both from you and others, continues to be confusing. > The main point is that we are following your suggestion to define the solution as an application proxy using a dedicated port number. As feedback for the doc, that could be made more explicit, including in the title (this is an application proxy, not typically referred to as middleboxes). That also includes limiting the doc to using TCP app-layer APIs and describing any behavior that *might* happen at the segment level as just that - hypothetical, perhaps desired, but NOT the mechanism being proposed. FWIW. Joe From nobody Thu Jul 20 07:40:35 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268AE131C66; Thu, 20 Jul 2017 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ULOI9UTUyoTh; Thu, 20 Jul 2017 07:40:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 B88CE1317A4; Thu, 20 Jul 2017 07:40:26 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEdZeq009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:39:47 -0700 (PDT) Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com, Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Thu, 20 Jul 2017 07:39:33 -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: <787AE7BB302AE849A7480A190F8B93300A00F6BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 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-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:40:28 -0000 On 7/19/2017 10:43 PM, mohamed.boucadair@orange.com wrote: > ... >>> The converter is not intended to be used for all TCP connections. In >>> the draft we explain how an MPTCP endpoint can bypass the converter if >>> the destination server supports MPTCP. For TCP-AO, my recommendation >>> would be that the default policy of the client would be to never use >>> the converter if TCP-AO is requested by the application. >> How do you know you're using the converter? > [Med] The converter is explicilty configured (e.g., locally configured or y means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07). AOK. If these are independent TCP connections that are explicitly addressed, they should be described as such. The current doc implies SYN translation - whether that's an implementation optimization (limited to successful TFO SYNs) or not needs to be very clearly described as such as well. Joe From nobody Thu Jul 20 07:52:31 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25E131A7A; Thu, 20 Jul 2017 07:52:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 EUOYEVtvJKvn; Thu, 20 Jul 2017 07:52:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 148EF131CFA; Thu, 20 Jul 2017 07:52:23 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KEpcuc024893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:51:48 -0700 (PDT) Subject: Re: Middleboxes to aid the deployment of MPTCP To: Olivier Bonaventure , Internet Area , tsv-area@ietf.org References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <6977c9a1-19b8-0bf5-4396-3cc3d8385b57@isi.edu> <7b76a8de-d07e-a51d-28fc-f6d3e70b9f1c@isi.edu> <2ee957ad-757b-c457-f6ff-894a3d995149@isi.edu> <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> From: Joe Touch Message-ID: <63ad0458-0eed-e843-fec8-aadcedcc3e74@isi.edu> Date: Thu, 20 Jul 2017 07:51:36 -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: <3bf7fffa-c267-5d67-c124-01fa52ebafdc@tessares.net> Content-Type: multipart/alternative; boundary="------------1BBCBFC63D2B35D9D0089E4D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:52:25 -0000 This is a multi-part message in MIME format. --------------1BBCBFC63D2B35D9D0089E4D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/19/2017 11:19 PM, Olivier Bonaventure wrote: >> How do you know you're using the converter? Is the initial connection to >> that converter? Or does the converter hijack (the latter is the >> implication of the text, AFAICT). > > Consider a simple implementation using LD_PRELOAD to overload the > connect system call on Linux. When the application issues connect, it > has already set the required socket options that apply for this new > connection. The converter implementation uses the destination address > of the connect system call to create the TLV message and sets the TFO > socket option to send it during its own connect with the converter. If > the application had requested TFO, then the converter library simply > uses the regular connect call and everything is fine. The Linux API is not the TCP API. The TCP API is a generic, implementation-independent interface to upper layer protocols and applications. This mechanism needs to be described in terms of the TCP API. Yes, the app can SEND data to the socketpair before the connection is established, per RFC793 (note - I'm using 793 terms, not unix terms here). There's nothing in RFC7413 (TFO) that confirms that TFO will succeed on a new connection and that RFC explicitly admits it did not introduce an API extension by which an application can read (RECEIVE) SYN data before the connection is established: But the client's socket may have data available to read before it's connected. This document does not cover the corresponding API change. I.e., it's important to explain what you're doing using the TCP API, not the features of an implementation (the latter can be helpful as an example, e.g., in an appendix, though). Joe --------------1BBCBFC63D2B35D9D0089E4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 7/19/2017 11:19 PM, Olivier Bonaventure wrote:
How do you know you're using the converter? Is the initial connection to
that converter? Or does the converter hijack (the latter is the
implication of the text, AFAICT).

Consider a simple implementation using LD_PRELOAD to overload the connect system call on Linux. When the application issues connect, it has already set the required socket options that apply for this new connection. The converter implementation uses the destination address of the connect system call to create the TLV message and sets the TFO socket option to send it during its own connect with the converter. If the application had requested TFO, then the converter library simply uses the regular connect call and everything is fine.
The Linux API is not the TCP API. The TCP API is a generic, implementation-independent interface to upper layer protocols and applications.

This mechanism needs to be described in terms of the TCP API.

Yes, the app can SEND data to the socketpair before the connection is established, per RFC793 (note - I'm using 793 terms, not unix terms here). There's nothing in RFC7413 (TFO) that confirms that TFO will succeed on a new connection and that RFC explicitly admits it did not introduce an API extension by which an application can read (RECEIVE) SYN data before the connection is established:
   But the client's socket may have data available to read before it's
   connected.  This document does not cover the corresponding API
   change.
I.e., it's important to explain what you're doing using the TCP API, not the features of an implementation (the latter can be helpful as an example, e.g., in an appendix, though).

Joe
--------------1BBCBFC63D2B35D9D0089E4D-- From nobody Thu Jul 20 08:26:44 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E244C131CE7; Thu, 20 Jul 2017 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 49hS1wE_ZFCE; Thu, 20 Jul 2017 08:26:36 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB752131C43; Thu, 20 Jul 2017 08:26:35 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 702C6A05A0; Thu, 20 Jul 2017 17:26:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 472C11C008F; Thu, 20 Jul 2017 17:26:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 17:26:33 +0200 From: To: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAWXFBmj7/jopsUiQDq1/JQyPZ6Jc1ZKA Date: Thu, 20 Jul 2017 15:26:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> In-Reply-To: <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:26:38 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2ku ZWR1XQ0KPiBFbnZvecOpwqA6IGpldWRpIDIwIGp1aWxsZXQgMjAxNyAxNjozNw0KPiDDgMKgOiBC T1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBPbGl2aWVyIEJvbmF2ZW50dXJlOyBJbnRlcm5ldCBB cmVhOyB0c3YtDQo+IGFyZWFAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtJbnQtYXJlYV0gTWlk ZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+IA0KPiANCj4gDQo+IE9u IDcvMTkvMjAxNyAxMDozOSBQTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4gPiBIaSBKb2UsDQo+ID4NCj4gPiBUaGUgdGV4dCBjYW4gYWx3YXlzIGJlIHdvcmtlZCBvdXQu IFRoaXMgaXMgbm90IGFuIElFVEYgTEMgOikNCj4gQWdyZWVkIC0gSSB3YXMgZXhwbGFpbmluZyB0 aGF0IHRoZSBjdXJyZW50IHRleHQgLSBhbmQgbWFueSBvZiB0aGUNCj4gcmVzcG9uc2VzIGluIHRo aXMgY2hhaW4sIGJvdGggZnJvbSB5b3UgYW5kIG90aGVycywgY29udGludWVzIHRvIGJlDQo+IGNv bmZ1c2luZy4NCj4gDQpbTWVkXSBDYWxsaW5nIG91dCB0aG9zZSBjb25mdXNpbmcgcG9pbnRzIHdv dWxkIGhlbHAuICANCg0KPiA+IFRoZSBtYWluIHBvaW50IGlzIHRoYXQgd2UgYXJlIGZvbGxvd2lu ZyB5b3VyIHN1Z2dlc3Rpb24gdG8gZGVmaW5lIHRoZQ0KPiBzb2x1dGlvbiBhcyBhbiBhcHBsaWNh dGlvbiBwcm94eSB1c2luZyBhIGRlZGljYXRlZCBwb3J0IG51bWJlci4NCj4gQXMgZmVlZGJhY2sg Zm9yIHRoZSBkb2MsIHRoYXQgY291bGQgYmUgbWFkZSBtb3JlIGV4cGxpY2l0LCBpbmNsdWRpbmcg aW4NCj4gdGhlIHRpdGxlICh0aGlzIGlzIGFuIGFwcGxpY2F0aW9uIHByb3h5LCBub3QgdHlwaWNh bGx5IHJlZmVycmVkIHRvIGFzDQo+IG1pZGRsZWJveGVzKS4NCj4gDQoNCltNZWRdIExvb2tzIGxp a2UgYSBnb29kIGlkZWEgdG8gbWUuDQoNCj4gVGhhdCBhbHNvIGluY2x1ZGVzIGxpbWl0aW5nIHRo ZSBkb2MgdG8gdXNpbmcgVENQIGFwcC1sYXllciBBUElzIGFuZA0KPiBkZXNjcmliaW5nIGFueSBi ZWhhdmlvciB0aGF0ICptaWdodCogaGFwcGVuIGF0IHRoZSBzZWdtZW50IGxldmVsIGFzIGp1c3QN Cj4gdGhhdCAtIGh5cG90aGV0aWNhbCwgcGVyaGFwcyBkZXNpcmVkLCBidXQgTk9UIHRoZSBtZWNo YW5pc20gYmVpbmcNCj4gcHJvcG9zZWQuDQo+DQo+IEZXSVcuDQo+IA0KPiBKb2UNCg0K From nobody Thu Jul 20 08:38:58 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D76131CCA for ; Thu, 20 Jul 2017 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 M6hTc9zY_mvd for ; Thu, 20 Jul 2017 08:38:54 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 02F1E131A56 for ; Thu, 20 Jul 2017 08:38:54 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w126so27840232wme.0 for ; Thu, 20 Jul 2017 08:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xSa96iYIa+pgwsJ4c3jbbO2CwyZgxIptI14mVczm36g=; b=HtmbgozqcLtFxkNYXwkQ6WbvglihsMfBTJyB6ZgtXcJqJgi8TrG/5q0jggnlV4SxCr 97E90LLBEKCTZ5EBwj5tx4gRdnBp4LtxV7qRMyOnrDVJwsIPU4UEPKW4CEGeg9+IMNgx /YEEEM+I4y5bMsL3ZQnpzv6Ab/r/ykWwTMe/b6gHySEwIVYkicxoywIhk1TCCy/aaA1Y ga0zlvu0tblu5pFgOlpIeYEhUs/oa5hVJmUVE69bqXZOTmw0dEnzoEevbmh/EXMeU7kj A47sGVsDU/HcmDHg0DPiX4rFyTaHX9SSvPxBVakcUsRkZK0lNJOOf37qHKF/DJ/1VXTH M3Kg== 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=xSa96iYIa+pgwsJ4c3jbbO2CwyZgxIptI14mVczm36g=; b=j0u99oAjkDD4Klu2nfq9yUw7oezlSjdI483Z3e35qxVEU/vulugZCQfNHxliFAyK+D UQeldq+W6u5Z83OGL8jDS5NKUHcz2d2nvprYPD9gAXzpTO+6ddf+4Wv/ppy5lE+1+a7a cspE7o/+LXseB1OzrBoCZu61hnZ4bNCSVbd8ZARYjE6JehD0nlag9GQ81sgpaNd2UrGR RjW6QJyup/bjlsrFmYQSicXoWkPfBEpTafmUqheZtymvwgiWYGZ7pVD0XDaByexyTWKU bDDoumwa6Qh+L4HnUxsRfIHr/hdidoT45yohO1ZkfVjhlI6E58exRuw4rRgIiHnUfWpk XZcw== X-Gm-Message-State: AIVw113wbypiZTujt3hhECiHW1clPwYrFt2b7Cmj8iqb/gyLqSUtpxBB K/zPO7uTqdQveQqX7uoVkaKAnXsHp23u X-Received: by 10.28.175.135 with SMTP id y129mr2640532wme.87.1500565132465; Thu, 20 Jul 2017 08:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Thu, 20 Jul 2017 08:38:51 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Tom Herbert Date: Thu, 20 Jul 2017 08:38:51 -0700 Message-ID: Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP To: mohamed.boucadair@orange.com Cc: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:38:56 -0000 On Thu, Jul 20, 2017 at 8:26 AM, wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joe Touch [mailto:touch@isi.edu] >> Envoy=C3=A9 : jeudi 20 juillet 2017 16:37 >> =C3=80 : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; = tsv- >> area@ietf.org >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP >> >> >> >> On 7/19/2017 10:39 PM, mohamed.boucadair@orange.com wrote: >> > Hi Joe, >> > >> > The text can always be worked out. This is not an IETF LC :) >> Agreed - I was explaining that the current text - and many of the >> responses in this chain, both from you and others, continues to be >> confusing. >> > [Med] Calling out those confusing points would help. > >> > The main point is that we are following your suggestion to define the >> solution as an application proxy using a dedicated port number. >> As feedback for the doc, that could be made more explicit, including in >> the title (this is an application proxy, not typically referred to as >> middleboxes). >> > > [Med] Looks like a good idea to me. > That use of the term middleboxes as opposed to proxy was also confusing to me. I'd also suggest not to call this a netwotk function, that has other connotations that don't apply here. Tom >> That also includes limiting the doc to using TCP app-layer APIs and >> describing any behavior that *might* happen at the segment level as just >> that - hypothetical, perhaps desired, but NOT the mechanism being >> proposed. >> >> FWIW. >> >> Joe > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Jul 20 08:40:16 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE8A12EC46; Thu, 20 Jul 2017 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2V0wi3Om7FLD; Thu, 20 Jul 2017 08:40:13 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB45413188D; Thu, 20 Jul 2017 08:40:12 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id C0A5B1C02B8; Thu, 20 Jul 2017 17:40:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 94D1E4005C; Thu, 20 Jul 2017 17:40:11 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 17:40:11 +0200 From: To: Tom Herbert CC: Joe Touch , Olivier Bonaventure , Internet Area , "tsv-area@ietf.org" Subject: RE: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTAW5LBJKptC9OQkqhFf+x8f1OoqJc2f2Q Date: Thu, 20 Jul 2017 15:40:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A01027E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <45768767-79b5-42bf-6d2b-fe3a9799ef57@isi.edu> <787AE7BB302AE849A7480A190F8B93300A00F6A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <32b3e629-e37e-631a-32c6-11446a601e65@isi.edu> <787AE7BB302AE849A7480A190F8B93300A010201@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:40:15 -0000 R29vZCBzdWdnZXN0aW9uLCBUb20uDQoNClRoYW5rcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9t QGhlcmJlcnRsYW5kLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyMCBqdWlsbGV0IDIwMTcgMTc6 MzkNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8KgOiBKb2UgVG91Y2g7 IE9saXZpZXIgQm9uYXZlbnR1cmU7IEludGVybmV0IEFyZWE7IHRzdi1hcmVhQGlldGYub3JnDQo+ IE9iamV0wqA6IFJlOiBbSW50LWFyZWFdIE1pZGRsZWJveGVzIHRvIGFpZCB0aGUgZGVwbG95bWVu dCBvZiBNUFRDUA0KPiANCj4gT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgODoyNiBBTSwgIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPiBSZS0sDQo+ID4NCj4gPiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGUgOiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XQ0KPiA+PiBFbnZvecOpIDogamV1ZGkgMjAganVpbGxldCAyMDE3IDE2OjM3DQo+ ID4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgT2xpdmllciBCb25hdmVudHVyZTsg SW50ZXJuZXQgQXJlYTsgdHN2LQ0KPiA+PiBhcmVhQGlldGYub3JnDQo+ID4+IE9iamV0IDogUmU6 IFtJbnQtYXJlYV0gTWlkZGxlYm94ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDcvMTkvMjAxNyAxMDozOSBQTSwgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4gPiBIaSBKb2UsDQo+ID4+ID4NCj4gPj4gPiBU aGUgdGV4dCBjYW4gYWx3YXlzIGJlIHdvcmtlZCBvdXQuIFRoaXMgaXMgbm90IGFuIElFVEYgTEMg OikNCj4gPj4gQWdyZWVkIC0gSSB3YXMgZXhwbGFpbmluZyB0aGF0IHRoZSBjdXJyZW50IHRleHQg LSBhbmQgbWFueSBvZiB0aGUNCj4gPj4gcmVzcG9uc2VzIGluIHRoaXMgY2hhaW4sIGJvdGggZnJv bSB5b3UgYW5kIG90aGVycywgY29udGludWVzIHRvIGJlDQo+ID4+IGNvbmZ1c2luZy4NCj4gPj4N Cj4gPiBbTWVkXSBDYWxsaW5nIG91dCB0aG9zZSBjb25mdXNpbmcgcG9pbnRzIHdvdWxkIGhlbHAu DQo+ID4NCj4gPj4gPiBUaGUgbWFpbiBwb2ludCBpcyB0aGF0IHdlIGFyZSBmb2xsb3dpbmcgeW91 ciBzdWdnZXN0aW9uIHRvIGRlZmluZSB0aGUNCj4gPj4gc29sdXRpb24gYXMgYW4gYXBwbGljYXRp b24gcHJveHkgdXNpbmcgYSBkZWRpY2F0ZWQgcG9ydCBudW1iZXIuDQo+ID4+IEFzIGZlZWRiYWNr IGZvciB0aGUgZG9jLCB0aGF0IGNvdWxkIGJlIG1hZGUgbW9yZSBleHBsaWNpdCwgaW5jbHVkaW5n IGluDQo+ID4+IHRoZSB0aXRsZSAodGhpcyBpcyBhbiBhcHBsaWNhdGlvbiBwcm94eSwgbm90IHR5 cGljYWxseSByZWZlcnJlZCB0byBhcw0KPiA+PiBtaWRkbGVib3hlcykuDQo+ID4+DQo+ID4NCj4g PiBbTWVkXSBMb29rcyBsaWtlIGEgZ29vZCBpZGVhIHRvIG1lLg0KPiA+DQo+IFRoYXQgdXNlIG9m IHRoZSB0ZXJtIG1pZGRsZWJveGVzIGFzIG9wcG9zZWQgdG8gcHJveHkgd2FzIGFsc28NCj4gY29u ZnVzaW5nIHRvIG1lLiBJJ2QgYWxzbyBzdWdnZXN0IG5vdCB0byBjYWxsIHRoaXMgYSBuZXR3b3Rr IGZ1bmN0aW9uLA0KPiB0aGF0IGhhcyBvdGhlciBjb25ub3RhdGlvbnMgdGhhdCBkb24ndCBhcHBs eSBoZXJlLg0KPiANCj4gVG9tDQo+IA0KPiA+PiBUaGF0IGFsc28gaW5jbHVkZXMgbGltaXRpbmcg dGhlIGRvYyB0byB1c2luZyBUQ1AgYXBwLWxheWVyIEFQSXMgYW5kDQo+ID4+IGRlc2NyaWJpbmcg YW55IGJlaGF2aW9yIHRoYXQgKm1pZ2h0KiBoYXBwZW4gYXQgdGhlIHNlZ21lbnQgbGV2ZWwgYXMN Cj4ganVzdA0KPiA+PiB0aGF0IC0gaHlwb3RoZXRpY2FsLCBwZXJoYXBzIGRlc2lyZWQsIGJ1dCBO T1QgdGhlIG1lY2hhbmlzbSBiZWluZw0KPiA+PiBwcm9wb3NlZC4NCj4gPj4NCj4gPj4gRldJVy4N Cj4gPj4NCj4gPj4gSm9lDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IEludC1hcmVhIG1haWxpbmcgbGlzdA0KPiA+IEludC1hcmVh QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQt YXJlYQ0K