From nobody Wed Jun 1 09:16:05 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972C312B03F for ; Wed, 1 Jun 2016 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 8cKPha0xdPxr for ; Wed, 1 Jun 2016 09:16:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DFA9912D0DD for ; Wed, 1 Jun 2016 09:16:01 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u51GFx4h005784 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Jun 2016 16:15:59 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u51GFvrF022888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 16:15:59 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u51GFt7J014659; Wed, 1 Jun 2016 16:15:56 GMT Received: from [10.159.225.216] (/10.159.225.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jun 2016 09:15:55 -0700 To: mohamed.boucadair@orange.com, "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Rao Shoaib Message-ID: <574F0A36.10101@oracle.com> Date: Wed, 1 Jun 2016 09:15:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:16:03 -0000 On 05/30/2016 02:22 AM, mohamed.boucadair@orange.com wrote: > Hi Shoaib, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Rao >> Shoaib >> Envoyé : samedi 28 mai 2016 10:56 >> À : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >> >> >> >> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: >>> Rao, >>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: >>>>> The assumption is that this solution will be deployed in controlled >>>>> environments and only used between the CPE and the Concentrator. Since >>>>> the operator controls the two networks that are bound together, he can >>>>> verify that there are no middleboxes that drop the PM option. >>>>> >>>>> >>>>> Olivier >>>> I am extremely interested in encapsulating UDP in MPTCP but this >>>> solution is very specific and hence why should it even be standardized >> ? >>> There is a clear demand from operators for a solution to this problem >>> in hybrid access networks. >> OK but this solution is very specific to the mobile network. > [Med] The solution is not specific to the mobile network, but targets all network providers who want to allow their customers to make use of all available network attachments (e.g., fixed, WLAN, cellular, etc.) The way it is designed it is very specific to a particular use case and is not a generic encapsulation solution. > > We would >> prefer a generic encapsulation solution which has no address mapping. > [Med] It seems that you want to cover the case of an MPTCP-enabled host communicating an MPTCP-enabled server exchanging any protocol data inside an MPTCP connection? Can you please confirm/infirm? Yes. We want a generic MPTCP encapsulation solution with no address mapping. Address mapping and other features (like single connection) should be separate options. >> Maybe the address mapping part should be made optional based on a flag ? > [Med] The technical details can be worked out once we understand your deployment case. > > [snip] OK. > > > After re-reading the draft I think the proposal for encapsulation is > pretty good, only minor details need to be cleared up. > > [Med] Thank you. We are more than open to discuss those details. > > Great. I think first we need to decide if we want a generic encapsulation solution (which is why I want) or do we entangle it with the other requirements of the cellular deployment. Shoaib From nobody Wed Jun 1 09:28:42 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555F012D0C8 for ; Wed, 1 Jun 2016 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 gIcjXEqLcSWl for ; Wed, 1 Jun 2016 09:28:39 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 8F0FB12D0B7 for ; Wed, 1 Jun 2016 09:28:39 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id f62so4120803vkc.2 for ; Wed, 01 Jun 2016 09:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=P3Bh+2mMs0s+W7H1DNsR2o8MuzE37O1QsvqTMBLyOalYorClSJ0M86b/HNAHA/hGqb XkpxY5qQNa0x3C/BSITw1W6an6YRHr0A+rf92eXb5pE42A74w8HUf3DL/2ejmThFknw9 Fnt74B0kUcGq9k7uqQIAaWzl9+vfw+OntE4U1lVJVD0pP0HQzMkzCfOZCkB1FBX2Mx8B 0YZVD/dQ0xBgL+Yr92KxS+SdaEIXr56TjoQZnNT7EmKDurJCNc/HqkykRKl1nKeLbsSB uMojd46VeBXcOJ2CLRV08JL+1wSDACqoIydxtDzzRwc/NQXJoRGVcRjuB7FHgLp6Dncc t/ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=XedX3ZyZMopqYiRIkhpFK7dCuJvtCwTsQrdTsMdRmT7DGePSOZTKBZICMcwY3YpDlo Y5ExQ2fALDgZ5lrbQ4s+qbqOWE4LerdD5FfZENl6RVWmejvNPdED2t8yjeOLlhNI2M2b Vc/PQO9tFGgrvQA6TnTqCiIpO+5tFKfcegtnXr9cv7NC1g2Iy5zRLKfJfVxwf5pYM14e VZbSE8xaOeFDfeb4V+s/xO8s1giG9XBXVItOD8g401HV0nQDzmEPWg27gA9j+oRRPQtY jAwqaMgbqmbMF402HnDaa07HPBEQ4b8hLzRU1OtpP7P02AoVPJRaNFg+/M1eHCsbJygK 0Qag== X-Gm-Message-State: ALyK8tLcJRr1PALQQGpyZwie/m8LHVOdIqKRgViMaFMGjxWrZO6P3AC9ctZI9Gx0DTsgDwDx5gY2NraHdhyN3A== MIME-Version: 1.0 X-Received: by 10.176.65.161 with SMTP id 30mr2465335uap.48.1464798518732; Wed, 01 Jun 2016 09:28:38 -0700 (PDT) Received: by 10.176.2.232 with HTTP; Wed, 1 Jun 2016 09:28:38 -0700 (PDT) Date: Wed, 1 Jun 2016 11:28:38 -0500 Message-ID: From: Behcet Sarikaya To: multipathtcp@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [multipathtcp] Test mail X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:28:41 -0000 From nobody Wed Jun 1 11:37:50 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BBA12D18C for ; Wed, 1 Jun 2016 11:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 WWWn4OhjYw6v for ; Wed, 1 Jun 2016 11:37:47 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4942412D16C for ; Wed, 1 Jun 2016 11:37:47 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id a6so39464275vkg.3 for ; Wed, 01 Jun 2016 11:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to; bh=QUM5H4MjoRq9FYLmnZUWUW+hEgE2jNvLaO37JkDb/y4=; b=RRoBpetK9/SWhVA79ZtQa3qJ8DCLWX899R+hSBIhDpUBJASKmrpkQormLhkRfmBKyI ivyTJXaOZYVMR0BeE2kDe7SeJ5AJ/Wsf3Hj0SV2y0B9EWNJ6RMN/OYf8K2XgUi+xGzLv 0d3TJ3KdF/r8X4jJ5YnY5GulYLh11QGggNy0FeADas6iZ+b/9MP1x+5lOzAhpyMPau2Q 8vI/e/JJtzmZqxEwv5hwtuF6qY4Qxmmit0yc98UHBiKZG5XkkAhj1X3bzL2DAU8OUCXG BoWLlS/yozUK+psDe5+2iJ1psuwZ5gOeEEJOfuRvZIrJt4pomXtIav4iYh3DW+Mm/zyi Yi+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to; bh=QUM5H4MjoRq9FYLmnZUWUW+hEgE2jNvLaO37JkDb/y4=; b=SgYTZD/qwydYAZC/DoxgtsDgE2QKyr1Z8R1ETpTBiAVUaOr07PTkT8Kjnm8ngvBkab xabMHKFU/LoSeAPb9OQ26d6St0laVPhIdPfwbLzqOjAauQamL/O1xUnM7NXWA9sbqtiI YpK4oBFtvJV9L9Jpm/48z9c2BuCbbcXX+gmWQv4UdiJeRln45ZxMbdLhgviFQH/YDNBw rz+lp20hRdW3aT2pNfRF1ZYTQjmPT+hJ2qa1r0Tuwl7icmaW1/RzC+CLUbdP/FGz+YcG nMae73jGqYomqSMbOmsNkekNc9XAAFFPENTz43KEmQMjHAAm0F1rHn0qD5TbOwF6cOGE OeYQ== X-Gm-Message-State: ALyK8tIlOc3US+B3CcV1tIPL22HQdAmu26+4QoyQVINXlzN16pU2KQj4UhCAqyXWYDP3FNICAjC544+4JpfnKg== MIME-Version: 1.0 X-Received: by 10.159.38.54 with SMTP id 51mr2777916uag.27.1464806266176; Wed, 01 Jun 2016 11:37:46 -0700 (PDT) Received: by 10.176.2.232 with HTTP; Wed, 1 Jun 2016 11:37:46 -0700 (PDT) Date: Wed, 1 Jun 2016 13:37:46 -0500 Message-ID: From: Behcet Sarikaya To: multipathtcp@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:37:49 -0000 Hi all, Recent mails in this thread came to my attention because I work on the hybrid access network issues and wish to convey my views on some of the issues discussed. First of all, the claims that there is strong operator interest on this is over blown. Hybrid access is based on offloading some CPE traffic to 3G/LTE network, I don't think mobile operators are fond of such a thing. Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP into MPTCP and requires Concentrators to convert back MPTCP into UDP or TCP is a complex process. The crux of this is the problems arising from the use of MPTCP for tunneling, which is what this draft is advocating. Here I recommend Joe Touch's Intarea draft https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt on IP Tunnels in the Internet Architecture. IETF developed many tunneling protocols which are surveyed in this draft but none of them are TCP/MPTCP based. I also question suitability of this work to the charter. There is this charter text: Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues. This draft has a middlebox called Concentrator but it is not trying to enable MPTCP hosts to communicate with TCP hosts, it is just tunneling the traffic. So there is no charter item that fits to this draft. I strongly suggest staying away from making MPTCP a tunneling protocol. Regards, Behcet From nobody Thu Jun 2 01:25:42 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DE12B04A for ; Thu, 2 Jun 2016 01:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 8pvyVNx80TOp for ; Thu, 2 Jun 2016 01:25:38 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F64112B038 for ; Thu, 2 Jun 2016 01:25:37 -0700 (PDT) Received: from E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Jun 2016 09:25:34 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 2 Jun 2016 09:25:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Jun 2016 09:25:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Thu, 2 Jun 2016 09:25:35 +0100 From: To: Thread-Topic: MPTCP Interim (audio) - doodle for date Thread-Index: AQHRth6eSFbtIoQmhUSa3XpJ7d/8jZ/V5DkA Date: Thu, 2 Jun 2016 08:25:34 +0000 Message-ID: References: <260545774.2496927.1463995812803.POLL_ADMIN_PARTICIPATELINK@worker2.doodle.com> <1464137048262.13874@bt.com> In-Reply-To: <1464137048262.13874@bt.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] MPTCP Interim (audio) - doodle for date X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 08:25:41 -0000 Just a reminder, please fill in the doodle as soon as possible, so we can d= ecide a date for this call Thanks Phil & Yoshi. -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 25 May 2016 01:44 To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP Interim (audio) - doodle for date Hi, http://doodle.com/poll/9ne8wz67tdrtxzk2=20 In order to try and make good progress on draft-ietf-mptcp-rfc6824bis, we'd= like to have an interim meeting by audio. The proposal is sometime week of= 20th June. In the past we've found that 3pm GMT/UTC is a reasonable compro= mise for the time (we can adjust this if it isn't a suitable time). Hopeful= ly we can complete the call in less than 1 hour, but we'll book a timeslot = of 1.5 hours. Please fill in the doodle with the dates you can make.=20 The topic for the call will be the proposal for a generic alternative keyin= g mechanism (support for front-end proxies) from Alan F & Christoph P - the= topic has been discussed before, and the detailed proposal will be distrib= uted soon.=20 We believe that this is the only significant functional addition that has = wide-scale interest (ie beyond what's already in the bis doc) (*). Therefor= e our proposal is to hold a WG Last Call on the draft after the interim and= in the period leading up to the IETF. So that we can discuss issues during= the Berlin meeting. Beyond that, our current thinking is that we should ha= ve some implementation before progressing the doc to the IESG (and that exp= erience may of course lead to mods to the doc).=20 (*) one of the things we'll ask in the WGLC is whether people think the doc= does include all the additional functionality that people want. Of course = you can raise things before the wglc.=20 Best wishes, phil & Yoshi=20 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 2 07:02:41 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15E412D723 for ; Thu, 2 Jun 2016 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 UGXLvoHCliny for ; Thu, 2 Jun 2016 07:02:36 -0700 (PDT) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) (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 957C812D701 for ; Thu, 2 Jun 2016 07:02:35 -0700 (PDT) Received: by mail.swisscom.com; Thu, 2 Jun 2016 16:02:31 +0200 From: To: , Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS5/kRyThp3H0qXGRVw5nwe1J/WNmyA Date: Thu, 2 Jun 2016 14:02:30 +0000 Message-ID: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> References: In-Reply-To: Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [138.190.134.10] Content-Type: text/plain; charset="utf-8" Content-ID: <39B1CF02CF25564D8105122715822C24@swisscom.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:02:40 -0000 SGkgQmVoY2V0LA0KDQpBcyBvbmUgb2YgdGhlIG9wZXJhdG9ycyB2ZXJ5IGludGVyZXN0ZWQgaW4g dGhpcywgSSBkb27igJl0IHRoaW5rIGl0IGlzIG92ZXIgYmxvd24gYW5kIHRoZSB1c2UgY2FzZSB5 b3UgZGVzY3JpYmUgbWlnaHQgYmUgdGhlIGZpcnN0IG9uZSBmb3IgYSBudW1iZXIgb2Ygb3BlcmF0 b3JzLCBidXQgb3RoZXJzIGFyZSBmb2xsb3dpbmcuIEZ1bmRhbWVudGFsbHkgaXQgaXMgYWJvdXQg cmVzb3VyY2UgcG9vbGluZyBvZiBhY2Nlc3MgbmV0d29ya2luZyByZXNvdXJjZXMgKG9mIHdoYXRl dmVyIHRlY2hub2xvZ3kgdHJhbnNwb3J0aW5nIElQKS4NCg0KV2UgYXJlIHdlbGwtYXdhcmUgb2Yg dGhlIHByb2JsZW1zIG9mIGEgTVBUQ1AtYmFzZWQgc29sdXRpb24gKGFuZCBkcmFmdC1ib3VjYWRh aXIgdHJpZXMgdG8gc29sdmUgc29tZSBvZiB0aGVtKS4gSG93ZXZlciwgd2UgYXJlIG5vdCBhd2Fy ZSBvZiBhbnkgYmV0dGVyIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3IgbXVsdGlwbGUgcGF0aHMg d2l0aCBoZXRlcm9nZW5lb3VzIGNoYXJhY3RlcmlzdGljcyBvZiBhdmFpbGFibGUgYW5kIHZhcnlp bmcgYmFuZHdpZHRoLCB2YXJ5aW5nIGRlbGF5cywgYW5kIGRpZmZlcmVudCBwYWNrZXQgaGFuZGxp bmcgY2hhcmFjdGVyaXN0aWNzLiBJbiBjYXNlIHRoZXJlIGlzIGJldHRlciB3YXlzIG9mIHNvbHZp bmcgdGhhdCBwcm9ibGVtIGxldCB1cyBrbm93LiANCg0KVGhlIG5lZWQgZm9yIHRoZSB1bmZvcnR1 bmF0ZSBwcm94eWluZy9jb25jZW50cmF0b3JzIGlzIGEgc2hvcnQgdGVybSBzb2x1dGlvbiB1bnRp bCBNUFRDUCBpcyBtb3JlIHdpZGVzcHJlYWQgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiANCg0K DQpLaW5kIHJlZ2FyZHMvVmllbGUgR3LDvHNzZQ0KDQpNYXJjdXMNCg0K4oCU4oCULQ0KTWFyY3Vz IEJydW5uZXINClN3aXNzY29tDQoNCg0KDQoNCg0KDQoNCg0KDQpBbSAwMS4wNi4xNiwgMjA6Mzcg c2NocmllYiAibXVsdGlwYXRodGNwIGltIEF1ZnRyYWcgdm9uIEJlaGNldCBTYXJpa2F5YSIgPG11 bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnIGltIEF1ZnRyYWcgdm9uIHNhcmlrYXlhMjAxMkBn bWFpbC5jb20+Og0KDQo+IEhpIGFsbCwNCj4NCj5SZWNlbnQgbWFpbHMgaW4gdGhpcyB0aHJlYWQg Y2FtZSB0byBteSBhdHRlbnRpb24gYmVjYXVzZSBJIHdvcmsgb24gdGhlDQo+aHlicmlkIGFjY2Vz cyBuZXR3b3JrIGlzc3VlcyBhbmQgd2lzaCB0byBjb252ZXkgbXkgdmlld3Mgb24gc29tZSBvZg0K PnRoZSBpc3N1ZXMgZGlzY3Vzc2VkLg0KPg0KPkZpcnN0IG9mIGFsbCwgdGhlIGNsYWltcyB0aGF0 IHRoZXJlIGlzIHN0cm9uZyBvcGVyYXRvciBpbnRlcmVzdCBvbg0KPnRoaXMgaXMgb3ZlciBibG93 bi4gSHlicmlkIGFjY2VzcyBpcyBiYXNlZCBvbiBvZmZsb2FkaW5nIHNvbWUgQ1BFDQo+dHJhZmZp YyB0byAzRy9MVEUgbmV0d29yaywgSSBkb24ndCB0aGluayBtb2JpbGUgb3BlcmF0b3JzIGFyZSBm b25kIG9mDQo+c3VjaCBhIHRoaW5nLg0KPg0KPkFsc28gSSBzdHJvbmdseSBjb25jdXIgd2l0aCBZ b3NoaSdzIHBvaW50IG9mIENQRSB0byBjb252ZXJ0IFVEUCBvciBUQ1ANCj5pbnRvIE1QVENQIGFu ZCByZXF1aXJlcw0KPkNvbmNlbnRyYXRvcnMgdG8gY29udmVydCBiYWNrIE1QVENQIGludG8gVURQ IG9yIFRDUCBpcyBhIGNvbXBsZXgNCj5wcm9jZXNzLiBUaGUgY3J1eCBvZiB0aGlzIGlzIHRoZSBw cm9ibGVtcyBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZg0KPk1QVENQIGZvciB0dW5uZWxpbmcsIHdo aWNoIGlzIHdoYXQgdGhpcyBkcmFmdCBpcyBhZHZvY2F0aW5nLg0KPg0KPkhlcmUgSSByZWNvbW1l bmQgSm9lIFRvdWNoJ3MgSW50YXJlYSBkcmFmdA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDIudHh0DQo+b24gSVAgVHVubmVscyBpbiB0aGUg SW50ZXJuZXQgQXJjaGl0ZWN0dXJlLiBJRVRGIGRldmVsb3BlZCBtYW55DQo+dHVubmVsaW5nIHBy b3RvY29scyB3aGljaCBhcmUgc3VydmV5ZWQgaW4gdGhpcyBkcmFmdCBidXQgbm9uZSBvZiB0aGVt DQo+YXJlIFRDUC9NUFRDUCBiYXNlZC4NCj5JIGFsc28gcXVlc3Rpb24gc3VpdGFiaWxpdHkgb2Yg dGhpcyB3b3JrIHRvIHRoZSBjaGFydGVyLiBUaGVyZSBpcyB0aGlzDQo+Y2hhcnRlciB0ZXh0Og0K PkZpbmFsbHksIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZXhwbG9yZSB3aGV0aGVyIGFuIE1QVENQ LWF3YXJlDQo+ICBtaWRkbGVib3ggd291bGQgYmUgdXNlZnVsLCB3aGVyZSBhdCBsZWFzdCBvbmUg ZW5kIGhvc3QgaXMgTVBUQ1AtZW5hYmxlZC4NCj4gIEZvciBleGFtcGxlLCBwb3RlbnRpYWxseSBo ZWxwaW5nIE1QVENQJ3MgaW5jcmVtZW50YWwgZGVwbG95bWVudCBieQ0KPiAgYWxsb3dpbmcgb25s eSBvbmUgZW5kIGhvc3QgdG8gYmUgTVBUQ1AtZW5hYmxlZCBhbmQgdGhlIG1pZGRsZWJveCBhY3Rz IGFzDQo+ICBhbiBNUFRDUCBwcm94eSBmb3IgdGhlIG90aGVyIGVuZCBob3N0LCB3aGljaCBydW5z IFRDUDsgYW5kIHBvdGVudGlhbGx5DQo+ICBoZWxwaW5nIHNvbWUgbW9iaWxpdHkgc2NlbmFyaW9z LCB3aGVyZSB0aGUgbWlkZGxlYm94IGFjdHMgYXMgYW4gYW5jaG9yDQo+ICBiZXR3ZWVuIHR3byBN UFRDUC1lbmFibGVkIGhvc3RzLiBUaGUgd29ya2luZyBncm91cCB3aWxsIGRldGFpbCB3aGF0IHJl YWwNCj4gIHByb2JsZW1zIGFuIE1QVENQLWVuYWJsZWQgbWlkZGxlYm94IG1pZ2h0IHNvbHZlLCBo b3cgaXQgd291bGQgaW1wYWN0IHRoZQ0KPiAgTXVsdGlwYXRoIFRDUCBhcmNoaXRlY3R1cmUgKFJG QzYxODIpLCB3aGF0IHByb3h5IGFwcHJvYWNoIG1pZ2h0IGJlDQo+ICBqdXN0aWZpZWQgYXMgY29t cGFyZWQgYWdhaW5zdCBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW1zLCBhbmQN Cj4gIHRoZSBsaWtlbHkgZmVhc2liaWxpdHkgb2Ygc29sdmluZyB0aGUgdGVjaG5pY2FsIGFuZCBz ZWN1cml0eSBpc3N1ZXMuDQo+DQo+VGhpcyBkcmFmdCBoYXMgYSBtaWRkbGVib3ggY2FsbGVkIENv bmNlbnRyYXRvciBidXQgaXQgaXMgbm90IHRyeWluZyB0bw0KPmVuYWJsZSBNUFRDUCBob3N0cyB0 byBjb21tdW5pY2F0ZSB3aXRoIFRDUCBob3N0cywgaXQgaXMganVzdCB0dW5uZWxpbmcNCj50aGUg dHJhZmZpYy4gU28gdGhlcmUgaXMgbm8gY2hhcnRlciBpdGVtIHRoYXQgZml0cyB0byB0aGlzIGRy YWZ0Lg0KPkkgc3Ryb25nbHkgc3VnZ2VzdCBzdGF5aW5nIGF3YXkgZnJvbSBtYWtpbmcgTVBUQ1Ag YSB0dW5uZWxpbmcgcHJvdG9jb2wuDQo+DQo+UmVnYXJkcywNCj4NCj5CZWhjZXQNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm11bHRpcGF0aHRj cCBtYWlsaW5nIGxpc3QNCj5tdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpcGF0aHRjcA0K From nobody Thu Jun 2 10:18:43 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD9212D777 for ; Thu, 2 Jun 2016 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 xMpC_c7-PG0e for ; Thu, 2 Jun 2016 10:18:41 -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 359BB12D730 for ; Thu, 2 Jun 2016 10:18:41 -0700 (PDT) Received: from [128.9.184.178] ([128.9.184.178]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u52HHkZu021180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 10:17:52 -0700 (PDT) To: Markus.Brunner3@swisscom.com, sarikaya@ieee.org, multipathtcp@ietf.org References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> From: Joe Touch Message-ID: <57506A37.60502@isi.edu> Date: Thu, 2 Jun 2016 10:17:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:18:43 -0000 On 6/2/2016 7:02 AM, Markus.Brunner3@swisscom.com wrote: > Hi Behcet, > > As one of the operators very interested in this, I don’t think it is over blown and the use case you describe might be the first one for a number of operators, but others are following. Fundamentally it is about resource pooling of access networking resources (of whatever technology transporting IP). > > We are well-aware of the problems of a MPTCP-based solution (and draft-boucadair tries to solve some of them). However, we are not aware of any better standardized solution for multiple paths with heterogeneous characteristics of available and varying bandwidth, varying delays, and different packet handling characteristics. In case there is better ways of solving that problem let us know. Why wouldn't an overlay that employs dynamic routing be easier? It wouldn't incur the delays of using reliable delivery with messages that don't preserve IP datagram boundaries and it's already supported with existing equipment. Further, it could use much more sophisticated path monitoring and choice. I.e., this is exactly what you'd get if you deploy something akin to LISP and basically ignore the label distribution problem (which you really don't have). Joe > > The need for the unfortunate proxying/concentrators is a short term solution until MPTCP is more widespread implemented and deployed. > > > Kind regards/Viele Grüsse > > Marcus > > ——- > Marcus Brunner > Swisscom > > > > > > > > > > Am 01.06.16, 20:37 schrieb "multipathtcp im Auftrag von Behcet Sarikaya" : > >> Hi all, >> >> Recent mails in this thread came to my attention because I work on the >> hybrid access network issues and wish to convey my views on some of >> the issues discussed. >> >> First of all, the claims that there is strong operator interest on >> this is over blown. Hybrid access is based on offloading some CPE >> traffic to 3G/LTE network, I don't think mobile operators are fond of >> such a thing. >> >> Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP >> into MPTCP and requires >> Concentrators to convert back MPTCP into UDP or TCP is a complex >> process. The crux of this is the problems arising from the use of >> MPTCP for tunneling, which is what this draft is advocating. >> >> Here I recommend Joe Touch's Intarea draft >> https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt >> on IP Tunnels in the Internet Architecture. IETF developed many >> tunneling protocols which are surveyed in this draft but none of them >> are TCP/MPTCP based. >> I also question suitability of this work to the charter. There is this >> charter text: >> Finally, the working group will explore whether an MPTCP-aware >> middlebox would be useful, where at least one end host is MPTCP-enabled. >> For example, potentially helping MPTCP's incremental deployment by >> allowing only one end host to be MPTCP-enabled and the middlebox acts as >> an MPTCP proxy for the other end host, which runs TCP; and potentially >> helping some mobility scenarios, where the middlebox acts as an anchor >> between two MPTCP-enabled hosts. The working group will detail what real >> problems an MPTCP-enabled middlebox might solve, how it would impact the >> Multipath TCP architecture (RFC6182), what proxy approach might be >> justified as compared against alternative solutions to the problems, and >> the likely feasibility of solving the technical and security issues. >> >> This draft has a middlebox called Concentrator but it is not trying to >> enable MPTCP hosts to communicate with TCP hosts, it is just tunneling >> the traffic. So there is no charter item that fits to this draft. >> I strongly suggest staying away from making MPTCP a tunneling protocol. >> >> Regards, >> >> Behcet >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 2 12:35:10 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9FB12D58D for ; Thu, 2 Jun 2016 12:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 h953LvNk2jY7 for ; Thu, 2 Jun 2016 12:35:06 -0700 (PDT) Received: from ndmsvnpf104.ndc.nasa.gov (NDMSVNPF104.ndc.nasa.gov [198.117.0.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6370712D567 for ; Thu, 2 Jun 2016 12:35:05 -0700 (PDT) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndmsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id CD7044016669 for ; Thu, 2 Jun 2016 14:35:04 -0500 (CDT) Received: from NDMSCHT101.ndc.nasa.gov (ndmscht101-pub.ndc.nasa.gov [198.117.0.201]) by ndmsppt103.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u52JZ4Se032497 for ; Thu, 2 Jun 2016 14:35:04 -0500 Received: from NDMSMBX102.ndc.nasa.gov ([169.254.7.138]) by NDMSCHT101.ndc.nasa.gov ([198.117.0.201]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 14:35:04 -0500 From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" To: "multipathtcp@ietf.org" Thread-Topic: MPTCP Proxy Current Best Practices Thread-Index: AQHRvQXbVk8xTotSe0O575jBG6T+BQ== Date: Thu, 2 Jun 2016 19:35:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.44.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-02_09:, , signatures=0 Archived-At: Subject: [multipathtcp] MPTCP Proxy Current Best Practices X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 19:35:09 -0000 Hello all, I was wondering if anyone on the list has experience deploying an MPTCP proxy and would be willing to discuss the current best practices/proxy deployment options? I have been looking through the mptcp-dev and multipathtcp mailing lists at discussions revolving around MPTCP proxies and it seems like the two general strategies seem to be setting up a SOCKS proxy or using the mptcp-proxy code released by Bell Labs http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01934.html. Are there other options or more up-to-date code to use? The Bell Labs code is several years old, and I was unsure if using the code is still a viable option at this point or not. Is a SOCKS proxy the go to option? If so, how does an MPTCP capable SOCKS proxy setup differ from setting up a regular TCP SOCKS proxy? Best, Matt From nobody Thu Jun 2 13:08:39 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2112D1E8 for ; Thu, 2 Jun 2016 13:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=Jordan.Melzer@telus.com header.d=telus.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 GMq_HcDv41YH for ; Thu, 2 Jun 2016 13:08:34 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89312B011 for ; Thu, 2 Jun 2016 13:08:33 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:Date:Subject:Thread-Topic:Thread-Index: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: acceptlanguage:Content-Type:Content-Transfer-Encoding: MIME-Version; b=kIDXmWRVts5mr2kiZU0noePugMAABBUDFtKqEV6w91Kgx5T9ufhKFFgL FGYUUfD+L6RiHbvQRk097R9e9aHtDY64VZh4I9DJ7gNdbxSxJUf/8/yW3 s3AGmyeiHxLXGrAOUYpsSPV0M+8j+pufVHlVTHLVwV8xs/IB3ohsbkkK1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AaAwB9kVBX/5Jjso5egw4sSQ19omSXZIF5Fw2FJEoCgTM4FAEBAQEBAQFlJ4RFAQEBBAEBATcZGxcEAgEIDQQEAQEfCQcnCxQJCAIEARIIAYgmAQQJwkwBAQEBAQEBAwEBAQEBAQEghieETYQjAQEdgyqCLgWOWYlel3iFRI9MHjaEDU8BiUaBNQEBAQ X-IronPort-AV: E=Sophos;i="5.26,408,1459814400"; d="scan'208";a="523280340" Received: from unknown (HELO WP40081.corp.ads) ([142.178.99.146]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 02 Jun 2016 20:08:30 +0000 Received: from WP40046.corp.ads ([::1]) by WP40081.corp.ads ([::1]) with mapi; Thu, 2 Jun 2016 14:08:30 -0600 From: Jordan Melzer To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" , "multipathtcp@ietf.org" Date: Thu, 2 Jun 2016 14:08:29 -0600 Thread-Topic: MPTCP Proxy Current Best Practices Thread-Index: AQHRvQXbVk8xTotSe0O575jBG6T+BZ/Wl/kw Message-ID: <80C0017654A043479F53C41112BE84768979E1F6B2@WP40046.corp.ads> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] MPTCP Proxy Current Best Practices X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:08:37 -0000 Hi Matthew, As long as your OS kernel supports MPTCP, any proxy works as a TCP to MPTCP= proxy. Eg, if you're on Linux using the UCL MPTCP implementation and you turn on H= AProxy as a TCP proxy, it becomes an MPTCP / TCP proxy. The same should be= true of Dante or OpenSSH or whatever else you want to try out. As there are commercial implementations from a range of vendors that come w= ith support etc., I don't think it would be fair to say there is one best p= ractice! It's worth noting that the default proxy will also terminate existing MPTCP= sessions and convert them to MPTCP, so if this is not a "feature" you want= , you may have to work harder. Apologies if this is off-topic for the list. Regards, Jordan -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Sarg= ent, Matthew T. (GRC-LCA0)[Peerless Technologies] Sent: June 2, 2016 03:35 PM To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP Proxy Current Best Practices Hello all, I was wondering if anyone on the list has experience deploying an MPTCP pro= xy and would be willing to discuss the current best practices/proxy deploym= ent options? I have been looking through the mptcp-dev and multipathtcp mai= ling lists at discussions revolving around MPTCP proxies and it seems like = the two general strategies seem to be setting up a SOCKS proxy or using the= mptcp-proxy code released by Bell Labs http://www.ietf.org/mail-archive/we= b/multipathtcp/current/msg01934.html. Are there other options or more up-to-date code to use? The Bell Labs code = is several years old, and I was unsure if using the code is still a viable = option at this point or not. Is a SOCKS proxy the go to option? If so, how = does an MPTCP capable SOCKS proxy setup differ from setting up a regular TC= P SOCKS proxy? Best, Matt _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 2 19:58:49 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2679C12D635 for ; Thu, 2 Jun 2016 19:58:47 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 NdeS3T7Tpf6q for ; Thu, 2 Jun 2016 19:58:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B6912D1E8 for ; Thu, 2 Jun 2016 19:58:43 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0E4DA562BECAF; Fri, 3 Jun 2016 02:58:41 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u532weGV029010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 02:58:40 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u532weTT022929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 04:58:40 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 04:58:39 +0200 From: "Henderickx, Wim (Nokia - BE)" To: Joe Touch , "Markus.Brunner3@swisscom.com" , "sarikaya@ieee.org" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvPLWg8MTdmGsmUykfkcCgIRGwp/WduCA Date: Fri, 3 Jun 2016 02:58:38 +0000 Message-ID: <0920D50D-3D89-44EB-9D61-122CD10E0B56@alcatel-lucent.com> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> In-Reply-To: <57506A37.60502@isi.edu> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <05D25F4628610D4CAB6F922334101FBF@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 02:58:47 -0000 SW4tbGluZQ0KDQoNCg0KDQpPbiAwMi8wNi8xNiAxMDoxNywgIm11bHRpcGF0aHRjcCBvbiBiZWhh bGYgb2YgSm9lIFRvdWNoIiA8bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIHRvdWNoQGlzaS5lZHU+IHdyb3RlOg0KDQo+DQo+DQo+T24gNi8yLzIwMTYgNzowMiBBTSwg TWFya3VzLkJydW5uZXIzQHN3aXNzY29tLmNvbSB3cm90ZToNCj4+IEhpIEJlaGNldCwNCj4+DQo+ PiBBcyBvbmUgb2YgdGhlIG9wZXJhdG9ycyB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhpcywgSSBkb27i gJl0IHRoaW5rIGl0IGlzIG92ZXIgYmxvd24gYW5kIHRoZSB1c2UgY2FzZSB5b3UgZGVzY3JpYmUg bWlnaHQgYmUgdGhlIGZpcnN0IG9uZSBmb3IgYSBudW1iZXIgb2Ygb3BlcmF0b3JzLCBidXQgb3Ro ZXJzIGFyZSBmb2xsb3dpbmcuIEZ1bmRhbWVudGFsbHkgaXQgaXMgYWJvdXQgcmVzb3VyY2UgcG9v bGluZyBvZiBhY2Nlc3MgbmV0d29ya2luZyByZXNvdXJjZXMgKG9mIHdoYXRldmVyIHRlY2hub2xv Z3kgdHJhbnNwb3J0aW5nIElQKS4NCj4+DQo+PiBXZSBhcmUgd2VsbC1hd2FyZSBvZiB0aGUgcHJv YmxlbXMgb2YgYSBNUFRDUC1iYXNlZCBzb2x1dGlvbiAoYW5kIGRyYWZ0LWJvdWNhZGFpciB0cmll cyB0byBzb2x2ZSBzb21lIG9mIHRoZW0pLiBIb3dldmVyLCB3ZSBhcmUgbm90IGF3YXJlIG9mIGFu eSBiZXR0ZXIgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvciBtdWx0aXBsZSBwYXRocyB3aXRoIGhl dGVyb2dlbmVvdXMgY2hhcmFjdGVyaXN0aWNzIG9mIGF2YWlsYWJsZSBhbmQgdmFyeWluZyBiYW5k d2lkdGgsIHZhcnlpbmcgZGVsYXlzLCBhbmQgZGlmZmVyZW50IHBhY2tldCBoYW5kbGluZyBjaGFy YWN0ZXJpc3RpY3MuIEluIGNhc2UgdGhlcmUgaXMgYmV0dGVyIHdheXMgb2Ygc29sdmluZyB0aGF0 IHByb2JsZW0gbGV0IHVzIGtub3cuIA0KPg0KPldoeSB3b3VsZG4ndCBhbiBvdmVybGF5IHRoYXQg ZW1wbG95cyBkeW5hbWljIHJvdXRpbmcgYmUgZWFzaWVyPw0KPg0KPkl0IHdvdWxkbid0IGluY3Vy IHRoZSBkZWxheXMgb2YgdXNpbmcgcmVsaWFibGUgZGVsaXZlcnkgd2l0aCBtZXNzYWdlcw0KPnRo YXQgZG9uJ3QgcHJlc2VydmUgSVAgZGF0YWdyYW0gYm91bmRhcmllcyBhbmQgaXQncyBhbHJlYWR5 IHN1cHBvcnRlZA0KPndpdGggZXhpc3RpbmcgZXF1aXBtZW50LiBGdXJ0aGVyLCBpdCBjb3VsZCB1 c2UgbXVjaCBtb3JlIHNvcGhpc3RpY2F0ZWQNCj5wYXRoIG1vbml0b3JpbmcgYW5kIGNob2ljZS4N Cj4NCj5JLmUuLCB0aGlzIGlzIGV4YWN0bHkgd2hhdCB5b3UnZCBnZXQgaWYgeW91IGRlcGxveSBz b21ldGhpbmcgYWtpbiB0bw0KPkxJU1AgYW5kIGJhc2ljYWxseSBpZ25vcmUgdGhlIGxhYmVsIGRp c3RyaWJ1dGlvbiBwcm9ibGVtICh3aGljaCB5b3UNCj5yZWFsbHkgZG9uJ3QgaGF2ZSkuDQo+DQo+ Sm9lDQpXSD4gaXQgZG9lc27igJl0IHNvbHZlIHRoZSB1c2UgY2FzZSB3aGVyZSBwYWNrZXRzIG9m IGEgZmxvdyBoYXZlIHRvIGJlIHNwbGl0IG92ZXIgbXVsdGlwbGUgbGlua3MgYW5kIHJlb3JkZXJp bmcgKyBjb25nZXN0aW9uIGNvbnRyb2wgaXMgcmVxdWlyZWQgZm9yIHRoZXNlIGZsb3dzLiBJZiB0 aGVzZSByZXF1aXJlbWVudHMgd2VyZSBub3QgdGhlcmUgeW914oCZcmUgcmlnaHQgdGhhdCByb3V0 aW5nIGNhbiBiZSB1c2VkLg0KPg0KPg0KPj4NCj4+IFRoZSBuZWVkIGZvciB0aGUgdW5mb3J0dW5h dGUgcHJveHlpbmcvY29uY2VudHJhdG9ycyBpcyBhIHNob3J0IHRlcm0gc29sdXRpb24gdW50aWwg TVBUQ1AgaXMgbW9yZSB3aWRlc3ByZWFkIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4gDQo+Pg0K Pj4NCj4+IEtpbmQgcmVnYXJkcy9WaWVsZSBHcsO8c3NlDQo+Pg0KPj4gTWFyY3VzDQo+Pg0KPj4g 4oCU4oCULQ0KPj4gTWFyY3VzIEJydW5uZXINCj4+IFN3aXNzY29tDQo+Pg0KPj4NCj4+DQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBBbSAwMS4wNi4xNiwgMjA6Mzcgc2NocmllYiAibXVsdGlw YXRodGNwIGltIEF1ZnRyYWcgdm9uIEJlaGNldCBTYXJpa2F5YSIgPG11bHRpcGF0aHRjcC1ib3Vu Y2VzQGlldGYub3JnIGltIEF1ZnRyYWcgdm9uIHNhcmlrYXlhMjAxMkBnbWFpbC5jb20+Og0KPj4N Cj4+PiBIaSBhbGwsDQo+Pj4NCj4+PiBSZWNlbnQgbWFpbHMgaW4gdGhpcyB0aHJlYWQgY2FtZSB0 byBteSBhdHRlbnRpb24gYmVjYXVzZSBJIHdvcmsgb24gdGhlDQo+Pj4gaHlicmlkIGFjY2VzcyBu ZXR3b3JrIGlzc3VlcyBhbmQgd2lzaCB0byBjb252ZXkgbXkgdmlld3Mgb24gc29tZSBvZg0KPj4+ IHRoZSBpc3N1ZXMgZGlzY3Vzc2VkLg0KPj4+DQo+Pj4gRmlyc3Qgb2YgYWxsLCB0aGUgY2xhaW1z IHRoYXQgdGhlcmUgaXMgc3Ryb25nIG9wZXJhdG9yIGludGVyZXN0IG9uDQo+Pj4gdGhpcyBpcyBv dmVyIGJsb3duLiBIeWJyaWQgYWNjZXNzIGlzIGJhc2VkIG9uIG9mZmxvYWRpbmcgc29tZSBDUEUN Cj4+PiB0cmFmZmljIHRvIDNHL0xURSBuZXR3b3JrLCBJIGRvbid0IHRoaW5rIG1vYmlsZSBvcGVy YXRvcnMgYXJlIGZvbmQgb2YNCj4+PiBzdWNoIGEgdGhpbmcuDQo+Pj4NCj4+PiBBbHNvIEkgc3Ry b25nbHkgY29uY3VyIHdpdGggWW9zaGkncyBwb2ludCBvZiBDUEUgdG8gY29udmVydCBVRFAgb3Ig VENQDQo+Pj4gaW50byBNUFRDUCBhbmQgcmVxdWlyZXMNCj4+PiBDb25jZW50cmF0b3JzIHRvIGNv bnZlcnQgYmFjayBNUFRDUCBpbnRvIFVEUCBvciBUQ1AgaXMgYSBjb21wbGV4DQo+Pj4gcHJvY2Vz cy4gVGhlIGNydXggb2YgdGhpcyBpcyB0aGUgcHJvYmxlbXMgYXJpc2luZyBmcm9tIHRoZSB1c2Ug b2YNCj4+PiBNUFRDUCBmb3IgdHVubmVsaW5nLCB3aGljaCBpcyB3aGF0IHRoaXMgZHJhZnQgaXMg YWR2b2NhdGluZy4NCj4+Pg0KPj4+IEhlcmUgSSByZWNvbW1lbmQgSm9lIFRvdWNoJ3MgSW50YXJl YSBkcmFmdA0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1pbnRhcmVh LXR1bm5lbHMtMDIudHh0DQo+Pj4gb24gSVAgVHVubmVscyBpbiB0aGUgSW50ZXJuZXQgQXJjaGl0 ZWN0dXJlLiBJRVRGIGRldmVsb3BlZCBtYW55DQo+Pj4gdHVubmVsaW5nIHByb3RvY29scyB3aGlj aCBhcmUgc3VydmV5ZWQgaW4gdGhpcyBkcmFmdCBidXQgbm9uZSBvZiB0aGVtDQo+Pj4gYXJlIFRD UC9NUFRDUCBiYXNlZC4NCj4+PiBJIGFsc28gcXVlc3Rpb24gc3VpdGFiaWxpdHkgb2YgdGhpcyB3 b3JrIHRvIHRoZSBjaGFydGVyLiBUaGVyZSBpcyB0aGlzDQo+Pj4gY2hhcnRlciB0ZXh0Og0KPj4+ IEZpbmFsbHksIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZXhwbG9yZSB3aGV0aGVyIGFuIE1QVENQ LWF3YXJlDQo+Pj4gIG1pZGRsZWJveCB3b3VsZCBiZSB1c2VmdWwsIHdoZXJlIGF0IGxlYXN0IG9u ZSBlbmQgaG9zdCBpcyBNUFRDUC1lbmFibGVkLg0KPj4+ICBGb3IgZXhhbXBsZSwgcG90ZW50aWFs bHkgaGVscGluZyBNUFRDUCdzIGluY3JlbWVudGFsIGRlcGxveW1lbnQgYnkNCj4+PiAgYWxsb3dp bmcgb25seSBvbmUgZW5kIGhvc3QgdG8gYmUgTVBUQ1AtZW5hYmxlZCBhbmQgdGhlIG1pZGRsZWJv eCBhY3RzIGFzDQo+Pj4gIGFuIE1QVENQIHByb3h5IGZvciB0aGUgb3RoZXIgZW5kIGhvc3QsIHdo aWNoIHJ1bnMgVENQOyBhbmQgcG90ZW50aWFsbHkNCj4+PiAgaGVscGluZyBzb21lIG1vYmlsaXR5 IHNjZW5hcmlvcywgd2hlcmUgdGhlIG1pZGRsZWJveCBhY3RzIGFzIGFuIGFuY2hvcg0KPj4+ICBi ZXR3ZWVuIHR3byBNUFRDUC1lbmFibGVkIGhvc3RzLiBUaGUgd29ya2luZyBncm91cCB3aWxsIGRl dGFpbCB3aGF0IHJlYWwNCj4+PiAgcHJvYmxlbXMgYW4gTVBUQ1AtZW5hYmxlZCBtaWRkbGVib3gg bWlnaHQgc29sdmUsIGhvdyBpdCB3b3VsZCBpbXBhY3QgdGhlDQo+Pj4gIE11bHRpcGF0aCBUQ1Ag YXJjaGl0ZWN0dXJlIChSRkM2MTgyKSwgd2hhdCBwcm94eSBhcHByb2FjaCBtaWdodCBiZQ0KPj4+ ICBqdXN0aWZpZWQgYXMgY29tcGFyZWQgYWdhaW5zdCBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMgdG8g dGhlIHByb2JsZW1zLCBhbmQNCj4+PiAgdGhlIGxpa2VseSBmZWFzaWJpbGl0eSBvZiBzb2x2aW5n IHRoZSB0ZWNobmljYWwgYW5kIHNlY3VyaXR5IGlzc3Vlcy4NCj4+Pg0KPj4+IFRoaXMgZHJhZnQg aGFzIGEgbWlkZGxlYm94IGNhbGxlZCBDb25jZW50cmF0b3IgYnV0IGl0IGlzIG5vdCB0cnlpbmcg dG8NCj4+PiBlbmFibGUgTVBUQ1AgaG9zdHMgdG8gY29tbXVuaWNhdGUgd2l0aCBUQ1AgaG9zdHMs IGl0IGlzIGp1c3QgdHVubmVsaW5nDQo+Pj4gdGhlIHRyYWZmaWMuIFNvIHRoZXJlIGlzIG5vIGNo YXJ0ZXIgaXRlbSB0aGF0IGZpdHMgdG8gdGhpcyBkcmFmdC4NCj4+PiBJIHN0cm9uZ2x5IHN1Z2dl c3Qgc3RheWluZyBhd2F5IGZyb20gbWFraW5nIE1QVENQIGEgdHVubmVsaW5nIHByb3RvY29sLg0K Pj4+DQo+Pj4gUmVnYXJkcywNCj4+Pg0KPj4+IEJlaGNldA0KPj4+DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBtdWx0aXBhdGh0Y3AgbWFp bGluZyBsaXN0DQo+Pj4gbXVsdGlwYXRodGNwQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3ANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtdWx0aXBhdGh0Y3AgbWFpbGluZyBs aXN0DQo+PiBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5tdWx0aXBhdGh0Y3AgbWFpbGluZyBsaXN0DQo+bXVs dGlwYXRodGNwQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tdWx0aXBhdGh0Y3ANCg== From nobody Thu Jun 2 20:02:33 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA8812D1E8; Thu, 2 Jun 2016 20:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 ip3KoWXyPjdi; Thu, 2 Jun 2016 20:02:26 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A4112B01E; Thu, 2 Jun 2016 20:02:26 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 18FA827862D; Fri, 3 Jun 2016 12:02:24 +0900 (JST) Received: by mail-yw0-f179.google.com with SMTP id o16so68868638ywd.2; Thu, 02 Jun 2016 20:02:24 -0700 (PDT) X-Gm-Message-State: ALyK8tL+XzA3L8cu4y/evou+7N5ZcDiRQLU6z/YandhiQhFfActsgT58ct5Ly+3GEv2y5lfJ9rzFv/OalIEHvw== MIME-Version: 1.0 X-Received: by 10.129.81.151 with SMTP id f145mr990072ywb.266.1464922942661; Thu, 02 Jun 2016 20:02:22 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Thu, 2 Jun 2016 20:02:22 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D8DAC3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> <787AE7BB302AE849A7480A190F8B933008D8DAC3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 2 Jun 2016 20:02:22 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a1145696a9eed80053456f3ee Archived-At: Cc: MultiPath WG , Olivier Bonaventure , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:02:30 -0000 --001a1145696a9eed80053456f3ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, My question was if we can do the same or similar thing at the application level, like create a mapping between a TCP/UDP socket and a MPTCP socket. It doesn't have to be socks. Also, as socks5 supports UDP, the description might not be very precise. Thanks, -- Yoshi On Mon, May 30, 2016 at 1:58 AM, wrote: > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Envoy=C3=A9 :* samedi 28 mai 2016 02:09 > *=C3=80 :* Olivier Bonaventure > *Cc :* Yoshifumi Nishida; Olivier Bonaventure; BOUCADAIR Mohamed IMT/OLN; > MultiPath WG; draft-boucadair-mptcp-plain-mode@ietf.org > *Objet :* Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 > > > > Hi Olivier, > > > > On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure < > olivier.bonaventure@tessares.net> wrote: > > Yoshifumi, > > > > Since the mapping is between a TCP connection (UDP flow) and an > MPTCP connection, it applies for all the subflows of the MPTCP > connection automatically. I'm not in favor of changing the mapping > during the lifetime of an MPTCP connection, it leads to > implementation complexity that are not worth the effort given that > we can establish another MPTCP connection bound to another flow. > > > I see. Sorry. I might be confused by the name of Concentrator.. > > Then, my another question is if we can do the same thing with > application level. > I am wondering if we can write an application gateway for CPE and > Concentrator to send mapping information just like PM option, (and do > some segmentation tasks as well) so that we can mitigate middlebox > interventions. > > > The closest solution in the application level is SOCKS. This is what KT i= s > doing in Korea and what OVH is deploying for their OverTheBox solution. > Both do this on top of MPTCP. > > > > I might want to understand pros and cons for the proposal > > > > [Med] Below is provided an excerpt from the draft: > > > > o No encapsulation required (no tunnels, whatsoever). > > o No out-of-band signaling for each MPTCP subflow required. > > o Carries any protocol (incl. UDP) for the benefit of massive MPTCP > > adoption (Section 5 ). > > o Accommodates various deployment contexts (Section 6 ). > > > > Which can be interpreted as follows: > > =C2=B7 No chatty: the solution does not overload the concentrator= with > out-of-banding signaling messages. > > =C2=B7 No extra delay to establish MPTCP connections. > > =C2=B7 Supports UDP > > =C2=B7 Allows to share the same external IP address among various > subscribers (deployments suffering from IPv4 address depletion) > > =C2=B7 Allows to assign a single IP address for connections that > belong to the same subscriber (deployments with no pressure on IPv4 addre= ss > usage) > > =C2=B7 Allows to preserve the source IPv6 address > > =C2=B7 =E2=80=A6 > > > > The draft acknowledges the overhead for UDP. > > > > and others. > > It would be good to have this sort of discussions in the draft. > > > > [Med] We already have some text in the draft about the cons of using, > e.g., SOCKS: > > > > Current operational MPTCP deployments by network operators are > > focused on the forwarding of TCP traffic. In addition, the design of > > such deployments sometimes assumes the use of extra signalling > > provided by SOCKS [RFC1928 ], at > the cost of additional management > > complexity and possible service degradation (e.g., up to 8 SOCKS > > messages may need to be exchanged between two MPTCP proxies before an > > MPTCP connection is established, thereby yielding several tens of > > milliseconds of extra delay before the connection is established). > > Further, a SOCKS-based solution does not allow to support natively UDP > bonding. > > > > Thanks, > > -- > > Yoshi > --001a1145696a9eed80053456f3ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

My question was if we can do th= e same or similar thing at the application level, like create a mapping bet= ween a TCP/UDP socket and a MPTCP socket. It doesn't have to be socks. = Also, as socks5 supports UDP, the description might not be very precise.

Thanks,
--
Yoshi

On Mon, May 30, 2016 at 1:5= 8 AM, <mohamed.boucadair@orange.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Re-,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Yosh= ifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoy=C3=A9=C2=A0: samedi 28 mai 2016 02:09
=C3=80=C2=A0: Olivier Bonaventure
Cc=C2=A0: Yoshifumi Nishida; Olivier Bonaventure; BOUCADAIR Mohamed = IMT/OLN; MultiPath WG; draft-boucadair-mptcp-plain-mode@ietf.org Objet=C2=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07<= u>

=C2=A0

Hi Olivier,

=C2=A0

On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventur= e <olivier.bonaventure@tessares.net> wrote:

Yoshifumi,<= /u>



=C2=A0 =C2=A0 Since the mapping is between a TCP connection (UDP flow) and = an
=C2=A0 =C2=A0 MPTCP connection, it applies for all the subflows of the MPTC= P
=C2=A0 =C2=A0 connection automatically. I'm not in favor of changing th= e mapping
=C2=A0 =C2=A0 during the lifetime of an MPTCP connection, it leads to
=C2=A0 =C2=A0 implementation complexity that are not worth the effort given= that
=C2=A0 =C2=A0 we can establish another MPTCP connection bound to another fl= ow.


I see. Sorry. I might be confused by the name of Concentrator..

Then, my another question is if we can do the same thing with
application level.
I am wondering if we can write an application gateway for CPE and
Concentrator to send mapping information just like PM option, (and do
some segmentation tasks as well) so that we can mitigate middlebox
interventions.


The closest solution in the application level is SOCKS. This is what KT is = doing in Korea and what OVH is deploying for their OverTheBox solution. Bot= h do this on top of MPTCP.

=C2=A0

I might want to understand pros and cons for the pro= posal

=C2=A0

[Med] Below is provided = an excerpt from the draft:

=C2=A0

=C2=A0=C2=A0 o=C2=A0 No encapsulation required (n=
o tunnels, whatsoever).
=C2=A0=C2=A0 o=C2=A0 No out-of-band signaling for=
 each MPTCP subflow required.
=C2=A0=C2=A0 o=C2=A0 Carries any protocol (incl.=
=C2=A0 UDP) for the benefit of massive MPTCP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 adoption (<=
a href=3D"https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07#s=
ection-5" target=3D"_blank">Section 5).
=C2=A0=C2=A0 o=C2=A0 Accommodates various deployment contexts (Section 6).

=C2=A0

Which can be interpreted as fol= lows:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No chatty: the solution do= es not overload the concentrator with out-of-banding signaling messages.=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No extra delay to establis= h MPTCP connections.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Supports UDP=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allows to share the same e= xternal IP address among various subscribers (deployments suffering from IP= v4 address depletion)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allows to assign a single = IP address for connections that belong to the same subscriber (deployments = with no pressure on IPv4 address usage)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allows to preserve the sou= rce IPv6 address

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A6

=C2=A0

The draft acknowledges the over= head for UDP.

=C2=A0

and others.=C2=A0=

It would be good to have this sort of discussions in= the draft.

=C2=A0

[Med] We already have so= me text in the draft about the cons of using, e.g., SOCKS:

=C2=A0

=C2=A0=C2=A0 Current operational MPTCP depl= oyments by network operators are

=C2=A0=C2=A0 focused on the forwarding of T= CP traffic.=C2=A0 In addition, the design of

=C2=A0=C2=A0 such deployments sometimes ass= umes the use of extra signalling

=C2=A0=C2=A0 provided by SOCKS [RFC1928<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Courier New= "">], at the cost of additional management

=C2=A0=C2=A0 complexity and possible servic= e degradation (e.g., up to 8 SOCKS

=C2=A0=C2=A0 messages may need to be exchan= ged between two MPTCP proxies before an

=C2=A0=C2=A0 MPTCP connection is establishe= d, thereby yielding several tens of

=C2=A0=C2=A0 milliseconds of extra delay be= fore the connection is established).

Further, a SOCKS-based solution= does not allow to support natively UDP bonding.

=C2=A0

Thanks,

--

Yoshi


--001a1145696a9eed80053456f3ee-- From nobody Thu Jun 2 20:04:01 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0312B01E; Thu, 2 Jun 2016 20:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 MLnOKRrhIVHn; Thu, 2 Jun 2016 20:03:54 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3055612D1A0; Thu, 2 Jun 2016 20:03:49 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.161.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id AA57C278638; Fri, 3 Jun 2016 12:03:47 +0900 (JST) Received: by mail-yw0-f182.google.com with SMTP id h19so68965135ywc.0; Thu, 02 Jun 2016 20:03:47 -0700 (PDT) X-Gm-Message-State: ALyK8tKIsaRk6bBVEi/DL6D8Jfdf2r9+erlWcAoTbQsrGrZql7s6akHEZmFt2jSOpB4UpAY0usEFvlwBimAvCQ== MIME-Version: 1.0 X-Received: by 10.37.223.5 with SMTP id w5mr902364ybg.139.1464923026221; Thu, 02 Jun 2016 20:03:46 -0700 (PDT) Received: by 10.13.196.3 with HTTP; Thu, 2 Jun 2016 20:03:46 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D8DAAC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D8DAAC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 2 Jun 2016 20:03:46 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=94eb2c089a9299f67f053456f832 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:03:59 -0000 --94eb2c089a9299f67f053456f832 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, On Mon, May 30, 2016 at 1:48 AM, wrote: > Hi Yoshi, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > *Envoy=C3=A9 :* jeudi 26 mai 2016 08:31 > *=C3=80 :* Olivier Bonaventure > *Cc :* Yoshifumi Nishida; BOUCADAIR Mohamed IMT/OLN; MultiPath WG; > draft-boucadair-mptcp-plain-mode@ietf.org > *Objet :* Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 > > > > Hi Olivier, > > > > On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure < > Olivier.Bonaventure@uclouvain.be> wrote: > > Yoshifumi, > > > I might want to see more feedback before the adoption call. > I've read the draft, but I think I still have some unclear points in the > draft. > > I particularly would like to understand the following points as starting > point. Please let me know if I miss something. > > 1: This method requires CPEs to convert UDP or TCP into MPTCP and > requires Concentrators to convert back MPTCP into UDP or TCP. This could > be rather complex process than other approach such as GRE. So, what's > the benefits to utilize MPTCP here? I think the draft should describe > some useful scenarios to use MPTCP. > > > There is already operational experience with this type of solution and it > turns out that using MPTCP to support TCP traffic in hybrid access networ= ks > is a much better approach than using a tunneling technique like GRE. In a= n > hybrid access network such as DSL+LTE, there are two types of problems th= at > need to be tackled : > > 1. How to hide the different addresses used on the DSL and LTE networks > 2. How to achieve efficient load balancing over networks having different > characteristics (delay, bandwidth, packet losses) that change dynamically > > GRE solves the first problem in a clean manner. However, it causes two > issues when you consider the second problem : > > a. Since paths have different delays, doing per packet load balancing > creates massive reording that results in bad TCP performance > b. Since the two underlying paths are hidden by encapsulation, TCP's > congestion control scheme cannot probe the different paths and adjust ths > congestion window correctl. This results in bad TCP performance as well. > > An MPTCP-based solution solves these problems in a clean manner since > MPTCP sees the different paths and can use them efficiently. > > You can find some additional information in the Tessares whitepaper > published last year > > http://www.tessares.net/white-papers/ > > There is already operational experience with this type of MPTCP-based > solutions and if you think that this would be useful, we could organise a > presentation at the next IETF meeting on this experience > > > > I think I understand general idea. > > But, as far as I read the draft, I got an impression that a UDP or a TCP > flow will be mapped to a single subflow of a mptcp session. > > > > [Med] The draft says the following: > > > > Section 5.1: > > > > The data carried in UDP datagrams belonging to > > a given UDP flow are therefore transported in an MPTCP connection. > > > > The management of MPTCP connections that are triggered by UDP > > datagrams follows the guidelines documented in [RFC6824 ]. > > > > Section 5.2: > > > > A flow example is shown in Figure 5 to illustrate how TCP packets are > > generated to relay UDP datagrams using several subflows. Non-SYN > > messages that belong to a given subflow do not include any PM option. > > Also, this example shows how subsequent UDP datagrams of this flow > > are transported over the existing subflow or how a new subflow is > > created. In this example, the SYN segment issued to add a new > > subflow also includes data received in a UDP datagram. > > > > and > > > > Figure 6 shows an example of UDP datagrams that are transported over > > MPTCP subflows. Unlike the previous example, additional subflows to > > transport UDP datagrams of the same flow are established in advance > > between the CPE and the concentrator. > > > > Do you think additional text is needed to make it clear? Thank you. > Well, It is still not very clear to me how each UDP packet is mapped to a mptcp session. How do you distinguish each UDP packet ? Is it based on 4-tuple or others? The notion of Internal transport session identifier is a bit ambiguous. If 4-tuple is not used, how do you construct packets when you send back them at CPE? > > > There is no description about using multiple subflows for a single TCP/UD= P > flow, or updating subflow mappings in the middle of a session. > > > > [Med] Please refer to Figures 5 & 6. > > > > I think the draft should mention these cases. > > > > > 2: Including data in SYN is allowed in RFC793, but I'm not very sure how > many implementations actually accept it. > > > Well, the deployment of TFO shows that this is possible. > > I think the draft should > discuss this point. Also, what will happen if PM option is included in > the payload, but it is removed by the middleboxes? > > > The assumption is that this solution will be deployed in controlled > environments and only used between the CPE and the Concentrator. Since th= e > operator controls the two networks that are bound together, he can verify > that there are no middleboxes that drop the PM option. > > > > Hmm. then, I think these presumptions should be listed in the draft. > > > > [Med] These assumptions are already called out in the draft, e.g., > > > > Section 1: > > > > Also, it assumes the various > > network attachments provided to an MPTCP-enabled CPE are managed by > > the same administrative entity. > > > > Section 4.2: > > > > Given > > that this option is designed to be used in a controlled > > environment, this specification recommends to always place the PM > > options inside the payload of a SYN segment. > > > > Do you think additional text is still required? > hmm, even though it is designed to be used in a certain environment, what if it is used in other situations? I personally think the draft is a bit ambiguous on this point. -- Yoshi --94eb2c089a9299f67f053456f832 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

On Mon, May 30, 2016 at 1:48 AM, <mohamed.boucadai= r@orange.com> wrote:

Hi Yoshi,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoy=C3=A9=C2=A0: jeudi 26 mai 2016 08:31
=C3=80=C2=A0: Olivier Bonaventure
Cc=C2=A0: Yoshifumi Nishida; BOUCADAIR Mohamed IMT/OLN; MultiPath WG= ; draft-boucadair-mptcp-plain-mode@ietf.org
Objet=C2=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07<= u>

=C2=A0

Hi Olivier,

=C2=A0

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventur= e <Olivier.Bonaventure@uclouvain.be> wrote:

Yoshifumi,


I might want to see more feedback before the adoption call.
I've read the draft, but I think I still have some unclear points in th= e
draft.

I particularly would like to understand the following points as starting point. Please let me know if I miss something.

1: This method requires CPEs to convert UDP or TCP into MPTCP and
requires Concentrators to convert back MPTCP into UDP or TCP. This could be rather complex process than other approach such as GRE. So, what's the benefits to utilize MPTCP here? I think the draft should describe
some useful scenarios to use MPTCP.


There is already operational experience with this type of solution and it t= urns out that using MPTCP to support TCP traffic in hybrid access networks = is a much better approach than using a tunneling technique like GRE. In an = hybrid access network such as DSL+LTE, there are two types of problems that need to be tackled :

1. How to hide the different addresses used on the DSL and LTE networks
2. How to achieve efficient load balancing over networks having different c= haracteristics (delay, bandwidth, packet losses) that change dynamically
GRE solves the first problem in a clean manner. However, it causes two issu= es when you consider the second problem :

a. Since paths have different delays, doing per packet load balancing creat= es massive reording that results in bad TCP performance
b. Since the two underlying paths are hidden by encapsulation, TCP's co= ngestion control scheme cannot probe the different paths and adjust ths con= gestion window correctl. This results in bad TCP performance as well.

An MPTCP-based solution solves these problems in a clean manner since MPTCP= sees the different paths and can use them efficiently.

You can find some additional information in the Tessares whitepaper publish= ed last year

http://= www.tessares.net/white-papers/

There is already operational experience with this type of MPTCP-based solut= ions and if you think that this would be useful, we could organise a presen= tation at the next IETF meeting on this experience

=C2=A0

I think I understand general idea.

But, as far as I read the draft, I got an impression= that a UDP or a TCP flow will be mapped to a single subflow of a mptcp ses= sion.=C2=A0

=C2=A0

[Med] The draft says th= e following:

=C2=A0

Section 5.1:

=C2=A0

The data carried in UDP datagrams belonging to=

=C2=A0=C2=A0 a given UDP flow are therefore trans=
ported in an MPTCP connection.
=C2=A0
=C2=A0=C2=A0 The management of MPTCP connections =
that are triggered by UDP
=C2=A0=C2=A0 datagrams follows the guidelines doc=
umented in [RFC6824].

=C2=A0

Section 5.2:

=C2=A0

=C2=A0=C2=A0 A flow example is shown in Figure = 5 to illustrate how TCP packets are

=C2=A0=C2=A0 generated to relay UDP datagrams u= sing several subflows.=C2=A0 Non-SYN

=C2=A0=C2=A0 messages that belong to a given su= bflow do not include any PM option.

=C2=A0=C2=A0 Also, this example shows how subse= quent UDP datagrams of this flow

=C2=A0=C2=A0 are transported over the existing = subflow or how a new subflow is

=C2=A0=C2=A0 created.=C2=A0 In this example, th= e SYN segment issued to add a new

=C2=A0=C2=A0 subflow also includes data receive= d in a UDP datagram.

=C2=A0

and

=C2=A0

=C2=A0=C2=A0 Figure 6 shows an example of UDP dat=
agrams that are transported over
=C2=A0=C2=A0 MPTCP subflows.=C2=A0 Unlike the pre=
vious example, additional subflows to
=C2=A0=C2=A0 transport UDP datagrams of the same =
flow are established in advance
=C2=A0=C2=A0 between the CPE and the concentrator=
.

=C2=A0

Do you think additional text is nee= ded to make it clear? Thank you.


Well, It is still not very= clear to me how each UDP packet is mapped to a mptcp session.
How do you distinguish each UDP packet ? Is it based on 4-tuple or others= ? The notion of=C2=A0I= nternal transport session identifier is a bit ambiguous.
<= span style=3D"color:rgb(0,0,0);font-size:13.3333px">If 4-tuple is not used,= how do you construct packets when you send back them at CPE?
<= div>=C2=A0

=C2=A0

There is no description about u= sing multiple subflows for a single TCP/UDP flow, or updating subflow mappi= ngs in the middle of a session.

=C2=A0

[Med] Please refer to Figure= s 5 & 6.

=C2=A0

I think the draft should mention these cases.=

=C2=A0


2: Including data in SYN is allowed in RFC793, but I'm not very sure ho= w
many implementations actually accept it.


Well, the deployment of TFO shows that this is possible.

I think the draft should
discuss this point. Also, what will happen if PM option is included in
the payload, but it is removed by the middleboxes?


The assumption is that this solution will be deployed in controlled environ= ments and only used between the CPE and the Concentrator. Since the operato= r controls the two networks that are bound together, he can verify that the= re are no middleboxes that drop the PM option.

=C2=A0

Hmm. then, I think these presumptions should be list= ed in the draft.

=C2=A0

[Med] These assumptions are = already called out in the draft, e.g.,

=C2=A0

Section 1:

=C2=A0

Also, it assumes the various=

=C2=A0=C2=A0 network attachments provided to an M=
PTCP-enabled CPE are managed by
=C2=A0=C2=A0 the same administrative entity.

=C2=A0

Section 4.2:

=C2=A0

Given
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0that this option i=
s designed to be used in a controlled
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 environment, this =
specification recommends to always place the PM
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options inside the=
 payload of a SYN segment.

=C2=A0

Do you think additional text is sti= ll required?


hmm, even though it is designed to be used in = a certain environment, what if it is used in other situations?
I = personally think the draft is a bit ambiguous on this point.
--
Yoshi

--94eb2c089a9299f67f053456f832-- From nobody Thu Jun 2 21:18:28 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BBD12D0F9 for ; Thu, 2 Jun 2016 21:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 d3Z6ou1WUa15 for ; Thu, 2 Jun 2016 21:18:22 -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 EDBD912B05F for ; Thu, 2 Jun 2016 21:18:21 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u534Hn4s012716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Jun 2016 21:17:51 -0700 (PDT) To: "Henderickx, Wim (Nokia - BE)" , "Markus.Brunner3@swisscom.com" , "sarikaya@ieee.org" , "multipathtcp@ietf.org" References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <0920D50D-3D89-44EB-9D61-122CD10E0B56@alcatel-lucent.com> From: Joe Touch Message-ID: <575104EA.7040201@isi.edu> Date: Thu, 2 Jun 2016 21:17:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <0920D50D-3D89-44EB-9D61-122CD10E0B56@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 04:18:23 -0000 On 6/2/2016 7:58 PM, Henderickx, Wim (Nokia - BE) wrote: > In-line > > > > > On 02/06/16 10:17, "multipathtcp on behalf of Joe Touch" wrote: > >> >> On 6/2/2016 7:02 AM, Markus.Brunner3@swisscom.com wrote: >>> Hi Behcet, >>> >>> As one of the operators very interested in this, I don’t think it is over blown and the use case you describe might be the first one for a number of operators, but others are following. Fundamentally it is about resource pooling of access networking resources (of whatever technology transporting IP). >>> >>> We are well-aware of the problems of a MPTCP-based solution (and draft-boucadair tries to solve some of them). However, we are not aware of any better standardized solution for multiple paths with heterogeneous characteristics of available and varying bandwidth, varying delays, and different packet handling characteristics. In case there is better ways of solving that problem let us know. >> Why wouldn't an overlay that employs dynamic routing be easier? >> >> It wouldn't incur the delays of using reliable delivery with messages >> that don't preserve IP datagram boundaries and it's already supported >> with existing equipment. Further, it could use much more sophisticated >> path monitoring and choice. >> >> I.e., this is exactly what you'd get if you deploy something akin to >> LISP and basically ignore the label distribution problem (which you >> really don't have). >> >> Joe > WH> it doesn’t solve the use case where packets of a flow have to be split over multiple links and reordering + congestion control is required for these flows. If these requirements were not there you’re right that routing can be used. What you really don't want are: - to take a RTT hiccup to recover from a segment loss - to implement congestion control over your tunnels underneath congestion control inside transport on the IP packets you carry IMO, order preservation should be something done at the endpoints, not in the net, but if that's all you have left you can implement that with a fixed amount of delay at the egress collection point. None of this is worth the complexity and side-effects of MPTCP, IMO. Joe From nobody Thu Jun 2 22:29:25 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8A12D58B for ; Thu, 2 Jun 2016 22:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 bW-XdvwYjPUJ for ; Thu, 2 Jun 2016 22:29:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.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 BA22512D588 for ; Thu, 2 Jun 2016 22:29:20 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 8A3CDC0985; Fri, 3 Jun 2016 07:29:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 6196B120063; Fri, 3 Jun 2016 07:29:18 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 07:29:18 +0200 From: To: "sarikaya@ieee.org" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdG9WNjsVfDVndCKSyeA71f2kyLjwA== Date: Fri, 3 Jun 2016 05:29:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DABDFA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:29:24 -0000 Hi Behcet,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Behcet Sarikaya > Envoy=E9=A0: mercredi 1 juin 2016 20:38 > =C0=A0: multipathtcp@ietf.org > Objet=A0: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > Hi all, >=20 > Recent mails in this thread came to my attention because I work on the > hybrid access network issues and wish to convey my views on some of > the issues discussed. >=20 > First of all, the claims that there is strong operator interest on > this is over blown. Hybrid access is based on offloading some CPE > traffic to 3G/LTE network, I don't think mobile operators are fond of > such a thing. >=20 [Med] I confirm there is interest from operators. You can check, for exampl= e, http://www.netmanias.com/en/?m=3Dview&id=3Dreports&no=3D8532.=20 > Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP > into MPTCP and requires > Concentrators to convert back MPTCP into UDP or TCP is a complex > process.=20 [Med] FWIW, UDP/TCP conversion is not new. You can play with a Linux tool l= ike http://linux.die.net/man/1/socat. Also, it is a feature implemented by = SBCs (e.g., http://www.sip-dojo.com/why-brekeke-sip-server/tcp-udp-conversi= on). =20 The crux of this is the problems arising from the use of > MPTCP for tunneling, which is what this draft is advocating. >=20 > Here I recommend Joe Touch's Intarea draft > https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt > on IP Tunnels in the Internet Architecture. IETF developed many > tunneling protocols which are surveyed in this draft but none of them > are TCP/MPTCP based. [Med] One of the currently deployed MPTCP schemes relies on SOCKS, which do= es not require any tunneling at all! The Plain Mode solves many of the issu= es raised by SOCKS.=20 > I also question suitability of this work to the charter. There is this > charter text: > Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is MPTCP-enabled= . > For example, potentially helping MPTCP's incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts a= s > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what rea= l > problems an MPTCP-enabled middlebox might solve, how it would impact th= e > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, an= d > the likely feasibility of solving the technical and security issues. >=20 > This draft has a middlebox called Concentrator but it is not trying to > enable MPTCP hosts to communicate with TCP hosts, [Med] Hmm, the draft also covers MPTCP-enabled hosts, e.g.,:=20 o An MPTCP-enabled, multi-interfaced CPE or host that is directly ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ connected to one or multiple access networks is allocated ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 addresses/prefixes via legacy mechanisms (e.g., DHCP) supported by the various available network attachments. or This document focuses on the CPE-based model (i.e., the CPE embeds a MPTCP proxy that behaves on behalf of terminal devices), but plain transport mode can also apply to host-based models. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Both CPE and host-based models are in scope. From nobody Thu Jun 2 22:43:40 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B749912B069; Thu, 2 Jun 2016 22:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 B-Y41XKY9CHd; Thu, 2 Jun 2016 22:43:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4290D12B019; Thu, 2 Jun 2016 22:43:36 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5FD7D324E2C; Fri, 3 Jun 2016 07:43:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 38C1835C048; Fri, 3 Jun 2016 07:43:34 +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.0294.000; Fri, 3 Jun 2016 07:43:33 +0200 From: To: Yoshifumi Nishida Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvURZVfDVndCKSyeA71f2kyLjwJ/XN7qA Date: Fri, 3 Jun 2016 05:43:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DABE1B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> <787AE7BB302AE849A7480A190F8B933008D8DAC3@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DABE1BOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.3.43316 Archived-At: Cc: MultiPath WG , Olivier Bonaventure , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:43:40 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DABE1BOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNClllcywgU09DS1M1IHN1cHBvcnRzIFVEUCDigKYgYnV0IGZvciBzaWduZ2xl IHBhdGhzLiBFeHRlbnNpb25zIGFyZSByZXF1aXJlZCBzbyB0aGF0IHBhY2tldHMgZnJvbSBhIGdp dmVuIGhvc3QvQ1BFIHNlbnQgb3ZlciBtdWx0aXBsZSBwYXRocyAoaS5lLiwgd2l0aCBkaXN0aW5j dCBzb3VyY2UgSVAgYWRkcmVzc2VzKSBhcmUg4oCcZ2x1ZWTigJ0gc28gdGhhdCB0aGUgc2FtZSBl eHRlcm5hbCBJUCBhZGRyZXNzL3BvcnQgaXMgdXNlZCBieSB0aGUgU09DS1Mgc2VydmVyLiBBbHNv LCB0aGUgU09DS1Mgb3V0LW9mLWJhbmRpbmcgc2lnbmFsaW5nIHdpbGwgaW5kdWNlIGFuIGV4dHJh IGRlbGF5IGZvciBoYW5kbGluZyBVRFAgZmxvd3MuIFRoaXMgaXMgc3Vib3B0aW1hbC4NCg0KVGhh bmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBZb3NoaWZ1bWkgTmlzaGlkYSBbbWFpbHRv Om5pc2hpZGFAc2ZjLndpZGUuYWQuanBdDQpFbnZvecOpIDogdmVuZHJlZGkgMyBqdWluIDIwMTYg MDU6MDINCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KQ2MgOiBZb3NoaWZ1bWkgTmlz aGlkYTsgT2xpdmllciBCb25hdmVudHVyZTsgT2xpdmllciBCb25hdmVudHVyZTsgTXVsdGlQYXRo IFdHOyBkcmFmdC1ib3VjYWRhaXItbXB0Y3AtcGxhaW4tbW9kZUBpZXRmLm9yZw0KT2JqZXQgOiBS ZTogW211bHRpcGF0aHRjcF0gZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGUtMDcNCg0K SGkgTWVkLA0KDQpNeSBxdWVzdGlvbiB3YXMgaWYgd2UgY2FuIGRvIHRoZSBzYW1lIG9yIHNpbWls YXIgdGhpbmcgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsLCBsaWtlIGNyZWF0ZSBhIG1hcHBpbmcg YmV0d2VlbiBhIFRDUC9VRFAgc29ja2V0IGFuZCBhIE1QVENQIHNvY2tldC4gSXQgZG9lc24ndCBo YXZlIHRvIGJlIHNvY2tzLiBBbHNvLCBhcyBzb2NrczUgc3VwcG9ydHMgVURQLCB0aGUgZGVzY3Jp cHRpb24gbWlnaHQgbm90IGJlIHZlcnkgcHJlY2lzZS4NCg0KVGhhbmtzLA0KLS0NCllvc2hpDQoN Ck9uIE1vbiwgTWF5IDMwLCAyMDE2IGF0IDE6NTggQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQpSZS0s DQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBZb3NoaWZ1bWkg TmlzaGlkYSBbbWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanA8bWFpbHRvOm5pc2hpZGFAc2Zj LndpZGUuYWQuanA+XQ0KRW52b3nDqSA6IHNhbWVkaSAyOCBtYWkgMjAxNiAwMjowOQ0Kw4AgOiBP bGl2aWVyIEJvbmF2ZW50dXJlDQpDYyA6IFlvc2hpZnVtaSBOaXNoaWRhOyBPbGl2aWVyIEJvbmF2 ZW50dXJlOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBNdWx0aVBhdGggV0c7IGRyYWZ0LWJv dWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlQGlldGYub3JnPG1haWx0bzpkcmFmdC1ib3VjYWRhaXIt bXB0Y3AtcGxhaW4tbW9kZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFttdWx0aXBhdGh0Y3BdIGRy YWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3DQoNCkhpIE9saXZpZXIsDQoNCk9uIEZy aSwgTWF5IDI3LCAyMDE2IGF0IDEyOjM4IEFNLCBPbGl2aWVyIEJvbmF2ZW50dXJlIDxvbGl2aWVy LmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldDxtYWlsdG86b2xpdmllci5ib25hdmVudHVyZUB0ZXNz YXJlcy5uZXQ+PiB3cm90ZToNCllvc2hpZnVtaSwNCg0KDQogICAgU2luY2UgdGhlIG1hcHBpbmcg aXMgYmV0d2VlbiBhIFRDUCBjb25uZWN0aW9uIChVRFAgZmxvdykgYW5kIGFuDQogICAgTVBUQ1Ag Y29ubmVjdGlvbiwgaXQgYXBwbGllcyBmb3IgYWxsIHRoZSBzdWJmbG93cyBvZiB0aGUgTVBUQ1AN CiAgICBjb25uZWN0aW9uIGF1dG9tYXRpY2FsbHkuIEknbSBub3QgaW4gZmF2b3Igb2YgY2hhbmdp bmcgdGhlIG1hcHBpbmcNCiAgICBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIGFuIE1QVENQIGNvbm5l Y3Rpb24sIGl0IGxlYWRzIHRvDQogICAgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSB0aGF0IGFy ZSBub3Qgd29ydGggdGhlIGVmZm9ydCBnaXZlbiB0aGF0DQogICAgd2UgY2FuIGVzdGFibGlzaCBh bm90aGVyIE1QVENQIGNvbm5lY3Rpb24gYm91bmQgdG8gYW5vdGhlciBmbG93Lg0KDQoNCkkgc2Vl LiBTb3JyeS4gSSBtaWdodCBiZSBjb25mdXNlZCBieSB0aGUgbmFtZSBvZiBDb25jZW50cmF0b3Iu Lg0KDQpUaGVuLCBteSBhbm90aGVyIHF1ZXN0aW9uIGlzIGlmIHdlIGNhbiBkbyB0aGUgc2FtZSB0 aGluZyB3aXRoDQphcHBsaWNhdGlvbiBsZXZlbC4NCkkgYW0gd29uZGVyaW5nIGlmIHdlIGNhbiB3 cml0ZSBhbiBhcHBsaWNhdGlvbiBnYXRld2F5IGZvciBDUEUgYW5kDQpDb25jZW50cmF0b3IgdG8g c2VuZCBtYXBwaW5nIGluZm9ybWF0aW9uIGp1c3QgbGlrZSBQTSBvcHRpb24sIChhbmQgZG8NCnNv bWUgc2VnbWVudGF0aW9uIHRhc2tzIGFzIHdlbGwpIHNvIHRoYXQgd2UgY2FuIG1pdGlnYXRlIG1p ZGRsZWJveA0KaW50ZXJ2ZW50aW9ucy4NCg0KVGhlIGNsb3Nlc3Qgc29sdXRpb24gaW4gdGhlIGFw cGxpY2F0aW9uIGxldmVsIGlzIFNPQ0tTLiBUaGlzIGlzIHdoYXQgS1QgaXMgZG9pbmcgaW4gS29y ZWEgYW5kIHdoYXQgT1ZIIGlzIGRlcGxveWluZyBmb3IgdGhlaXIgT3ZlclRoZUJveCBzb2x1dGlv bi4gQm90aCBkbyB0aGlzIG9uIHRvcCBvZiBNUFRDUC4NCg0KSSBtaWdodCB3YW50IHRvIHVuZGVy c3RhbmQgcHJvcyBhbmQgY29ucyBmb3IgdGhlIHByb3Bvc2FsDQoNCltNZWRdIEJlbG93IGlzIHBy b3ZpZGVkIGFuIGV4Y2VycHQgZnJvbSB0aGUgZHJhZnQ6DQoNCg0KICAgbyAgTm8gZW5jYXBzdWxh dGlvbiByZXF1aXJlZCAobm8gdHVubmVscywgd2hhdHNvZXZlcikuDQoNCiAgIG8gIE5vIG91dC1v Zi1iYW5kIHNpZ25hbGluZyBmb3IgZWFjaCBNUFRDUCBzdWJmbG93IHJlcXVpcmVkLg0KDQogICBv ICBDYXJyaWVzIGFueSBwcm90b2NvbCAoaW5jbC4gIFVEUCkgZm9yIHRoZSBiZW5lZml0IG9mIG1h c3NpdmUgTVBUQ1ANCg0KICAgICAgYWRvcHRpb24gKFNlY3Rpb24gNTxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGUtMDcjc2VjdGlvbi01 PikuDQoNCiAgIG8gIEFjY29tbW9kYXRlcyB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMgKFNl Y3Rpb24gNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLW1wdGNw LXBsYWluLW1vZGUtMDcjc2VjdGlvbi02PikuDQoNCldoaWNoIGNhbiBiZSBpbnRlcnByZXRlZCBh cyBmb2xsb3dzOg0KDQrigKIgICAgICAgICBObyBjaGF0dHk6IHRoZSBzb2x1dGlvbiBkb2VzIG5v dCBvdmVybG9hZCB0aGUgY29uY2VudHJhdG9yIHdpdGggb3V0LW9mLWJhbmRpbmcgc2lnbmFsaW5n IG1lc3NhZ2VzLg0KDQrigKIgICAgICAgICBObyBleHRyYSBkZWxheSB0byBlc3RhYmxpc2ggTVBU Q1AgY29ubmVjdGlvbnMuDQoNCuKAoiAgICAgICAgIFN1cHBvcnRzIFVEUA0KDQrigKIgICAgICAg ICBBbGxvd3MgdG8gc2hhcmUgdGhlIHNhbWUgZXh0ZXJuYWwgSVAgYWRkcmVzcyBhbW9uZyB2YXJp b3VzIHN1YnNjcmliZXJzIChkZXBsb3ltZW50cyBzdWZmZXJpbmcgZnJvbSBJUHY0IGFkZHJlc3Mg ZGVwbGV0aW9uKQ0KDQrigKIgICAgICAgICBBbGxvd3MgdG8gYXNzaWduIGEgc2luZ2xlIElQIGFk ZHJlc3MgZm9yIGNvbm5lY3Rpb25zIHRoYXQgYmVsb25nIHRvIHRoZSBzYW1lIHN1YnNjcmliZXIg KGRlcGxveW1lbnRzIHdpdGggbm8gcHJlc3N1cmUgb24gSVB2NCBhZGRyZXNzIHVzYWdlKQ0KDQri gKIgICAgICAgICBBbGxvd3MgdG8gcHJlc2VydmUgdGhlIHNvdXJjZSBJUHY2IGFkZHJlc3MNCg0K 4oCiICAgICAgICAg4oCmDQoNClRoZSBkcmFmdCBhY2tub3dsZWRnZXMgdGhlIG92ZXJoZWFkIGZv ciBVRFAuDQoNCmFuZCBvdGhlcnMuDQpJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgdGhpcyBzb3J0 IG9mIGRpc2N1c3Npb25zIGluIHRoZSBkcmFmdC4NCg0KW01lZF0gV2UgYWxyZWFkeSBoYXZlIHNv bWUgdGV4dCBpbiB0aGUgZHJhZnQgYWJvdXQgdGhlIGNvbnMgb2YgdXNpbmcsIGUuZy4sIFNPQ0tT Og0KDQogICBDdXJyZW50IG9wZXJhdGlvbmFsIE1QVENQIGRlcGxveW1lbnRzIGJ5IG5ldHdvcmsg b3BlcmF0b3JzIGFyZQ0KICAgZm9jdXNlZCBvbiB0aGUgZm9yd2FyZGluZyBvZiBUQ1AgdHJhZmZp Yy4gIEluIGFkZGl0aW9uLCB0aGUgZGVzaWduIG9mDQogICBzdWNoIGRlcGxveW1lbnRzIHNvbWV0 aW1lcyBhc3N1bWVzIHRoZSB1c2Ugb2YgZXh0cmEgc2lnbmFsbGluZw0KICAgcHJvdmlkZWQgYnkg U09DS1MgW1JGQzE5Mjg8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE5Mjg+XSwgYXQg dGhlIGNvc3Qgb2YgYWRkaXRpb25hbCBtYW5hZ2VtZW50DQogICBjb21wbGV4aXR5IGFuZCBwb3Nz aWJsZSBzZXJ2aWNlIGRlZ3JhZGF0aW9uIChlLmcuLCB1cCB0byA4IFNPQ0tTDQogICBtZXNzYWdl cyBtYXkgbmVlZCB0byBiZSBleGNoYW5nZWQgYmV0d2VlbiB0d28gTVBUQ1AgcHJveGllcyBiZWZv cmUgYW4NCiAgIE1QVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQsIHRoZXJlYnkgeWllbGRp bmcgc2V2ZXJhbCB0ZW5zIG9mDQogICBtaWxsaXNlY29uZHMgb2YgZXh0cmEgZGVsYXkgYmVmb3Jl IHRoZSBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkKS4NCkZ1cnRoZXIsIGEgU09DS1MtYmFzZWQg c29sdXRpb24gZG9lcyBub3QgYWxsb3cgdG8gc3VwcG9ydCBuYXRpdmVseSBVRFAgYm9uZGluZy4N Cg0KVGhhbmtzLA0KLS0NCllvc2hpDQoNCg== --_000_787AE7BB302AE849A7480A190F8B933008DABE1BOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5UZXh0ZWRlYnVs bGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZS O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5IaSBZb3NoaSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlll cywgU09DS1M1IHN1cHBvcnRzIFVEUCDigKYgYnV0IGZvciBzaWduZ2xlIHBhdGhzLiBFeHRlbnNp b25zIGFyZSByZXF1aXJlZCBzbyB0aGF0IHBhY2tldHMgZnJvbSBhIGdpdmVuIGhvc3QvQ1BFIHNl bnQgb3ZlciBtdWx0aXBsZSBwYXRocyAoaS5lLiwgd2l0aCBkaXN0aW5jdA0KIHNvdXJjZSBJUCBh ZGRyZXNzZXMpIGFyZSDigJxnbHVlZOKAnSBzbyB0aGF0IHRoZSBzYW1lIGV4dGVybmFsIElQIGFk ZHJlc3MvcG9ydCBpcyB1c2VkIGJ5IHRoZSBTT0NLUyBzZXJ2ZXIuIEFsc28sIHRoZSBTT0NLUyBv dXQtb2YtYmFuZGluZyBzaWduYWxpbmcgd2lsbCBpbmR1Y2UgYW4gZXh0cmEgZGVsYXkgZm9yIGhh bmRsaW5nIFVEUCBmbG93cy4gVGhpcyBpcyBzdWJvcHRpbWFsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlv c2hpZnVtaSBOaXNoaWRhIFttYWlsdG86bmlzaGlkYUBzZmMud2lkZS5hZC5qcF0NCjxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAzIGp1aW4gMjAxNiAwNTowMjxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gWW9zaGlmdW1pIE5pc2hpZGE7IE9saXZpZXIgQm9uYXZlbnR1cmU7IE9saXZpZXIgQm9uYXZl bnR1cmU7IE11bHRpUGF0aCBXRzsgZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGVAaWV0 Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBkcmFmdC1i b3VjYWRhaXItbXB0Y3AtcGxhaW4tbW9kZS0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBxdWVzdGlvbiB3YXMgaWYgd2UgY2FuIGRvIHRoZSBz YW1lIG9yIHNpbWlsYXIgdGhpbmcgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsLCBsaWtlIGNyZWF0 ZSBhIG1hcHBpbmcgYmV0d2VlbiBhIFRDUC9VRFAgc29ja2V0IGFuZCBhIE1QVENQIHNvY2tldC4g SXQgZG9lc24ndCBoYXZlIHRvIGJlIHNvY2tzLiBBbHNvLCBhcyBzb2NrczUgc3VwcG9ydHMgVURQ LCB0aGUgZGVzY3JpcHRpb24gbWlnaHQgbm90IGJlDQogdmVyeSBwcmVjaXNlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9zaGk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWF5IDMwLCAy MDE2IGF0IDE6NTggQU0sICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUtLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlv c2hpZnVtaSBOaXNoaWRhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUu YWQuanAiIHRhcmdldD0iX2JsYW5rIj5uaXNoaWRhQHNmYy53aWRlLmFkLmpwPC9hPl0NCjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMjggbWFpIDIwMTYgMDI6MDk8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IE9saXZpZXIgQm9uYXZlbnR1cmU8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFlv c2hpZnVtaSBOaXNoaWRhOyBPbGl2aWVyIEJvbmF2ZW50dXJlOyBCT1VDQURBSVIgTW9oYW1lZCBJ TVQvT0xOOyBNdWx0aVBhdGggV0c7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtYm91Y2FkYWlyLW1w dGNwLXBsYWluLW1vZGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1ib3VjYWRhaXIt bXB0Y3AtcGxhaW4tbW9kZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJl OiBbbXVsdGlwYXRodGNwXSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AtcGxhaW4tbW9kZS0wNzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkg T2xpdmllciw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJp LCBNYXkgMjcsIDIwMTYgYXQgMTI6MzggQU0sIE9saXZpZXIgQm9uYXZlbnR1cmUgJmx0OzxhIGhy ZWY9Im1haWx0bzpvbGl2aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPllvc2hpZnVtaSw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBTaW5jZSB0aGUg bWFwcGluZyBpcyBiZXR3ZWVuIGEgVENQIGNvbm5lY3Rpb24gKFVEUCBmbG93KSBhbmQgYW48YnI+ DQombmJzcDsgJm5ic3A7IE1QVENQIGNvbm5lY3Rpb24sIGl0IGFwcGxpZXMgZm9yIGFsbCB0aGUg c3ViZmxvd3Mgb2YgdGhlIE1QVENQPGJyPg0KJm5ic3A7ICZuYnNwOyBjb25uZWN0aW9uIGF1dG9t YXRpY2FsbHkuIEknbSBub3QgaW4gZmF2b3Igb2YgY2hhbmdpbmcgdGhlIG1hcHBpbmc8YnI+DQom bmJzcDsgJm5ic3A7IGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgYW4gTVBUQ1AgY29ubmVjdGlvbiwg aXQgbGVhZHMgdG88YnI+DQombmJzcDsgJm5ic3A7IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkg dGhhdCBhcmUgbm90IHdvcnRoIHRoZSBlZmZvcnQgZ2l2ZW4gdGhhdDxicj4NCiZuYnNwOyAmbmJz cDsgd2UgY2FuIGVzdGFibGlzaCBhbm90aGVyIE1QVENQIGNvbm5lY3Rpb24gYm91bmQgdG8gYW5v dGhlciBmbG93Ljxicj4NCjxicj4NCjxicj4NCkkgc2VlLiBTb3JyeS4gSSBtaWdodCBiZSBjb25m dXNlZCBieSB0aGUgbmFtZSBvZiBDb25jZW50cmF0b3IuLjxicj4NCjxicj4NClRoZW4sIG15IGFu b3RoZXIgcXVlc3Rpb24gaXMgaWYgd2UgY2FuIGRvIHRoZSBzYW1lIHRoaW5nIHdpdGg8YnI+DQph cHBsaWNhdGlvbiBsZXZlbC48YnI+DQpJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gd3JpdGUgYW4g YXBwbGljYXRpb24gZ2F0ZXdheSBmb3IgQ1BFIGFuZDxicj4NCkNvbmNlbnRyYXRvciB0byBzZW5k IG1hcHBpbmcgaW5mb3JtYXRpb24ganVzdCBsaWtlIFBNIG9wdGlvbiwgKGFuZCBkbzxicj4NCnNv bWUgc2VnbWVudGF0aW9uIHRhc2tzIGFzIHdlbGwpIHNvIHRoYXQgd2UgY2FuIG1pdGlnYXRlIG1p ZGRsZWJveDxicj4NCmludGVydmVudGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NClRoZSBjbG9zZXN0IHNvbHV0aW9uIGluIHRoZSBhcHBsaWNhdGlvbiBs ZXZlbCBpcyBTT0NLUy4gVGhpcyBpcyB3aGF0IEtUIGlzIGRvaW5nIGluIEtvcmVhIGFuZCB3aGF0 IE9WSCBpcyBkZXBsb3lpbmcgZm9yIHRoZWlyIE92ZXJUaGVCb3ggc29sdXRpb24uIEJvdGggZG8g dGhpcyBvbiB0b3Agb2YgTVBUQ1AuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBtaWdodCB3YW50IHRvIHVuZGVyc3RhbmQgcHJvcyBhbmQgY29ucyBm b3IgdGhlIHByb3Bvc2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g QmVsb3cgaXMgcHJvdmlkZWQgYW4gZXhjZXJwdCBmcm9tIHRoZSBkcmFmdDo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTm8gZW5jYXBzdWxhdGlvbiByZXF1aXJlZCAo bm8gdHVubmVscywgd2hhdHNvZXZlcikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBObyBvdXQtb2YtYmFuZCBzaWdu YWxpbmcgZm9yIGVhY2ggTVBUQ1Agc3ViZmxvdyByZXF1aXJlZC48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IENhcnJp ZXMgYW55IHByb3RvY29sIChpbmNsLiZuYnNwOyBVRFApIGZvciB0aGUgYmVuZWZpdCBvZiBtYXNz aXZlIE1QVENQPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPmFkb3B0aW9uICg8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWlu LW1vZGUtMDcjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiA1PC9hPikuPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQWNjb21tb2RhdGVzIHZhcmlv dXMgZGVwbG95bWVudCBjb250ZXh0cyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3I3NlY3Rpb24tNiIgdGFyZ2V0 PSJfYmxhbmsiPlNlY3Rpb24gNjwvYT4pLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPldoaWNoIGNhbiBiZSBpbnRlcnByZXRlZCBhcyBmb2xsb3dzOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk5vIGNoYXR0eTogdGhlIHNvbHV0aW9uIGRvZXMg bm90IG92ZXJsb2FkIHRoZSBjb25jZW50cmF0b3Igd2l0aCBvdXQtb2YtYmFuZGluZyBzaWduYWxp bmcgbWVzc2FnZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+ wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Tm8gZXh0cmEgZGVsYXkg dG8gZXN0YWJsaXNoIE1QVENQIGNvbm5lY3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT eW1ib2w7Y29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlN1cHBvcnRzIFVEUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6Ymxh Y2siPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFsbG93cyB0byBz aGFyZSB0aGUgc2FtZSBleHRlcm5hbCBJUCBhZGRyZXNzIGFtb25nIHZhcmlvdXMgc3Vic2NyaWJl cnMgKGRlcGxveW1lbnRzIHN1ZmZlcmluZyBmcm9tIElQdjQgYWRkcmVzcyBkZXBsZXRpb24pPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWxsb3dzIHRvIGFzc2lnbiBhIHNpbmdsZSBJUCBh ZGRyZXNzIGZvciBjb25uZWN0aW9ucyB0aGF0IGJlbG9uZyB0byB0aGUgc2FtZSBzdWJzY3JpYmVy IChkZXBsb3ltZW50cyB3aXRoIG5vIHByZXNzdXJlIG9uIElQdjQgYWRkcmVzcyB1c2FnZSk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGxvd3MgdG8gcHJlc2VydmUgdGhlIHNvdXJjZSBJ UHY2IGFkZHJlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj7C tzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igKY8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkcmFmdCBhY2tu b3dsZWRnZXMgdGhlIG92ZXJoZWFkIGZvciBVRFAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5kIG90 aGVycy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHRoaXMgc29ydCBvZiBkaXNjdXNzaW9u cyBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0g V2UgYWxyZWFkeSBoYXZlIHNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgYWJvdXQgdGhlIGNvbnMgb2Yg dXNpbmcsIGUuZy4sIFNPQ0tTOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQ3VycmVudCBvcGVyYXRpb25hbCBNUFRDUCBkZXBsb3ltZW50 cyBieSBuZXR3b3JrIG9wZXJhdG9ycyBhcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGZvY3Vz ZWQgb24gdGhlIGZvcndhcmRpbmcgb2YgVENQIHRyYWZmaWMuJm5ic3A7IEluIGFkZGl0aW9uLCB0 aGUgZGVzaWduIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzdWNoIGRlcGxveW1lbnRzIHNv bWV0aW1lcyBhc3N1bWVzIHRoZSB1c2Ugb2YgZXh0cmEgc2lnbmFsbGluZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgcHJvdmlkZWQgYnkgU09DS1MgWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE5MjgiIHRhcmdldD0iX2JsYW5rIiB0aXRs ZT0iJnF1b3Q7U09DS1MgUHJvdG9jb2wgVmVyc2lvbiA1JnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1V UyI+UkZDMTkyODwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XSwNCiBh dCB0aGUgY29zdCBvZiBhZGRpdGlvbmFsIG1hbmFnZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IGNvbXBsZXhpdHkgYW5kIHBvc3NpYmxlIHNlcnZpY2UgZGVncmFkYXRpb24gKGUuZy4sIHVw IHRvIDggU09DS1M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2VzIG1heSBuZWVkIHRv IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBNUFRDUCBwcm94aWVzIGJlZm9yZSBhbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgTVBUQ1AgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgdGhlcmVi eSB5aWVsZGluZyBzZXZlcmFsIHRlbnMgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1pbGxp c2Vjb25kcyBvZiBleHRyYSBkZWxheSBiZWZvcmUgdGhlIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNo ZWQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5GdXJ0aGVyLCBhIFNPQ0tTLWJhc2VkIHNvbHV0 aW9uIGRvZXMgbm90IGFsbG93IHRvIHN1cHBvcnQgbmF0aXZlbHkgVURQIGJvbmRpbmcuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+WW9zaGk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933008DABE1BOPEXCLILMA3corp_-- From nobody Thu Jun 2 23:22:30 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7312D61F; Thu, 2 Jun 2016 23:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Fz1g4UtoWiY8; Thu, 2 Jun 2016 23:22:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C470D12D59B; Thu, 2 Jun 2016 23:22:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8F3B918CF69; Fri, 3 Jun 2016 08:22:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 60E8527C07D; Fri, 3 Jun 2016 08:22:25 +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.0294.000; Fri, 3 Jun 2016 08:22:25 +0200 From: To: Yoshifumi Nishida Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvUSLVfDVndCKSyeA71f2kyLjwJ/XO80g Date: Fri, 3 Jun 2016 06:22:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DABE58@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D8DAAC@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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DABE58OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.3.53617 Archived-At: Cc: MultiPath WG , "draft-boucadair-mptcp-plain-mode@ietf.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 06:22:29 -0000 --_000_787AE7BB302AE849A7480A190F8B933008DABE58OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogWW9zaGlm dW1pIE5pc2hpZGEgW21haWx0bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwXQ0KRW52b3nDqSA6IHZl bmRyZWRpIDMganVpbiAyMDE2IDA1OjA0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4N CkNjIDogWW9zaGlmdW1pIE5pc2hpZGE7IE9saXZpZXIgQm9uYXZlbnR1cmU7IE11bHRpUGF0aCBX RzsgZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGVAaWV0Zi5vcmcNCk9iamV0IDogUmU6 IFttdWx0aXBhdGh0Y3BdIGRyYWZ0LWJvdWNhZGFpci1tcHRjcC1wbGFpbi1tb2RlLTA3DQoNCkhp IE1lZCwNCg0KT24gTW9uLCBNYXkgMzAsIDIwMTYgYXQgMTo0OCBBTSwgPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90 ZToNCkhpIFlvc2hpLA0KW1NOSVBdDQoNCldlbGwsIEl0IGlzIHN0aWxsIG5vdCB2ZXJ5IGNsZWFy IHRvIG1lIGhvdyBlYWNoIFVEUCBwYWNrZXQgaXMgbWFwcGVkIHRvIGEgbXB0Y3Agc2Vzc2lvbi4N CkhvdyBkbyB5b3UgZGlzdGluZ3Vpc2ggZWFjaCBVRFAgcGFja2V0ID8gSXMgaXQgYmFzZWQgb24g NC10dXBsZSBvciBvdGhlcnM/DQpbTWVkXSBJdCBpcyBiYXNlZCB0eXBpY2FsbHkgb24gdGhlIHNv dXJjZSBJUCBhZGRyZXNzLCBzb3VyY2UgcG9ydCwgZGVzdGluYXRpb24gSVAgYWRkcmVzcywgYW5k IGRlc3RpbmF0aW9uIHBvcnQuDQoNClRoZSBub3Rpb24gb2YgSW50ZXJuYWwgdHJhbnNwb3J0IHNl c3Npb24gaWRlbnRpZmllciBpcyBhIGJpdCBhbWJpZ3VvdXMuDQpbTWVkXSBUaGlzIGlzIGhvdyBh IGdpdmVuIGZsb3cgaXMgaWRlbnRpZmllZCBpbiB0aGUgaW50ZXJuYWwgc2lkZSBvZiB0aGUgQ1BF IChpLmUuLCBMQU4pLiBUaGlzIGlzIHR5cGljYWxseSwgdGhlIDQtdHVwbGUgb2YgdGhlIHBhY2tl dCBhcyByZWNlaXZlZCBmcm9tIGEgaG9zdCBpbiB0aGUgTEFOLiBUaGUgNC10dXBsZSBpcyBhdWdt ZW50ZWQgd2l0aCB0aGUg4oCcdHJhbnNwb3J0IHByb3RvY29s4oCdIGluZm9ybWF0aW9uIGJlY2F1 c2UgdGhlIENQRSBjYW4gYXNzaWduIHRoZSBzYW1lIGV4dGVybmFsIHBvcnQgZm9yIFRDUCBhbmQg VURQLg0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008DABE58OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToi UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0 eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlv c2hpZnVtaSBOaXNoaWRhIFttYWlsdG86bmlzaGlkYUBzZmMud2lkZS5hZC5qcF0NCjxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAzIGp1aW4gMjAxNiAwNTowNDxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gWW9zaGlmdW1pIE5pc2hpZGE7IE9saXZpZXIgQm9uYXZlbnR1cmU7IE11bHRpUGF0aCBXRzsg ZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXBsYWluLW1vZGVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFJlOiBbbXVsdGlwYXRodGNwXSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AtcGxhaW4t bW9kZS0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBNZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u LCBNYXkgMzAsIDIwMTYgYXQgMTo0OCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NS4yNXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SGkgWW9zaGksDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NS4yNXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W1NOSVBd PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwsIEl0IGlz IHN0aWxsIG5vdCB2ZXJ5IGNsZWFyIHRvIG1lIGhvdyBlYWNoIFVEUCBwYWNrZXQgaXMgbWFwcGVk IHRvIGEgbXB0Y3Agc2Vzc2lvbi48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3cgZG8geW91IGRpc3Rpbmd1aXNoIGVhY2ggVURQIHBhY2tl dCA/IElzIGl0IGJhc2VkIG9uIDQtdHVwbGUgb3Igb3RoZXJzPzxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSXQgaXMgYmFzZWQgdHlw aWNhbGx5IG9uIHRoZSBzb3VyY2UgSVAgYWRkcmVzcywgc291cmNlIHBvcnQsIGRlc3RpbmF0aW9u IElQIGFkZHJlc3MsIGFuZCBkZXN0aW5hdGlvbiBwb3J0Lg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIG5vdGlvbiBvZiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkludGVybmFsIHRyYW5zcG9y dCBzZXNzaW9uIGlkZW50aWZpZXIgaXMgYSBiaXQgYW1iaWd1b3VzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ W01lZF0gVGhpcyBpcyBob3cgYSBnaXZlbiBmbG93IGlzIGlkZW50aWZpZWQgaW4gdGhlIGludGVy bmFsIHNpZGUgb2YgdGhlIENQRSAoaS5lLiwgTEFOKS4gVGhpcyBpcyB0eXBpY2FsbHksIHRoZSA0 LXR1cGxlIG9mIHRoZSBwYWNrZXQgYXMgcmVjZWl2ZWQgZnJvbSBhDQogaG9zdCBpbiB0aGUgTEFO LiBUaGUgNC10dXBsZSBpcyBhdWdtZW50ZWQgd2l0aCB0aGUg4oCcdHJhbnNwb3J0IHByb3RvY29s 4oCdIGluZm9ybWF0aW9uIGJlY2F1c2UgdGhlIENQRSBjYW4gYXNzaWduIHRoZSBzYW1lIGV4dGVy bmFsIHBvcnQgZm9yIFRDUCBhbmQgVURQLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008DABE58OPEXCLILMA3corp_-- From nobody Fri Jun 3 00:19:49 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2A12D15B for ; Fri, 3 Jun 2016 00:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 VUN_tV3RwaXI for ; Fri, 3 Jun 2016 00:19:44 -0700 (PDT) Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) (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 4D83812D148 for ; Fri, 3 Jun 2016 00:19:43 -0700 (PDT) Received: by mail.swisscom.com; Fri, 3 Jun 2016 09:19:40 +0200 From: To: Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS5/kRyThp3H0qXGRVw5nwe1J/WNmyAgAAU/ICAAQzCsw== Date: Fri, 3 Jun 2016 07:19:38 +0000 Message-ID: <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com>,<57506A37.60502@isi.edu> In-Reply-To: <57506A37.60502@isi.edu> Accept-Language: de-CH, en-US Content-Language: de-CH X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: multipathtcp@ietf.org, sarikaya@ieee.org Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:19:47 -0000 Hi Joe, If you mean with dynamic routing a packet by packet routing decision, that = could work however, how do you incorporate the path characteristic feedback= into that decision. Here the MPTCP mechanisms just come in handy and do th= e job quite well, but as you say we pay with some complexity. That complexi= ty we feel,will have anyway with whatever solution we are going. > Am 02.06.2016 um 19:18 schrieb Joe Touch : >=20 >=20 >=20 >> On 6/2/2016 7:02 AM, Markus.Brunner3@swisscom.com wrote: >> Hi Behcet, >>=20 >> As one of the operators very interested in this, I don=92t think it is o= ver blown and the use case you describe might be the first one for a number= of operators, but others are following. Fundamentally it is about resource= pooling of access networking resources (of whatever technology transportin= g IP). >>=20 >> We are well-aware of the problems of a MPTCP-based solution (and draft-b= oucadair tries to solve some of them). However, we are not aware of any bet= ter standardized solution for multiple paths with heterogeneous characteris= tics of available and varying bandwidth, varying delays, and different pack= et handling characteristics. In case there is better ways of solving that p= roblem let us know. >=20 > Why wouldn't an overlay that employs dynamic routing be easier? >=20 > It wouldn't incur the delays of using reliable delivery with messages > that don't preserve IP datagram boundaries and it's already supported > with existing equipment. Further, it could use much more sophisticated > path monitoring and choice. >=20 > I.e., this is exactly what you'd get if you deploy something akin to > LISP and basically ignore the label distribution problem (which you > really don't have). >=20 > Joe >=20 >=20 >>=20 >> The need for the unfortunate proxying/concentrators is a short term solu= tion until MPTCP is more widespread implemented and deployed.=20 >>=20 >>=20 >> Kind regards/Viele Gr=FCsse >>=20 >> Marcus >>=20 >> =97=97- >> Marcus Brunner >> Swisscom >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Am 01.06.16, 20:37 schrieb "multipathtcp im Auftrag von Behcet Sarikaya"= : >>=20 >>> Hi all, >>>=20 >>> Recent mails in this thread came to my attention because I work on the >>> hybrid access network issues and wish to convey my views on some of >>> the issues discussed. >>>=20 >>> First of all, the claims that there is strong operator interest on >>> this is over blown. Hybrid access is based on offloading some CPE >>> traffic to 3G/LTE network, I don't think mobile operators are fond of >>> such a thing. >>>=20 >>> Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP >>> into MPTCP and requires >>> Concentrators to convert back MPTCP into UDP or TCP is a complex >>> process. The crux of this is the problems arising from the use of >>> MPTCP for tunneling, which is what this draft is advocating. >>>=20 >>> Here I recommend Joe Touch's Intarea draft >>> https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt >>> on IP Tunnels in the Internet Architecture. IETF developed many >>> tunneling protocols which are surveyed in this draft but none of them >>> are TCP/MPTCP based. >>> I also question suitability of this work to the charter. There is this >>> charter text: >>> Finally, the working group will explore whether an MPTCP-aware >>> middlebox would be useful, where at least one end host is MPTCP-enabled= . >>> For example, potentially helping MPTCP's incremental deployment by >>> allowing only one end host to be MPTCP-enabled and the middlebox acts a= s >>> an MPTCP proxy for the other end host, which runs TCP; and potentially >>> helping some mobility scenarios, where the middlebox acts as an anchor >>> between two MPTCP-enabled hosts. The working group will detail what rea= l >>> problems an MPTCP-enabled middlebox might solve, how it would impact th= e >>> Multipath TCP architecture (RFC6182), what proxy approach might be >>> justified as compared against alternative solutions to the problems, an= d >>> the likely feasibility of solving the technical and security issues. >>>=20 >>> This draft has a middlebox called Concentrator but it is not trying to >>> enable MPTCP hosts to communicate with TCP hosts, it is just tunneling >>> the traffic. So there is no charter item that fits to this draft. >>> I strongly suggest staying away from making MPTCP a tunneling protocol. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From nobody Fri Jun 3 00:41:57 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1252812D0D8 for ; Fri, 3 Jun 2016 00:41:56 -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, 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 ZpZgDpk3Ap29 for ; Fri, 3 Jun 2016 00:41:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0603E12B056 for ; Fri, 3 Jun 2016 00:41:54 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6A03A3B4402; Fri, 3 Jun 2016 09:41:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4A2F827C08D; Fri, 3 Jun 2016 09:41:52 +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.0294.000; Fri, 3 Jun 2016 09:41:51 +0200 From: To: Rao Shoaib , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwJxe2NxAFAfZNA= Date: Fri, 3 Jun 2016 07:41:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DABEE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <574F0A36.10101@oracle.com> In-Reply-To: <574F0A36.10101@oracle.com> 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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:41:56 -0000 Hi Shoaib, I'm sure you have good reasons why TCP is not used between the client and t= he server in the first place. Calling out those reasons is helpful.=20 As a side note, the plain mode specification does not enforce (yet) a valid= ation check to assess whether the address conveyed in the option is distinc= t from an address that belong to the MPTCP node that receives the option. I= .e., if that node receives an option that includes ones of its IP addresses= , it is an indication that the data is to be consumed locally, not forwarde= d outside. Wouldn't that solve the first part of your "address mapping" con= cern?=20 =20 BTW, I added a note to the draft to indicate the following: * An implementation must ignore PM options that include multicast, broadcas= t, and host loopback addresses. Cheers, Med > -----Message d'origine----- > De=A0: Rao Shoaib [mailto:rao.shoaib@oracle.com] > Envoy=E9=A0: mercredi 1 juin 2016 18:16 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Olivier.Bonaventure@uclouvain.be; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 >=20 >=20 > On 05/30/2016 02:22 AM, mohamed.boucadair@orange.com wrote: > > Hi Shoaib, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Rao > >> Shoaib > >> Envoy=E9 : samedi 28 mai 2016 10:56 > >> =C0 : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org > >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 > >> > >> > >> > >> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: > >>> Rao, > >>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: > >>>>> The assumption is that this solution will be deployed in controlled > >>>>> environments and only used between the CPE and the Concentrator. > Since > >>>>> the operator controls the two networks that are bound together, he > can > >>>>> verify that there are no middleboxes that drop the PM option. > >>>>> > >>>>> > >>>>> Olivier > >>>> I am extremely interested in encapsulating UDP in MPTCP but this > >>>> solution is very specific and hence why should it even be > standardized > >> ? > >>> There is a clear demand from operators for a solution to this problem > >>> in hybrid access networks. > >> OK but this solution is very specific to the mobile network. > > [Med] The solution is not specific to the mobile network, but targets > all network providers who want to allow their customers to make use of al= l > available network attachments (e.g., fixed, WLAN, cellular, etc.) > The way it is designed it is very specific to a particular use case and > is not a generic encapsulation solution. > > > > We would > >> prefer a generic encapsulation solution which has no address mapping. > > [Med] It seems that you want to cover the case of an MPTCP-enabled host > communicating an MPTCP-enabled server exchanging any protocol data inside > an MPTCP connection? Can you please confirm/infirm? > Yes. We want a generic MPTCP encapsulation solution with no address > mapping. Address mapping and other features (like single connection) > should be separate options. > >> Maybe the address mapping part should be made optional based on a flag > ? > > [Med] The technical details can be worked out once we understand your > deployment case. > > > > [snip] > OK. > > > > > > After re-reading the draft I think the proposal for encapsulation is > > pretty good, only minor details need to be cleared up. > > > > [Med] Thank you. We are more than open to discuss those details. > > > > > Great. I think first we need to decide if we want a generic > encapsulation solution (which is why I want) or do we entangle it with > the other requirements of the cellular deployment. >=20 > Shoaib From nobody Fri Jun 3 00:53:44 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32EF12D11C for ; Fri, 3 Jun 2016 00:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 kjeNkDf4ILgs for ; Fri, 3 Jun 2016 00:53:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C07D12D0DE for ; Fri, 3 Jun 2016 00:53:33 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u537rVNE024188 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 07:53:32 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u537rVXB019228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 07:53:31 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u537rUou023884; Fri, 3 Jun 2016 07:53:30 GMT Received: from [10.154.99.243] (/10.154.99.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Jun 2016 00:53:30 -0700 To: mohamed.boucadair@orange.com, "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <574F0A36.10101@oracle.com> <787AE7BB302AE849A7480A190F8B933008DABEE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Rao Shoaib Message-ID: <57513772.6000406@oracle.com> Date: Fri, 3 Jun 2016 00:53:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DABEE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 07:53:37 -0000 On 06/03/2016 12:41 AM, mohamed.boucadair@orange.com wrote: > Hi Shoaib, > > I'm sure you have good reasons why TCP is not used between the client and the server in the first place. Calling out those reasons is helpful. MPTCP allows us to break a large UDP message into several segments and use multiple paths, Plus the added reliability. This reminds me of another issue, what happens if a fragment other than the 1st one that carries the header shows up first ? We need a header in each packet that indicates the order and association just like IP fragmentation. > > As a side note, the plain mode specification does not enforce (yet) a validation check to assess whether the address conveyed in the option is distinct from an address that belong to the MPTCP node that receives the option. I.e., if that node receives an option that includes ones of its IP addresses, it is an indication that the data is to be consumed locally, not forwarded outside. Wouldn't that solve the first part of your "address mapping" concern? Correct but why would I even want to send an IP address ? Why can't there be a flag to indicate that this packet carries no address translation information. Ideally encapsulation should be an option on it's own as it has nothing to do with address translation. Shoaib > > BTW, I added a note to the draft to indicate the following: > > * An implementation must ignore PM options that include multicast, broadcast, and host loopback addresses. > > Cheers, > Med > >> -----Message d'origine----- >> De : Rao Shoaib [mailto:rao.shoaib@oracle.com] >> Envoyé : mercredi 1 juin 2016 18:16 >> À : BOUCADAIR Mohamed IMT/OLN; Olivier.Bonaventure@uclouvain.be; >> multipathtcp@ietf.org >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >> >> >> >> On 05/30/2016 02:22 AM, mohamed.boucadair@orange.com wrote: >>> Hi Shoaib, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de >> Rao >>>> Shoaib >>>> Envoyé : samedi 28 mai 2016 10:56 >>>> À : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org >>>> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >>>> >>>> >>>> >>>> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: >>>>> Rao, >>>>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: >>>>>>> The assumption is that this solution will be deployed in controlled >>>>>>> environments and only used between the CPE and the Concentrator. >> Since >>>>>>> the operator controls the two networks that are bound together, he >> can >>>>>>> verify that there are no middleboxes that drop the PM option. >>>>>>> >>>>>>> >>>>>>> Olivier >>>>>> I am extremely interested in encapsulating UDP in MPTCP but this >>>>>> solution is very specific and hence why should it even be >> standardized >>>> ? >>>>> There is a clear demand from operators for a solution to this problem >>>>> in hybrid access networks. >>>> OK but this solution is very specific to the mobile network. >>> [Med] The solution is not specific to the mobile network, but targets >> all network providers who want to allow their customers to make use of all >> available network attachments (e.g., fixed, WLAN, cellular, etc.) >> The way it is designed it is very specific to a particular use case and >> is not a generic encapsulation solution. >>> We would >>>> prefer a generic encapsulation solution which has no address mapping. >>> [Med] It seems that you want to cover the case of an MPTCP-enabled host >> communicating an MPTCP-enabled server exchanging any protocol data inside >> an MPTCP connection? Can you please confirm/infirm? >> Yes. We want a generic MPTCP encapsulation solution with no address >> mapping. Address mapping and other features (like single connection) >> should be separate options. >>>> Maybe the address mapping part should be made optional based on a flag >> ? >>> [Med] The technical details can be worked out once we understand your >> deployment case. >>> [snip] >> OK. >>> >>> After re-reading the draft I think the proposal for encapsulation is >>> pretty good, only minor details need to be cleared up. >>> >>> [Med] Thank you. We are more than open to discuss those details. >>> >>> >> Great. I think first we need to decide if we want a generic >> encapsulation solution (which is why I want) or do we entangle it with >> the other requirements of the cellular deployment. >> >> Shoaib From nobody Fri Jun 3 01:00:30 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614A12D0D8 for ; Fri, 3 Jun 2016 01:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 rxu7sNWKEGqL for ; Fri, 3 Jun 2016 01:00:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5380312D0D9 for ; Fri, 3 Jun 2016 01:00:25 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5380Nn1031894 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 08:00:24 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u5380LNY028490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 08:00:23 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u5380KYC026953; Fri, 3 Jun 2016 08:00:21 GMT Received: from [10.154.99.243] (/10.154.99.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Jun 2016 00:00:20 -0800 To: mohamed.boucadair@orange.com, "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <574F0A36.10101@oracle.com> <787AE7BB302AE849A7480A190F8B933008DABEE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <57513772.6000406@oracle.com> From: Rao Shoaib Message-ID: <5751390D.3040307@oracle.com> Date: Fri, 3 Jun 2016 01:00:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <57513772.6000406@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 08:00:28 -0000 BTW another use case we have is to use multiple TCP flows for different priority messages. In such a deployment we would not divide a single UDP packet and send it over multiple TCP streams but the complete message will be sent on a single stream based on the priority. This would avoid head of line blocking due to large messages for small high priority messages. Shoaib On 06/03/2016 12:53 AM, Rao Shoaib wrote: > > > On 06/03/2016 12:41 AM, mohamed.boucadair@orange.com wrote: >> Hi Shoaib, >> >> I'm sure you have good reasons why TCP is not used between the client >> and the server in the first place. Calling out those reasons is helpful. > MPTCP allows us to break a large UDP message into several segments and > use multiple paths, Plus the added reliability. This reminds me of > another issue, what happens if a fragment other than the 1st one that > carries the header shows up first ? We need a header in each packet > that indicates the order and association just like IP fragmentation. >> >> As a side note, the plain mode specification does not enforce (yet) a >> validation check to assess whether the address conveyed in the option >> is distinct from an address that belong to the MPTCP node that >> receives the option. I.e., if that node receives an option that >> includes ones of its IP addresses, it is an indication that the data >> is to be consumed locally, not forwarded outside. Wouldn't that solve >> the first part of your "address mapping" concern? > Correct but why would I even want to send an IP address ? Why can't > there be a flag to indicate that this packet carries no address > translation information. Ideally encapsulation should be an option on > it's own as it has nothing to do with address translation. > > Shoaib >> BTW, I added a note to the draft to indicate the following: >> >> * An implementation must ignore PM options that include multicast, >> broadcast, and host loopback addresses. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Rao Shoaib [mailto:rao.shoaib@oracle.com] >>> Envoyé : mercredi 1 juin 2016 18:16 >>> À : BOUCADAIR Mohamed IMT/OLN; Olivier.Bonaventure@uclouvain.be; >>> multipathtcp@ietf.org >>> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >>> >>> >>> >>> On 05/30/2016 02:22 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Shoaib, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la >>>>> part de >>> Rao >>>>> Shoaib >>>>> Envoyé : samedi 28 mai 2016 10:56 >>>>> À : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org >>>>> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >>>>> >>>>> >>>>> >>>>> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: >>>>>> Rao, >>>>>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: >>>>>>>> The assumption is that this solution will be deployed in >>>>>>>> controlled >>>>>>>> environments and only used between the CPE and the Concentrator. >>> Since >>>>>>>> the operator controls the two networks that are bound together, he >>> can >>>>>>>> verify that there are no middleboxes that drop the PM option. >>>>>>>> >>>>>>>> >>>>>>>> Olivier >>>>>>> I am extremely interested in encapsulating UDP in MPTCP but this >>>>>>> solution is very specific and hence why should it even be >>> standardized >>>>> ? >>>>>> There is a clear demand from operators for a solution to this >>>>>> problem >>>>>> in hybrid access networks. >>>>> OK but this solution is very specific to the mobile network. >>>> [Med] The solution is not specific to the mobile network, but targets >>> all network providers who want to allow their customers to make use >>> of all >>> available network attachments (e.g., fixed, WLAN, cellular, etc.) >>> The way it is designed it is very specific to a particular use case and >>> is not a generic encapsulation solution. >>>> We would >>>>> prefer a generic encapsulation solution which has no address mapping. >>>> [Med] It seems that you want to cover the case of an MPTCP-enabled >>>> host >>> communicating an MPTCP-enabled server exchanging any protocol data >>> inside >>> an MPTCP connection? Can you please confirm/infirm? >>> Yes. We want a generic MPTCP encapsulation solution with no address >>> mapping. Address mapping and other features (like single connection) >>> should be separate options. >>>>> Maybe the address mapping part should be made optional based on a >>>>> flag >>> ? >>>> [Med] The technical details can be worked out once we understand your >>> deployment case. >>>> [snip] >>> OK. >>>> >>>> After re-reading the draft I think the proposal for encapsulation is >>>> pretty good, only minor details need to be cleared up. >>>> >>>> [Med] Thank you. We are more than open to discuss those details. >>>> >>>> >>> Great. I think first we need to decide if we want a generic >>> encapsulation solution (which is why I want) or do we entangle it with >>> the other requirements of the cellular deployment. >>> >>> Shoaib > From nobody Fri Jun 3 01:39:15 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58DD12B065 for ; Fri, 3 Jun 2016 01:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 DbdGz3cE1eor for ; Fri, 3 Jun 2016 01:39:11 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.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 8779312B056 for ; Fri, 3 Jun 2016 01:39:11 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 096BD40B03; Fri, 3 Jun 2016 10:39:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id D2E291A0068; Fri, 3 Jun 2016 10:39:09 +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.0294.000; Fri, 3 Jun 2016 10:39:09 +0200 From: To: Rao Shoaib , "Olivier.Bonaventure@uclouvain.be" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09MwLEhBwIAADCe0A= Date: Fri, 3 Jun 2016 08:39:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DABF40@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5745E628.6010302@oracle.com> <57495D0D.50100@oracle.com> <787AE7BB302AE849A7480A190F8B933008D8DAFC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <574F0A36.10101@oracle.com> <787AE7BB302AE849A7480A190F8B933008DABEE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <57513772.6000406@oracle.com> In-Reply-To: <57513772.6000406@oracle.com> 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: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 08:39:14 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Rao Shoaib [mailto:rao.shoaib@oracle.com] > Envoy=E9=A0: vendredi 3 juin 2016 09:53 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Olivier.Bonaventure@uclouvain.be; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 >=20 >=20 > On 06/03/2016 12:41 AM, mohamed.boucadair@orange.com wrote: > > Hi Shoaib, > > > > I'm sure you have good reasons why TCP is not used between the client > and the server in the first place. Calling out those reasons is helpful. > MPTCP allows us to break a large UDP message into several segments and > use multiple paths, Plus the added reliability.=20 [Med] Ok, thanks. This reminds me of > another issue, what happens if a fragment other than the 1st one that > carries the header shows up first ? [Med] This is an issue for IPv4. In order to accommodate our of order fragm= ents, the implementation caches those till the first fragment that contains= the transport information is received. We hinted this in the draft: In order to protect the CPE and the concentrator and minimize the risk of degrading the overall bonding service performance, dedicated resources SHOULD be reserved for handling fragments (e.g., by = =20 limiting the amount of resources to process out-of-order packets). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We need a header in each packet that > indicates the order and association just like IP fragmentation. [Med] There are two cases for handling IPv4 fragments:=20 (1) IPv4 fragments that are received from the Internet or IPv4 received fro= m the LAN: for those, I proposed the following behavior (not yet discussed = with my co-authors):=20 5.3.1. Receiving IPv4 Fragments on the Internet-Facing Interface of the Concentrator The forwarding of an IPv4 packet received on the Internet-facing interface of the concentrator requires the IPv4 destination address and the transport-protocol destination port for binding lookup purposes. If the first packet received contains the transport- protocol information, the concentrator uses a cache and forwards the fragments unchanged (i.e., without reassembly). A description of such a caching algorithm is outside the scope of this document. If subsequent fragments arrive before the first fragment, the concentrator SHOULD queue these fragments till the first fragment is received. The processing of the first fragment MUST follow the same procedure as in Section 5.1.1. The rewriting of the IP addresses of subsequent fragments MUST follow the instructions maintained in the binding table and the fragmentation cache. The MF (More Fragments) bit and 'Fragment offset' field MUST NOT be modified by the concentrator. 5.3.2. Receiving IPv4 Fragments from the LAN If the first packet received contains the transport-protocol information, the CPE uses a cache and forwards the fragments unchanged (i.e., without reassembly). If subsequent fragments arrive before the first fragment, the concentrator SHOULD queue these fragments till the first fragment is received. The processing of the first fragment MUST follow the same procedure as in Section 5.1.2. The rewriting of the IP addresses of subsequent fragments MUST follow the instructions maintained in the binding table and the fragmentation cache. The MF bit and 'Fragment offset' field MUST NOT be modified by the CPE. (2) Large packets that need to be fragmented when relayed into the MPTCP co= nnection: The proposal is to fragment those only after the UDP/TCP conversi= on is achieved, and reassembly at the remote side before TCP/UDP conversion= . Please refer to Section 5.3. > > > > As a side note, the plain mode specification does not enforce (yet) a > validation check to assess whether the address conveyed in the option is > distinct from an address that belong to the MPTCP node that receives the > option. I.e., if that node receives an option that includes ones of its I= P > addresses, it is an indication that the data is to be consumed locally, > not forwarded outside. Wouldn't that solve the first part of your "addres= s > mapping" concern? > Correct but why would I even want to send an IP address ? [Med] Fair point. I was referring to -07. (An optimization would be indeed = that the client does not include an IP address if the ultimate DST address = is equal to the destination IP address of the MPTCP peer). =20 Why can't > there be a flag to indicate that this packet carries no address > translation information.=20 [Med] You don't need a flag for this. You can rely on the length of the opt= ion as an explicit indication that no address is included.=20 Ideally encapsulation should be an option on > it's own as it has nothing to do with address translation. >=20 > Shoaib > > > > BTW, I added a note to the draft to indicate the following: > > > > * An implementation must ignore PM options that include multicast, > broadcast, and host loopback addresses. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Rao Shoaib [mailto:rao.shoaib@oracle.com] > >> Envoy=E9 : mercredi 1 juin 2016 18:16 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; Olivier.Bonaventure@uclouvain.be; > >> multipathtcp@ietf.org > >> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 > >> > >> > >> > >> On 05/30/2016 02:22 AM, mohamed.boucadair@orange.com wrote: > >>> Hi Shoaib, > >>> > >>> Please see inline. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part > de > >> Rao > >>>> Shoaib > >>>> Envoy=E9 : samedi 28 mai 2016 10:56 > >>>> =C0 : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org > >>>> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 > >>>> > >>>> > >>>> > >>>> On 05/25/2016 12:07 PM, Olivier Bonaventure wrote: > >>>>> Rao, > >>>>>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote: > >>>>>>> The assumption is that this solution will be deployed in > controlled > >>>>>>> environments and only used between the CPE and the Concentrator. > >> Since > >>>>>>> the operator controls the two networks that are bound together, h= e > >> can > >>>>>>> verify that there are no middleboxes that drop the PM option. > >>>>>>> > >>>>>>> > >>>>>>> Olivier > >>>>>> I am extremely interested in encapsulating UDP in MPTCP but this > >>>>>> solution is very specific and hence why should it even be > >> standardized > >>>> ? > >>>>> There is a clear demand from operators for a solution to this > problem > >>>>> in hybrid access networks. > >>>> OK but this solution is very specific to the mobile network. > >>> [Med] The solution is not specific to the mobile network, but targets > >> all network providers who want to allow their customers to make use of > all > >> available network attachments (e.g., fixed, WLAN, cellular, etc.) > >> The way it is designed it is very specific to a particular use case an= d > >> is not a generic encapsulation solution. > >>> We would > >>>> prefer a generic encapsulation solution which has no address mapping= . > >>> [Med] It seems that you want to cover the case of an MPTCP-enabled > host > >> communicating an MPTCP-enabled server exchanging any protocol data > inside > >> an MPTCP connection? Can you please confirm/infirm? > >> Yes. We want a generic MPTCP encapsulation solution with no address > >> mapping. Address mapping and other features (like single connection) > >> should be separate options. > >>>> Maybe the address mapping part should be made optional based on a > flag > >> ? > >>> [Med] The technical details can be worked out once we understand your > >> deployment case. > >>> [snip] > >> OK. > >>> > >>> After re-reading the draft I think the proposal for encapsulation is > >>> pretty good, only minor details need to be cleared up. > >>> > >>> [Med] Thank you. We are more than open to discuss those details. > >>> > >>> > >> Great. I think first we need to decide if we want a generic > >> encapsulation solution (which is why I want) or do we entangle it with > >> the other requirements of the cellular deployment. > >> > >> Shoaib From nobody Fri Jun 3 05:37:42 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3822312D174 for ; Fri, 3 Jun 2016 05:37:41 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 mJaPcYgw4sbc for ; Fri, 3 Jun 2016 05:37:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A74512D120 for ; Fri, 3 Jun 2016 05:37:39 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D6EF738A28BA; Fri, 3 Jun 2016 12:37:34 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53CbaIN007974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 12:37:36 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53CbAU1003394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 14:37:35 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 14:37:28 +0200 From: "Henderickx, Wim (Nokia - BE)" To: Joe Touch , "Markus.Brunner3@swisscom.com" , "sarikaya@ieee.org" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvPLWg8MTdmGsmUykfkcCgIRGwp/WduCAgACLdgCAABZCAA== Date: Fri, 3 Jun 2016 12:37:28 +0000 Message-ID: <8624D399-F194-4B97-92FD-BE6239DFFAF9@alcatel-lucent.com> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <0920D50D-3D89-44EB-9D61-122CD10E0B56@alcatel-lucent.com> <575104EA.7040201@isi.edu> In-Reply-To: <575104EA.7040201@isi.edu> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <200801D3C587E64E91B417540CFB3855@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:37:41 -0000 SW4tbGluZQ0KDQoNCg0KDQpPbiAwMi8wNi8xNiAyMToxNywgIkpvZSBUb3VjaCIgPHRvdWNoQGlz aS5lZHU+IHdyb3RlOg0KDQo+DQo+DQo+T24gNi8yLzIwMTYgNzo1OCBQTSwgSGVuZGVyaWNreCwg V2ltIChOb2tpYSAtIEJFKSB3cm90ZToNCj4+IEluLWxpbmUNCj4+DQo+Pg0KPj4NCj4+DQo+PiBP biAwMi8wNi8xNiAxMDoxNywgIm11bHRpcGF0aHRjcCBvbiBiZWhhbGYgb2YgSm9lIFRvdWNoIiA8 bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRvdWNoQGlzaS5lZHU+ IHdyb3RlOg0KPj4NCj4+Pg0KPj4+IE9uIDYvMi8yMDE2IDc6MDIgQU0sIE1hcmt1cy5CcnVubmVy M0Bzd2lzc2NvbS5jb20gd3JvdGU6DQo+Pj4+IEhpIEJlaGNldCwNCj4+Pj4NCj4+Pj4gQXMgb25l IG9mIHRoZSBvcGVyYXRvcnMgdmVyeSBpbnRlcmVzdGVkIGluIHRoaXMsIEkgZG9u4oCZdCB0aGlu ayBpdCBpcyBvdmVyIGJsb3duIGFuZCB0aGUgdXNlIGNhc2UgeW91IGRlc2NyaWJlIG1pZ2h0IGJl IHRoZSBmaXJzdCBvbmUgZm9yIGEgbnVtYmVyIG9mIG9wZXJhdG9ycywgYnV0IG90aGVycyBhcmUg Zm9sbG93aW5nLiBGdW5kYW1lbnRhbGx5IGl0IGlzIGFib3V0IHJlc291cmNlIHBvb2xpbmcgb2Yg YWNjZXNzIG5ldHdvcmtpbmcgcmVzb3VyY2VzIChvZiB3aGF0ZXZlciB0ZWNobm9sb2d5IHRyYW5z cG9ydGluZyBJUCkuDQo+Pj4+DQo+Pj4+IFdlIGFyZSB3ZWxsLWF3YXJlIG9mIHRoZSBwcm9ibGVt cyBvZiBhIE1QVENQLWJhc2VkIHNvbHV0aW9uIChhbmQgZHJhZnQtYm91Y2FkYWlyIHRyaWVzIHRv IHNvbHZlIHNvbWUgb2YgdGhlbSkuIEhvd2V2ZXIsIHdlIGFyZSBub3QgYXdhcmUgb2YgYW55IGJl dHRlciBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yIG11bHRpcGxlIHBhdGhzIHdpdGggaGV0ZXJv Z2VuZW91cyBjaGFyYWN0ZXJpc3RpY3Mgb2YgYXZhaWxhYmxlIGFuZCB2YXJ5aW5nIGJhbmR3aWR0 aCwgdmFyeWluZyBkZWxheXMsIGFuZCBkaWZmZXJlbnQgcGFja2V0IGhhbmRsaW5nIGNoYXJhY3Rl cmlzdGljcy4gSW4gY2FzZSB0aGVyZSBpcyBiZXR0ZXIgd2F5cyBvZiBzb2x2aW5nIHRoYXQgcHJv YmxlbSBsZXQgdXMga25vdy4gDQo+Pj4gV2h5IHdvdWxkbid0IGFuIG92ZXJsYXkgdGhhdCBlbXBs b3lzIGR5bmFtaWMgcm91dGluZyBiZSBlYXNpZXI/DQo+Pj4NCj4+PiBJdCB3b3VsZG4ndCBpbmN1 ciB0aGUgZGVsYXlzIG9mIHVzaW5nIHJlbGlhYmxlIGRlbGl2ZXJ5IHdpdGggbWVzc2FnZXMNCj4+ PiB0aGF0IGRvbid0IHByZXNlcnZlIElQIGRhdGFncmFtIGJvdW5kYXJpZXMgYW5kIGl0J3MgYWxy ZWFkeSBzdXBwb3J0ZWQNCj4+PiB3aXRoIGV4aXN0aW5nIGVxdWlwbWVudC4gRnVydGhlciwgaXQg Y291bGQgdXNlIG11Y2ggbW9yZSBzb3BoaXN0aWNhdGVkDQo+Pj4gcGF0aCBtb25pdG9yaW5nIGFu ZCBjaG9pY2UuDQo+Pj4NCj4+PiBJLmUuLCB0aGlzIGlzIGV4YWN0bHkgd2hhdCB5b3UnZCBnZXQg aWYgeW91IGRlcGxveSBzb21ldGhpbmcgYWtpbiB0bw0KPj4+IExJU1AgYW5kIGJhc2ljYWxseSBp Z25vcmUgdGhlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm9ibGVtICh3aGljaCB5b3UNCj4+PiByZWFs bHkgZG9uJ3QgaGF2ZSkuDQo+Pj4NCj4+PiBKb2UNCj4+IFdIPiBpdCBkb2VzbuKAmXQgc29sdmUg dGhlIHVzZSBjYXNlIHdoZXJlIHBhY2tldHMgb2YgYSBmbG93IGhhdmUgdG8gYmUgc3BsaXQgb3Zl ciBtdWx0aXBsZSBsaW5rcyBhbmQgcmVvcmRlcmluZyArIGNvbmdlc3Rpb24gY29udHJvbCBpcyBy ZXF1aXJlZCBmb3IgdGhlc2UgZmxvd3MuIElmIHRoZXNlIHJlcXVpcmVtZW50cyB3ZXJlIG5vdCB0 aGVyZSB5b3XigJlyZSByaWdodCB0aGF0IHJvdXRpbmcgY2FuIGJlIHVzZWQuDQo+DQo+V2hhdCB5 b3UgcmVhbGx5IGRvbid0IHdhbnQgYXJlOg0KPg0KPiAgICAgLSB0byB0YWtlIGEgUlRUIGhpY2N1 cCB0byByZWNvdmVyIGZyb20gYSBzZWdtZW50IGxvc3MNCj4NCj4gICAgLSB0byBpbXBsZW1lbnQg Y29uZ2VzdGlvbiBjb250cm9sIG92ZXIgeW91ciB0dW5uZWxzIHVuZGVybmVhdGgNCj5jb25nZXN0 aW9uIGNvbnRyb2wgaW5zaWRlIHRyYW5zcG9ydCBvbiB0aGUgSVAgcGFja2V0cyB5b3UgY2FycnkN Cj4NCj5JTU8sIG9yZGVyIHByZXNlcnZhdGlvbiBzaG91bGQgYmUgc29tZXRoaW5nIGRvbmUgYXQg dGhlIGVuZHBvaW50cywgbm90DQo+aW4gdGhlIG5ldCwgYnV0IGlmIHRoYXQncyBhbGwgeW91IGhh dmUgbGVmdCB5b3UgY2FuIGltcGxlbWVudCB0aGF0IHdpdGgNCj5hIGZpeGVkIGFtb3VudCBvZiBk ZWxheSBhdCB0aGUgZWdyZXNzIGNvbGxlY3Rpb24gcG9pbnQuDQo+DQo+Tm9uZSBvZiB0aGlzIGlz IHdvcnRoIHRoZSBjb21wbGV4aXR5IGFuZCBzaWRlLWVmZmVjdHMgb2YgTVBUQ1AsIElNTy4NCg0K V0g+IElmIHlvdSBoYXZlIGEgZmxvd3MgdGhhdCBhcmUgYmlnZ2VyIHRoYW4gYSBnaXZlbiBsaW5r IGFuZCB5b3Ugd2FudCB0byBzcGxpdCB0aGVtIG92ZXIgbXVsdGlwbGUgcGF0aHMsIHRoZSBhcHBs aWNhdGlvbnMgY2FuIGltcGxlbWVudCBNUC1UQ1AgZm9yIHN1cmUsIGJ1dCB0aGlzIGlzIG5vdCBh bHdheXMgdGhlIGNhc2UgYW5kIHRoZXJlIGFyZSB1c2UgY2FzZXMgYXMgcGVyIGRyYWZ0IHdoZXJl IGJhc2ljIHJvdXRpbmcgaXMgbm90IHN1ZmZpY2llbnQgYW5kIHlvdSB3YW50IHRvIHVzZSB0aGUg cGF0aCBjaGFyYWN0ZXJpc3RpY3MgZmVlZGJhY2sgd2hpY2ggaXMgYnVpbGQgaW4gaW4gTVAtVENQ IHRvIGFjY29tbW9kYXRlIHRoYXQuIFRoZSBhbHRlcm5hdGl2ZSBpcyB0byByZWludmVudCBhbGwg b2YgdGhpcyBpbiB5ZXQgYW5vdGhlciBwcm90b2NvbC4NCj4NCj5Kb2UNCg== From nobody Fri Jun 3 10:21:57 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B965E12D542 for ; Fri, 3 Jun 2016 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 D23Nppic0gWu for ; Fri, 3 Jun 2016 10:21:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 412AF12B05A for ; Fri, 3 Jun 2016 10:21:54 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u53HL1hM015595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Jun 2016 10:21:01 -0700 (PDT) To: Markus.Brunner3@swisscom.com References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> From: Joe Touch Message-ID: <5751BC7B.1050902@isi.edu> Date: Fri, 3 Jun 2016 10:20:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u53HL1hM015595 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: multipathtcp@ietf.org, sarikaya@ieee.org Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:21:56 -0000 On 6/3/2016 12:19 AM, Markus.Brunner3@swisscom.com wrote: > Hi Joe, > > If you mean with dynamic routing a packet by packet routing decision, that could work however, how do you incorporate the path characteristic feedback into that decision. That's what multipath routing has been doing for years. AFAIK, the mechanisms in MPTCP are an instance inspired by existing multipath routing. > Here the MPTCP mechanisms just come in handy and do the job quite well, but as you say we pay with some complexity. That complexity we feel,will have anyway with whatever solution we are going. Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reasons: - it will layer congestion control on top of congestion control for all transports in the payload IP that already support it (which they should) - it fails to preserve payload IP messages inside a single TCP segment, which increases loss due to a lack of fate-sharing and increases latency and jitter - by recovering from loss, it increases latency and jitter - it can use only one load monitoring mechanism (the one built-in) - it can use only one traffic distribution mechanism (the one built-in) That's a lot of baggage vs. just using tunnels and existing dynamic multipath routing -- and the latter doesn't require a new spec. Joe From nobody Fri Jun 3 11:36:44 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741A912D15F for ; Fri, 3 Jun 2016 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 BrybMCPdiYt0 for ; Fri, 3 Jun 2016 11:36:41 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 9AB8512B00E for ; Fri, 3 Jun 2016 11:36:41 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id a6so126086734vkg.3 for ; Fri, 03 Jun 2016 11:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oOXAIIcJnapFYaZhV9m+HATVnTlAKBll1jmgWAtLDIw=; b=VqesJA84reJmQnLgnYhANCu6CNWwxra+x6QW+YomKr7D6WSrj/YHZQqpQg/BtC6K7X h1wtnYDq2Dbk5pcd8qmTZWwUfoVSJQ2pMBTn3TtywhE52HCuhA1TzCVdQwilWYwVYgeu ugrpdVAEy+8PdZ1fKpLzGiDnKcFHv+gsr1WcrisEUxNkkRaruExegkiVRo5gO8HyZ8gQ xDCD1e23iXMrUd4naGMugzkLGwYhluaqIN+hNxGA0nJrwXlwU5XEeDMkYPhNCasRJG9j s+MB5k06KP8QxwkLJ7g4JPXLd4eUYr3r2e3Wk3trBETA6BYRC+UhmL76DL/9nUr6Y373 7OZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=oOXAIIcJnapFYaZhV9m+HATVnTlAKBll1jmgWAtLDIw=; b=LmAJKB39CrCW+9VCCV047JYEg/iyKY4xn+Ip+ffjJmttq/viS5iRU+Rfe/oV9rrIua ZawPKyt2EUSV7NB7Z0Q2ReCkpRjHgHjDeMEvFVHD4UoKbdaKEvpEEsu6lpVmNQMzWBKk 0ubvr9H1W47plAQpAhkCjdIkm+R4dqwLrSNVH+vfR0GrWQyBt8fKmykV5kw6pzJ3Keoo Z3MTUXobNyteGNhiF9o8VMyzxn/aEwEdmNOoh4sNdqeSDb2V1y6Rhcl46QNxk6s74UzF WwN5wIF/wOal0TS5c5RBTIuhoPejS8HKBjFyU/3igXaEHG1W91d0+U9rsu4495tjLHYB wjxw== X-Gm-Message-State: ALyK8tIi7907HyyW/5zIKTs6PG1m3HPIXxjuZRMGjBNhHJwfXeswiwyTKDvjV9jEAM3Q8c47AHQ2FNeZN3LDRg== X-Received: by 10.31.57.14 with SMTP id g14mr2349535vka.32.1464979000659; Fri, 03 Jun 2016 11:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.232 with HTTP; Fri, 3 Jun 2016 11:36:40 -0700 (PDT) In-Reply-To: <5751BC7B.1050902@isi.edu> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> From: Behcet Sarikaya Date: Fri, 3 Jun 2016 13:36:40 -0500 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: multipathtcp@ietf.org, Markus.Brunner3@swisscom.com Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:36:43 -0000 On Fri, Jun 3, 2016 at 12:20 PM, Joe Touch wrote: > > > On 6/3/2016 12:19 AM, Markus.Brunner3@swisscom.com wrote: >> Hi Joe, >> >> If you mean with dynamic routing a packet by packet routing decision, that could work however, how do you incorporate the path characteristic feedback into that decision. > That's what multipath routing has been doing for years. > > AFAIK, the mechanisms in MPTCP are an instance inspired by existing > multipath routing. > >> Here the MPTCP mechanisms just come in handy and do the job quite well, but as you say we pay with some complexity. That complexity we feel,will have anyway with whatever solution we are going. > > Perhaps, but >MPTCP is the wrong solution for an IP tunnel for many reasons: > +1 This was the point in my mail. Thanks Joe for getting into the discussions and clarifying things on this list. Regards, Behcet > - it will layer congestion control on top of congestion control for all > transports in the payload IP that already support it (which they should) > - it fails to preserve payload IP messages inside a single TCP segment, > which increases loss due to a lack of fate-sharing and increases latency > and jitter > - by recovering from loss, it increases latency and jitter > - it can use only one load monitoring mechanism (the one built-in) > - it can use only one traffic distribution mechanism (the one built-in) > > That's a lot of baggage vs. just using tunnels and existing dynamic > multipath routing -- and the latter doesn't require a new spec. > > Joe From nobody Fri Jun 3 12:29:18 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C2E12D941 for ; Fri, 3 Jun 2016 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 t1I4iZYqdXGN for ; Fri, 3 Jun 2016 12:29:14 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABB012D940 for ; Fri, 3 Jun 2016 12:29:14 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-8a-5751da51dd37 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id D0.01.03614.15AD1575; Fri, 3 Jun 2016 21:28:18 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 15:29:13 -0400 From: David Allan I To: Joe Touch , "Markus.Brunner3@swisscom.com" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS2BAjEk24HX0GvN2aAbwiqtZ/WbT4QgAEt+QCAAKgEgP//3hog Date: Fri, 3 Jun 2016 19:29:12 +0000 Message-ID: References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> In-Reply-To: <5751BC7B.1050902@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXRPrG7QrcBwg31ruC3eNtxjsvi8+jqb xeze0ywW6/7MZXFg8Xg64SCTx5IlP5k8dr/fyuJxt2smcwBLFJdNSmpOZllqkb5dAldG94pn rAWTRSsOtr5gamCcItjFyMkhIWAi8WvudhYIW0ziwr31bF2MXBxCAkcZJd5d+gjlLGOU2LXq GytIFZuAgcSe/18YQWwRgTiJ+Wt+gNnMQPbBtbfYQWxhAXuJH7tmsEHUOEj8WXeGFcJ2k1jU uAasnkVAReLpmm5mEJtXwFfi98unzBDLPjFKHPn9DCzBKaAu8WrtHjCbEei876fWMEEsE5e4 9WQ+E8TZAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2tsSyha+hFgtKnJz5hGUC o9gsJGNnIWmZhaRlFpKWBYwsqxg5SosLcnLTjQw3MQIj6pgEm+MOxr29nocYBTgYlXh4E9YE hAuxJpYVV+YeYpTgYFYS4VU/HxguxJuSWFmVWpQfX1Sak1p8iFGag0VJnFf/pWK4kEB6Yklq dmpqQWoRTJaJg1OqgXGpjJoG7wexm45NH6sm6Uy3qkhrl2/a2iQ7403Bnqq8oCXH/1Q/WZiT MnW1TNWCaclO9bebDEq5Licx2VpartC3z74v/8lC6FncaYHtKb23/a6FGNS7rEk6y2B/saTx aPqh3RVaC31fR66YszP0lmKSwZK9D7VUqkMDm83suQs/sm5d6jcjRImlOCPRUIu5qDgRAP7X YfGkAgAA Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 19:29:16 -0000 Hi Joe: Comments below prefaced by DA> -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe = Touch Sent: Friday, June 03, 2016 10:21 AM To: Markus.Brunner3@swisscom.com Cc: multipathtcp@ietf.org; sarikaya@ieee.org Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 On 6/3/2016 12:19 AM, Markus.Brunner3@swisscom.com wrote: > Hi Joe, > > If you mean with dynamic routing a packet by packet routing decision, tha= t could work however, how do you incorporate the path characteristic feedba= ck into that decision.=20 That's what multipath routing has been doing for years. AFAIK, the mechanisms in MPTCP are an instance inspired by existing multipa= th routing. > Here the MPTCP mechanisms just come in handy and do the job quite well, b= ut as you say we pay with some complexity. That complexity we feel,will hav= e anyway with whatever solution we are going. Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reasons: - it will layer congestion control on top of congestion control for all tra= nsports in the payload IP that already support it (which they should) DA> Would that not be true of any tunnel mechanism that used feedback of th= e tunnel leg as well as the e2e application? - it fails to preserve payload IP messages inside a single TCP segment, whi= ch increases loss due to a lack of fate-sharing and increases latency and j= itter DA> I apologize for not getting your point here. - by recovering from loss, it increases latency and jitter DA> AFAIK, any loss does that irrespective of the delivery mechanism. In th= e hybrid access case you are correcting loss with a smaller RTT are you not= ? - it can use only one load monitoring mechanism (the one built-in) DA> How many did you want? - it can use only one traffic distribution mechanism (the one built-in) DA> If you are saying it is "implementation constrained", well go figure :-= ) =20 That's a lot of baggage vs. just using tunnels and existing dynamic multipa= th routing -- and the latter doesn't require a new spec. DA> Can you point me to the feedback mechanisms embodied in making dynamic = multipath work? And if you are striping flows across multiple paths (absol= ute requirement in my application), any indication of how successful this i= s in minimizing the residence time of packets in the reordering function? DA> If all we are talking about is a slightly smarter ECMP , IMO it does no= t cut it. Dave _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Jun 3 13:16:43 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1012D7FC for ; Fri, 3 Jun 2016 13:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 zHhJCiiFBM16 for ; Fri, 3 Jun 2016 13:16:40 -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 B697812D7FF for ; Fri, 3 Jun 2016 13:16:40 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u53K5jt4005641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Jun 2016 13:05:45 -0700 (PDT) To: David Allan I , "Markus.Brunner3@swisscom.com" References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> From: Joe Touch Message-ID: <5751E316.4010105@isi.edu> Date: Fri, 3 Jun 2016 13:05:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 20:16:42 -0000 On 6/3/2016 12:29 PM, David Allan I wrote: > Hi Joe: > > Comments below prefaced by DA> > > ... > Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reasons: > > - it will layer congestion control on top of congestion control for all transports in the payload IP that already support it (which they should) > DA> Would that not be true of any tunnel mechanism that used feedback of the tunnel leg as well as the e2e application? They might use a different sort of congestion feedback, one that isn't "TCP-compatible". That's actually desirable here - i.e., having congestion reaction happen over different timescales than TCP. > - it fails to preserve payload IP messages inside a single TCP segment, which increases loss due to a lack of fate-sharing and increases latency and jitter > DA> I apologize for not getting your point here. When you write a buffer to TCP, TCP has no obligation to preserve that as sitting inside a single TCP segment. TCP does not preserve these message boundaries. If your message spans multiple TCP segments, then you depend on BOTH of them arriving. The probability of losing one or more of two segments is higher than the probability of losing only one segment. That's the fate-sharing part - you end up taking a RTT to recover (just like if you lost the IP packet) when either TCP segment fails to arrive. That loss recovery increases delay and jitter. > - by recovering from loss, it increases latency and jitter > DA> AFAIK, any loss does that irrespective of the delivery mechanism. In the hybrid access case you are correcting loss with a smaller RTT are you not? You don't need to correct losses for an IP tunnel. You want to reduce their probability, but you definitely don't want to stop the stream and recover. IP is allowed to lose packets. The loss recovery should happen E2E. If you have high random loss on a path you might employ FEC, which would increase delay but in a fixed way. If you really do want ARQ loss recovery on a sub-path, then you can decide whether to implement that or not. However, you don't want to force that recovery all the time nor do you want to couple it with strict reordering - which IP does not require. > - it can use only one load monitoring mechanism (the one built-in) > DA> How many did you want? Maybe you want a variant that isn't already inside MPTCP. The point is that the load monitoring mechanism isn't configurable or easily replaced. > - it can use only one traffic distribution mechanism (the one built-in) > DA> If you are saying it is "implementation constrained", well go figure :-) No, it's design-constrained. MPTCP isn't designed for plug-replaceable load detection or traffic distribution. Dynamic multipath routing is already designed for that. > That's a lot of baggage vs. just using tunnels and existing dynamic multipath routing -- and the latter doesn't require a new spec. > > DA> Can you point me to the feedback mechanisms embodied in making dynamic multipath work? http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html > And if you are striping flows across multiple paths (absolute requirement in my application), any indication of how successful this is in minimizing the residence time of packets in the reordering function? http://www.sigcomm.org/node/2597 > DA> If all we are talking about is a slightly smarter ECMP , IMO it does not cut it. So you want something dumber than ECMP? Joe From nobody Fri Jun 3 15:03:55 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49EC12D887 for ; Fri, 3 Jun 2016 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 DDJ7Ms_dVrSk for ; Fri, 3 Jun 2016 15:03:51 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2D612D831 for ; Fri, 3 Jun 2016 15:03:51 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-2d-5751f5bc6c54 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.37.09012.CB5F1575; Fri, 3 Jun 2016 23:25:17 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 18:03:48 -0400 From: David Allan I To: Joe Touch , "Markus.Brunner3@swisscom.com" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS2BAjEk24HX0GvN2aAbwiqtZ/WbT4QgAEt+QCAAKgEgP//3hoggABP7AD//8MR0A== Date: Fri, 3 Jun 2016 22:03:47 +0000 Message-ID: References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> In-Reply-To: <5751E316.4010105@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonXHfv18Bwg21zBSzeNtxjsvi8+jqb xeze0ywW6/7MZXFg8Xg64SCTx5IlP5k8dr/fyuJxt2smcwBLFJdNSmpOZllqkb5dAldGw/8P bAUHNSruzPnM2MC4VaGLkZNDQsBE4s36PewQtpjEhXvr2boYuTiEBI4yShz9/YgJJCEksIxR 4tujChCbTcBAYs//L4wgtohAnMT8NT/AbGYg++DaW2CDhAXsJX7smsEGUeMg8WfdGdYuRg4g O0zi1VpjkDCLgIpE8+mVYCW8Ar4S277NZYHYe5lJ4v+i46wgCU4BdYmzl3vAihiBjvt+ag0T xC5xiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2osS+/unsEPU6Egt2f2KDsLUlli18zQyxWFDi 5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWlyQk5tuZLCJERhNxyTYdHcw3p/ueYhRgINR iYc3YU1AuBBrYllxZe4hRgkOZiUR3pafgeFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEecUeKYYL CaQnlqRmp6YWpBbBZJk4OKUaGC3fibWLHgxm0RaOtCjq/VNgv1m7SGr5x4LezOr6qGTVYtvv Dxpn6W16WHraJv710fXJ12ZmcMuYbznTeGv5hmf1/9auusbJqVSVqLY2effq/T/lwsTLHZQL NS3evJJa79n5soxpRo3VicQNnnoq3p4fpvyzeff6Z5nxSfGGhQ3+v0vNNkkeVGIpzkg01GIu Kk4EAOsPHrqiAgAA Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 22:03:53 -0000 Hello again: Replies in line "DA2>" and some snips to eliminate clutter.... > Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reason= s: > > - it will layer congestion control on top of congestion control for=20 > all transports in the payload IP that already support it (which they=20 > should) > DA> Would that not be true of any tunnel mechanism that used feedback of = the tunnel leg as well as the e2e application? They might use a different sort of congestion feedback, one that isn't "TCP= -compatible". That's actually desirable here - i.e., having congestion reac= tion happen over different timescales than TCP. DA2> As the tunnel leg would have a different RTT, would that not be true b= y definition? > - it fails to preserve payload IP messages inside a single TCP=20 > segment, which increases loss due to a lack of fate-sharing and=20 > increases latency and jitter > DA> I apologize for not getting your point here. When you write a buffer to TCP, TCP has no obligation to preserve that as s= itting inside a single TCP segment. TCP does not preserve these message bou= ndaries. If your message spans multiple TCP segments, then you depend on BOTH of the= m arriving. The probability of losing one or more of two segments is higher= than the probability of losing only one segment. That's the fate-sharing p= art - you end up taking a RTT to recover (just like if you lost the IP pack= et) when either TCP segment fails to arrive. That loss recovery increases d= elay and jitter. DA2> Understood, but true of any fragmentation mechanism.=20 > - by recovering from loss, it increases latency and jitter > DA> AFAIK, any loss does that irrespective of the delivery mechanism. In = the hybrid access case you are correcting loss with a smaller RTT are you n= ot? You don't need to correct losses for an IP tunnel. You want to reduce their= probability, but you definitely don't want to stop the stream and recover.= IP is allowed to lose packets. The loss recovery should happen E2E. DA2> unfortunately that sounds like dogma to me. You already have the under= lying radio layers correcting loss for the on-air interface portion. If you have high random loss on a path you might employ FEC, which would in= crease delay but in a fixed way. DA2> It takes a little FEC to fix a bit error, it takes a lot to reconstruc= t a missing packet. The mode of failure for a path is packet loss. So I do = not really see FEC as a starter. If you really do want ARQ loss recovery on a sub-path, then you can decide = whether to implement that or not. However, you don't want to force that rec= overy all the time nor do you want to couple it with strict reordering - wh= ich IP does not require. DA2> No IP does not require ordered delivery from the network. But if it wa= s a way of life rather than a rare event it would be a problem. Poorly done= striping of traffic across heterogeneous links with very dynamic transfer = characteristics would result in a lot of "out of order" receipt to correct.= =20 > - it can use only one load monitoring mechanism (the one built-in) > DA> How many did you want? Maybe you want a variant that isn't already inside MPTCP. The point is that= the load monitoring mechanism isn't configurable or easily replaced. DA2> Load monitoring or load spreading. I do not understand why you would = want a configurable monitoring function.? > - it can use only one traffic distribution mechanism (the one=20 > built-in) > DA> If you are saying it is "implementation constrained", well go=20 > DA> figure :-) No, it's design-constrained. MPTCP isn't designed for plug-replaceable load= detection or traffic distribution. Dynamic multipath routing is already de= signed for that. DA2> You are looking for an a la carte menu of functions? > That's a lot of baggage vs. just using tunnels and existing dynamic multi= path routing -- and the latter doesn't require a new spec. > > DA> Can you point me to the feedback mechanisms embodied in making dynami= c multipath work?=20 http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/52= 12-46.html > And if you are striping flows across multiple paths (absolute requirement= in my application), any indication of how successful this is in minimizing= the residence time of packets in the reordering function? http://www.sigcomm.org/node/2597 DA2> OK, I see where you are going.....=20 DA2> So for mechanisms that age out assignment of load spreading buckets, t= hat is great for the core. But at the edge with very few flows, and the arr= ival rate I approaching link rate it strikes me that there is only a fairly= narrow range of operation in which I could successfully stripe across all = uplinks safely. Is that your take as well? DA2> Now your original assertion was that for MPTCP, something needed to be= invented, whereas for dynamic multipath nothing new was required. From wh= at I have gleaned from this conversation is that both require specification= to produce a workable solution. Dave From nobody Fri Jun 3 16:11:44 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DB112D620 for ; Fri, 3 Jun 2016 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 kZLsitH_x1LO for ; Fri, 3 Jun 2016 16:11: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 AB14412D511 for ; Fri, 3 Jun 2016 16:11:40 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u53NAhxj008170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Jun 2016 16:10:44 -0700 (PDT) To: David Allan I , "Markus.Brunner3@swisscom.com" References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> From: Joe Touch Message-ID: <57520E71.3010903@isi.edu> Date: Fri, 3 Jun 2016 16:10:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 23:11:43 -0000 On 6/3/2016 3:03 PM, David Allan I wrote: > Hello again: > > Replies in line "DA2>" and some snips to eliminate clutter.... > > >> Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reasons: >> >> - it will layer congestion control on top of congestion control for >> all transports in the payload IP that already support it (which they >> should) >> DA> Would that not be true of any tunnel mechanism that used feedback of the tunnel leg as well as the e2e application? > They might use a different sort of congestion feedback, one that isn't "TCP-compatible". That's actually desirable here - i.e., having congestion reaction happen over different timescales than TCP. > > DA2> As the tunnel leg would have a different RTT, would that not be true by definition? The difference needs to be on significantly different timescales. Sure, a deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you can't know that for the tunneled traffic. It's safer to run congestion feedback on the tunnel at 10x (or some value bigger than) the largest RTT that can ever occur. >> - it fails to preserve payload IP messages inside a single TCP >> segment, which increases loss due to a lack of fate-sharing and >> increases latency and jitter >> DA> I apologize for not getting your point here. > When you write a buffer to TCP, TCP has no obligation to preserve that as sitting inside a single TCP segment. TCP does not preserve these message boundaries. > > If your message spans multiple TCP segments, then you depend on BOTH of them arriving. The probability of losing one or more of two segments is higher than the probability of losing only one segment. That's the fate-sharing part - you end up taking a RTT to recover (just like if you lost the IP packet) when either TCP segment fails to arrive. That loss recovery increases delay and jitter. > > DA2> Understood, but true of any fragmentation mechanism. We're not talking about fragmentation. Even if TCP runs over IPv6 and has 1200+B segments, there's absolutely no guarantee that a sequence of 576B IPv4 packets will each occur solely inside one TCP segment. TCP can - and will - pack, straddle, or do anything else it wants with the buffers it is given. >> - by recovering from loss, it increases latency and jitter >> DA> AFAIK, any loss does that irrespective of the delivery mechanism. In the hybrid access case you are correcting loss with a smaller RTT are you not? > You don't need to correct losses for an IP tunnel. You want to reduce their probability, but you definitely don't want to stop the stream and recover. IP is allowed to lose packets. The loss recovery should happen E2E. > > DA2> unfortunately that sounds like dogma to me. You already have the underlying radio layers correcting loss for the on-air interface portion. Some radios do, some do not. Packets are lost in a lot of different places, including routers. The fact that IP is "best effort" isn't dogma; it's the one of its defining properties. > If you have high random loss on a path you might employ FEC, which would increase delay but in a fixed way. > > DA2> It takes a little FEC to fix a bit error, it takes a lot to reconstruct a missing packet. The mode of failure for a path is packet loss. So I do not really see FEC as a starter. Some paths do employ FEC using block codes that are tolerant to burst losses - which is what packet loss along the tunnel would look like. But sure, it's up to you whether you need that level of recovery or not. > If you really do want ARQ loss recovery on a sub-path, then you can decide whether to implement that or not. However, you don't want to force that recovery all the time nor do you want to couple it with strict reordering - which IP does not require. > > DA2> No IP does not require ordered delivery from the network. But if it was a way of life rather than a rare event it would be a problem. Poorly done striping of traffic across heterogeneous links with very dynamic transfer characteristics would result in a lot of "out of order" receipt to correct. First, anything that uses IP and treats misordering as an error is itself broken. IP is best effort and doesn't guarantee in-order delivery. However, as noted, there are mechanisms to reduce the reordering at the egress collection point, esp. for striped paths. >> - it can use only one load monitoring mechanism (the one built-in) >> DA> How many did you want? > Maybe you want a variant that isn't already inside MPTCP. The point is that the load monitoring mechanism isn't configurable or easily replaced. > > DA2> Load monitoring or load spreading. I do not understand why you would want a configurable monitoring function.? There are a lot of ways of measuring load and a lot of ways of interpreting those measurements. The variant in MPTCP represents one point in that space. It might not be the one you want - you might want to detect congestion in groups of tunnels as sets rather than as individual paths, e.g. >> - it can use only one traffic distribution mechanism (the one >> built-in) >> DA> If you are saying it is "implementation constrained", well go >> DA> figure :-) > No, it's design-constrained. MPTCP isn't designed for plug-replaceable load detection or traffic distribution. Dynamic multipath routing is already designed for that. > > DA2> You are looking for an a la carte menu of functions? Not necessarily; I'm saying that MPTCP comes bundled with one solution that fits its use for two TCP endpoints. That need not be the best solution when used as a tunnel. And - more to the point - we already have a wide variety of those solutions. >> That's a lot of baggage vs. just using tunnels and existing dynamic multipath routing -- and the latter doesn't require a new spec. >> >> DA> Can you point me to the feedback mechanisms embodied in making dynamic multipath work? > http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html > >> And if you are striping flows across multiple paths (absolute requirement in my application), any indication of how successful this is in minimizing the residence time of packets in the reordering function? > http://www.sigcomm.org/node/2597 > > DA2> OK, I see where you are going..... > > > DA2> So for mechanisms that age out assignment of load spreading buckets, that is great for the core. But at the edge with very few flows, and the arrival rate I approaching link rate it strikes me that there is only a fairly narrow range of operation in which I could successfully stripe across all uplinks safely. Is that your take as well? The way in which the routing protocols are tuned for core vs edge operation may certainly vary. The routing protocol solution gives you exactly the flexibility to make that decision and adjust as needed. > DA2> Now your original assertion was that for MPTCP, something needed to be invented, whereas for dynamic multipath nothing new was required. From what I have gleaned from this conversation is that both require specification to produce a workable solution. MPTCP needs a spec to indicate how to tunnel. The existing solution uses existing tunnel mechanisms and existing routing protocols, but needs no new spec. Both then need to be deployed, and yes - that's work. Joe From nobody Fri Jun 3 16:40:18 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3E12D8EB for ; Fri, 3 Jun 2016 16:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 sj6PnpXyzCTl for ; Fri, 3 Jun 2016 16:40:14 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D7C12D8E6 for ; Fri, 3 Jun 2016 16:40:14 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-c9-57520c53f28f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 7C.6A.09012.35C02575; Sat, 4 Jun 2016 01:01:39 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 19:40:13 -0400 From: David Allan I To: Joe Touch , "Markus.Brunner3@swisscom.com" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS2BAjEk24HX0GvN2aAbwiqtZ/WbT4QgAEt+QCAAKgEgP//3hoggABP7AD//8MR0IAAcJ6A//++24A= Date: Fri, 3 Jun 2016 23:40:11 +0000 Message-ID: References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> In-Reply-To: <57520E71.3010903@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPn24wT1C4wYZTehZvG+4xWXxefZ3N YnbvaRaLdX/msjiweDydcJDJY8mSn0weu99vZfG42zWTOYAlissmJTUnsyy1SN8ugSvjyPKt bAWfDCqWL13K2sD4Q62LkZNDQsBEYtW5w4wQtpjEhXvr2UBsIYGjjBKLzmV1MXIB2csYJXae 2MoEkmATMJDY8/8LWIOIQJzE/DU/wGxmIPvg2lvsILawgL3Ej10z2CBqHCT+rDvDCmEnSVzq 2wpmswioSKw9tx3M5hXwlZh38QQ7xLItzBIt+x6CJTgF1CVuToZYzAh03fdTa5gglolL3Hoy nwniagGJJXvOM0PYohIvH/9jhbAVJfb1T2eHqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAo NgvJ2FlIWmYhaZmFpGUBI8sqRo7S4oKc3HQjg02MwHg6JsGmu4Px/nTPQ4wCHIxKPLwP/gaG C7EmlhVX5h5ilOBgVhLhDQBGoxBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFesUeK4UIC6Yklqdmp qQWpRTBZJg5OqQbG1QrnLgUY+JiK8tyJcnuuJHD+gPGNVfMPNL60yZuk8DPf8uDN+T8sf2gG 7v1m9fOIwwWHy0ILVs/NF/Vdbf9rfYrIU+0ZD3uT3O7y79nyOfNegUvkZOtDWxbe9/gvvXbC u8JKndAJGy+Y8H+4LPVZb2Wo1tnw2TeLyruT6zxklMXSFM+6SX5JVmIpzkg01GIuKk4EAIo3 KjOjAgAA Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 23:40:17 -0000 Hi=20 > They might use a different sort of congestion feedback, one that isn't "T= CP-compatible". That's actually desirable here - i.e., having congestion re= action happen over different timescales than TCP. > > DA2> As the tunnel leg would have a different RTT, would that not be true= by definition? The difference needs to be on significantly different timescales. Sure, a d= eployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you ca= n't know that for the tunneled traffic. It's safer to run congestion feedba= ck on the tunnel at 10x (or some value bigger than) the largest RTT that ca= n ever occur. DA3> I think we are talking past each other here. I'm not sure quite what y= ou're arguing other than it is not TCP with the rationale being timescales.= IMO the largest RTT that can occur is irrelevant (and I believe you are d= iscussing E2E). And the ratio of E2E to tunnel is also a don't care as near= as I can tell. My best guess is you think TCP RTT measurement timescales = for the tunnel itself is inadequate. Is that correct? >> - it fails to preserve payload IP messages inside a single TCP=20 >> segment, which increases loss due to a lack of fate-sharing and=20 >> increases latency and jitter >> DA> I apologize for not getting your point here. > When you write a buffer to TCP, TCP has no obligation to preserve that as= sitting inside a single TCP segment. TCP does not preserve these message b= oundaries. > > If your message spans multiple TCP segments, then you depend on BOTH of t= hem arriving. The probability of losing one or more of two segments is high= er than the probability of losing only one segment. That's the fate-sharing= part - you end up taking a RTT to recover (just like if you lost the IP pa= cket) when either TCP segment fails to arrive. That loss recovery increases= delay and jitter. > > DA2> Understood, but true of any fragmentation mechanism.=20 We're not talking about fragmentation. Even if TCP runs over IPv6 and has 1= 200+B segments, there's absolutely no guarantee that a sequence of 576B IPv= 4 packets will each occur solely inside one TCP segment. TCP can - and will - pack, straddle, or do anything else it wants with the buffers = it is given. DA3> OK, will park this one for now. >> - by recovering from loss, it increases latency and jitter >> DA> AFAIK, any loss does that irrespective of the delivery mechanism. In= the hybrid access case you are correcting loss with a smaller RTT are you = not? > You don't need to correct losses for an IP tunnel. You want to reduce the= ir probability, but you definitely don't want to stop the stream and recove= r. IP is allowed to lose packets. The loss recovery should happen E2E. > > DA2> unfortunately that sounds like dogma to me. You already have the und= erlying radio layers correcting loss for the on-air interface portion. Some radios do, some do not. Packets are lost in a lot of different places,= including routers. The fact that IP is "best effort" isn't dogma; it's the one of its defining= properties. DA3> Therefore in your world a link or path that provides a reliable transp= ort service is not allowed. I would say at best you could argue that it is= redundant. I'd simply describe it as an artifact of other technical choice= s. > DA2> No IP does not require ordered delivery from the network. But if it = was a way of life rather than a rare event it would be a problem. Poorly do= ne striping of traffic across heterogeneous links with very dynamic transfe= r characteristics would result in a lot of "out of order" receipt to correc= t.=20 First, anything that uses IP and treats misordering as an error is itself b= roken. IP is best effort and doesn't guarantee in-order delivery. However, = as noted, there are mechanisms to reduce the reordering at the egress colle= ction point, esp. for striped paths. DA3> It may not treat it as an error, but it does treat it as far more than= a minor inconvenience. Ask the vendor whose initial OC-192 interfaces did= not provide ordered transmission. (dumb striping across concatenated OC48s= ) > No, it's design-constrained. MPTCP isn't designed for plug-replaceable lo= ad detection or traffic distribution. Dynamic multipath routing is already = designed for that. > > DA2> You are looking for an a la carte menu of functions? Not necessarily; I'm saying that MPTCP comes bundled with one solution that= fits its use for two TCP endpoints. That need not be the best solution whe= n used as a tunnel. And - more to the point - we already have a wide variet= y of those solutions. DA3> Ahh, then if I understand you, you are objecting to the need for funct= ionality at both ends of the tunnel vs. just decap at one end. > > DA2> So for mechanisms that age out assignment of load spreading buckets,= that is great for the core. But at the edge with very few flows, and the a= rrival rate I approaching link rate it strikes me that there is only a fair= ly narrow range of operation in which I could successfully stripe across al= l uplinks safely. Is that your take as well? The way in which the routing protocols are tuned for core vs edge operation= may certainly vary. The routing protocol solution gives you exactly the fl= exibility to make that decision and adjust as needed. DA3> I'm not sure why you keep calling it a routing protocol solution when = it is simply forwarding and some ongoing supervision to tell you when strip= ing is not a good idea.=20 DA2> Now your original assertion was that for MPTCP, something needed to be= invented, whereas for dynamic multipath nothing new was required. From wh= at I have gleaned from this conversation is that both require specification= to produce a workable solution. MPTCP needs a spec to indicate how to tunnel. The existing solution uses e= xisting tunnel mechanisms and existing routing protocols, but needs no new = spec. DA3> It sounds like it also needs "experience" to know how to tune it.=20 Both then need to be deployed, and yes - that's work. DA3> Agreed Have a good weekend Dave From nobody Fri Jun 3 16:50:50 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FE812D9FF for ; Fri, 3 Jun 2016 16:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 4V6Xivh9TNNB for ; Fri, 3 Jun 2016 16:50: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 2CCE312D8FD for ; Fri, 3 Jun 2016 16:50:39 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u53NoMnn018762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Jun 2016 16:50:23 -0700 (PDT) To: David Allan I , "Markus.Brunner3@swisscom.com" References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> From: Joe Touch Message-ID: <575217BC.4090105@isi.edu> Date: Fri, 3 Jun 2016 16:50:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 23:50:48 -0000 On 6/3/2016 4:40 PM, David Allan I wrote: > Hi > > >> They might use a different sort of congestion feedback, one that isn't "TCP-compatible". That's actually desirable here - i.e., having congestion reaction happen over different timescales than TCP. >> >> DA2> As the tunnel leg would have a different RTT, would that not be true by definition? > The difference needs to be on significantly different timescales. Sure, a deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you can't know that for the tunneled traffic. It's safer to run congestion feedback on the tunnel at 10x (or some value bigger than) the largest RTT that can ever occur. > > DA3> I think we are talking past each other here. I'm not sure quite what you're arguing other than it is not TCP with the rationale being timescales. IMO the largest RTT that can occur is irrelevant (and I believe you are discussing E2E). And the ratio of E2E to tunnel is also a don't care as near as I can tell. My best guess is you think TCP RTT measurement timescales for the tunnel itself is inadequate. Is that correct? I think that if the routing algorithm uses TCP timescales to shift and the E2E traffic uses TCP timescales to backoff, the two will interact in bad ways. When I say "RTT" for the tunnel congestion, I should have been more clear - I'm talking about the timescales on which the traffic load balancing picks different paths. That's not RTT, but it's a similar kind of cycle time. ... >>> - by recovering from loss, it increases latency and jitter >>> DA> AFAIK, any loss does that irrespective of the delivery mechanism. In the hybrid access case you are correcting loss with a smaller RTT are you not? >> You don't need to correct losses for an IP tunnel. You want to reduce their probability, but you definitely don't want to stop the stream and recover. IP is allowed to lose packets. The loss recovery should happen E2E. >> >> DA2> unfortunately that sounds like dogma to me. You already have the underlying radio layers correcting loss for the on-air interface portion. > Some radios do, some do not. Packets are lost in a lot of different places, including routers. > > The fact that IP is "best effort" isn't dogma; it's the one of its defining properties. > DA3> Therefore in your world a link or path that provides a reliable transport service is not allowed. I would say at best you could argue that it is redundant. I'd simply describe it as an artifact of other technical choices. My view is that tunnel ARQ is an expensive choice and applicable in only a very specialized set of environments. I don't see that sort of specific environment being the intended use case for this approach. ... >> DA2> No IP does not require ordered delivery from the network. But if it was a way of life rather than a rare event it would be a problem. Poorly done striping of traffic across heterogeneous links with very dynamic transfer characteristics would result in a lot of "out of order" receipt to correct. > First, anything that uses IP and treats misordering as an error is itself broken. IP is best effort and doesn't guarantee in-order delivery. However, as noted, there are mechanisms to reduce the reordering at the egress collection point, esp. for striped paths. > DA3> It may not treat it as an error, but it does treat it as far more than a minor inconvenience. Ask the vendor whose initial OC-192 interfaces did not provide ordered transmission. (dumb striping across concatenated OC48s) OC192 provides SONET service, where reordering is not permitted (at least not outside the jitter specified for a connection). IP is a different service with different expectations. > > > >> No, it's design-constrained. MPTCP isn't designed for plug-replaceable load detection or traffic distribution. Dynamic multipath routing is already designed for that. >> >> DA2> You are looking for an a la carte menu of functions? > Not necessarily; I'm saying that MPTCP comes bundled with one solution that fits its use for two TCP endpoints. That need not be the best solution when used as a tunnel. And - more to the point - we already have a wide variety of those solutions. > > DA3> Ahh, then if I understand you, you are objecting to the need for functionality at both ends of the tunnel vs. just decap at one end. There's functionality at both ends of the tunnel in both approaches. I'm objecting to the use of TCP (any form of TCP) to tunnel IP traffic. > > >> DA2> So for mechanisms that age out assignment of load spreading buckets, that is great for the core. But at the edge with very few flows, and the arrival rate I approaching link rate it strikes me that there is only a fairly narrow range of operation in which I could successfully stripe across all uplinks safely. Is that your take as well? > The way in which the routing protocols are tuned for core vs edge operation may certainly vary. The routing protocol solution gives you exactly the flexibility to make that decision and adjust as needed. > > DA3> I'm not sure why you keep calling it a routing protocol solution when it is simply forwarding and some ongoing supervision to tell you when striping is not a good idea. > > DA2> Now your original assertion was that for MPTCP, something needed to be invented, whereas for dynamic multipath nothing new was required. From what I have gleaned from this conversation is that both require specification to produce a workable solution. > > MPTCP needs a spec to indicate how to tunnel. The existing solution uses existing tunnel mechanisms and existing routing protocols, but needs no new spec. > > DA3> It sounds like it also needs "experience" to know how to tune it. First, we already have a lot of that experience (this isn't anywhere near a new issue). Second, at least you can tune the dynamic routing variant. MPTCP doesn't have that option unless you rewrite that spec too. > Both then need to be deployed, and yes - that's work. > > DA3> Agreed > > Have a good weekend +1 and cheers... Joe From nobody Fri Jun 3 17:46:59 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D797712D189 for ; Fri, 3 Jun 2016 17:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 OfSWX5otMvzF for ; Fri, 3 Jun 2016 17:46:53 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEA712B024 for ; Fri, 3 Jun 2016 17:46:53 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-59-57521bf20d22 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 2F.EB.09012.2FB12575; Sat, 4 Jun 2016 02:08:18 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 20:46:52 -0400 From: David Allan I To: Joe Touch , "Markus.Brunner3@swisscom.com" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS2BAjEk24HX0GvN2aAbwiqtZ/WbT4QgAEt+QCAAKgEgP//3hoggABP7AD//8MR0IAAcJ6A//++24AACYcrAAAGzyCg Date: Sat, 4 Jun 2016 00:46:52 +0000 Message-ID: References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> <575217BC.4090105@isi.edu> In-Reply-To: <575217BC.4090105@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPrO4n6aBwg419UhZvG+4xWXxefZ3N YnbvaRaLdX/msjiweDydcJDJY8mSn0weu99vZfG42zWTOYAlissmJTUnsyy1SN8ugStj8vId jAVTbCpuTpjO3sD4Sr+LkZNDQsBE4tzmt6wQtpjEhXvr2boYuTiEBI4ySjz/fpsVwlnGKNHc uJ0FpIpNwEBiz/8vjCC2iECcxPw1P8BsZiD74Npb7CC2sIC9xI9dM9ggahwk/qw7wwph50mc fvSaGcRmEVCR6P/5CKyeV8BX4vGSqWDzhQSmskicb4gFsTkF1CW27n4NNp8R6Lrvp9YwQewS l7j1ZD4TxNUCEkv2nGeGsEUlXj7+B/WNksSc19eYIep1JBbs/sQGYWtLLFsIcQOvgKDEyZlP WCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtLggJzfdyGATIzCejkmw6e5gvD/d8xCjAAejEg/v g7+B4UKsiWXFlbmHGCU4mJVEeK8oB4UL8aYkVlalFuXHF5XmpBYfYpTmYFES5xV7pBguJJCe WJKanZpakFoEk2Xi4JRqYJx66K7riptX/q991bDX4vtBvYVcPi80PrW9FL69nLV0/XrjHuXt qzJlnmV1XkorYLZTFcnzfm3l5R796EhArVeR1sxNYfduc7HsOptzM6P00HdZTrWwuj/+kpz2 u1ne5WV4nZv+5M7+pg6mKVxvu7/4li6vczcyWyh837boyZbtL2/qPz4sdl2JpTgj0VCLuag4 EQB9wZoqowIAAA== Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 00:46:56 -0000 And when I thought I was done for the weekend :-) I've enjoyed the discussi= on, so just one more :-)=20 > >> They might use a different sort of congestion feedback, one that isn't "= TCP-compatible". That's actually desirable here - i.e., having congestion r= eaction happen over different timescales than TCP. >> >> DA2> As the tunnel leg would have a different RTT, would that not be tru= e by definition? > The difference needs to be on significantly different timescales. Sure, a= deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you = can't know that for the tunneled traffic. It's safer to run congestion feed= back on the tunnel at 10x (or some value bigger than) the largest RTT that = can ever occur. > > DA3> I think we are talking past each other here. I'm not sure quite what= you're arguing other than it is not TCP with the rationale being timescale= s. IMO the largest RTT that can occur is irrelevant (and I believe you are= discussing E2E). And the ratio of E2E to tunnel is also a don't care as ne= ar as I can tell. My best guess is you think TCP RTT measurement timescale= s for the tunnel itself is inadequate. Is that correct? I think that if the routing algorithm uses TCP timescales to shift and the = E2E traffic uses TCP timescales to backoff, the two will interact in bad wa= ys. DA4> I can understand that for dissimilar algorithms (like TCP over ATM-ABR= ). When I say "RTT" for the tunnel congestion, I should have been more clear -= I'm talking about the timescales on which the traffic load balancing picks= different paths. That's not RTT, but it's a similar kind of cycle time. DA4> In the context of the solution you've been discussing, there is measur= ement time, and the arrival rate which can be striped when compared to the = delta of individual path latencies. I would have to believe you need to mea= sure that frequently in the context that an ordering guarantee is a single = ended function with no redress. DA4> That is where I would lean to a double ended function, I can actually = offer the guarantee , and can stripe traffic across a greater disparity in = path throughput vs. shutting striping down past a certain threshold in disp= arity. Which when considering how asymmetric DSL is, becomes a rather large= benefit IMO. ... >>> - by recovering from loss, it increases latency and jitter >>> DA> AFAIK, any loss does that irrespective of the delivery mechanism. I= n the hybrid access case you are correcting loss with a smaller RTT are you= not? >> You don't need to correct losses for an IP tunnel. You want to reduce th= eir probability, but you definitely don't want to stop the stream and recov= er. IP is allowed to lose packets. The loss recovery should happen E2E. >> >> DA2> unfortunately that sounds like dogma to me. You already have the un= derlying radio layers correcting loss for the on-air interface portion. > Some radios do, some do not. Packets are lost in a lot of different place= s, including routers. > > The fact that IP is "best effort" isn't dogma; it's the one of its defini= ng properties. > DA3> Therefore in your world a link or path that provides a reliable tran= sport service is not allowed. I would say at best you could argue that it = is redundant. I'd simply describe it as an artifact of other technical choi= ces. My view is that tunnel ARQ is an expensive choice and applicable in only a = very specialized set of environments. I don't see that sort of specific env= ironment being the intended use case for this approach. DA4> Well for your approach, yes. As per my summary above ... >> DA2> No IP does not require ordered delivery from the network. But if it= was a way of life rather than a rare event it would be a problem. Poorly d= one striping of traffic across heterogeneous links with very dynamic transf= er characteristics would result in a lot of "out of order" receipt to corre= ct.=20 > First, anything that uses IP and treats misordering as an error is itself= broken. IP is best effort and doesn't guarantee in-order delivery. However= , as noted, there are mechanisms to reduce the reordering at the egress col= lection point, esp. for striped paths. > DA3> It may not treat it as an error, but it does treat it as far more=20 > DA3> than a minor inconvenience. Ask the vendor whose initial OC-192=20 > DA3> interfaces did not provide ordered transmission. (dumb striping=20 > DA3> across concatenated OC48s) OC192 provides SONET service, where reordering is not permitted (at least n= ot outside the jitter specified for a connection). IP is a different service with different expectations. DA4> You missed my point, there was a router that misordered packets and ca= used much unhappiness. All the deployed blades needed to be replaced IIRC. = Yes end systems will tolerate it, but not as a way of life. > > > >> No, it's design-constrained. MPTCP isn't designed for plug-replaceable l= oad detection or traffic distribution. Dynamic multipath routing is already= designed for that. >> >> DA2> You are looking for an a la carte menu of functions? > Not necessarily; I'm saying that MPTCP comes bundled with one solution th= at fits its use for two TCP endpoints. That need not be the best solution w= hen used as a tunnel. And - more to the point - we already have a wide vari= ety of those solutions. > > DA3> Ahh, then if I understand you, you are objecting to the need for fun= ctionality at both ends of the tunnel vs. just decap at one end. There's functionality at both ends of the tunnel in both approaches. I'm objecting to the use of TCP (any form of TCP) to tunnel IP traffic. DA4> I gathered that! > > >> DA2> So for mechanisms that age out assignment of load spreading buckets= , that is great for the core. But at the edge with very few flows, and the = arrival rate I approaching link rate it strikes me that there is only a fai= rly narrow range of operation in which I could successfully stripe across a= ll uplinks safely. Is that your take as well? > The way in which the routing protocols are tuned for core vs edge operati= on may certainly vary. The routing protocol solution gives you exactly the = flexibility to make that decision and adjust as needed. > > DA3> I'm not sure why you keep calling it a routing protocol solution whe= n it is simply forwarding and some ongoing supervision to tell you when str= iping is not a good idea.=20 > > DA2> Now your original assertion was that for MPTCP, something needed to = be invented, whereas for dynamic multipath nothing new was required. From = what I have gleaned from this conversation is that both require specificati= on to produce a workable solution. > > MPTCP needs a spec to indicate how to tunnel. The existing solution uses= existing tunnel mechanisms and existing routing protocols, but needs no ne= w spec. > > DA3> It sounds like it also needs "experience" to know how to tune it.=20 First, we already have a lot of that experience (this isn't anywhere near a= new issue). DA4> SO I understand :-) Second, at least you can tune the dynamic routing variant. MPTCP doesn't ha= ve that option unless you rewrite that spec too. DA4> Any HA solution will have policy as the economics of using each interf= ace are different. So both solutions will have overall very similar options= when the dust settles. > Both then need to be deployed, and yes - that's work. > > DA3> Agreed > > Have a good weekend +1 and cheers... DA4> cheers as well Dave From nobody Sat Jun 4 05:39:17 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0542712D0F2 for ; Sat, 4 Jun 2016 05:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=Jordan.Melzer@telus.com header.d=telus.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 34JN1oV3k_aJ for ; Sat, 4 Jun 2016 05:39:14 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id A478B12B02C for ; Sat, 4 Jun 2016 05:39:13 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cNorDyiysxZS10m/43BJcvkv7qTCWhD7qMGM/D3JiCDraSj2w6W/5K2Z dDvRh3cEdLCHd7Ogdc21HFgtrPtB0g6qdc2iKZZWLYU+K4QJIeFx8MrkM qwmUMIWszYrSDtv2gXY39svQJvnyTpWlHzRTxiKhmMamhBdDy3zZo9vpR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DJAgABy1JX/5Jjso5eDoMALEkNfaJ1l3GBehcLhSZKAoEvOBQBAQEBAQEBZSeERQEBAQMBAQEBNxkbCwUHBAIBCA0EBAEBHwkHJwsUCQgCBAEJBAUIEQKIDAgBBAm5OQEBAQEBAQEBAgEBAQEBAQEBAQEBFwWGJ4NKgQOEQoMqgi4FjlqJboh7hxSEUIMgDIU5j1oeNoIHBReBEFpPiWMBAQE X-IronPort-AV: E=Sophos;i="5.26,417,1459814400"; d="scan'208";a="523832991" Received: from unknown (HELO WP40081.corp.ads) ([142.178.99.146]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 04 Jun 2016 12:39:09 +0000 Received: from WP40046.corp.ads ([::1]) by WP40081.corp.ads ([::1]) with mapi; Sat, 4 Jun 2016 06:39:09 -0600 From: Jordan Melzer To: David Allan I , Joe Touch , "Markus.Brunner3@swisscom.com" Date: Sat, 4 Jun 2016 06:39:07 -0600 Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS2BAjEk24HX0GvN2aAbwiqtZ/WbT4QgAEt+QCAAKgEgP//3hoggABP7AD//8MR0IAAcJ6A//++24AACYcrAAAGzyCgAAplZOA= Message-ID: <80C0017654A043479F53C41112BE84768979E1F993@WP40046.corp.ads> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> <575217BC.4090105@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 12:39:17 -0000 Thanks, David, Joe. That was very interesting to read through. I'm also from an operator interested in deploying MPTCP as an access multip= ath mechanism. I am concerned about breaking user applications, and I do w= ant to highlight from the discussion how many assumptions there are on IP t= raffic behaviour. As David argued, while IP doesn't guarantee traffic is delivered in order, = Internet users and applications largely do expect it to be mostly delivered= in order, and if it isn't, they don't guarantee to work. As cool as FLARE= is at taking advantage of TCP burstiness to be able to multipath it, its a= ssumptions sound very fragile: it can work for TCP as an underlying protoco= l, when TCP is bursty. So... it can work for some protocols, sometimes. A= nd what is FLARE doing? It's trying to reduce the number of out of order I= P packets when one is multipathing. Joe, however, raised the timing of packet delivery as an issue. Running TC= P over TCP can be problematic despite TCP being able to deliver IP packets = in order. If the tunneled layer is more aggressive about retransmission th= an the base layer, the tunnel breaks. As we know, size also matters. MTU is expected to be consistent, transpare= nt, and generous. I don't have a good handle on what the arguments were fo= r each solution with respect to MTU challenges. I'm not convinced anything proposed is a good general method for transporti= ng UDP flows across links with different characteristics. I don't know wha= t is happening inside the UDP flow and if I will be violating any of the un= written assumptions written above. Am I overly concerned, and, if so, abou= t what? I would consider using either approach for some subset of traffic driven by= a bunch of semi-opaque policy because I work for an ISP, but I don't know = if I would want to force a user's VPN onto any aggregated link. Please con= vince me I do. Regards, Jordan -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Davi= d Allan I Sent: June 3, 2016 08:47 PM To: Joe Touch; Markus.Brunner3@swisscom.com Cc: multipathtcp@ietf.org; sarikaya@ieee.org Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 And when I thought I was done for the weekend :-) I've enjoyed the discussi= on, so just one more :-)=20 > >> They might use a different sort of congestion feedback, one that isn't "= TCP-compatible". That's actually desirable here - i.e., having congestion r= eaction happen over different timescales than TCP. >> >> DA2> As the tunnel leg would have a different RTT, would that not be tru= e by definition? > The difference needs to be on significantly different timescales. Sure, a= deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you = can't know that for the tunneled traffic. It's safer to run congestion feed= back on the tunnel at 10x (or some value bigger than) the largest RTT that = can ever occur. > > DA3> I think we are talking past each other here. I'm not sure quite what= you're arguing other than it is not TCP with the rationale being timescale= s. IMO the largest RTT that can occur is irrelevant (and I believe you are= discussing E2E). And the ratio of E2E to tunnel is also a don't care as ne= ar as I can tell. My best guess is you think TCP RTT measurement timescale= s for the tunnel itself is inadequate. Is that correct? I think that if the routing algorithm uses TCP timescales to shift and the = E2E traffic uses TCP timescales to backoff, the two will interact in bad wa= ys. DA4> I can understand that for dissimilar algorithms (like TCP over ATM-ABR= ). When I say "RTT" for the tunnel congestion, I should have been more clear -= I'm talking about the timescales on which the traffic load balancing picks= different paths. That's not RTT, but it's a similar kind of cycle time. DA4> In the context of the solution you've been discussing, there is measur= ement time, and the arrival rate which can be striped when compared to the = delta of individual path latencies. I would have to believe you need to mea= sure that frequently in the context that an ordering guarantee is a single = ended function with no redress. DA4> That is where I would lean to a double ended function, I can actually = offer the guarantee , and can stripe traffic across a greater disparity in = path throughput vs. shutting striping down past a certain threshold in disp= arity. Which when considering how asymmetric DSL is, becomes a rather large= benefit IMO. ... >>> - by recovering from loss, it increases latency and jitter >>> DA> AFAIK, any loss does that irrespective of the delivery mechanism. I= n the hybrid access case you are correcting loss with a smaller RTT are you= not? >> You don't need to correct losses for an IP tunnel. You want to reduce th= eir probability, but you definitely don't want to stop the stream and recov= er. IP is allowed to lose packets. The loss recovery should happen E2E. >> >> DA2> unfortunately that sounds like dogma to me. You already have the un= derlying radio layers correcting loss for the on-air interface portion. > Some radios do, some do not. Packets are lost in a lot of different place= s, including routers. > > The fact that IP is "best effort" isn't dogma; it's the one of its defini= ng properties. > DA3> Therefore in your world a link or path that provides a reliable tran= sport service is not allowed. I would say at best you could argue that it = is redundant. I'd simply describe it as an artifact of other technical choi= ces. My view is that tunnel ARQ is an expensive choice and applicable in only a = very specialized set of environments. I don't see that sort of specific env= ironment being the intended use case for this approach. DA4> Well for your approach, yes. As per my summary above ... >> DA2> No IP does not require ordered delivery from the network. But if it= was a way of life rather than a rare event it would be a problem. Poorly d= one striping of traffic across heterogeneous links with very dynamic transf= er characteristics would result in a lot of "out of order" receipt to corre= ct.=20 > First, anything that uses IP and treats misordering as an error is itself= broken. IP is best effort and doesn't guarantee in-order delivery. However= , as noted, there are mechanisms to reduce the reordering at the egress col= lection point, esp. for striped paths. > DA3> It may not treat it as an error, but it does treat it as far more=20 > DA3> than a minor inconvenience. Ask the vendor whose initial OC-192=20 > DA3> interfaces did not provide ordered transmission. (dumb striping=20 > DA3> across concatenated OC48s) OC192 provides SONET service, where reordering is not permitted (at least n= ot outside the jitter specified for a connection). IP is a different service with different expectations. DA4> You missed my point, there was a router that misordered packets and ca= used much unhappiness. All the deployed blades needed to be replaced IIRC. = Yes end systems will tolerate it, but not as a way of life. > > > >> No, it's design-constrained. MPTCP isn't designed for plug-replaceable l= oad detection or traffic distribution. Dynamic multipath routing is already= designed for that. >> >> DA2> You are looking for an a la carte menu of functions? > Not necessarily; I'm saying that MPTCP comes bundled with one solution th= at fits its use for two TCP endpoints. That need not be the best solution w= hen used as a tunnel. And - more to the point - we already have a wide vari= ety of those solutions. > > DA3> Ahh, then if I understand you, you are objecting to the need for fun= ctionality at both ends of the tunnel vs. just decap at one end. There's functionality at both ends of the tunnel in both approaches. I'm objecting to the use of TCP (any form of TCP) to tunnel IP traffic. DA4> I gathered that! > > >> DA2> So for mechanisms that age out assignment of load spreading buckets= , that is great for the core. But at the edge with very few flows, and the = arrival rate I approaching link rate it strikes me that there is only a fai= rly narrow range of operation in which I could successfully stripe across a= ll uplinks safely. Is that your take as well? > The way in which the routing protocols are tuned for core vs edge operati= on may certainly vary. The routing protocol solution gives you exactly the = flexibility to make that decision and adjust as needed. > > DA3> I'm not sure why you keep calling it a routing protocol solution whe= n it is simply forwarding and some ongoing supervision to tell you when str= iping is not a good idea.=20 > > DA2> Now your original assertion was that for MPTCP, something needed to = be invented, whereas for dynamic multipath nothing new was required. From = what I have gleaned from this conversation is that both require specificati= on to produce a workable solution. > > MPTCP needs a spec to indicate how to tunnel. The existing solution uses= existing tunnel mechanisms and existing routing protocols, but needs no ne= w spec. > > DA3> It sounds like it also needs "experience" to know how to tune it.=20 First, we already have a lot of that experience (this isn't anywhere near a= new issue). DA4> SO I understand :-) Second, at least you can tune the dynamic routing variant. MPTCP doesn't ha= ve that option unless you rewrite that spec too. DA4> Any HA solution will have policy as the economics of using each interf= ace are different. So both solutions will have overall very similar options= when the dust settles. > Both then need to be deployed, and yes - that's work. > > DA3> Agreed > > Have a good weekend +1 and cheers... DA4> cheers as well Dave _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jun 5 05:52:30 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0A12B006 for ; Sun, 5 Jun 2016 05:52:29 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 TZkNHap9aGYT for ; Sun, 5 Jun 2016 05:52:26 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009CB12D095 for ; Sun, 5 Jun 2016 05:52:25 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C3CAC7786F02B; Sun, 5 Jun 2016 12:52:21 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u55CqNgl004427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Jun 2016 12:52:23 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u55CqMDO019374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Jun 2016 14:52:22 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sun, 5 Jun 2016 14:52:22 +0200 From: "Henderickx, Wim (Nokia - BE)" To: David Allan I , Joe Touch , "Markus.Brunner3@swisscom.com" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvPLWg8MTdmGsmUykfkcCgIRGwp/X/xaDgAAB5wCAAAoyAIAAIP6AgAASsYCAAAg+gIAAAtYAgAAPzACAAn6OgA== Date: Sun, 5 Jun 2016 12:52:21 +0000 Message-ID: <263779B7-DA62-4C02-891E-1D7E2C5C04E2@alcatel-lucent.com> References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> <575217BC.4090105@isi.edu> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <0F9BC9D959B2434BB83F59B6F6CE000E@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 12:52:29 -0000 SSBiZWxpZXZlIHRoYXQgd2UgYXJlIG92ZXJsb29raW5nIG9uZSBtYWpvciB0aGluZyBpbiB0aGlz IGRpc2N1c3Npb24uIFRoZSBwbGFpbiBNUFRDUCBzb2x1dGlvbiBwcm9wb3NlcyBhIGZ1bGwgcHJv eHkgYXQgZGlmZmVyZW50IHBvaW50cywgbWVhbmluZyBpdCByZWluaXRpYXRlcyBhIFRDUC9NUC1U Q1Agc2Vzc2lvbiBhdCB2YXJpb3VzIHBvaW50cyB0byBhY2NvbW1vZGF0ZSB0aGUgdmFyaW91cyBU Q1AgdGltZXJzLCBldGMNClRoZSBkcmFmdCByZXF1aXJlcyBlYWNoIHByb3h5IHRvIGNvbXBlbnNh dGUgZm9yIHZhcmlvdXMgZGVsYXlzIGluIHZhcmlvdXMgc2VnbWVudHMuIFRoaXMgaGFzIGlzIGRl cGxveWVkIGluIHZhcmlvdXMgbmV0d29ya3MsIG1haW5seSBtb2JpbGUgdG8gaW1wcm92ZSBRb0Ug dG9kYXkgdy9vIE1QLVRDUC4gVGhlIHBsYWluIE1QLVRDUCBlbmhhbmNlcyB0aGlzIHNvbHV0aW9u IGFuZCBhbGxvd3MgZmxvd3Mgd2hpY2ggYXJlIGJpZ2dlciB0aGFuIGEgZ2l2ZW4gcGF0aCB0byBz dGlsbCB3b3JrLCB3aGVyZWFzIHRvZGF5IHRoZXkgYnJlYWsuDQpFeGFtcGxlIGhlcmUNCg0KRW5k SG9zdCAoVENQKSA84oCU4oCUPiAoVENQKSBDUEUgKE1QLVRDUCBwcm94eSkgPOKAlOKAlD4gIChN UC1UQ1AgcHJveHkpIENvbmNlbnRyYXRvcikgKFRDUCkgPOKAlOKAlD4gQXBwDQoNCkFzIHN1Y2gg dGhlIENQRSBhbmQgY29uY2VudHJhdG9yIGhhdmUgdG8gY29tcGVuc2F0ZSBmb3IgdGhlIHZhcmlv dXMgZGVsYXlzL2ZlZWRiYWNrcyBpbiB0aGUgcHJvdG9jb2wgc3RhY2suDQoNCg0KDQoNCk9uIDA0 LzA2LzE2IDAyOjQ2LCAibXVsdGlwYXRodGNwIG9uIGJlaGFsZiBvZiBEYXZpZCBBbGxhbiBJIiA8 bXVsdGlwYXRodGNwLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRhdmlkLmkuYWxsYW5A ZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkFuZCB3aGVuIEkgdGhvdWdodCBJIHdhcyBkb25lIGZv ciB0aGUgd2Vla2VuZCA6LSkgSSd2ZSBlbmpveWVkIHRoZSBkaXNjdXNzaW9uLCBzbyBqdXN0IG9u ZSBtb3JlIDotKSANCj4NCj4+IDxzbmlwcGVkPg0KPj4+IFRoZXkgbWlnaHQgdXNlIGEgZGlmZmVy ZW50IHNvcnQgb2YgY29uZ2VzdGlvbiBmZWVkYmFjaywgb25lIHRoYXQgaXNuJ3QgIlRDUC1jb21w YXRpYmxlIi4gVGhhdCdzIGFjdHVhbGx5IGRlc2lyYWJsZSBoZXJlIC0gaS5lLiwgaGF2aW5nIGNv bmdlc3Rpb24gcmVhY3Rpb24gaGFwcGVuIG92ZXIgZGlmZmVyZW50IHRpbWVzY2FsZXMgdGhhbiBU Q1AuDQo+Pj4NCj4+PiBEQTI+IEFzIHRoZSB0dW5uZWwgbGVnIHdvdWxkIGhhdmUgYSBkaWZmZXJl bnQgUlRULCB3b3VsZCB0aGF0IG5vdCBiZSB0cnVlIGJ5IGRlZmluaXRpb24/DQo+PiBUaGUgZGlm ZmVyZW5jZSBuZWVkcyB0byBiZSBvbiBzaWduaWZpY2FudGx5IGRpZmZlcmVudCB0aW1lc2NhbGVz LiBTdXJlLCBhIGRlcGxveW1lbnQgbWlnaHQgd29yayBpZiB0aGUgdHVubmVsIGlzIDEvMTAgb3Ig MS8xMDAgdGhlIEUyRSBSVFQsIGJ1dCB5b3UgY2FuJ3Qga25vdyB0aGF0IGZvciB0aGUgdHVubmVs ZWQgdHJhZmZpYy4gSXQncyBzYWZlciB0byBydW4gY29uZ2VzdGlvbiBmZWVkYmFjayBvbiB0aGUg dHVubmVsIGF0IDEweCAob3Igc29tZSB2YWx1ZSBiaWdnZXIgdGhhbikgdGhlIGxhcmdlc3QgUlRU IHRoYXQgY2FuIGV2ZXIgb2NjdXIuDQo+Pg0KPj4gREEzPiBJIHRoaW5rIHdlIGFyZSB0YWxraW5n IHBhc3QgZWFjaCBvdGhlciBoZXJlLiBJJ20gbm90IHN1cmUgcXVpdGUgd2hhdCB5b3UncmUgYXJn dWluZyBvdGhlciB0aGFuIGl0IGlzIG5vdCBUQ1Agd2l0aCB0aGUgcmF0aW9uYWxlIGJlaW5nIHRp bWVzY2FsZXMuICBJTU8gdGhlIGxhcmdlc3QgUlRUIHRoYXQgY2FuIG9jY3VyIGlzIGlycmVsZXZh bnQgKGFuZCBJIGJlbGlldmUgeW91IGFyZSBkaXNjdXNzaW5nIEUyRSkuIEFuZCB0aGUgcmF0aW8g b2YgRTJFIHRvIHR1bm5lbCBpcyBhbHNvIGEgZG9uJ3QgY2FyZSBhcyBuZWFyIGFzIEkgY2FuIHRl bGwuICBNeSBiZXN0IGd1ZXNzIGlzIHlvdSB0aGluayBUQ1AgUlRUIG1lYXN1cmVtZW50IHRpbWVz Y2FsZXMgZm9yIHRoZSB0dW5uZWwgaXRzZWxmIGlzIGluYWRlcXVhdGUuIElzIHRoYXQgY29ycmVj dD8NCj4NCj5JIHRoaW5rIHRoYXQgaWYgdGhlIHJvdXRpbmcgYWxnb3JpdGhtIHVzZXMgVENQIHRp bWVzY2FsZXMgdG8gc2hpZnQgYW5kIHRoZSBFMkUgdHJhZmZpYyB1c2VzIFRDUCB0aW1lc2NhbGVz IHRvIGJhY2tvZmYsIHRoZSB0d28gd2lsbCBpbnRlcmFjdCBpbiBiYWQgd2F5cy4NCj4NCj5EQTQ+ IEkgY2FuIHVuZGVyc3RhbmQgdGhhdCBmb3IgZGlzc2ltaWxhciBhbGdvcml0aG1zIChsaWtlIFRD UCBvdmVyIEFUTS1BQlIpLg0KPg0KPldoZW4gSSBzYXkgIlJUVCIgZm9yIHRoZSB0dW5uZWwgY29u Z2VzdGlvbiwgSSBzaG91bGQgaGF2ZSBiZWVuIG1vcmUgY2xlYXIgLSBJJ20gdGFsa2luZyBhYm91 dCB0aGUgdGltZXNjYWxlcyBvbiB3aGljaCB0aGUgdHJhZmZpYyBsb2FkIGJhbGFuY2luZyBwaWNr cyBkaWZmZXJlbnQgcGF0aHMuIFRoYXQncyBub3QgUlRULCBidXQgaXQncyBhIHNpbWlsYXIga2lu ZCBvZiBjeWNsZSB0aW1lLg0KPg0KPkRBND4gSW4gdGhlIGNvbnRleHQgb2YgdGhlIHNvbHV0aW9u IHlvdSd2ZSBiZWVuIGRpc2N1c3NpbmcsIHRoZXJlIGlzIG1lYXN1cmVtZW50IHRpbWUsIGFuZCB0 aGUgYXJyaXZhbCByYXRlIHdoaWNoIGNhbiBiZSBzdHJpcGVkIHdoZW4gY29tcGFyZWQgdG8gdGhl IGRlbHRhIG9mIGluZGl2aWR1YWwgcGF0aCBsYXRlbmNpZXMuIEkgd291bGQgaGF2ZSB0byBiZWxp ZXZlIHlvdSBuZWVkIHRvIG1lYXN1cmUgdGhhdCBmcmVxdWVudGx5IGluIHRoZSBjb250ZXh0IHRo YXQgYW4gb3JkZXJpbmcgZ3VhcmFudGVlIGlzIGEgc2luZ2xlIGVuZGVkIGZ1bmN0aW9uIHdpdGgg bm8gcmVkcmVzcy4NCj4NCj5EQTQ+IFRoYXQgaXMgd2hlcmUgSSB3b3VsZCBsZWFuIHRvIGEgZG91 YmxlIGVuZGVkIGZ1bmN0aW9uLCBJIGNhbiBhY3R1YWxseSBvZmZlciB0aGUgZ3VhcmFudGVlICwg YW5kIGNhbiBzdHJpcGUgdHJhZmZpYyBhY3Jvc3MgYSBncmVhdGVyIGRpc3Bhcml0eSBpbiBwYXRo IHRocm91Z2hwdXQgdnMuIHNodXR0aW5nIHN0cmlwaW5nIGRvd24gcGFzdCBhIGNlcnRhaW4gdGhy ZXNob2xkIGluIGRpc3Bhcml0eS4gV2hpY2ggd2hlbiBjb25zaWRlcmluZyBob3cgYXN5bW1ldHJp YyBEU0wgaXMsIGJlY29tZXMgYSByYXRoZXIgbGFyZ2UgYmVuZWZpdCBJTU8uDQo+DQo+Li4uDQo+ DQo+Pj4+IC0gYnkgcmVjb3ZlcmluZyBmcm9tIGxvc3MsIGl0IGluY3JlYXNlcyBsYXRlbmN5IGFu ZCBqaXR0ZXINCj4+Pj4gREE+IEFGQUlLLCBhbnkgbG9zcyBkb2VzIHRoYXQgaXJyZXNwZWN0aXZl IG9mIHRoZSBkZWxpdmVyeSBtZWNoYW5pc20uIEluIHRoZSBoeWJyaWQgYWNjZXNzIGNhc2UgeW91 IGFyZSBjb3JyZWN0aW5nIGxvc3Mgd2l0aCBhIHNtYWxsZXIgUlRUIGFyZSB5b3Ugbm90Pw0KPj4+ IFlvdSBkb24ndCBuZWVkIHRvIGNvcnJlY3QgbG9zc2VzIGZvciBhbiBJUCB0dW5uZWwuIFlvdSB3 YW50IHRvIHJlZHVjZSB0aGVpciBwcm9iYWJpbGl0eSwgYnV0IHlvdSBkZWZpbml0ZWx5IGRvbid0 IHdhbnQgdG8gc3RvcCB0aGUgc3RyZWFtIGFuZCByZWNvdmVyLiBJUCBpcyBhbGxvd2VkIHRvIGxv c2UgcGFja2V0cy4gVGhlIGxvc3MgcmVjb3Zlcnkgc2hvdWxkIGhhcHBlbiBFMkUuDQo+Pj4NCj4+ PiBEQTI+IHVuZm9ydHVuYXRlbHkgdGhhdCBzb3VuZHMgbGlrZSBkb2dtYSB0byBtZS4gWW91IGFs cmVhZHkgaGF2ZSB0aGUgdW5kZXJseWluZyByYWRpbyBsYXllcnMgY29ycmVjdGluZyBsb3NzIGZv ciB0aGUgb24tYWlyIGludGVyZmFjZSBwb3J0aW9uLg0KPj4gU29tZSByYWRpb3MgZG8sIHNvbWUg ZG8gbm90LiBQYWNrZXRzIGFyZSBsb3N0IGluIGEgbG90IG9mIGRpZmZlcmVudCBwbGFjZXMsIGlu Y2x1ZGluZyByb3V0ZXJzLg0KPj4NCj4+IFRoZSBmYWN0IHRoYXQgSVAgaXMgImJlc3QgZWZmb3J0 IiBpc24ndCBkb2dtYTsgaXQncyB0aGUgb25lIG9mIGl0cyBkZWZpbmluZyBwcm9wZXJ0aWVzLg0K Pj4gREEzPiBUaGVyZWZvcmUgaW4geW91ciB3b3JsZCBhIGxpbmsgb3IgcGF0aCB0aGF0IHByb3Zp ZGVzIGEgcmVsaWFibGUgdHJhbnNwb3J0IHNlcnZpY2UgaXMgbm90IGFsbG93ZWQuICBJIHdvdWxk IHNheSBhdCBiZXN0IHlvdSBjb3VsZCBhcmd1ZSB0aGF0IGl0IGlzIHJlZHVuZGFudC4gSSdkIHNp bXBseSBkZXNjcmliZSBpdCBhcyBhbiBhcnRpZmFjdCBvZiBvdGhlciB0ZWNobmljYWwgY2hvaWNl cy4NCj4NCj5NeSB2aWV3IGlzIHRoYXQgdHVubmVsIEFSUSBpcyBhbiBleHBlbnNpdmUgY2hvaWNl IGFuZCBhcHBsaWNhYmxlIGluIG9ubHkgYSB2ZXJ5IHNwZWNpYWxpemVkIHNldCBvZiBlbnZpcm9u bWVudHMuIEkgZG9uJ3Qgc2VlIHRoYXQgc29ydCBvZiBzcGVjaWZpYyBlbnZpcm9ubWVudCBiZWlu ZyB0aGUgaW50ZW5kZWQgdXNlIGNhc2UgZm9yIHRoaXMgYXBwcm9hY2guDQo+REE0PiBXZWxsIGZv ciB5b3VyIGFwcHJvYWNoLCB5ZXMuIEFzIHBlciBteSBzdW1tYXJ5IGFib3ZlDQo+DQo+Li4uDQo+ Pj4gREEyPiBObyBJUCBkb2VzIG5vdCByZXF1aXJlIG9yZGVyZWQgZGVsaXZlcnkgZnJvbSB0aGUg bmV0d29yay4gQnV0IGlmIGl0IHdhcyBhIHdheSBvZiBsaWZlIHJhdGhlciB0aGFuIGEgcmFyZSBl dmVudCBpdCB3b3VsZCBiZSBhIHByb2JsZW0uIFBvb3JseSBkb25lIHN0cmlwaW5nIG9mIHRyYWZm aWMgYWNyb3NzIGhldGVyb2dlbmVvdXMgbGlua3Mgd2l0aCB2ZXJ5IGR5bmFtaWMgdHJhbnNmZXIg Y2hhcmFjdGVyaXN0aWNzIHdvdWxkIHJlc3VsdCBpbiBhIGxvdCBvZiAib3V0IG9mIG9yZGVyIiBy ZWNlaXB0IHRvIGNvcnJlY3QuIA0KPj4gRmlyc3QsIGFueXRoaW5nIHRoYXQgdXNlcyBJUCBhbmQg dHJlYXRzIG1pc29yZGVyaW5nIGFzIGFuIGVycm9yIGlzIGl0c2VsZiBicm9rZW4uIElQIGlzIGJl c3QgZWZmb3J0IGFuZCBkb2Vzbid0IGd1YXJhbnRlZSBpbi1vcmRlciBkZWxpdmVyeS4gSG93ZXZl ciwgYXMgbm90ZWQsIHRoZXJlIGFyZSBtZWNoYW5pc21zIHRvIHJlZHVjZSB0aGUgcmVvcmRlcmlu ZyBhdCB0aGUgZWdyZXNzIGNvbGxlY3Rpb24gcG9pbnQsIGVzcC4gZm9yIHN0cmlwZWQgcGF0aHMu DQo+PiBEQTM+IEl0IG1heSBub3QgdHJlYXQgaXQgYXMgYW4gZXJyb3IsIGJ1dCBpdCBkb2VzIHRy ZWF0IGl0IGFzIGZhciBtb3JlIA0KPj4gREEzPiB0aGFuIGEgbWlub3IgaW5jb252ZW5pZW5jZS4g IEFzayB0aGUgdmVuZG9yIHdob3NlIGluaXRpYWwgT0MtMTkyIA0KPj4gREEzPiBpbnRlcmZhY2Vz IGRpZCBub3QgcHJvdmlkZSBvcmRlcmVkIHRyYW5zbWlzc2lvbi4gKGR1bWIgc3RyaXBpbmcgDQo+ PiBEQTM+IGFjcm9zcyBjb25jYXRlbmF0ZWQgT0M0OHMpDQo+DQo+T0MxOTIgcHJvdmlkZXMgU09O RVQgc2VydmljZSwgd2hlcmUgcmVvcmRlcmluZyBpcyBub3QgcGVybWl0dGVkIChhdCBsZWFzdCBu b3Qgb3V0c2lkZSB0aGUgaml0dGVyIHNwZWNpZmllZCBmb3IgYSBjb25uZWN0aW9uKS4NCj4NCj5J UCBpcyBhIGRpZmZlcmVudCBzZXJ2aWNlIHdpdGggZGlmZmVyZW50IGV4cGVjdGF0aW9ucy4NCj4N Cj5EQTQ+IFlvdSBtaXNzZWQgbXkgcG9pbnQsIHRoZXJlIHdhcyBhIHJvdXRlciB0aGF0IG1pc29y ZGVyZWQgcGFja2V0cyBhbmQgY2F1c2VkIG11Y2ggdW5oYXBwaW5lc3MuIEFsbCB0aGUgZGVwbG95 ZWQgYmxhZGVzIG5lZWRlZCB0byBiZSByZXBsYWNlZCBJSVJDLiBZZXMgZW5kIHN5c3RlbXMgd2ls bCB0b2xlcmF0ZSBpdCwgYnV0IG5vdCBhcyBhIHdheSBvZiBsaWZlLg0KPg0KPg0KPj4NCj4+IDxz bmlwcGVkPg0KPj4NCj4+PiBObywgaXQncyBkZXNpZ24tY29uc3RyYWluZWQuIE1QVENQIGlzbid0 IGRlc2lnbmVkIGZvciBwbHVnLXJlcGxhY2VhYmxlIGxvYWQgZGV0ZWN0aW9uIG9yIHRyYWZmaWMg ZGlzdHJpYnV0aW9uLiBEeW5hbWljIG11bHRpcGF0aCByb3V0aW5nIGlzIGFscmVhZHkgZGVzaWdu ZWQgZm9yIHRoYXQuDQo+Pj4NCj4+PiBEQTI+IFlvdSBhcmUgbG9va2luZyBmb3IgYW4gYSBsYSBj YXJ0ZSBtZW51IG9mIGZ1bmN0aW9ucz8NCj4+IE5vdCBuZWNlc3NhcmlseTsgSSdtIHNheWluZyB0 aGF0IE1QVENQIGNvbWVzIGJ1bmRsZWQgd2l0aCBvbmUgc29sdXRpb24gdGhhdCBmaXRzIGl0cyB1 c2UgZm9yIHR3byBUQ1AgZW5kcG9pbnRzLiBUaGF0IG5lZWQgbm90IGJlIHRoZSBiZXN0IHNvbHV0 aW9uIHdoZW4gdXNlZCBhcyBhIHR1bm5lbC4gQW5kIC0gbW9yZSB0byB0aGUgcG9pbnQgLSB3ZSBh bHJlYWR5IGhhdmUgYSB3aWRlIHZhcmlldHkgb2YgdGhvc2Ugc29sdXRpb25zLg0KPj4NCj4+IERB Mz4gQWhoLCB0aGVuIGlmIEkgdW5kZXJzdGFuZCB5b3UsIHlvdSBhcmUgb2JqZWN0aW5nIHRvIHRo ZSBuZWVkIGZvciBmdW5jdGlvbmFsaXR5IGF0IGJvdGggZW5kcyBvZiB0aGUgdHVubmVsIHZzLiBq dXN0IGRlY2FwIGF0IG9uZSBlbmQuDQo+DQo+VGhlcmUncyBmdW5jdGlvbmFsaXR5IGF0IGJvdGgg ZW5kcyBvZiB0aGUgdHVubmVsIGluIGJvdGggYXBwcm9hY2hlcy4NCj4NCj5JJ20gb2JqZWN0aW5n IHRvIHRoZSB1c2Ugb2YgVENQIChhbnkgZm9ybSBvZiBUQ1ApIHRvIHR1bm5lbCBJUCB0cmFmZmlj Lg0KPkRBND4gSSBnYXRoZXJlZCB0aGF0IQ0KPg0KPg0KPj4NCj4+IDxzbmlwcGVkPg0KPj4+IERB Mj4gU28gZm9yIG1lY2hhbmlzbXMgdGhhdCBhZ2Ugb3V0IGFzc2lnbm1lbnQgb2YgbG9hZCBzcHJl YWRpbmcgYnVja2V0cywgdGhhdCBpcyBncmVhdCBmb3IgdGhlIGNvcmUuIEJ1dCBhdCB0aGUgZWRn ZSB3aXRoIHZlcnkgZmV3IGZsb3dzLCBhbmQgdGhlIGFycml2YWwgcmF0ZSBJIGFwcHJvYWNoaW5n IGxpbmsgcmF0ZSBpdCBzdHJpa2VzIG1lIHRoYXQgdGhlcmUgaXMgb25seSBhIGZhaXJseSBuYXJy b3cgcmFuZ2Ugb2Ygb3BlcmF0aW9uIGluIHdoaWNoIEkgY291bGQgc3VjY2Vzc2Z1bGx5IHN0cmlw ZSBhY3Jvc3MgYWxsIHVwbGlua3Mgc2FmZWx5LiBJcyB0aGF0IHlvdXIgdGFrZSBhcyB3ZWxsPw0K Pj4gVGhlIHdheSBpbiB3aGljaCB0aGUgcm91dGluZyBwcm90b2NvbHMgYXJlIHR1bmVkIGZvciBj b3JlIHZzIGVkZ2Ugb3BlcmF0aW9uIG1heSBjZXJ0YWlubHkgdmFyeS4gVGhlIHJvdXRpbmcgcHJv dG9jb2wgc29sdXRpb24gZ2l2ZXMgeW91IGV4YWN0bHkgdGhlIGZsZXhpYmlsaXR5IHRvIG1ha2Ug dGhhdCBkZWNpc2lvbiBhbmQgYWRqdXN0IGFzIG5lZWRlZC4NCj4+DQo+PiBEQTM+IEknbSBub3Qg c3VyZSB3aHkgeW91IGtlZXAgY2FsbGluZyBpdCBhIHJvdXRpbmcgcHJvdG9jb2wgc29sdXRpb24g d2hlbiBpdCBpcyBzaW1wbHkgZm9yd2FyZGluZyBhbmQgc29tZSBvbmdvaW5nIHN1cGVydmlzaW9u IHRvIHRlbGwgeW91IHdoZW4gc3RyaXBpbmcgaXMgbm90IGEgZ29vZCBpZGVhLiANCj4+DQo+PiBE QTI+IE5vdyB5b3VyIG9yaWdpbmFsIGFzc2VydGlvbiB3YXMgdGhhdCBmb3IgTVBUQ1AsIHNvbWV0 aGluZyBuZWVkZWQgdG8gYmUgaW52ZW50ZWQsIHdoZXJlYXMgZm9yIGR5bmFtaWMgbXVsdGlwYXRo IG5vdGhpbmcgbmV3IHdhcyByZXF1aXJlZC4gIEZyb20gd2hhdCBJIGhhdmUgZ2xlYW5lZCBmcm9t IHRoaXMgY29udmVyc2F0aW9uIGlzIHRoYXQgYm90aCByZXF1aXJlIHNwZWNpZmljYXRpb24gdG8g cHJvZHVjZSBhIHdvcmthYmxlIHNvbHV0aW9uLg0KPj4NCj4+ICBNUFRDUCBuZWVkcyBhIHNwZWMg dG8gaW5kaWNhdGUgaG93IHRvIHR1bm5lbC4gVGhlIGV4aXN0aW5nIHNvbHV0aW9uIHVzZXMgZXhp c3RpbmcgdHVubmVsIG1lY2hhbmlzbXMgYW5kIGV4aXN0aW5nIHJvdXRpbmcgcHJvdG9jb2xzLCBi dXQgbmVlZHMgbm8gbmV3IHNwZWMuDQo+Pg0KPj4gREEzPiBJdCBzb3VuZHMgbGlrZSBpdCBhbHNv IG5lZWRzICJleHBlcmllbmNlIiB0byBrbm93IGhvdyB0byB0dW5lIGl0LiANCj4NCj5GaXJzdCwg d2UgYWxyZWFkeSBoYXZlIGEgbG90IG9mIHRoYXQgZXhwZXJpZW5jZSAodGhpcyBpc24ndCBhbnl3 aGVyZSBuZWFyIGEgbmV3IGlzc3VlKS4NCj4NCj5EQTQ+IFNPIEkgdW5kZXJzdGFuZCA6LSkNCj4N Cj5TZWNvbmQsIGF0IGxlYXN0IHlvdSBjYW4gdHVuZSB0aGUgZHluYW1pYyByb3V0aW5nIHZhcmlh bnQuIE1QVENQIGRvZXNuJ3QgaGF2ZSB0aGF0IG9wdGlvbiB1bmxlc3MgeW91IHJld3JpdGUgdGhh dCBzcGVjIHRvby4NCj4NCj5EQTQ+IEFueSBIQSBzb2x1dGlvbiB3aWxsIGhhdmUgcG9saWN5IGFz IHRoZSBlY29ub21pY3Mgb2YgdXNpbmcgZWFjaCBpbnRlcmZhY2UgYXJlIGRpZmZlcmVudC4gU28g Ym90aCBzb2x1dGlvbnMgd2lsbCBoYXZlIG92ZXJhbGwgdmVyeSBzaW1pbGFyIG9wdGlvbnMgd2hl biB0aGUgZHVzdCBzZXR0bGVzLg0KPg0KPj4gQm90aCB0aGVuIG5lZWQgdG8gYmUgZGVwbG95ZWQs IGFuZCB5ZXMgLSB0aGF0J3Mgd29yay4NCj4+DQo+PiBEQTM+IEFncmVlZA0KPj4NCj4+IEhhdmUg YSBnb29kIHdlZWtlbmQNCj4NCj4rMSBhbmQgY2hlZXJzLi4uDQo+DQo+REE0PiBjaGVlcnMgYXMg d2VsbA0KPkRhdmUNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPm11bHRpcGF0aHRjcCBtYWlsaW5nIGxpc3QNCj5tdWx0aXBhdGh0Y3BAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpcGF0aHRjcA0K From nobody Sun Jun 5 12:01:20 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D67F12D17A for ; Sun, 5 Jun 2016 12:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 zMqVRGW7087c for ; Sun, 5 Jun 2016 12:01:16 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381A512D0BF for ; Sun, 5 Jun 2016 12:01:15 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 5 Jun 2016 20:01:11 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sun, 5 Jun 2016 20:01:12 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Jun 2016 20:01:11 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Sun, 5 Jun 2016 20:01:12 +0100 From: To: Thread-Topic: Monday 20th June, 3pm GMT/UTC: MPTCP Interim (audio) Thread-Index: AdG/XJ93qPpNuzSQRNOKURL4/wjh3Q== Date: Sun, 5 Jun 2016 19:01:11 +0000 Message-ID: <4618ac6e12ee49b09c8be29204dba686@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Monday 20th June, 3pm GMT/UTC: MPTCP Interim (audio) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 19:01:18 -0000 The interim will be on Monday 20th June, at 3pm GMT/UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DMPTCP+interim&is= o=3D20160620T15&p1=3D1440&ah=3D1&am=3D30=20 We'll gradually add info at https://trac.tools.ietf.org/wg/mptcp/trac/wiki/= Interim_June_2016 Thanks Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 02 June 2016 09:26 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Interim (audio) - doodle for date Just a reminder, please fill in the doodle as soon as possible, so we can d= ecide a date for this call Thanks Phil & Yoshi. -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 25 May 2016 01:44 To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP Interim (audio) - doodle for date Hi, http://doodle.com/poll/9ne8wz67tdrtxzk2=20 In order to try and make good progress on draft-ietf-mptcp-rfc6824bis, we'd= like to have an interim meeting by audio. The proposal is sometime week of= 20th June. In the past we've found that 3pm GMT/UTC is a reasonable compro= mise for the time (we can adjust this if it isn't a suitable time). Hopeful= ly we can complete the call in less than 1 hour, but we'll book a timeslot = of 1.5 hours. Please fill in the doodle with the dates you can make.=20 The topic for the call will be the proposal for a generic alternative keyin= g mechanism (support for front-end proxies) from Alan F & Christoph P - the= topic has been discussed before, and the detailed proposal will be distrib= uted soon.=20 We believe that this is the only significant functional addition that has = wide-scale interest (ie beyond what's already in the bis doc) (*). Therefor= e our proposal is to hold a WG Last Call on the draft after the interim and= in the period leading up to the IETF. So that we can discuss issues during= the Berlin meeting. Beyond that, our current thinking is that we should ha= ve some implementation before progressing the doc to the IESG (and that exp= erience may of course lead to mods to the doc).=20 (*) one of the things we'll ask in the WGLC is whether people think the doc= does include all the additional functionality that people want. Of course = you can raise things before the wglc.=20 Best wishes, phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jun 5 13:50:27 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0585712D54B for ; Sun, 5 Jun 2016 13:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 wqL-dHxiiFPb for ; Sun, 5 Jun 2016 13:50:25 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 8ECF212D1D1 for ; Sun, 5 Jun 2016 13:50:25 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u55KnYkL025802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 5 Jun 2016 13:49:35 -0700 (PDT) To: David Allan I , "Markus.Brunner3@swisscom.com" References: <836B90ED-2110-4F0F-86CB-7B12C0C4D1E8@swisscom.com> <57506A37.60502@isi.edu> <7262010A-DC38-4BDC-9965-658679D351D9@swisscom.com> <5751BC7B.1050902@isi.edu> <5751E316.4010105@isi.edu> <57520E71.3010903@isi.edu> <575217BC.4090105@isi.edu> From: Joe Touch Message-ID: <5754905B.7000908@isi.edu> Date: Sun, 5 Jun 2016 13:49:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u55KnYkL025802 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "multipathtcp@ietf.org" , "sarikaya@ieee.org" Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 20:50:27 -0000 On 6/3/2016 5:46 PM, David Allan I wrote: > And when I thought I was done for the weekend :-) I've enjoyed the discussion, so just one more :-) > >> >>> They might use a different sort of congestion feedback, one that isn't "TCP-compatible". That's actually desirable here - i.e., having congestion reaction happen over different timescales than TCP. >>> >>> DA2> As the tunnel leg would have a different RTT, would that not be true by definition? >> The difference needs to be on significantly different timescales. Sure, a deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you can't know that for the tunneled traffic. It's safer to run congestion feedback on the tunnel at 10x (or some value bigger than) the largest RTT that can ever occur. >> >> DA3> I think we are talking past each other here. I'm not sure quite what you're arguing other than it is not TCP with the rationale being timescales. IMO the largest RTT that can occur is irrelevant (and I believe you are discussing E2E). And the ratio of E2E to tunnel is also a don't care as near as I can tell. My best guess is you think TCP RTT measurement timescales for the tunnel itself is inadequate. Is that correct? > I think that if the routing algorithm uses TCP timescales to shift and the E2E traffic uses TCP timescales to backoff, the two will interact in bad ways. > > DA4> I can understand that for dissimilar algorithms (like TCP over ATM-ABR). Actually, similar algorithms layered over each other have already been shown to interact in bad ways - for TCP in particular. > When I say "RTT" for the tunnel congestion, I should have been more clear - I'm talking about the timescales on which the traffic load balancing picks different paths. That's not RTT, but it's a similar kind of cycle time. > > DA4> In the context of the solution you've been discussing, there is measurement time, and the arrival rate which can be striped when compared to the delta of individual path latencies. I would have to believe you need to measure that frequently in the context that an ordering guarantee is a single ended function with no redress. There's the measurement time, the time to make a decision, and the hysteresis needed to avoid route flapping. And you can tune each of those independently when you use dynamic routing, but it's not as easily changed for MPTCP. > DA4> That is where I would lean to a double ended function, I can actually offer the guarantee , and can stripe traffic across a greater disparity in path throughput vs. shutting striping down past a certain threshold in disparity. Which when considering how asymmetric DSL is, becomes a rather large benefit IMO. > > ... > >>>> - by recovering from loss, it increases latency and jitter >>>> DA> AFAIK, any loss does that irrespective of the delivery mechanism. In the hybrid access case you are correcting loss with a smaller RTT are you not? >>> You don't need to correct losses for an IP tunnel. You want to reduce their probability, but you definitely don't want to stop the stream and recover. IP is allowed to lose packets. The loss recovery should happen E2E. >>> >>> DA2> unfortunately that sounds like dogma to me. You already have the underlying radio layers correcting loss for the on-air interface portion. >> Some radios do, some do not. Packets are lost in a lot of different places, including routers. >> >> The fact that IP is "best effort" isn't dogma; it's the one of its defining properties. >> DA3> Therefore in your world a link or path that provides a reliable transport service is not allowed. I would say at best you could argue that it is redundant. I'd simply describe it as an artifact of other technical choices. > My view is that tunnel ARQ is an expensive choice and applicable in only a very specialized set of environments. I don't see that sort of specific environment being the intended use case for this approach. > DA4> Well for your approach, yes. As per my summary above > > ... >>> DA2> No IP does not require ordered delivery from the network. But if it was a way of life rather than a rare event it would be a problem. Poorly done striping of traffic across heterogeneous links with very dynamic transfer characteristics would result in a lot of "out of order" receipt to correct. >> First, anything that uses IP and treats misordering as an error is itself broken. IP is best effort and doesn't guarantee in-order delivery. However, as noted, there are mechanisms to reduce the reordering at the egress collection point, esp. for striped paths. >> DA3> It may not treat it as an error, but it does treat it as far more >> DA3> than a minor inconvenience. Ask the vendor whose initial OC-192 >> DA3> interfaces did not provide ordered transmission. (dumb striping >> DA3> across concatenated OC48s) > OC192 provides SONET service, where reordering is not permitted (at least not outside the jitter specified for a connection). > > IP is a different service with different expectations. > > DA4> You missed my point, there was a router that misordered packets and caused much unhappiness. All the deployed blades needed to be replaced IIRC. Yes end systems will tolerate it, but not as a way of life. A system that runs IP but does not tolerate reordering as a "way of life" isn't IP. If there's a cost at any level, it needs to be adapted at the endpoint (install some playout buffers and do local reordering). Expecting in-order delivery should never be a requirement of IP. However, as noted, there are ways to reduce the amount of persistent reordering in multipath routing already. I cited one of them; there are others. ... >> >>> DA2> So for mechanisms that age out assignment of load spreading buckets, that is great for the core. But at the edge with very few flows, and the arrival rate I approaching link rate it strikes me that there is only a fairly narrow range of operation in which I could successfully stripe across all uplinks safely. Is that your take as well? >> The way in which the routing protocols are tuned for core vs edge operation may certainly vary. The routing protocol solution gives you exactly the flexibility to make that decision and adjust as needed. >> >> DA3> I'm not sure why you keep calling it a routing protocol solution when it is simply forwarding and some ongoing supervision to tell you when striping is not a good idea. Sorry I overlooked this one - I call it a routing protocol solution because the routing protocol is the distributed algorithm that detects path properties and decides how to configure forwarding accordingly. That's what routing is. Forwarding is what the router does with incoming packets based on the configuration of its forwarding table based on the routing protocol. (A routing table is the data used by the routing protocol to coordinate the algorithm and derive the forwarding table). >> DA2> Now your original assertion was that for MPTCP, something needed to be invented, whereas for dynamic multipath nothing new was required. From what I have gleaned from this conversation is that both require specification to produce a workable solution. >> >> MPTCP needs a spec to indicate how to tunnel. The existing solution uses existing tunnel mechanisms and existing routing protocols, but needs no new spec. >> >> DA3> It sounds like it also needs "experience" to know how to tune it. > First, we already have a lot of that experience (this isn't anywhere near a new issue). > > DA4> SO I understand :-) > > Second, at least you can tune the dynamic routing variant. MPTCP doesn't have that option unless you rewrite that spec too. > > DA4> Any HA solution will have policy as the economics of using each interface are different. So both solutions will have overall very similar options when the dust settles. Both systems can be extended to have identical capabilities - except for the part about segment boundaries and requiring ARQ stalls to fill in dropped packets that MPTCP incurs - but dynamic routing solutions already have all of these features now. Extending MPTCP to provide those capabilities is just reinventing the wheel. Joe From nobody Tue Jun 7 08:04:33 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8FF12D768 for ; Tue, 7 Jun 2016 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 zQFKLIxTL-G8 for ; Tue, 7 Jun 2016 08:04:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5D812D75A for ; Tue, 7 Jun 2016 08:04:22 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DC1472784B7 for ; Wed, 8 Jun 2016 00:04:20 +0900 (JST) Received: by mail-yw0-f171.google.com with SMTP id o16so172378178ywd.2 for ; Tue, 07 Jun 2016 08:04:20 -0700 (PDT) X-Gm-Message-State: ALyK8tLxsfA74aCZt1aIqLI+p1rLaX1FmIQx1s6vrGCuYzdgkP8SnnDJRT99PVmR+R3XVo2xfD5MBiM9q6CGmQ== X-Received: by 10.129.81.151 with SMTP id f145mr15846749ywb.266.1465311859444; Tue, 07 Jun 2016 08:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Tue, 7 Jun 2016 08:04:19 -0700 (PDT) From: Yoshifumi Nishida Date: Tue, 7 Jun 2016 08:04:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary=001a1145696ade3c120534b180d4 Archived-At: Subject: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:04:31 -0000 --001a1145696ade3c120534b180d4 Content-Type: text/plain; charset=UTF-8 Hello, I might need a bit more time to think about this, but I currently have a few questions on the draft. 1: I am wondering if this is an asymmetric scheme. I mean, if it can be possible to use a token with G flag on one side, while a key without G flag is used on the other side. It seems to me that the draft is a bit unclear on this point, but I am guessing this might be typical for load-balancer use case. I don't see incentive for client to use G flag in this case. 2: How we should react if G and H flags are set in a packet? 3: key-A and key-B in figure 2 might be token-A and token-B? (presume G flag is used) Thanks, -- Yoshi --001a1145696ade3c120534b180d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
I might need a bit more time to think about thi= s, but I currently have a few questions on the draft.

<= div>1: I am wondering if this is an asymmetric scheme. I mean, if it can be= possible to use a token with G flag on one side, while a key without G fla= g is used on the other side. It seems to me that the draft is a bit unclear= on this point, but I am guessing this might be typical for load-balancer u= se case. I don't see incentive for client to use G flag in this case.

2: How we should react if G and H flags are set in = a packet?=C2=A0
=C2=A0=C2=A0
3: key-A and key-B in figu= re 2 might be token-A and token-B? (presume G flag is used)

<= /div>
Thanks,
--
Yoshi

--001a1145696ade3c120534b180d4-- From nobody Tue Jun 7 23:22:34 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FB612D197 for ; Tue, 7 Jun 2016 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.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 8rQ_akTpekT2 for ; Tue, 7 Jun 2016 23:22:31 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E850112D0C8 for ; Tue, 7 Jun 2016 23:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1465366951; x=2329280551; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8aCzkQ6zYRvZmhm5WY+0tCAzki8d8gUltD443c4SUP0=; b=AYHTcHvKONPmW6LxxcG/uhhsU4YrulZvE0rWcETMvM1QNE1TgLRHl7yBi+2YdtCd cqZnvoizSN/nFXXdI1/5KNE7uS9X9fycv7pxes8+6nw6gz6iLqYs23daHt9Gyq/x UtZpR2Edgs46t1T6iLrXJ6p5spM5AP9z5xMOahHx7Wm6JgmVHTEfnG7k3VcroqrG Jv/CDxl8w9myWCltxcFDxZSiQVer9Lz11x0af1nGtpo1ukZW4jZHL3tasaPnMWB0 gneeEmMPtMWXrszrym0J9umiJj4ymf5lEaMCrevvyLkraf/wG5YqT2PLvyPj6ep0 dcAO742CD4ID5efpQDZ1Xg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 43.A3.25552.7A9B7575; Tue, 7 Jun 2016 23:22:31 -0700 (PDT) X-AuditID: 11973e16-f79bc6d0000063d0-ec-5757b9a7ebf3 Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id D2.FA.09064.7A9B7575; Tue, 7 Jun 2016 23:22:31 -0700 (PDT) Received: from [17.149.220.157] (unknown [17.149.220.157]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8F00I09WDIJT70@nwk-mmpp-sz06.apple.com> for multipathtcp@ietf.org; Tue, 07 Jun 2016 23:22:31 -0700 (PDT) Sender: cpaasch@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Christoph Paasch In-reply-to: Date: Tue, 07 Jun 2016 23:22:30 -0700 Content-transfer-encoding: quoted-printable Message-id: <051C927C-9571-429A-89E6-278AAEA2A0B8@apple.com> References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYobt8Z3i4wb8VOhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqPmooJfPBUP7lxha2Bs5+pi5OSQEDCRaJ3UxAphi0lcuLee DcQWEtjLKPHzn30XIwdYzb8+uy5GLqDwciaJnftgaoCcaRfB5ggLSEp037nDDGIzC2hJrN95 nAnE5hXQk5h8tIENoiZM4tijJewgNhtQzdvb7WB7OQWCJbpnPATrZRFQlfixcDEryF5mAWOJ KTONIEZqSzx5d4EVYqSNxIrjm1khTgiQ6OzrA1slArTqw/ePTBCvyEo8ObmIBeRmCYE5bBK7 37xnnMAoMgvJebOQnDcLyY4FjMyrGIVyEzNzdDPzzPUSCwpyUvWS83M3MYICe7qd2A7Gh6us DjEKcDAq8fCe0AsPF2JNLCuuzD3EKM3BoiTOm9QMFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cA42XCWSvoK7eyFp9OC8ldvrv8+a3bMs/BtVxsK11xaJLlBl8nJrjzP6U7yun5LrdXqh5JF 7C/68lic8XzvOIt9prIww5E3eru/289SC2dZIb7zN3PU2Y33+ZyK3FyqVnY5T7CaqhW75NHx tzOqJi2uObV0imFYk8x6eX7XkHtul+KSd2T2fZ2qxFKckWioxVxUnAgAVTA3ik0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUi2FD8Snf5zvBwg/U3VSw+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEfNRQW/eCoe3LnC1sDYztXFyMEhIWAi8a/ProuRE8gUk7hw bz1bFyMXh5DAciaJnftAHE4IZ9pFLhBbWEBSovvOHWYQm1lAS2L9zuNMIDavgJ7E5KMNbBA1 YRLHHi1hB7HZgGre3m5nBbE5BYIlumc8BOtlEVCV+LFwMSvIDcwCxhJTZhpBjNSWePLuAivE SBuJFcc3s0KcECDR2dcHtkoEaNWH7x+ZIG6WlXhychHLBEbBWUgumoXkollIxi5gZF7FKFCU mpNYaaqXWFCQk6qXnJ+7iREcioUROxj/L7M6xCjAwajEw3tCLzxciDWxrLgy9xCjBAezkgjv 3i1AId6UxMqq1KL8+KLSnNTiQ4zJQL9MZJYSTc4HxkleSbyhiYmBibGxmbGxuYk5acJK4rxx J8PChQTSE0tSs1NTC1KLYLYwcXBKNTDmRblHnt1yon5FC4OF9dEZ6zzfXHzrssJIwN/Dvv8o e4j/rIR/cRuzy5V6jvtejt11wztUzqnq3N1Pbc8epBmYyLhOL1ly95xmxO1tS9qONhtos2jy vfrU8K+r71OcTuCLRXaWd+Y9r2r17d/Ymno/aE/rp51/M2u6zZtLDYzdJefM8PJXClJiKc5I NNRiLipOBADRbIkSiQIAAA== Archived-At: Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 06:22:33 -0000 Hello Yoshifumi, > On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida = wrote: > 1: I am wondering if this is an asymmetric scheme. I mean, if it can = be possible to use a token with G flag on one side, while a key without = G flag is used on the other side. It seems to me that the draft is a bit = unclear on this point, but I am guessing this might be typical for = load-balancer use case. I don't see incentive for client to use G flag = in this case. it was intended to be an asymmetric scheme. I agree that the use of the = G-bit is not very clear in the draft. The way I see it is that the client signals to the server its = capabilities. It may thus set the G and the H bit at the same time. The = server then chooses which mode it uses and thus should only reply in the = SYN/ACK with one of the bits set. We will clarify this in the draft. > 2: How we should react if G and H flags are set in a packet?=20 See above. > 3: key-A and key-B in figure 2 might be token-A and token-B? (presume = G flag is used) When the G-flag was set in the MP_CAPABLE-handshake, key-A and key-B in = Figure 2 are the keys provided by the application. If the H-flag however is set in the handshake, key-A and key-B are the = ones used in the MP_CAPABLE handshake. We do fallback to the "regular" = MPTCP handshake in case the H-flag is set. Does this answers your question? Cheers, Christoph >=20 > Thanks, > -- > Yoshi >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jun 8 01:08:09 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523CA12D1EA for ; Wed, 8 Jun 2016 01:08:08 -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 Hv4E-RiCGSms for ; Wed, 8 Jun 2016 01:08:06 -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 8E1E312D1E3 for ; Wed, 8 Jun 2016 01:08:06 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id x189so498830ywe.3 for ; Wed, 08 Jun 2016 01:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JyBamfxVuaUzvwbzOeCOyKnWzbshWrLwMYAOjBKJUj4=; b=0+WYPHthKO5VScQVciXSIs1lFW8oQdL1CpSlSH783OYZF/DBIoSu3nOkNzEuQ6pp5/ IovLhNalu5GqYzpONEffhXTaJlTPsARbL5MKk7LSLuCvMwF/bDVtcj/7O+lM+tQHO48n dyFmEESaLaakkBBxPhHDxwLlFqAH5HCRHNWr9HRedzv3neNdJM03/hK6RBwaMyk4ZQnz d11tKlARnf8AjwlBwAtoac88DzY12sTqhH5cqvNFbLnbnGOl+OzemClP8HKqdSh29y1f lPiKb1EzTyEXRgXTPoa/Bpi+EHG60SQtoH+ts1ez41Aa+sHYhCHFecTh5jwQnhsN45Pz TqnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JyBamfxVuaUzvwbzOeCOyKnWzbshWrLwMYAOjBKJUj4=; b=jrRD+pzAuL1gosQzNg7xXjnH/ZZhWd3pz1uP35waIZcbGeGgmHdGmnWzhPouRxG9Yu dwMjir8ITmZfSGxoeuDDbfgEy4Py6YKD3meTyebRFSFxSDS7/7jGYp6ut2OnZUisUgfd fzdaYeckwdWSegQoXhWjwQ12/67XecGJyW2rgDYMcykvjHNVVwv4zuAETeozzPlgguCZ XIkTWdW2IBWBVxMqdnNaJ9mDOG4tSdv7AsIh3u0enBWibh8EwF6Z6ayojdQ2pbAB1pW7 xCcafceH/Wfz1EFpq40guRzgUZa/xk3R7/e7Fwvu5rPsmE80Ctfaj/z0gobbPdv59Ges R+bg== X-Gm-Message-State: ALyK8tIgHmCcWMatXV2MNZUSLRlKzEyjL+1y4NPLwmZmPbUpXoFbeUYM9kBvODaCXY+ldypdZEhPmdxWz9Pjlw== X-Received: by 10.129.48.205 with SMTP id w196mr1245493yww.266.1465373285741; Wed, 08 Jun 2016 01:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.11 with HTTP; Wed, 8 Jun 2016 01:08:05 -0700 (PDT) In-Reply-To: <051C927C-9571-429A-89E6-278AAEA2A0B8@apple.com> References: <051C927C-9571-429A-89E6-278AAEA2A0B8@apple.com> From: Alan Ford Date: Wed, 8 Jun 2016 09:08:05 +0100 Message-ID: To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a113f4c0a28fa3e0534bfce07 Archived-At: Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:08:08 -0000 --001a113f4c0a28fa3e0534bfce07 Content-Type: text/plain; charset=UTF-8 The rfc6824bis draft already lays the groundwork for negotiating crypto capabilities: For crypto negotiation, the responder has the choice. The initiator creates a proposal setting a bit for each algorithm it supports to 1 (in this version of the specification, there is only one proposal, so bit "H" will be always set to 1). The responder responds with only 1 bit set -- this is the chosen algorithm. We are just making use of this! Regards, Alan On 8 June 2016 at 07:22, Christoph Paasch wrote: > Hello Yoshifumi, > > > On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida > wrote: > > 1: I am wondering if this is an asymmetric scheme. I mean, if it can be > possible to use a token with G flag on one side, while a key without G flag > is used on the other side. It seems to me that the draft is a bit unclear > on this point, but I am guessing this might be typical for load-balancer > use case. I don't see incentive for client to use G flag in this case. > > it was intended to be an asymmetric scheme. I agree that the use of the > G-bit is not very clear in the draft. > > The way I see it is that the client signals to the server its > capabilities. It may thus set the G and the H bit at the same time. The > server then chooses which mode it uses and thus should only reply in the > SYN/ACK with one of the bits set. > > We will clarify this in the draft. > > > 2: How we should react if G and H flags are set in a packet? > > See above. > > > 3: key-A and key-B in figure 2 might be token-A and token-B? (presume G > flag is used) > > When the G-flag was set in the MP_CAPABLE-handshake, key-A and key-B in > Figure 2 are the keys provided by the application. > > If the H-flag however is set in the handshake, key-A and key-B are the > ones used in the MP_CAPABLE handshake. We do fallback to the "regular" > MPTCP handshake in case the H-flag is set. > > Does this answers your question? > > > Cheers, > Christoph > > > > > > Thanks, > > -- > > Yoshi > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a113f4c0a28fa3e0534bfce07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The rfc6824bis draft already lays the groundwork for negot= iating crypto capabilities:

   For crypt=
o negotiation, the responder has the choice.  The initiator
   creates a proposal setting a bit for each algorithm it supports to 1
   (in this version of the specification, there is only one proposal, so
   bit "H" will be always set to 1).  The responder responds with=
 only 1
   bit set -- this is the chosen algorithm.

We are just making use of this!

Regards,
Alan

On 8 June 2016 at 07:22, Christoph Paasch <cpaasch@apple.com> wrote:
Hello Yoshifumi,

> On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> 1: I am wondering if this is an asymmetric scheme. I mean, if it can b= e possible to use a token with G flag on one side, while a key without G fl= ag is used on the other side. It seems to me that the draft is a bit unclea= r on this point, but I am guessing this might be typical for load-balancer = use case. I don't see incentive for client to use G flag in this case.<= br>
it was intended to be an asymmetric scheme. I agree that the use of = the G-bit is not very clear in the draft.

The way I see it is that the client signals to the server its capabilities.= It may thus set the G and the H bit at the same time. The server then choo= ses which mode it uses and thus should only reply in the SYN/ACK with one o= f the bits set.

We will clarify this in the draft.

> 2: How we should react if G and H flags are set in a packet?

See above.

> 3: key-A and key-B in figure 2 might be token-A and token-B? (presume = G flag is used)

When the G-flag was set in the MP_CAPABLE-handshake, key-A and key-B= in Figure 2 are the keys provided by the application.

If the H-flag however is set in the handshake, key-A and key-B are the ones= used in the MP_CAPABLE handshake. We do fallback to the "regular"= ; MPTCP handshake in case the H-flag is set.

Does this answers your question?


Cheers,
Christoph


>
> Thanks,
> --
> Yoshi
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipa= thtcp

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

--001a113f4c0a28fa3e0534bfce07-- From nobody Wed Jun 8 02:54:04 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01E612B030 for ; Wed, 8 Jun 2016 02:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 NUjaDlnmNVZS for ; Wed, 8 Jun 2016 02:54:00 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E64C12D0E8 for ; Wed, 8 Jun 2016 02:54:00 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Jun 2016 10:53:54 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 8 Jun 2016 10:53:57 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Jun 2016 10:53:57 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Wed, 8 Jun 2016 10:53:57 +0100 From: To: , Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS1bDzuVHfTNEiIoWcFbf0dcp/fXGCQ Date: Wed, 8 Jun 2016 09:53:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 09:54:03 -0000 I believe you're right that such work would be outside the charter. We're hoping (if we get 2 sessions) in Berlin to have some discussion about= potential re-chartering. In practice we haven't managed to get much work f= ocussed specifically on meeting the current charter item on proxy (there wa= s some individual drafts a while back) - but there seems to be quite a bit = of industry work on proxies (beyond charter's single-ended proxy). So poten= tial discussion topic=20 >From my perspective there seems to be some operator interest in hybrid. See= for instance the discussions in banana bar-bofs we've had at last couple o= f ietfs - including description of the DT deployment. (note, not all hybrid= solutions use mptcp) Best wishes phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Behc= et Sarikaya Sent: 01 June 2016 19:38 To: multipathtcp@ietf.org Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Hi all, Recent mails in this thread came to my attention because I work on the hybr= id access network issues and wish to convey my views on some of the issues = discussed. First of all, the claims that there is strong operator interest on this is = over blown. Hybrid access is based on offloading some CPE traffic to 3G/LTE= network, I don't think mobile operators are fond of such a thing. Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP into= MPTCP and requires Concentrators to convert back MPTCP into UDP or TCP is = a complex process. The crux of this is the problems arising from the use of= MPTCP for tunneling, which is what this draft is advocating. Here I recommend Joe Touch's Intarea draft https://tools.ietf.org/id/draft-= ietf-intarea-tunnels-02.txt on IP Tunnels in the Internet Architecture. IETF developed many tunneling p= rotocols which are surveyed in this draft but none of them are TCP/MPTCP ba= sed. I also question suitability of this work to the charter. There is this char= ter text: Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues. This draft has a middlebox called Concentrator but it is not trying to enab= le MPTCP hosts to communicate with TCP hosts, it is just tunneling the traf= fic. So there is no charter item that fits to this draft. I strongly suggest staying away from making MPTCP a tunneling protocol. Regards, Behcet _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 9 02:15:17 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB75212D10B for ; Thu, 9 Jun 2016 02:15:15 -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, 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 yc_QoBxSIKUW for ; Thu, 9 Jun 2016 02:15:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C912712D0AC for ; Thu, 9 Jun 2016 02:15:13 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7E4A1264447; Thu, 9 Jun 2016 11:15:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 525CD27C064; Thu, 9 Jun 2016 11:15:12 +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.0294.000; Thu, 9 Jun 2016 11:15:12 +0200 From: To: "philip.eardley@bt.com" , "sarikaya@ieee.org" , "multipathtcp@ietf.org" Thread-Topic: (re-)charter discussion (RE: [multipathtcp] draft-boucadair-mptcp-plain-mode-07) Thread-Index: AdHCL2wiVzPXhj9XTR6AlCMNlpwvHg== Date: Thu, 9 Jun 2016 09:15:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DAF4FC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.7.90315 Archived-At: Subject: [multipathtcp] (re-)charter discussion (RE: draft-boucadair-mptcp-plain-mode-07) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:15:16 -0000 Hi Phil,=20 A proxy is always single-ended: that is, it transforms an MPTCP connection = into an TCP connection, and vice versa. Does it really matter if the MPTCP = peer is a CPE or a host directly connected to an operator network? IMHO, the key word in the charter is "helping MPTCP's incremental deploymen= t" which is a goal of the plain mode specification. I do agree that the UDP part of the discussion is not covered by the charte= r.=20 Is there any chance to initiate the re-chartering discussion prior to the m= eeting? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > philip.eardley@bt.com > Envoy=E9=A0: mercredi 8 juin 2016 11:54 > =C0=A0: sarikaya@ieee.org; multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > I believe you're right that such work would be outside the charter. >=20 > We're hoping (if we get 2 sessions) in Berlin to have some discussion > about potential re-chartering. In practice we haven't managed to get much > work focussed specifically on meeting the current charter item on proxy > (there was some individual drafts a while back) - but there seems to be > quite a bit of industry work on proxies (beyond charter's single-ended > proxy). So potential discussion topic >=20 > >From my perspective there seems to be some operator interest in hybrid. > See for instance the discussions in banana bar-bofs we've had at last > couple of ietfs - including description of the DT deployment. (note, not > all hybrid solutions use mptcp) >=20 > Best wishes > phil >=20 > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: 01 June 2016 19:38 > To: multipathtcp@ietf.org > Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > Hi all, >=20 > Recent mails in this thread came to my attention because I work on the > hybrid access network issues and wish to convey my views on some of the > issues discussed. >=20 > First of all, the claims that there is strong operator interest on this i= s > over blown. Hybrid access is based on offloading some CPE traffic to > 3G/LTE network, I don't think mobile operators are fond of such a thing. >=20 > Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP > into MPTCP and requires Concentrators to convert back MPTCP into UDP or > TCP is a complex process. The crux of this is the problems arising from > the use of MPTCP for tunneling, which is what this draft is advocating. >=20 > Here I recommend Joe Touch's Intarea draft > https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt > on IP Tunnels in the Internet Architecture. IETF developed many tunneling > protocols which are surveyed in this draft but none of them are TCP/MPTCP > based. > I also question suitability of this work to the charter. There is this > charter text: > Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is MPTCP-enabled= . > For example, potentially helping MPTCP's incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts a= s > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what rea= l > problems an MPTCP-enabled middlebox might solve, how it would impact th= e > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, an= d > the likely feasibility of solving the technical and security issues. >=20 > This draft has a middlebox called Concentrator but it is not trying to > enable MPTCP hosts to communicate with TCP hosts, it is just tunneling th= e > traffic. So there is no charter item that fits to this draft. > I strongly suggest staying away from making MPTCP a tunneling protocol. >=20 > Regards, >=20 > Behcet >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 9 23:46:39 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12A012D94A for ; Thu, 9 Jun 2016 23:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 NDuV85KDZiof for ; Thu, 9 Jun 2016 23:46:35 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A2312D529 for ; Thu, 9 Jun 2016 23:46:34 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D4FD52783A4 for ; Fri, 10 Jun 2016 15:46:32 +0900 (JST) Received: by mail-yw0-f179.google.com with SMTP id c72so58574837ywb.1 for ; Thu, 09 Jun 2016 23:46:32 -0700 (PDT) X-Gm-Message-State: ALyK8tKUmCd2NIuUJQ/xW5SjrwDgPvi3ZvMxnFtH7ZkwYCA3qiBVH8oHQjpLSHTu2fGukPsaCbYhbQMEBFXwsA== X-Received: by 10.129.48.147 with SMTP id w141mr198042yww.266.1465541191380; Thu, 09 Jun 2016 23:46:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Thu, 9 Jun 2016 23:46:30 -0700 (PDT) In-Reply-To: <051C927C-9571-429A-89E6-278AAEA2A0B8@apple.com> References: <051C927C-9571-429A-89E6-278AAEA2A0B8@apple.com> From: Yoshifumi Nishida Date: Thu, 9 Jun 2016 23:46:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a114086741db6ec0534e6e688 Archived-At: Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 06:46:38 -0000 --001a114086741db6ec0534e6e688 Content-Type: text/plain; charset=UTF-8 Hi Christoph, On Tue, Jun 7, 2016 at 11:22 PM, Christoph Paasch wrote: > Hello Yoshifumi, > > > On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida > wrote: > > 1: I am wondering if this is an asymmetric scheme. I mean, if it can be > possible to use a token with G flag on one side, while a key without G flag > is used on the other side. It seems to me that the draft is a bit unclear > on this point, but I am guessing this might be typical for load-balancer > use case. I don't see incentive for client to use G flag in this case. > > it was intended to be an asymmetric scheme. I agree that the use of the > G-bit is not very clear in the draft. > > The way I see it is that the client signals to the server its > capabilities. It may thus set the G and the H bit at the same time. The > server then chooses which mode it uses and thus should only reply in the > SYN/ACK with one of the bits set. > > We will clarify this in the draft. > Thanks for the clarification. I got it. I was thinking about something like the followings, that's why I asked if it's an asymmetric. Host A Host B ---------------------- ---------- Address A1 Address B1 ---------- ---------- | | | SYN + MP_CAPABLE (H flag) | |--------------------------------------------->| |<---------------------------------------------| | SYN/ACK + MP_CAPABLE(token-B,G flag) | | | | ACK + MP_CAPABLE(Key-A, token-B,H flag) | |--------------------------------------------->| ---------- Address A2 ---------- | | | | | SYN + MP_JOIN(Token-B, R-A) | | |------------------------------->| | |<-------------------------------| | | SYN/ACK + MP_JOIN(HMAC-B, R-B) | | | | | | ACK + MP_JOIN(HMAC-A) | | |------------------------------->| | |<-------------------------------| | | ACK | HMAC-A = HMAC(Key=(Key-A+ (Token-B or B'), Msg=(R-A+R-B)) HMAC-B = HMAC(Key=(Token-B or B' +Key-A), Msg=(R-B+R-A)) You might think this is ridiculous or problematic, but I was just thinking about load-balancer use case and curious about the possibility. >From host A's point of view, it probably doesn't know whether host B is behind a balancer or not. So, I thought host A is less motivated to upgrade the application in order to support load balancer. You might presume host A will upgrade the app for TLS or some other reasons, but I thought it might not be always true. > > 2: How we should react if G and H flags are set in a packet? > > See above. > Sorry. This is minor thing, but I thought you might want to describe how to react when you see G and H are set in SYN/ACK or ACK. Thanks, -- Yoshi --001a114086741db6ec0534e6e688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

On Tue, Jun 7, 2016 at 11:22 PM, Christoph Paasch <cpaasc= h@apple.com> wrote:
Hello Yoshifumi,

> On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrot= e:
> 1: I am wondering if this is an asymmetric scheme. I mean, if it can b= e possible to use a token with G flag on one side, while a key without G fl= ag is used on the other side. It seems to me that the draft is a bit unclea= r on this point, but I am guessing this might be typical for load-balancer = use case. I don't see incentive for client to use G flag in this case.<= br>
it was intended to be an asymmetric scheme. I agree that the use of = the G-bit is not very clear in the draft.

The way I see it is that the client signals to the server its capabilities.= It may thus set the G and the H bit at the same time. The server then choo= ses which mode it uses and thus should only reply in the SYN/ACK with one o= f the bits set.

We will clarify this in the draft.

Than= ks for the clarification. I got it.=C2=A0
I was thinking about so= mething like the followings, that's why I asked if it's an asymmetr= ic.

             Host A                =
                                                                       Host=
 B
     ----------------------            =
          ----------
     Address A1                                   Address B1
     ----------                                  ----------
         |                                              |
         |            SYN + MP_CAPABLE (H flag)         |
         |--------------------------------------------->|
         |<---------------------------------------------|
         |       SYN/ACK + MP_CAPABLE(token-B,G flag)   |
         |                                              |
         |     ACK + MP_CAPABLE(Key-A, token-B,H flag)  |
         |--------------------------------------------->|
   =C2=A0

                  --------=
--                               
                  Address A2
                  ----------              =
          
         |             |    =
                            |
         |             |   SYN + MP_JOIN(Token-B, R-A)  |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
         |             |                                |
         |             |     ACK + MP_JOIN(HMAC-A)      |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             |             ACK                |

   HMAC-A =3D HMAC(Key=3D(Key-A+ =
(Token-B or B'), Msg=3D(R-A+R-B))
   HMAC-B =3D HMAC(Key=3D(Token-B or B' +Key-A), Msg=3D(R-B+R-A))
=

You might think this is ridiculous or problematic= , but I was just thinking about load-balancer use case and curious about th= e possibility.
From host A's point of view, it probably doesn= 't know whether host B is behind a balancer or not.
So, I tho= ught host A is less motivated to upgrade the application in order to suppor= t load balancer.
You might presume host A will upgrade the app fo= r TLS or some other reasons, but I thought it might not be always true.

=C2=A0
> 2: How we should react if G and H flags are set in a packet?

See above.

Sorry. This is minor = thing, but I thought you might want to describe how to react when you see G= and H are set in SYN/ACK or ACK.

Thanks,
--
Yoshi
--001a114086741db6ec0534e6e688-- From nobody Wed Jun 15 14:03:27 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F412D8E1; Wed, 15 Jun 2016 14:03:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615210325.26233.67071.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 14:03:25 -0700 Archived-At: Cc: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP WG Virtual Interim Meeting: 20 June 2016 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:03:26 -0000 The Multipath TCP (mptcp) will hold a virtual interim meeting on Monday, 20 June 2016 at 1500 UTC. Monday, 20 June 2016 15:00 | Greenwich Time (Reykjavik, GMT) | 2 hrs Meeting number (access code): 640 977 925 Meeting password: 6mpBVCz3 Add to Calendar When it's time, join the meeting . *Join by phone* *1-877-668-4493* Call-in toll free number (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) Toll-free calling restrictions Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Fri Jun 17 08:14:56 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C7D12D6B1; Fri, 17 Jun 2016 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 LTS-DWBt64fz; Fri, 17 Jun 2016 08:14:48 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6362A12D0FC; Fri, 17 Jun 2016 08:14:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D661CD9305; Fri, 17 Jun 2016 17:14:46 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xUszh1qyMsvF; Fri, 17 Jun 2016 17:14:46 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 89620D9304; Fri, 17 Jun 2016 17:14:46 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> Date: Fri, 17 Jun 2016 17:14:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch> References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> To: Alan Ford X-Mailer: Apple Mail (2.3124) Archived-At: Cc: multipathtcp , tcpinc Subject: Re: [multipathtcp] MPTCP external auth drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:14:51 -0000 Hi Alan, adding tcpinc. How does this relate to working tcpinc? Mirja > Am 28.05.2016 um 10:32 schrieb Alan Ford : >=20 > Hi all, >=20 > Following on from the discussion at the previous two IETFs, we have = submitted two drafts proposing a way forward for resolving the = loadbalancers issue (or in other words, separating tokens and keys), and = in turn have a proposal for using TLS keying material with MPTCP. >=20 > This proposal comes in the form of two drafts, to separate protocol = changes (which we would be proposing for adoption into rfc6824bis), and = TLS-specific extensions (which we would suggest are kept separate). >=20 > The protocol changes = (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.t= xt) propose an additional handshake mechanism to be negotiated in the = MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This = means that MPTCP queries the application layer for Token and Key = materials. This is negotiated by being offered by the initiator, and = chosen by the answerer. >=20 > Only tokens are sent on the wire, and these can be used to contain any = information that could assist a far end to demultiplex connections (e.g. = including routing data which would help front-end proxies). >=20 > Minor changes that fall out of this also mean the IDSN, in that = scenario, would be generated from the Token not the Key. >=20 > Keying information may not be available at the SYN/ACK exchange, but = will be provided by the application when available. Only once that has = occurred can subflow setup continue. >=20 > The TLS draft = (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) = shows how we can interface this proposal with TLS, using RFC5705 key = export from TLS. This requires no changes to the protocol, but would = register a new RFC5705 exporter with IANA. Exported keys from a TLS = session would be passed to the MPTCP layer and used in the HMAC = authentication algorithm. >=20 > We would like to present and discuss these points in the upcoming = interim, to see if there is consensus to add the necessary protocol = changes to rfc6824bis. >=20 > Best regards, > Alan & Christoph > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jun 19 14:55:40 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0BB12D842 for ; Sun, 19 Jun 2016 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 txdTxXugI1Ah for ; Sun, 19 Jun 2016 14:55:36 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A10312D84C for ; Sun, 19 Jun 2016 14:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1466373335; x=2330286935; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OHa/qeDVJLvzQ8anjr9BlzznLV2QHvrTEh92AR5sWFg=; b=V0WN8YL315BpJlejbvX5vcfLeursQxYfuXNsxeHpvbh1OmJ1A3lPyChKaB8OkcAz 6xu1AMxo0cPm4Yeax2aCnvHbe1zDMbdrylEj1w6nQWFjPY+nfSp2lwJG23nRVbgE AHCLOizMm2TSJxqfLHdvGKnnCsO4psli5dIrqPimy9G96z/ttPxh/aS4OIDdQPst mDm6hRl2K+fEQIEGTsqsxb+g6Ch6SueL6QuYocNZMh5DOH6gxKH4J4TyHqFVPyHR pWzOLtxbUlumRHNDSUEhR064xEDQA/MIfiOGproWqfkJNNvqoRrBH8iCMPagfTju wkDvYqt1YUhw68ORLd2woQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 69.BF.18746.7D417675; Sun, 19 Jun 2016 14:55:35 -0700 (PDT) X-AuditID: 11973e15-f79436d00000493a-49-576714d74b96 Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 8F.43.12923.7D417675; Sun, 19 Jun 2016 14:55:35 -0700 (PDT) Received: from [17.149.220.208] (unknown [17.149.220.208]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9100382GWMJY50@nwk-mmpp-sz08.apple.com>; Sun, 19 Jun 2016 14:55:35 -0700 (PDT) Sender: cpaasch@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Christoph Paasch In-reply-to: <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch> Date: Sun, 19 Jun 2016 14:55:34 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUi2FAYrHtdJD3c4OJLYYvPq6+zWUw9fJHd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZJ79tYy44LF5x5ccLpgbGTcJdjJwcEgImEu1XXrBB 2GISF+6tB7K5OIQE9jJKfL/7k7GLkQOs6Mz5Koj4MiaJrTNOskA4vUwSa1/dYQLpFhaQlOi+ c4cZpIFZQF1iypRckDCvgJ7E5KMNbBAl9hKtew+BlbMJaEm8vd3OCmJzCjhJfHx6DMxmEVCV mP/kPguIzSxQIPGn8wYbhK0t8eTdBVaImTYSfx/tBYsLCZRIvFs3gxHEFhFwk/hy6SnUM7IS T04uArtTQmANm8SSkw9YJzCKzEI4bxaS82YhWbGAkXkVo1BuYmaObmaemV5iQUFOql5yfu4m RlCYT7cT3cF4ZpXVIUYBDkYlHt4J59PChVgTy4orcw8xSnOwKInznnsNFBJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYEPLMh5chNGaHkTJXf0yG/Wqx5fkM//X/LprMd/Ot5Wmj/UE/WLcX nDF6IKC5r/3bpzN8OybPa3mZ+vlhpZ7FqpIuce8di65U77Of89jq/hVT2wmhq41VXxsUbr/H H92aI7n5HLPs00mPdp2IXzrhbzo3c8KzH74WG8/+E5zqMUXqUNDj5sxsJZbijERDLeai4kQA NLWfM1QCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FAsqXtdJD3cYNEXfovPq6+zWUw9fJHd gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZJ79tYy44LF5x5ccLpgbGTcJdjBwcEgImEmfOV3Ux cgKZYhIX7q1n62Lk4hASWMYksXXGSRYIp5dJYu2rO0wgVcICkhLdd+4wgzQzC6hLTJmSCxLm FdCTmHy0gQ2ixF6ide8hsHI2AS2Jt7fbWUFsTgEniY9Pj4HZLAKqEvOf3GcBsZkFCiT+dN5g g7C1JZ68u8AKMdNG4u+jvWBxIYESiXfrZjCC2CICbhJfLj1lgzhaVuLJyUUsExgFZyFcNAvJ RbOQTF3AyLyKUaAoNSex0lgvsaAgJ1UvOT93EyM4LAuDdzD+WWZ1iFGAg1GJh9fibFq4EGti WXFl7iFGCQ5mJRFeJ2BQC/GmJFZWpRblxxeV5qQWH2JMBvplIrOUaHI+MGbySuINTUwMTIyN zYyNzU3MSRNWEued750YLiSQnliSmp2aWpBaBLOFiYNTqoEx8ydfvvFu3u1mW+e9uSJcJffI RDh7dQXjitWSMxft/7DB9Ksxh02A2KQjv3yDuU11uaVW6EZedPacfzBwU5aa/IfmoAtPfx/b b9ShobVacxGfqccPi6dzq1dPaFcpLX15ZFn37f2n+/7HGkou4bjddutRR7LMgcP/BK9msWlN NPywYYGl+6S5SizFGYmGWsxFxYkAV2QaD48CAAA= Archived-At: Cc: MultiPath TCP - IETF WG , tcpinc Subject: Re: [multipathtcp] [tcpinc] MPTCP external auth drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 21:55:37 -0000 Hello Mirja, > On Jun 17, 2016, at 8:14 AM, Mirja K=C3=BChlewind = wrote: > adding tcpinc. How does this relate to working tcpinc? in a tcpinc-deployment, MPTCP could use a derivate of tcpinc's key to = authenticate new subflows. A draft similar to = http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt = would need to describe how the MPTCP-key is derived from the = tcpinc-secret. Christoph >=20 > Mirja >=20 >=20 >> Am 28.05.2016 um 10:32 schrieb Alan Ford : >>=20 >> Hi all, >>=20 >> Following on from the discussion at the previous two IETFs, we have = submitted two drafts proposing a way forward for resolving the = loadbalancers issue (or in other words, separating tokens and keys), and = in turn have a proposal for using TLS keying material with MPTCP. >>=20 >> This proposal comes in the form of two drafts, to separate protocol = changes (which we would be proposing for adoption into rfc6824bis), and = TLS-specific extensions (which we would suggest are kept separate). >>=20 >> The protocol changes = (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.t= xt) propose an additional handshake mechanism to be negotiated in the = MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This = means that MPTCP queries the application layer for Token and Key = materials. This is negotiated by being offered by the initiator, and = chosen by the answerer. >>=20 >> Only tokens are sent on the wire, and these can be used to contain = any information that could assist a far end to demultiplex connections = (e.g. including routing data which would help front-end proxies). >>=20 >> Minor changes that fall out of this also mean the IDSN, in that = scenario, would be generated from the Token not the Key. >>=20 >> Keying information may not be available at the SYN/ACK exchange, but = will be provided by the application when available. Only once that has = occurred can subflow setup continue. >>=20 >> The TLS draft = (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) = shows how we can interface this proposal with TLS, using RFC5705 key = export from TLS. This requires no changes to the protocol, but would = register a new RFC5705 exporter with IANA. Exported keys from a TLS = session would be passed to the MPTCP layer and used in the HMAC = authentication algorithm. >>=20 >> We would like to present and discuss these points in the upcoming = interim, to see if there is consensus to add the necessary protocol = changes to rfc6824bis. >>=20 >> Best regards, >> Alan & Christoph >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc From nobody Mon Jun 20 02:14:29 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD212B04D for ; Mon, 20 Jun 2016 02:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 y-sSqVQujikK for ; Mon, 20 Jun 2016 02:14:25 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC1D12B035 for ; Mon, 20 Jun 2016 02:14:24 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 10:14:18 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 20 Jun 2016 10:14:22 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 20 Jun 2016 10:14:21 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 20 Jun 2016 10:14:21 +0100 From: To: Thread-Topic: REMINDER: TODAY: [multipathtcp] MPTCP WG Virtual Interim Meeting: 20 June 2016 Thread-Index: AdHK06l3TVaatdI7QIWWlUIOycucZA== Date: Mon, 20 Jun 2016 09:14:20 +0000 Message-ID: <498b9ee32afe4f8b8b82e30fd86d339e@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] REMINDER: TODAY: MPTCP WG Virtual Interim Meeting: 20 June 2016 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 09:14:28 -0000 A reminder that we have our interim later today (3pm GMT, 4pm BST, 5pm CEST= etc) As you know the topic of the interim meeting is how to support load balance= rs. We've got 3 relevant items to discuss: * a more generic proposal to separate keys & tokens, from Alan & Christoph = https://mailarchive.ietf.org/arch/msg/multipathtcp/4lgoBI3gfdu8bui9RYAkF279= y2M (includes pointer to I-Ds) * a proposal from Costin, which doesn't change the protocol https://mailarc= hive.ietf.org/arch/msg/multipathtcp/r5rffL3G93a64Xj3Gb43hT2gYYE (includes p= ointer to paper - idea enhanced since then) * an proposal from Olivier Bonaventure (no draft, abstract below) We need a volunteer to take some notes please. Please note that the audio will be recorded=20 Slides being added to https://datatracker.ietf.org/meeting/interim-2016-mpt= cp-1/session/mptcp/ as we get them. Also, we're trying got add material to = the wiki https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_June_2016 (but = currently having login issues) Thanks Phil & Yoshi. - Absrtact from Olivier There are many situations where Multipath TCP clients and servers cannot ac= cept the establishment of additional subflows over the address used to crea= te the initial subflow. For clients, this occurs typically when they are be= hind a NAT or firewall. For servers, this occurs typically when they are be= hind a load balancers. In these situations, it is beneficial for the affect= ed host to be able to inform the other host of the restriction on the reach= ablity of their primary address. We propose to reserve one bit to encode th= is information in the MP_CAPABLE option and show how load balancers can exp= loit this new feature. -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of IESG= Secretary Sent: 15 June 2016 22:03 To: IETF Announcement List Cc: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP WG Virtual Interim Meeting: 20 June 2016 The Multipath TCP (mptcp) will hold a virtual interim meeting on Monday, 20 June 2016 at 1500 UTC. Monday, 20 June 2016 15:00 | Greenwich Time (Reykjavik, GMT) | 2 hrs Meeting number (access code= ): 640 977 925 Meeting password: 6mpBVCz3 Add to Calendar When it's time, join the meeting . *Join by phone* *1-877-668-4493* Call-in toll free number (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada) Toll-free calling restrict= ions Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Jun 20 02:16:45 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A509612B04D for ; Mon, 20 Jun 2016 02:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 KBnBGzHyd_Om for ; Mon, 20 Jun 2016 02:16:42 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2118C12B035 for ; Mon, 20 Jun 2016 02:16:42 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 10:16:36 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 20 Jun 2016 10:16:40 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 20 Jun 2016 10:16:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 20 Jun 2016 10:16:39 +0100 From: To: Thread-Topic: Interest in hackathon in Berlin? Thread-Index: AdHK1DXOkxQUk8NTSHiiZodM9jIEGQ== Date: Mon, 20 Jun 2016 09:16:38 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_ecdc8147d12c4c35b868ec0e949274f7rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Interest in hackathon in Berlin? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 09:16:43 -0000 --_000_ecdc8147d12c4c35b868ec0e949274f7rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Berlin IETF meeting, there's a hackathon on the first weekend - is t= here any interest in doing something with MPTCP at this? https://www.ietf.org/hackathon/96-hackathon.html --_000_ecdc8147d12c4c35b868ec0e949274f7rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Berlin IETF meeting, there’s a hackathon on the first= weekend – is there any interest in doing something with MPTCP at thi= s?

https://www.ietf.org/hack= athon/96-hackathon.html

 

--_000_ecdc8147d12c4c35b868ec0e949274f7rew09926dag03bdomain1sy_-- From nobody Mon Jun 20 02:20:01 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21A12D597 for ; Mon, 20 Jun 2016 02:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 mn4g13AtEGLV for ; Mon, 20 Jun 2016 02:19:57 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F95412D189 for ; Mon, 20 Jun 2016 02:19:57 -0700 (PDT) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 10:19:50 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 20 Jun 2016 10:19:53 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 20 Jun 2016 10:19:53 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 20 Jun 2016 10:19:53 +0100 From: To: Thread-Topic: MPTCP session: Call for Participation: ACM, IRTF & ISOC Applied Networking Research Workshop 2016 Thread-Index: AdHK1KIfZ8H0CoppRdq1YtICYnvExg== Date: Mon, 20 Jun 2016 09:19:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] MPTCP session: Call for Participation: ACM, IRTF & ISOC Applied Networking Research Workshop 2016 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 09:19:59 -0000 Tm90ZSB0aGF0IHRoaXMgcmVzZWFyY2ggd29ya3Nob3AgaGFzIHNldmVyYWwgcGFwZXJzIHJlbGF0 ZWQgdG8gTVBUQ1AgLSBpdCdzIG9uIHRoZSBTYXR1cmRheSBiZWZvcmUgdGhlIElFVEYgKGluIHRo ZSBzYW1lIHZlbnVlKQ0KDQpCZXN0IHdpc2hlcw0KcGhpbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiA5NmF0dGVuZGVlcyBbbWFpbHRvOjk2YXR0ZW5kZWVzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFZ2dlcnQsIExhcnMNClNlbnQ6IDE3IEp1bmUgMjAxNiAw ODozOQ0KVG86IGlydGYtYW5ub3VuY2VAaXJ0Zi5vcmc7IGlydGYtZGlzY3Vzc0BpcnRmLm9yZzsg aWV0ZkBpZXRmLm9yZzsgOTZhdHRlbmRlZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFs5NmF0dGVuZGVl c10gQ2FsbCBmb3IgUGFydGljaXBhdGlvbjogQUNNLCBJUlRGICYgSVNPQyBBcHBsaWVkIE5ldHdv cmtpbmcgUmVzZWFyY2ggV29ya3Nob3AgMjAxNg0KDQogICAgQUNNLCBJUlRGICYgSVNPQyBBcHBs aWVkIE5ldHdvcmtpbmcgUmVzZWFyY2ggV29ya3Nob3AgMjAxNg0KDQogICAgICAgICAgICAgICAg ICAgICAgICBCZXJsaW4sIEdlcm1hbnkNCiAgICAgICAgICAgICAgICAgICAgU2F0dXJkYXksIEp1 bHkgMTYsIDIwMTYNCiAgICAgICAgICAgICAgICAgIGh0dHBzOi8vaXJ0Zi5vcmcvYW5ydy8yMDE2 Lw0KDQoNCioqKiBDQUxMIEZPUiBQQVJUSUNJUEFUSU9OICoqKg0KDQpUaGUgaW5hdWd1cmFsIEFD TSwgSVJURiAmIElTT0MgQXBwbGllZCBOZXR3b3JraW5nIFJlc2VhcmNoIFdvcmtzaG9wDQoyMDE2 IChBTlJX4oCZMTYpIGlzIGFuIGFjYWRlbWljIHdvcmtzaG9wIHRoYXQgcHJvdmlkZXMgYSBmb3J1 bSBmb3IgcmVzZWFyY2hlcnMsIHZlbmRvcnMsIG5ldHdvcmsgb3BlcmF0b3JzIGFuZCB0aGUgSW50 ZXJuZXQgc3RhbmRhcmRzIGNvbW11bml0eSB0byBwcmVzZW50IGFuZCBkaXNjdXNzIGVtZXJnaW5n IHJlc3VsdHMgaW4gYXBwbGllZCBuZXR3b3JraW5nIHJlc2VhcmNoLiBJdCBpcyBzcG9uc29yZWQg YnkgQUNNIFNJR0NPTU0sIHRoZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlIChJUlRGICkg YW5kIHRoZSBJbnRlcm5ldCBTb2NpZXR5IChJU09DKS4NCg0KVGhlIEFOUlcg4oCYMTYgdGFrZXMg cGxhY2Ugb24gU2F0dXJkYXksIEp1bHkgMTYsIDIwMTYgaW4gdGhlIENoYXJsb3R0ZW5idXJnIElJ L0lJSSByb29tIGF0IHRoZSB2ZW51ZSBvZiB0aGUgSUVURi05NiBtZWV0aW5nLCB0aGUgSW50ZXJD b250aW5lbnRhbCBCZXJsaW4uIFRoaXMgYWNhZGVtaWMgd29ya3Nob3AgaXMgb3BlbiB0byBhbGw7 IHRoZSByZWdpc3RyYXRpb24gZmVlIGlzICQxMDAgVVNELiBTZWUgaHR0cHM6Ly9pcnRmLm9yZy9h bnJ3LzIwMTYvYXR0ZW5kLmh0bWwgZm9yIGRldGFpbHMuDQoNClN0dWRlbnQgdHJhdmVsIGdyYW50 cyBhdmFpbGFibGU7IGRlYWRsaW5lIEp1bmUgMjQsIDIwMTYgKGhhcmQpLg0KU2VlIGh0dHBzOi8v aXJ0Zi5vcmcvYW5ydy8yMDE2L3RyYXZlbGdyYW50cy5odG1sIGZvciBkZXRhaWxzLg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KKioqIFBSRUxJTUlOQVJZIFBST0dSQU0gKioqDQpodHRwczovL2lydGYu b3JnL2FucncvMjAxNi9wcm9ncmFtLmh0bWwNCg0KDQpTRVNTSU9OOiBNVUxUSVBBVEgNCg0KQW4g ZW5oYW5jZWQgc29ja2V0IEFQSSBmb3IgTXVsdGlwYXRoIFRDUC4gW0Z1bGwgUGFwZXJdIEJlbmph bWluIEhlc21hbnMgKFVDTCkgYW5kIE9saXZpZXIgQm9uYXZlbnR1cmUuDQoNCk11bHRpcGF0aCBi b25kaW5nIGF0IExheWVyIDMuIFtGdWxsIFBhcGVyXQ0KDQpNYWNpZWogQmVkbmFyZWsgKEVUSCBa dXJpY2gpLCBHdWlsbGVybW8gQmFycmVuZXR4ZWEgS29iYXMgKFN3aXNzY29tKSwgTWlyamEgS8O8 aGxld2luZCAoRVRIIFp1cmljaCksIGFuZCBCcmlhbiBUcmFtbWVsbCAoRVRIIFp1cmljaCkuDQoN ClRvd2FyZHMgYSBNdWx0aXBhdGggVENQIEF3YXJlIExvYWQgQmFsYW5jZXIuIFtTaG9ydCBQYXBl cl0gU2ltb24gTGnDqW5hcmR5IChVbml2ZXJzaXTDqSBkZSBMacOoZ2UpIGFuZCBCZW5vaXQgRG9u bmV0IChVbml2ZXJzaXTDqSBkZSBMacOoZ2UpLg0KDQpNdWx0aS1Ib21lZCBvbiBhIFNpbmdsZSBM aW5rOiBVc2luZyBNdWx0aXBsZSBJUHY2IEFjY2VzcyBOZXR3b3Jrcy4NCltTaG9ydCBQYXBlcl0N ClBoaWxpcHAgUy4gVGllc2VsIChUVS1CZXJsaW4pLCBCZXJuZCBNYXkgKFRVLUJlcmxpbiksIGFu ZCBBbmphIEZlbGRtYW5uIChUVS1CZXJsaW4pLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU0VTU0lP TjogU0ROLCBST1VUSU5HIEFORCBQRUVSSU5HDQoNClRvd2FyZHMgRGVjZW50cmFsaXplZCBGYXN0 IENvbnNpc3RlbnQgVXBkYXRlcy4gW0Z1bGwgUGFwZXJdIFRoYW5oIERhbmcgTmd1eWVuIChVbml2 ZXJzaXTDqSBjYXRob2xpcXVlIGRlIExvdXZhaW4pLCBNYXJjbyBDaGllc2EgKFVuaXZlcnNpdMOp IGNhdGhvbGlxdWUgZGUgTG91dmFpbiksIGFuZCBNYXJjbyBDYW5pbmkgKFVuaXZlcnNpdMOpIGNh dGhvbGlxdWUgZGUgTG91dmFpbikuDQoNCkNvbXBvc2l0aW9uIG9mIFNETiBhcHBsaWNhdGlvbnM6 IE9wdGlvbnMvY2hhbGxlbmdlcyBmb3IgcmVhbCBpbXBsZW1lbnRhdGlvbnMuIFtGdWxsIFBhcGVy XSBBcm5lIFNjaHdhYmUgKFVuaXZlcnNpdHkgb2YgUGFkZXJib3JuKSwgUGVkcm8gQS4gQXJhbmRh IEd1dGnDqXJyZXogKFRlbGVmw7NuaWNhIEkrRCksIGFuZCBIb2xnZXIgS2FybCAoVW5pdmVyc2l0 eSBvZiBQYWRlcmJvcm4pLg0KDQpTSVhQQUNLOiBTZWN1cmluZyBJbnRlcm5ldCBlWGNoYW5nZSBQ b2ludHMgQWdhaW5zdCBDdXJpb3VzIG9ubG9vS2Vycy4NCltTaG9ydCBQYXBlcl0NCk1hcmNvIENo aWVzYSAoVW5pdmVyc2l0ZSBjYXRob2xpcXVlIGRlIExvdXZhaW4pLCBEYW5pZWwgRGVtbWxlciAo VGVjaG5pc2NoZSBVbml2ZXJzaXRhdCBEYXJtc3RhZHQpLCBNYXJjbyBDYW5pbmkgKFVuaXZlcnNp dGUgY2F0aG9saXF1ZSBkZSBMb3V2YWluKSwgTWljaGFlbCBTY2hhcGlyYSAoSGVicmV3IFVuaXZl cnNpdHkgb2YgSmVydXNhbGVtKSwgYW5kIFRob21hcyBTY2huZWlkZXIgKFRlY2huaXNjaGUgVW5p dmVyc2l0YXQgRGFybXN0YWR0KS4NCg0KQ29tcHV0aW5nIEN1c3RvbWVyIENvbmVzIG9mIFBlZXJp bmcgTmV0d29ya3MuIFtTaG9ydCBQYXBlcl0gSmludSBTdXNhbiBWYXJnaGVzZSAoSW93YSBTdGF0 ZSBVbml2ZXJzaXR5KSBhbmQgTHUgUnVhbiAoSW93YSBTdGF0ZSBVbml2ZXJzaXR5KS4NCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClNFU1NJT046IFRSQU5TUE9SVCBRVUFMSVRZIEFORCDigJxIQVBQWSBF WUVCQUxMU+KAnQ0KDQpNZWFzdXJpbmcgdGhlIEVmZmVjdHMgb2YgSGFwcHkgRXllYmFsbHMuIFtG dWxsIFBhcGVyXSBWYWliaGF2IEJhanBhaSAoSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuKSBhbmQg SsO8cmdlbiBTY2jDtm53w6RsZGVyIChKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4pLg0KDQpPbiB0 aGUgQ29zdCBvZiBVc2luZyBIYXBweSBFeWViYWxscyBmb3IgVHJhbnNwb3J0IFByb3RvY29sIFNl bGVjdGlvbi4NCltGdWxsIFBhcGVyXQ0KR2lvcmdvcyBQYXBhc3Rlcmdpb3UgKFNpbXVsYSBSZXNl YXJjaCBMYWJvcmF0b3J5KSwgS2FybC1Kb2hhbiBHcmlubmVtbyAoS2FybHN0YWQgVW5pdmVyc2l0 eSksIEFubmEgQnJ1bnN0cm9tIChLYXJsc3RhZCBVbml2ZXJzaXR5KSwgRGF2aWQgUm9zIChTaW11 bGEgUmVzZWFyY2ggTGFib3JhdG9yeSksIE1pY2hhZWwgVMO8eGVuIChGYWNoaG9jaHNjaHVsZSBN w7xuc3RlciksIE5hZWVtIEtoYWRlbWkgKFVuaXZlcnNpdHkgb2YgT3NsbyksIGFuZCBQZXIgSHVy dGlnIChLYXJsc3RhZCBVbml2ZXJzaXR5KS4NCg0KU3RhcnQgTWUgVXA6IERldGVybWluaW5nIGFu ZCBTaGFyaW5nIFRDUOKAmXMgSW5pdGlhbCBDb25nZXN0aW9uIFdpbmRvdy4NCltTaG9ydCBQYXBl cl0NClNhZmlxdWwgSXNsYW0gKFVuaXZlcnNpdHkgb2YgT3NsbykgYW5kIE1pY2hhZWwgV2Vsemwg KFVuaXZlcnNpdHkgb2YgT3NsbykuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTRVNTSU9OOiBNRUFT VVJFTUVOVA0KDQpSZXZpc2l0aW5nIEJlbmNobWFya2luZyBNZXRob2RvbG9neSBmb3IgSW50ZXJj b25uZWN0IERldmljZXMuDQpbRnVsbCBQYXBlcl0NCkRhbmllbCBSYXVtZXIgKFRlY2huaWNhbCBV bml2ZXJzaXR5IG9mIE11bmljaCksIFNlYmFzdGlhbiBHYWxsZW5tw7xsbGVyIChUZWNobmljYWwg VW5pdmVyc2l0eSBvZiBNdW5pY2gpLCBGbG9yaWFuIFdvaGxmYXJ0IChUZWNobmljYWwgVW5pdmVy c2l0eSBvZiBNdW5pY2gpLCBQYXVsIEVtbWVyaWNoIChUZWNobmljYWwgVW5pdmVyc2l0eSBvZiBN dW5pY2gpLCBQYXRyaWNrIFdlcm5lY2sgKFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIE11bmljaCks IGFuZCBHZW9yZyBDYXJsZSAoVGVjaG5pY2FsIFVuaXZlcnNpdHkgb2YgTXVuaWNoKS4NCg0KUEFU SHNwaWRlcjogQSB0b29sIGZvciBhY3RpdmUgbWVhc3VyZW1lbnQgb2YgcGF0aCB0cmFuc3BhcmVu Y3kuDQpbU2hvcnQgUGFwZXJdDQpJYWluIFIuIExlYXJtb250aCAoVW5pdmVyc2l0eSBvZiBBYmVy ZGVlbiksIEJyaWFuIFRyYW1tZWxsIChFVEggWnVyaWNoKSwgTWlyamEgS3VobGV3aW5kIChFVEgg WnVyaWNoKSwgYW5kIEdvcnJ5IEZhaXJodXJzdCAoVW5pdmVyc2l0eSBvZiBBYmVyZGVlbikuDQoN CkRpdXJuYWwgYW5kIFdlZWtseSBDeWNsZXMgaW4gSVB2NiBUcmFmZmljLiBbU2hvcnQgUGFwZXJd IFN0ZXBoZW4gRC4gU3Ryb3dlcyAoWWFob28pLg0KDQpIb3cgdG8gc2F5IHRoYXQgeW914oCZcmUg c3BlY2lhbDogQ2FuIHdlIHVzZSBiaXRzIGluIHRoZSBJUHY0IGhlYWRlcj8NCltTaG9ydCBQYXBl cl0NClJ1bmEgQmFyaWsgKFVuaXZlcnNpdHkgb2YgT3NsbywgTm9yd2F5KSwgTWljaGFlbCBXZWx6 bCAoVW5pdmVyc2l0eSBvZiBPc2xvLCBOb3J3YXkpLCBhbmQgQWhtZWQgRWxtb2thc2hmaSAoU2lt dWxhIFJlc2VhcmNoIExhYm9yYXRvcnksIE5vcndheSkuDQoNClRvd2FyZHMgYW4gT2JzZXJ2YXRv cnkgZm9yIE5ldHdvcmsgVHJhbnNwYXJlbmN5IFJlc2VhcmNoLiBbU2hvcnQgUGFwZXJdDQoNClN0 ZXBoYW4gTmV1aGF1cyAoWsO8cmNoZXIgSG9jaHNjaHVsZSBmw7xyIEFuZ2V3YW5kdGUgV2lzc2Vu c2NoYWZ0ZW4pLCBLb3JpYW4gRWRlbGluZSAoVW5pdmVyc2l0w6kgZGUgTGnDqGdlKSwgQmVub2l0 IERvbm5ldCAoVW5pdmVyc2l0w6kgZGUgTGnDqGdlKSwgYW5kIEVsaW8gR3Vic2VyIChFVEggWnVy aWNoKS4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNFU1NJT046IElOVEVSTkVUIE1FRElBDQoNCk1h a2luZyBHb29nbGUgQ29uZ2VzdGlvbiBDb250cm9sIHJvYnVzdCBvdmVyIFdpLUZpIG5ldHdvcmtz IHVzaW5nIHBhY2tldCBncm91cGluZy4gW0Z1bGwgUGFwZXJdIEdhZXRhbm8gQ2FybHVjY2kgKFBv bGl0ZWNuaWNvIGRpIEJhcmksIEl0YWx5KSwgTHVjYSBEZSBDaWNjbyAoUG9saXRlY25pY28gZGkg QmFyaSwgSXRhbHkpLCBTdGVmYW4gSG9sbWVyIChHb29nbGUgSW5jLCBTd2VkZW4pLCBhbmQgU2F2 ZXJpbyBNYXNjb2xvIChQb2xpdGVjbmljbyBkaSBCYXJpLCBJdGFseSkuDQoNCkltcGxlbWVudGlu ZyBSZWFsLVRpbWUgVHJhbnNwb3J0IFNlcnZpY2VzIG92ZXIgYW4gT3NzaWZpZWQgTmV0d29yay4N CltGdWxsIFBhcGVyXQ0KU3RlcGhlbiBNY1F1aXN0aW4gKFVuaXZlcnNpdHkgb2YgR2xhc2dvdyks IENvbGluIFBlcmtpbnMgKFVuaXZlcnNpdHkgb2YgR2xhc2dvdyksIGFuZCBNYXJ3YW4gRmF5ZWQg KFVuaXZlcnNpdHkgb2YgU3RpcmxpbmcpLg0KDQo= From nobody Mon Jun 20 05:44:30 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75B612D0A5 for ; Mon, 20 Jun 2016 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 AI9_fxhy5m8I for ; Mon, 20 Jun 2016 05:44:26 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB9212B05C for ; Mon, 20 Jun 2016 05:44:21 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3B1BB67DA08; Mon, 20 Jun 2016 14:44:09 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 3B1BB67DA08 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1466426649; bh=2Adrxy3jFk1mr5mpKUMugZLkCozNfZmpcuUcMFPNyyk=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=eay53sRU/V6gRDq7149JVFW7cHgIfRmkzDNgrCDMb4Q4ulFBrHJyJ1dzDWhVjpV2C o7a9urr76OckmNPEcb8unu1Mw+Us+yVkJk9HGkQ/lmVqV6Mj9r2ciJ2MXGZt7Ixjxm uLiOVhljxE5U/uMrH/qop3FKTuW966RrZApKVGQY= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at smtp-3 References: To: philip.eardley@bt.com, multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <3630620a-7c08-385e-c40c-a924fd89f2ad@uclouvain.be> Date: Mon, 20 Jun 2016 14:44:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3B1BB67DA08.A4A47 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Interest in hackathon in Berlin? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 12:44:29 -0000 Phil, > At the Berlin IETF meeting, there’s a hackathon on the first weekend – > is there any interest in doing something with MPTCP at this? > > https://www.ietf.org/hackathon/96-hackathon.html > We are currently finalising an extended socket API that enables applications to control the operation of the Multipath TCP implementation in the Linux kernel. If there are people interested in looking at how applications can be modified to better utilise MPTCP, this could be a good objective for a hackathon Olivier From nobody Mon Jun 20 07:19:01 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6FC12B02C; Mon, 20 Jun 2016 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Bw-HwY8LP72n; Mon, 20 Jun 2016 07:18:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CEA12D0B6; Mon, 20 Jun 2016 07:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A5B72D931B; Mon, 20 Jun 2016 16:18:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LpqB8+wpYkcT; Mon, 20 Jun 2016 16:18:45 +0200 (MEST) Received: from [192.168.178.33] (p5DEC2E4F.dip0.t-ipconnect.de [93.236.46.79]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 41C7DD9316; Mon, 20 Jun 2016 16:18:45 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 20 Jun 2016 16:18:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E6D9951-D1EB-4F1F-8666-7189357053C0@gmail.com> <9158F6E6-F21D-4EB6-828D-C89191554C79@tik.ee.ethz.ch> To: Christoph Paasch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: MultiPath TCP - IETF WG , tcpinc Subject: Re: [multipathtcp] [tcpinc] MPTCP external auth drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:18:57 -0000 Hi Christoph, please note that tcpinc also discusses to use the tcpinc option to = negotiate application layer TLS. Maybe it would make sense to use tcpinc = directly instead of defining yet another negotiation mechanism? Mirja > Am 19.06.2016 um 23:55 schrieb Christoph Paasch : >=20 > Hello Mirja, >=20 >> On Jun 17, 2016, at 8:14 AM, Mirja K=C3=BChlewind = wrote: >> adding tcpinc. How does this relate to working tcpinc? >=20 > in a tcpinc-deployment, MPTCP could use a derivate of tcpinc's key to = authenticate new subflows. >=20 > A draft similar to = http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt = would need to describe how the MPTCP-key is derived from the = tcpinc-secret. >=20 >=20 > Christoph >=20 >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 28.05.2016 um 10:32 schrieb Alan Ford : >>>=20 >>> Hi all, >>>=20 >>> Following on from the discussion at the previous two IETFs, we have = submitted two drafts proposing a way forward for resolving the = loadbalancers issue (or in other words, separating tokens and keys), and = in turn have a proposal for using TLS keying material with MPTCP. >>>=20 >>> This proposal comes in the form of two drafts, to separate protocol = changes (which we would be proposing for adoption into rfc6824bis), and = TLS-specific extensions (which we would suggest are kept separate). >>>=20 >>> The protocol changes = (http://www.ietf.org/id/draft-paasch-mptcp-application-authentication-00.t= xt) propose an additional handshake mechanism to be negotiated in the = MP_CAPABLE flags - the "G" bit, allocated to "application-layer". This = means that MPTCP queries the application layer for Token and Key = materials. This is negotiated by being offered by the initiator, and = chosen by the answerer. >>>=20 >>> Only tokens are sent on the wire, and these can be used to contain = any information that could assist a far end to demultiplex connections = (e.g. including routing data which would help front-end proxies). >>>=20 >>> Minor changes that fall out of this also mean the IDSN, in that = scenario, would be generated from the Token not the Key. >>>=20 >>> Keying information may not be available at the SYN/ACK exchange, but = will be provided by the application when available. Only once that has = occurred can subflow setup continue. >>>=20 >>> The TLS draft = (http://www.ietf.org/id/draft-paasch-mptcp-tls-authentication-00.txt) = shows how we can interface this proposal with TLS, using RFC5705 key = export from TLS. This requires no changes to the protocol, but would = register a new RFC5705 exporter with IANA. Exported keys from a TLS = session would be passed to the MPTCP layer and used in the HMAC = authentication algorithm. >>>=20 >>> We would like to present and discuss these points in the upcoming = interim, to see if there is consensus to add the necessary protocol = changes to rfc6824bis. >>>=20 >>> Best regards, >>> Alan & Christoph >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 >> _______________________________________________ >> Tcpinc mailing list >> Tcpinc@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpinc >=20 > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc From nobody Mon Jun 20 12:57:41 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3559112D920 for ; Mon, 20 Jun 2016 12:57:39 -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 794SjuptVyY4 for ; Mon, 20 Jun 2016 12:57:36 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D40E12D928 for ; Mon, 20 Jun 2016 12:57:36 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id f6so44941638lfg.0 for ; Mon, 20 Jun 2016 12:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=RE72j/DGplJJWmNu4pCLedD7CT/9+Re1tT4fBOwL8lQ=; b=seOPE4vuM6Xp2zInSchh5uueCab3aRQWSkbrOYk5CbE5C2JjdnB97VwfIsQZhBrsxq LJ7pwbVYhdJ2dT6ybJZRIwAVHLGB1X7niF+Aab0z82uf9aUYQjC5XfvII6bcqZjlRpdl Dqmaveo2aujloiUKGv4f93hPgZsDZA56V2txmSqD0vg3kb9nBm7oBV7Gw9KSH03ljEzG IMJenNPfWSpx218XY9rC6mJ6OvlfoFfXkM79TKTtTGwBn/5kNWRdh8I7eZEYp/X4VozB J+ov2w1a3YGJ81hL6wpRa24dzuiEaAr2k/g0RgOuBJ7QUn7laMrDJ8pbnXN5eFWxTjor pU6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=RE72j/DGplJJWmNu4pCLedD7CT/9+Re1tT4fBOwL8lQ=; b=lu81ahCLDHLClN43Ggh+CaGASfRjkKCT8E6zBCCdjZ8e15IkCekeayIq0GYPTFRECl LQAdTfNDgVscNy9UnWeqkf5Z1Ms5JXnOAN1LP2Y+hU1fBqKlGlCsKlR6zd98nhmZsf7y wi4+QkwDFketxCDN3FYy3ZjSWxbMPk2ic7kiT3fYbX2Pji/NFgM6mcVA1i4LpCvFKHfU bs5EIiIJHIFTpIgD8xaAdiR1ozALxhY7T659pMUfmRn0+J5O2MpKctESIuvW2RPffgUq 7ZUNe5eOPve/vNBCq00qErjjm4DHh6E8kYLdCo4XfPR7Vcp92YYq8l1O2MGTivrm4Lwy m6wQ== X-Gm-Message-State: ALyK8tLr4S8gxrJf+GLWpuIHZCDRhbzQJYIJvphqv9xlP3qyc30aHSBw5vhygv4eP93z/A== X-Received: by 10.28.227.136 with SMTP id a130mr13407787wmh.3.1466452654144; Mon, 20 Jun 2016 12:57:34 -0700 (PDT) Received: from triton.lan (116.35.199.146.dyn.plus.net. [146.199.35.116]) by smtp.gmail.com with ESMTPSA id b200sm15223130wmb.9.2016.06.20.12.57.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 12:57:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F66C0B99-B4A6-442A-B0AB-2E22F8C0C401" From: Alan Ford In-Reply-To: <20160407173442.GJ1732@dhcp-a286.meeting.ietf.org> Date: Mon, 20 Jun 2016 20:57:20 +0100 Message-Id: <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com> References: <8ED39350-21EE-43B6-9D30-8786A7709702@cs.pub.ro> <20160406214450.GA1732@dhcp-a286.meeting.ietf.org> <20160407173442.GJ1732@dhcp-a286.meeting.ietf.org> To: Christoph Paasch X-Mailer: Apple Mail (2.1283) Archived-At: Cc: MultiPath WG , Costin Raiciu Subject: Re: [multipathtcp] Bumping the MPTCP version number: some cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 19:57:40 -0000 --Apple-Mail=_F66C0B99-B4A6-442A-B0AB-2E22F8C0C401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, Costin re-visited the issue of version number bumping in today's = interim. In order to clarify matters here, I think it's worth just going = back over why working group consensus for -05 was to do this. The thread can be found here: = http://www.ietf.org/mail-archive/web/multipathtcp/current/msg02572.html The benefits this has so far brought are: - Support for stateless servers: - No need for key in initial SYN (saves option space) - Reliability of third ACK (including carrying data) - Save 1 subtype (ADD_ADDR2 -> ADD_ADDR) And we can potentially make other protocol-level changes before = finalising v1 for standards track, for example the keyless SYN makes the = proposal in draft-paasch-mptcp-application-authentication simpler = (although it could be done with discarded key whilst retaining = compatibility with the SHA-1 exchange). I guess support for stateless servers could be signalled in the flags, = i.e. the client saying "I will echo this reliably in the ACK if you want = me to" and the server also sets that flag if it wants the client do = this. What do you think? Bear in mind the MPTCP version negotiation is = specified anyway: The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0 [5]. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. The passive opener, on receipt of this, will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded, and therefore if the far end has requested a lower version then the initiator SHOULD respond with an ACK without any MP_CAPABLE option, to fall back to regular TCP. If the initiator supports the requsted version, on future connections to the target host, the initiator MAY cache the version preference. Alternatively, the initiator MAY close the connection with a TCP RST and immediately re-establish with the requested version of MPTCP. Regards, Alan On 7 Apr 2016, at 18:34, Christoph Paasch wrote: > On 06/04/16 - 20:48:04, Yoshifumi Nishida wrote: >> Just in case, I might want to clarify some points. I think the new >> handshake mechanism in 6824bis can have the two benefits for stateful = nodes. >> You won't fallback to normal TCP when the 3rd ack is lost. Also, you = can >> save lots of option space in the first SYN packet which might = increase the >> chance to combine other features with mptcp. >=20 > Yes, independent from what we do with the TLS/load-balancer issue I = think > that the gain in option-space is a nice addition. >=20 >=20 > Christoph >=20 >> =46rom my personal point of view, supporting stateless server looks >> additional advantage. >>=20 >> I believe load balancer and TLS key negotiation are not included in = 6824bis >> yet. >> I think we will need more discussions if it is integrated. >> Please let me know if I miss some points. (Sorry, I couldn't find = time to >> check audio archive yet..) >>=20 >> Regards, >> -- >> Yoshi >>=20 >>=20 >> On Wed, Apr 6, 2016 at 2:44 PM, Christoph Paasch = wrote: >>=20 >>> Hello, >>>=20 >>> On 06/04/16 - 20:47:59, Costin Raiciu wrote: >>>> I first have to admit that I missed the MPTCP version number bump. >>>>=20 >>>> While I see it has a few benefits, from what I heard in Christoph=92s= talk >>> I am not convinced the change is worth those benefits. I=92ll take = them in >>> turn: >>>> - the SYN cookie reliability bug - a nice feature, but not enough = to >>> change version number - after all, TCP works fine without it! >>>=20 >>> TCP does not have this issue, as it already echoes the information >>> necessary >>> for the server to create the TCP-state in subsequent segments that = do >>> contain data. >>>=20 >>> MPTCP doesn't do this yet, as the keys are not sent in the = data-segments. >>>=20 >>> I can see that it might be considered a minor issue (after all, we = only >>> fall >>> back to regular TCP if there is one unfortunate packet-loss). = However, when >>> the packet-loss rate is high, this is the scenario where we really = want >>> MPTCP to work, as that's where it provides the benefits. That's why = I would >>> like to make MPTCP as reliable as possible in scenarios where there = is a >>> high packet-loss. >>>=20 >>>=20 >>>> - the load balancer support - we have a solution that requires no >>> protocol changes whatsoever and works fine at datacenter scale. Will >>> present it in the next meeting. >>>> - the TLS key integration - I honestly see no benefit - if you have = e2e >>> encryption, the actual routing of paths doesn=92t matter that much = honestly. >>> The attacker could DDos, at most. >>>=20 >>> I think one more benefit is that splitting the token from the key = allows to >>> easily ensure that the token is unique. >>> At the moment, a server has to generate a key randomly, hash it to = get the >>> token and then check the hash-table for a colliding token and repeat = again >>> if there is a collision. >>>=20 >>>=20 >>>> Now about drawbacks: we have a feeble deployment so far. If we = bump the >>> version number, we=92ll basically have two protocols running in = parallel, >>> since it=92s unlikely all (any) implementations will support both. = So we >>> might kill MPTCP before its even born. But maybe I=92m just being = pessimistic. >>>=20 >>> I don't think so, but it is difficult to foresee this. >>>=20 >>>=20 >>>=20 >>> One thing to consider is that if we don't bump the version-number, = how do >>> we >>> "negotiate" support for the new ADD_ADDR option and other changes = that are >>> already in the bis-version (e.g., RST-option and the experimental = one). >>>=20 >>>=20 >>> Cheers, >>> Christoph >>>=20 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail=_F66C0B99-B4A6-442A-B0AB-2E22F8C0C401 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all,

Costin re-visited the issue of version number = bumping in today's interim. In order to clarify matters here, I think = it's worth just going back over why working group consensus for -05 was = to do this.


The benefits this has so far brought = are:

- Support for stateless = servers:
  - No need for key in initial SYN (saves option = space)
  - Reliability of third ACK (including carrying = data)
- Save 1 subtype (ADD_ADDR2 -> = ADD_ADDR)

And we can potentially make other = protocol-level changes before finalising v1 for standards track, for = example the keyless SYN makes the proposal in = draft-paasch-mptcp-application-authentication simpler (although it could = be done with discarded key whilst retaining compatibility with the SHA-1 = exchange).

I guess support for stateless = servers could be signalled in the flags, i.e. the client saying "I will = echo this reliably in the ACK if you want me to" and the server also = sets that flag if it wants the client do = this.

What do you think? Bear in mind the = MPTCP version negotiation is specified = anyway:

   The =
MP_CAPABLE exchange in this specification (v1) is different to
   that specified in v0 [5].  If a host supports multiple versions of
   MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest
   version number it supports.  The passive opener, on receipt of this,
   will signal the version number it wishes to use, which MUST be equal
   to or lower than the version number indicated in the initial
   MP_CAPABLE.  Given the SYN exchange is different between v1 and v0
   the exchange cannot be immediately downgraded, and therefore if the
   far end has requested a lower version then the initiator SHOULD
   respond with an ACK without any MP_CAPABLE option, to fall back to
   regular TCP.  If the initiator supports the requsted version, on
   future connections to the target host, the initiator MAY cache the
   version preference.  Alternatively, the initiator MAY close the
   connection with a TCP RST and immediately re-establish with the
   requested version of =
MPTCP.

Regards,
Alan

On 7 Apr 2016, at 18:34, Christoph = Paasch wrote:

On 06/04/16 - 20:48:04, Yoshifumi Nishida = wrote:
Just in case, I might want to = clarify some points. I think the new
handshake mechanism in 6824bis can have the two benefits = for stateful nodes.
You won't = fallback to normal TCP when the 3rd ack is lost. Also, you = can
save lots of option space = in the first SYN packet which might increase = the
chance to combine other = features with mptcp.

Yes, independent from what we = do with the TLS/load-balancer issue I think
that the gain in = option-space is a nice addition.


Christoph

=46rom my personal point of view, supporting stateless = server looks
additional = advantage.

I believe load = balancer and TLS key negotiation are not included in = 6824bis
yet.
I think we = will need more discussions if it is = integrated.
Please let me know = if I miss some points. (Sorry, I couldn't find time = to
check audio archive = yet..)

Regards,
--
Yoshi


On Wed, Apr 6, = 2016 at 2:44 PM, Christoph Paasch <cpaasch@apple.com> = wrote:

Hello,

On 06/04/16 - 20:47:59, Costin = Raiciu wrote:
I = first have to admit that I missed the MPTCP version number = bump.

While = I see it has a few benefits, from what I heard in Christoph=92s = talk
I am not convinced the change is = worth those benefits. I=92ll take them = in
turn:
- the = SYN cookie reliability bug - a nice feature, but not enough = to
change version number - after = all, TCP works fine without it!

TCP does not have this issue, as = it already echoes the = information
necessary
for the server to create the = TCP-state in subsequent segments that = do
contain data.

MPTCP doesn't do this yet, as = the keys are not sent in the = data-segments.

I can see that it might be = considered a minor issue (after all, we = only
fall
back to regular TCP if there is = one unfortunate packet-loss). However, = when
the packet-loss rate is high, this is the scenario where = we really want
MPTCP to work, as that's where = it provides the benefits. That's why I = would
like to make MPTCP as reliable as possible in scenarios = where there is a
high = packet-loss.


- the = load balancer support - we have a solution that requires = no
protocol changes whatsoever and = works fine at datacenter scale. = Will
present it in the next = meeting.
- the = TLS key integration - I honestly see no benefit - if you have = e2e
encryption, the actual routing = of paths doesn=92t matter that much = honestly.
The attacker could DDos, at = most.

I think one more benefit is that = splitting the token from the key allows = to
easily ensure that the token is = unique.
At the moment, a server has to generate a key randomly, = hash it to get the
token and then check the = hash-table for a colliding token and repeat = again
if there is a = collision.


Now = about drawbacks: we have a feeble  deployment so far. If we bump = the
version number, we=92ll = basically have two protocols running in = parallel,
since it=92s unlikely all (any) = implementations will support both. So = we
might kill MPTCP before its even born. But maybe I=92m = just being pessimistic.

I don't think so, but it is = difficult to foresee this.



One thing to consider is that if = we don't bump the version-number, how = do
we
"negotiate" support for the new = ADD_ADDR option and other changes that = are
already in the bis-version (e.g., RST-option and the = experimental one).


Cheers,
Christoph

_______________________________________________
multipathtcp mailing = list
multipathtcp@ietf.org
https://www.ie= tf.org/mailman/listinfo/multipathtcp


__________________________= _____________________
multipathtcp mailing list
multipathtcp@ietf.org
https:/= /www.ietf.org/mailman/listinfo/multipathtcp
= --Apple-Mail=_F66C0B99-B4A6-442A-B0AB-2E22F8C0C401-- From nobody Mon Jun 20 22:47:35 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81EA12D179 for ; Mon, 20 Jun 2016 22:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 j4vFnNoiedgB for ; Mon, 20 Jun 2016 22:47:31 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EF512D590 for ; Mon, 20 Jun 2016 22:47:31 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7CCB02784C6 for ; Tue, 21 Jun 2016 14:47:29 +0900 (JST) Received: by mail-yw0-f171.google.com with SMTP id b72so4986978ywa.3 for ; Mon, 20 Jun 2016 22:47:29 -0700 (PDT) X-Gm-Message-State: ALyK8tJdYUWxIiSRM4Bj76cvSxFZnPOAXAtEgkr3q1YMHDPqLlxCPHEhsmZmcZsfLDwfrEOBkw3O0uHPoMpPfg== X-Received: by 10.129.75.206 with SMTP id y197mr10819821ywa.312.1466488048076; Mon, 20 Jun 2016 22:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Mon, 20 Jun 2016 22:47:27 -0700 (PDT) In-Reply-To: <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com> References: <8ED39350-21EE-43B6-9D30-8786A7709702@cs.pub.ro> <20160406214450.GA1732@dhcp-a286.meeting.ietf.org> <20160407173442.GJ1732@dhcp-a286.meeting.ietf.org> <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com> From: Yoshifumi Nishida Date: Mon, 20 Jun 2016 22:47:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Content-Type: multipart/alternative; boundary=001a113f1ae62c50ba0535c35b39 Archived-At: Cc: MultiPath WG , Costin Raiciu Subject: Re: [multipathtcp] Bumping the MPTCP version number: some cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 05:47:34 -0000 --001a113f1ae62c50ba0535c35b39 Content-Type: text/plain; charset=UTF-8 Hi Alan, On Mon, Jun 20, 2016 at 12:57 PM, Alan Ford wrote: > Hi all, > > Costin re-visited the issue of version number bumping in today's interim. > In order to clarify matters here, I think it's worth just going back over > why working group consensus for -05 was to do this. > > The thread can be found here: > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg02572.html > > The benefits this has so far brought are: > > - Support for stateless servers: > - No need for key in initial SYN (saves option space) > - Reliability of third ACK (including carrying data) > - Save 1 subtype (ADD_ADDR2 -> ADD_ADDR) > > And we can potentially make other protocol-level changes before finalising > v1 for standards track, for example the keyless SYN makes the proposal in > draft-paasch-mptcp-application-authentication simpler (although it could be > done with discarded key whilst retaining compatibility with the SHA-1 > exchange). > > I guess support for stateless servers could be signalled in the flags, > i.e. the client saying "I will echo this reliably in the ACK if you want me > to" and the server also sets that flag if it wants the client do this. > Hmm. the signal you mentioned will be used for reliability of the third ACK, but won't be used for keyless syn? I am guessing keyless syn cannot be supported by the flags. Thanks, -- Yoshi --001a113f1ae62c50ba0535c35b39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alan,

On Mon, Jun 20, 2016 at 12:57 PM, Alan Ford <ala= n.ford@gmail.com> wrote:
Hi all,

Costin re-visi= ted the issue of version number bumping in today's interim. In order to= clarify matters here, I think it's worth just going back over why work= ing group consensus for -05 was to do this.


The benefits this has so far brought are:

-= Support for stateless servers:
=C2=A0 - No need for key in initi= al SYN (saves option space)
=C2=A0 - Reliability of third ACK (in= cluding carrying data)
- Save 1 subtype (ADD_ADDR2 -> ADD_ADDR= )

And we can potentially make other protocol-level= changes before finalising v1 for standards track, for example the keyless = SYN makes the proposal in draft-paasch-mptcp-application-authentication sim= pler (although it could be done with discarded key whilst retaining compati= bility with the SHA-1 exchange).

I guess support f= or stateless servers could be signalled in the flags, i.e. the client sayin= g "I will echo this reliably in the ACK if you want me to" and th= e server also sets that flag if it wants the client do this.

Hmm. the signal you mentioned will be used fo= r reliability of the third ACK, but won't be used for keyless syn?
<= /div>
I am guessing keyless syn cannot be supported by the flags.
=

Thanks,
--
Yoshi
<= /div>
--001a113f1ae62c50ba0535c35b39-- From nobody Tue Jun 21 02:14:17 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDEA12D0B8 for ; Tue, 21 Jun 2016 02:14:16 -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 se3Utiek_wBT for ; Tue, 21 Jun 2016 02:14:14 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F1D12D08F for ; Tue, 21 Jun 2016 02:14:02 -0700 (PDT) Received: by mail-lb0-x235.google.com with SMTP id xp5so6473470lbb.0 for ; Tue, 21 Jun 2016 02:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=7lJ9r7vT+1JUWoIfWeUmLhbHZyMIBavvpbZDLt9Z38E=; b=SgtWf1iCazoyNDgwBsI925M32MSWAdprGhSX2K9a7uIdNzrYwsBs/aWYgT9++mkBIE c8oppgPkE76l1cAnHA9rpCIEtI8Dt6RWttqRLICDJ+Rf6mNBx3zzTnkzCLgVv+xyp2Ou EXncg1Kn0GwPJYz9rRV35QwLtCf/+VtxFZwKk7w8lEQ38N4wjjsg6fG38vrn7ZnOFM9J uyce7R2360OrRpSSfYJOF3l1IWO1SuDEPAkD0bmbMphPxVvDLcIeL1XWs5Qu81Q+XTqn qYI9JbON0ShtY0ZR77ceKizNuTEI2/rU/yQWxlW8sI3D/SAZxGukpBrH74uDbM+MUnF4 +kCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=7lJ9r7vT+1JUWoIfWeUmLhbHZyMIBavvpbZDLt9Z38E=; b=fZHlm3mVw52nmoTDe2x7U1tIrBeqfa3rOaID5GBfuM/vy4EPJ2S/VZbMC76wUfYpgz rG46YI3gbqTKCzPrcD6OeKTt9DP+drTWPpQaHdc5MR4CxbHKIU6Km/MOjbzDQfoWJMR+ KOwbzixHSJOo5IHGw1cvg8/PCkcOS+DaSTdoWs9vcx6T9m8azu/rxgk7L+Oc4l9jV60u sFeohBW8LXZOCfkxBcisUDbs3cfyyYpZaAnEuKhoCvNoyEYgUbO5GiFYQKWcotukocq0 prsP+htTseWFN5L19nmG9nDyfdMDWUJK/IirNBfrmpy+GJSImoDX2gDY5xs/KGBobQaY TvVw== X-Gm-Message-State: ALyK8tLSu984xbsB2WbREfN+h1Cz0ynwnqW8sqjc9ITiTpC+nb/vduB9Y/sEUug+ZkKi5A== X-Received: by 10.194.238.234 with SMTP id vn10mr18262221wjc.127.1466500440621; Tue, 21 Jun 2016 02:14:00 -0700 (PDT) Received: from triton.lan (116.35.199.146.dyn.plus.net. [146.199.35.116]) by smtp.gmail.com with ESMTPSA id t198sm1952936wmt.16.2016.06.21.02.13.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Jun 2016 02:14:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0F1C473F-10B1-429D-B3D6-8B47589A9F87" From: Alan Ford In-Reply-To: Date: Tue, 21 Jun 2016 10:14:06 +0100 Message-Id: <78D95FED-B451-4758-8E9A-3EF8ECE115BE@gmail.com> References: <8ED39350-21EE-43B6-9D30-8786A7709702@cs.pub.ro> <20160406214450.GA1732@dhcp-a286.meeting.ietf.org> <20160407173442.GJ1732@dhcp-a286.meeting.ietf.org> <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1283) Archived-At: Cc: MultiPath WG , Costin Raiciu Subject: Re: [multipathtcp] Bumping the MPTCP version number: some cons X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:14:16 -0000 --Apple-Mail=_0F1C473F-10B1-429D-B3D6-8B47589A9F87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoshi, On 21 Jun 2016, at 06:47, Yoshifumi Nishida wrote: > Hi Alan, >=20 > On Mon, Jun 20, 2016 at 12:57 PM, Alan Ford = wrote: >=20 > I guess support for stateless servers could be signalled in the flags, = i.e. the client saying "I will echo this reliably in the ACK if you want = me to" and the server also sets that flag if it wants the client do = this. >=20 > Hmm. the signal you mentioned will be used for reliability of the = third ACK, but won't be used for keyless syn? > I am guessing keyless syn cannot be supported by the flags. Yes... The SYN would still need to carry a key, but if the far end = chooses to use stateless operation, then the sender would send the key = again in the reliable ACK. And if the far end chooses to use = application-layer authentication, the key would be ignored. However, this would mean that the client would have to support both old = and new mechanisms, which would make implementations more complex. Regards, Alan --Apple-Mail=_0F1C473F-10B1-429D-B3D6-8B47589A9F87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Yoshi,

On 21 Jun 2016, at 06:47, Yoshifumi Nishida = wrote:

Hi Alan,

On Mon, Jun 20, 2016 at = 12:57 PM, Alan Ford <alan.ford@gmail.com> = wrote:

I guess = support for stateless servers could be signalled in the flags, i.e. the = client saying "I will echo this reliably in the ACK if you want me to" = and the server also sets that flag if it wants the client do = this.

Hmm. the signal you = mentioned will be used for reliability of the third ACK, but won't be = used for keyless syn?
I am guessing keyless syn cannot be = supported by the = flags.

Yes... = The SYN would still need to carry a key, but if the far end chooses to = use stateless operation, then the sender would send the key again in the = reliable ACK. And if the far end chooses to use application-layer = authentication, the key would be = ignored.

However, this would mean that the = client would have to support both old and new mechanisms, which would = make implementations more = complex.

Regards,
Alan

<= /body>= --Apple-Mail=_0F1C473F-10B1-429D-B3D6-8B47589A9F87-- From nobody Tue Jun 21 06:02:10 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1512D7B3 for ; Tue, 21 Jun 2016 06:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_MED=-2.3, 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 z3qTbXzcWZeN for ; Tue, 21 Jun 2016 06:01:57 -0700 (PDT) Received: from smtp.ehu.eus (smtp-backup.ehu.es [158.227.0.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED060128B44 for ; Tue, 21 Jun 2016 06:01:56 -0700 (PDT) Received: from smtp.ehu.eus (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5F753679B for ; Tue, 21 Jun 2016 15:01:54 +0200 (CEST) Received: from smtp.ehu.eus (smtp2.lgp.ehu.es [10.0.100.76]) by smtp3.lgp.ehu.es (Postfix) with ESMTPS id 4FF73679A for ; Tue, 21 Jun 2016 15:01:54 +0200 (CEST) Received: from smtp.ehu.eus (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 62C832887 for ; Tue, 21 Jun 2016 15:01:53 +0200 (CEST) Received: from U017737 (u017737.bi.ehu.es [158.227.66.100]) by smtp2 (Postfix) with ESMTPSA id 4AEDFC65 for ; Tue, 21 Jun 2016 15:01:52 +0200 (CEST) From: "Igor Lopez Orbe" To: References: <3630620a-7c08-385e-c40c-a924fd89f2ad@uclouvain.be> In-Reply-To: <3630620a-7c08-385e-c40c-a924fd89f2ad@uclouvain.be> Date: Tue, 21 Jun 2016 15:01:52 +0200 Message-ID: <003801d1cbbd$15185a30$3f490e90$@lopez@ehu.eus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHK8YNY15GWdnh6ROOsfEETKr/G8QAygZGw Content-Language: es X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (smtp2); Tue, 21 Jun 2016 15:01:53 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22404.007 X-TM-AS-Result: No--4.476-7.0-31-1 X-imss-scan-details: No--4.476-7.0-31-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (postfix.imss71); Tue, 21 Jun 2016 15:01:54 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp3.lgp.ehu.es); Tue, 21 Jun 2016 15:01:54 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (postfix.imss71); Tue, 21 Jun 2016 15:01:54 +0200 (CEST) Archived-At: Subject: Re: [multipathtcp] Interest in hackathon in Berlin? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:02:08 -0000 Hello, Will this extended API also fit the requirements defined for the advanced API (Appendix A) in the RFC6897? Best regards, Igor -----Mensaje original----- De: multipathtcp [mailto:multipathtcp-bounces@ietf.org] En nombre de Olivier Bonaventure Enviado el: lunes, 20 de junio de 2016 14:44 Para: philip.eardley@bt.com; multipathtcp@ietf.org Asunto: Re: [multipathtcp] Interest in hackathon in Berlin? Phil, > At the Berlin IETF meeting, there's a hackathon on the first weekend - > is there any interest in doing something with MPTCP at this? > > https://www.ietf.org/hackathon/96-hackathon.html > We are currently finalising an extended socket API that enables applications to control the operation of the Multipath TCP implementation in the Linux kernel. If there are people interested in looking at how applications can be modified to better utilise MPTCP, this could be a good objective for a hackathon Olivier _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 23 20:15:33 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9C12D882 for ; Thu, 23 Jun 2016 20:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, 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 KViGEoM5IF6n for ; Thu, 23 Jun 2016 20:15:29 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC4712D87D for ; Thu, 23 Jun 2016 20:15:29 -0700 (PDT) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A1AB527848D for ; Fri, 24 Jun 2016 12:15:27 +0900 (JST) Received: by mail-yw0-f176.google.com with SMTP id v77so89409589ywg.0 for ; Thu, 23 Jun 2016 20:15:27 -0700 (PDT) X-Gm-Message-State: ALyK8tJwGBn+bkKRpKcxgQGsIdafVnd8XI+FLC/Ton8VN/Ddj2rCQH2yln4chu0siXurXFrwUxXtaGybmecFzw== X-Received: by 10.13.204.83 with SMTP id o80mr1396843ywd.296.1466738126215; Thu, 23 Jun 2016 20:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Thu, 23 Jun 2016 20:15:25 -0700 (PDT) From: Yoshifumi Nishida Date: Thu, 23 Jun 2016 20:15:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary=001a114e3f08fde1cb0535fd94a6 Archived-At: Subject: [multipathtcp] Agenda for Berlin meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 03:15:32 -0000 --001a114e3f08fde1cb0535fd94a6 Content-Type: text/plain; charset=UTF-8 Hi, As the current agenda (https://datatracker.ietf.org/meeting/96/agenda.html) shows we are current having a 2 hour slot and a 1.5 hour slot. We are thinking that the first slot will be used to discuss charter items and progressing RFC6824bis, and the second slot will be used for other items such as new ideas or sorting out the remaining stuff from the first session. If you're planning to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation Also, please suggest us if you have some idea of the topics to be discussed at the venue. Ideas or opinions for hackathon are also welcome. Thanks, -- Yoshi & Phil --001a114e3f08fde1cb0535fd94a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As the current agenda (https://datatracker.ietf.org/meetin= g/96/agenda.html) shows we are current having a 2 hour slot and a 1.5 h= our slot.
We are thinking that the first slot will be used to discuss c= harter items and progressing RFC6824bis, and the second slot will be used f= or other items such as new ideas or sorting out the remaining stuff from th= e first session.

If you're planning to present something,= please provide us the following info.=C2=A0

=C2=A0 =C2=A01: = presenter's name
=C2=A0 =C2=A02: title
=C2=A0 =C2=A03: length of = the presentation

Also, please suggest us if you have some ide= a of the topics to be discussed at the venue.=C2=A0
Ideas or opin= ions for hackathon are also welcome.

Thanks,
--
Yos= hi & Phil
--001a114e3f08fde1cb0535fd94a6-- From nobody Fri Jun 24 02:55:18 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DBB12DA01 for ; Fri, 24 Jun 2016 02:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 bBHC7dGeXV7j for ; Fri, 24 Jun 2016 02:55:14 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6693812D14D for ; Fri, 24 Jun 2016 02:55:14 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 8BEAF67E24D; Fri, 24 Jun 2016 11:55:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 8BEAF67E24D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1466762105; bh=tU2YM90Gu56EHLqo1o9swncDVkjMj/hmlB80ZNjZEzA=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=a5N92TKdVReW3UYVbolUnd/VfjC1bD9RLT2MgN1T57Hbos051hrHyHxqb+QZUni/X luxio+KrCgkuqGN1imKY9PyBzADIpX23LArzffIXwUMvQphUod84NMTrK1ga8+8XwY crHX1qCsKGlDw/uRtNqOXt+Fstn7ubiEvENM+FIk= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99 at smtp-2 References: <3630620a-7c08-385e-c40c-a924fd89f2ad@uclouvain.be> <003801d1cbbd$15185a30$3f490e90$@lopez@ehu.eus> To: Igor Lopez Orbe , multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <11c9f72b-40e7-0fc9-4cf5-1ab01188fd3b@uclouvain.be> Date: Fri, 24 Jun 2016 11:55:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <003801d1cbbd$15185a30$3f490e90$@lopez@ehu.eus> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 8BEAF67E24D.A4DB1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Interest in hackathon in Berlin? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 09:55:17 -0000 Hello, > > Will this extended API also fit the requirements defined for the advanced > API (Appendix A) in the RFC6897? We will prepare a draft for the Berlin meeting that explains the operation of the API. Looking at the requirements from RFC6897, the following ones are supported : > > REQ5: An application should be able to establish MPTCP connections > without using IP addresses as locators. We currently expose the IP addresses to the application and the application used them to create subflows. It could be possible to add an abstraction about the low-level socket API to meet this kind of requirement. > REQ6: An application should be able to obtain usage information and > statistics about all subflows (e.g., ratio of traffic sent > via this subflow). The API exposes subflows to the application. On Linux, the TCP_INFO socket option allows to retrieve stats about the subflows. Our API supports that on a per subflow basis. > REQ7: An application should be able to request a change in the > number of subflows in use, thus triggering removal or > addition of subflows. An even finer control granularity > would be a request for the establishment of a specific > subflow to a provided destination or a request for the > termination of a specified, existing subflow. Our API allows the application to create/terminate subflows at any time. > REQ8: An application should be able to inform the MPTCP > implementation about its high-level performance requirements, > e.g., in the form of a profile. This is beyond the scope of a low-level API, but a higher level API such as socket intents could be built on top of that. > REQ9: An application should be able to indicate communication > characteristics, e.g., the expected amount of data to be > sent, the expected duration of the connection, or the > expected rate at which data is provided. Applications may in > some cases be able to forecast such properties. If so, such > information could be an additional input parameter for > heuristics inside the MPTCP implementation, which could be > useful, for example, to decide when to set up additional > subflows. Same comment as REQ8 > REQ10: An application should be able to control the automatic > establishment/termination of subflows. This would imply a > selection among different heuristics of the path manager, > e.g., 'try as soon as possible', 'wait until there is a bunch > of data', etc. This is not currently supported but the API exposes events that allow the application to control the creation/termination of subflows. > REQ11: An application should be able to set preferred subflows or > subflow usage policies. This would result in a selection > among different configurations of the multipath scheduler. > For instance, an application might want to use certain > subflows as backup only. The API allows to set MP_PRIO on a per subflow basis. Selecting a scheduler on a per connection basis could be possible but it not yet completely implemented. > REQ12: An application should be able to control the level of > redundancy by telling whether segments should be sent on more > than one path in parallel. The Multipath TCP implementation in the Linux kernel does not currently support this kind of redundancy. > REQ13: An application should be able to control the use of fate- > sharing of the MPTCP connection and the initial subflow, > e.g., to overwrite system policies. I'm not sure that I understand this requirement > REQ14: An application should be able to register for callbacks to be > informed of changes to subflows on an MPTCP connection. This > "push" interface would allow the application to make timely > logging and configuration changes, if required, and would > avoid frequent polling of information. This is part of the ongoing work Olivier From nobody Fri Jun 24 09:05:05 2016 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E21A12DCC7; Fri, 24 Jun 2016 09:00:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160051.10933.66203.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:51 -0700 Archived-At: Cc: multipathtcp@ietf.org, ietf@kuehlewind.net Subject: [multipathtcp] mptcp - Requested sessions have been scheduled for IETF 96 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:51 -0000 Dear Philip Eardley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mptcp Session 1 (2:00:00) Monday, Afternoon Session II 1540-1740 Room Name: Charlottenburg I size: 80 --------------------------------------------- mptcp Session 2 (2:00:00) Wednesday, Afternoon Session I 1400-1530 Room Name: Tiergarten size: 110 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Multipath TCP Area Name: Transport Area Session Requester: Philip Eardley Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: ippm tcpinc tcpm tsvarea tsvwg lmap tls Second Priority: taps netext mif iccrg rtcweb Third Priority: nfvrg sdnrg Special Requests: sessions on separate days - preferably separated by a day. please avoid any transport area BoFs --------------------------------------------------------- From nobody Mon Jun 27 05:07:20 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061D12D122 for ; Mon, 27 Jun 2016 05:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 FxXS62KoOFnW for ; Mon, 27 Jun 2016 05:07:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 C044412D107 for ; Mon, 27 Jun 2016 05:07:08 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHVJi-0003YO-3O for multipathtcp@ietf.org; Mon, 27 Jun 2016 14:07:06 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHVJh-0002od-Bj for multipathtcp@ietf.org; Mon, 27 Jun 2016 14:07:05 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2016 14:07:05 +0200 References: <20160627120227.5289.61784.idtracker@ietfa.amsl.com> To: multipathtcp@ietf.org Message-Id: <03A32E7C-73B2-468A-BADC-6081007BDDEE@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total rcpts 43670 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D227565134314B7C26509F8EDD3AB142AF07BE37 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10623 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [multipathtcp] Fwd: New Version Notification for draft-barik-mptcp-lisa-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 12:07:19 -0000 Hi all, This is essentially a keep-alive, as the old draft has expired. We were told that we'll probably get a slot (thanks chairs!) to present = results that were asked for in our last presentation (Yokohama). Code will very soon be available from http://heim.ifi.uio.no/runabk/lisa Cheers, Michael (and the other LISA authors) > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-barik-mptcp-lisa-01.txt > Date: 27 Jun 2016 14:02:27 CEST > To: Runa Barik , Simone Ferlin , = "Michael Welzl" > Resent-From: >=20 >=20 > A new version of I-D, draft-barik-mptcp-lisa-01.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-barik-mptcp-lisa > Revision: 01 > Title: A Linked Slow-Start Algorithm for MPTCP > Document date: 2016-06-27 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-barik-mptcp-lisa-01.txt > Status: = https://datatracker.ietf.org/doc/draft-barik-mptcp-lisa/ > Htmlized: https://tools.ietf.org/html/draft-barik-mptcp-lisa-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-barik-mptcp-lisa-01 >=20 > Abstract: > This document describes the LISA (Linked Slow-Start Algorithm) for > Multipath TCP (MPTCP). Currently during slow-start, subflows behave > like independent TCP flows making MPTCP unfair to cross-traffic and > causing more congestion at the bottleneck. This also yields more > losses among the MPTCP subflows. LISA couples the initial windows > (IW) of MPTCP subflows during the initial slow-start phase to remove > this adverse behavior. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jun 29 13:57:47 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7318F12D697 for ; Wed, 29 Jun 2016 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 AgxqlfXpq4R5 for ; Wed, 29 Jun 2016 13:57:43 -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 3064712D7C1 for ; Wed, 29 Jun 2016 13:57:43 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5TKv7Rl012892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2016 13:57:08 -0700 (PDT) To: Michael Welzl , multipathtcp@ietf.org References: <20160627120227.5289.61784.idtracker@ietfa.amsl.com> <03A32E7C-73B2-468A-BADC-6081007BDDEE@ifi.uio.no> From: Joe Touch Message-ID: <57743622.2090803@isi.edu> Date: Wed, 29 Jun 2016 13:57:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <03A32E7C-73B2-468A-BADC-6081007BDDEE@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-barik-mptcp-lisa-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 20:57:45 -0000 At least in part, this sounds a little like RFC2140 IW-sharing during new "connection" start coupled with CM-style ongoing sharing. A paragraph discussing both might be useful. Joe On 6/27/2016 5:07 AM, Michael Welzl wrote: > Hi all, > > This is essentially a keep-alive, as the old draft has expired. > We were told that we'll probably get a slot (thanks chairs!) to present results that were asked for in our last presentation (Yokohama). > Code will very soon be available from http://heim.ifi.uio.no/runabk/lisa > > Cheers, > Michael (and the other LISA authors) > > >> Begin forwarded message: >> >> From: >> Subject: New Version Notification for draft-barik-mptcp-lisa-01.txt >> Date: 27 Jun 2016 14:02:27 CEST >> To: Runa Barik , Simone Ferlin , "Michael Welzl" >> Resent-From: >> >> >> A new version of I-D, draft-barik-mptcp-lisa-01.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >> >> Name: draft-barik-mptcp-lisa >> Revision: 01 >> Title: A Linked Slow-Start Algorithm for MPTCP >> Document date: 2016-06-27 >> Group: Individual Submission >> Pages: 8 >> URL: https://www.ietf.org/internet-drafts/draft-barik-mptcp-lisa-01.txt >> Status: https://datatracker.ietf.org/doc/draft-barik-mptcp-lisa/ >> Htmlized: https://tools.ietf.org/html/draft-barik-mptcp-lisa-01 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-barik-mptcp-lisa-01 >> >> Abstract: >> This document describes the LISA (Linked Slow-Start Algorithm) for >> Multipath TCP (MPTCP). Currently during slow-start, subflows behave >> like independent TCP flows making MPTCP unfair to cross-traffic and >> causing more congestion at the bottleneck. This also yields more >> losses among the MPTCP subflows. LISA couples the initial windows >> (IW) of MPTCP subflows during the initial slow-start phase to remove >> this adverse behavior. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 30 19:48:00 2016 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8A12D08D for ; Thu, 30 Jun 2016 19:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 saoa_Bw1fOh6 for ; Thu, 30 Jun 2016 19:47:56 -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 06B0512B077 for ; Thu, 30 Jun 2016 19:47:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMY91183; Fri, 01 Jul 2016 02:47:52 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 1 Jul 2016 03:47:50 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 1 Jul 2016 10:47:47 +0800 From: Mingui Zhang To: "philip.eardley@bt.com" , "sarikaya@ieee.org" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Thread-Index: AQHRvDS7HI9JfmbW4UOj9XGa1EY3EJ/e2NIAgCQl5AA= Date: Fri, 1 Jul 2016 02:47:47 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787CE22C1@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5775D9D9.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b7356afac8419864b0fedb55675a86b0 Archived-At: Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 02:47:58 -0000 Hi, In the paired MPTCP proxies mechanism, there is user's TCP session and ther= e is also multipath TCP session. It is a TCP over TCP idea, correct?=20 As for TCP over TCP, the following page explains why an internal meltdown e= ffect would take place due to the interaction between two leveled retransmi= ssion mechanisms.=20 http://sites.inka.de/bigred/devel/tcp-tcp.html Do we have solid solutions for this issue nowadays? Thanks, Mingui > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Wednesday, June 08, 2016 5:54 PM > To: sarikaya@ieee.org; multipathtcp@ietf.org > Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > I believe you're right that such work would be outside the charter. >=20 > We're hoping (if we get 2 sessions) in Berlin to have some discussion abo= ut > potential re-chartering. In practice we haven't managed to get much work > focussed specifically on meeting the current charter item on proxy (there= was > some individual drafts a while back) - but there seems to be quite a bit = of > industry work on proxies (beyond charter's single-ended proxy). So potent= ial > discussion topic >=20 > >From my perspective there seems to be some operator interest in hybrid. = See > for instance the discussions in banana bar-bofs we've had at last couple = of ietfs - > including description of the DT deployment. (note, not all hybrid solutio= ns use > mptcp) >=20 > Best wishes > phil >=20 > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Be= hcet > Sarikaya > Sent: 01 June 2016 19:38 > To: multipathtcp@ietf.org > Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07 >=20 > Hi all, >=20 > Recent mails in this thread came to my attention because I work on the hy= brid > access network issues and wish to convey my views on some of the issues > discussed. >=20 > First of all, the claims that there is strong operator interest on this i= s over blown. > Hybrid access is based on offloading some CPE traffic to 3G/LTE network, = I don't > think mobile operators are fond of such a thing. >=20 > Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP in= to MPTCP > and requires Concentrators to convert back MPTCP into UDP or TCP is a com= plex > process. The crux of this is the problems arising from the use of MPTCP f= or > tunneling, which is what this draft is advocating. >=20 > Here I recommend Joe Touch's Intarea draft > https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt > on IP Tunnels in the Internet Architecture. IETF developed many tunneling > protocols which are surveyed in this draft but none of them are TCP/MPTCP > based. > I also question suitability of this work to the charter. There is this ch= arter text: > Finally, the working group will explore whether an MPTCP-aware > middlebox would be useful, where at least one end host is MPTCP-enabled= . > For example, potentially helping MPTCP's incremental deployment by > allowing only one end host to be MPTCP-enabled and the middlebox acts a= s > an MPTCP proxy for the other end host, which runs TCP; and potentially > helping some mobility scenarios, where the middlebox acts as an anchor > between two MPTCP-enabled hosts. The working group will detail what rea= l > problems an MPTCP-enabled middlebox might solve, how it would impact th= e > Multipath TCP architecture (RFC6182), what proxy approach might be > justified as compared against alternative solutions to the problems, an= d > the likely feasibility of solving the technical and security issues. >=20 > This draft has a middlebox called Concentrator but it is not trying to en= able > MPTCP hosts to communicate with TCP hosts, it is just tunneling the traff= ic. So > there is no charter item that fits to this draft. > I strongly suggest staying away from making MPTCP a tunneling protocol. >=20 > Regards, >=20 > Behcet >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp