Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Fri, 04 November 2016 15:24 UTC

Return-Path: <touch@isi.edu>
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 9BD5C129587 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 08:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 UgA7oAAzzz5n for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 08:24:07 -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 83C24129521 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 08:24:07 -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 uA4FNglb012454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Nov 2016 08:23:43 -0700 (PDT)
To: mohamed.boucadair@orange.com, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <e81c001b-ba6b-2990-9a62-09622e1339e1@uclouvain.be> <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com> <DA4EE00C-A54A-45C0-95B1-72F59BE5134D@tik.ee.ethz.ch> <AE721A71-0B9C-4A05-94AE-C104318DCF7F@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAC89D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <eb401a5b-4260-fbe4-935c-08343c2ed2fd@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAC92E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <09499b8c-1905-1fd4-c073-39d442ce3f8b@isi.edu>
Date: Fri, 04 Nov 2016 08:23:40 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAC92E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/MSKOUAlENfJDL1k86Sj81z-k990>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2016 15:24:08 -0000

Hi, Med,


On 11/4/2016 8:07 AM, mohamed.boucadair@orange.com wrote:
> Re-,
>
> I'm familiar with those documents, Joe. 
Given those docs explain why SYN data is not a viable way forward, can
you explain why you think it now is?

Further, EDO would be exactly the generic version of what Oliver
proposed. So if SYN data could be used, all we would need to do would be
to update the EDO WG doc to use the long ("extension") variant in the
SYN and SYN-ACK rather than the short ("supported") variant. But again,
that won't work.

> In addition to the proposal shared by Olivier, we are also considering this one: https://tools.ietf.org/html/draft-boucadair-tcpm-capability-option-00 for managed environments. 

That variant avoids 1 byte per kind, but only for 2-byte kinds. Those
options consume very little space in the SYN and even if they were
compressed to near zero the SYN would lack space to support a
combination of multibyte kinds. I.e., it adds complexity without
usefully addressing the problem of SYN space.

Joe