From nobody Sun Dec 3 12:09:13 2017 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 27E67127201; Sun, 3 Dec 2017 12:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puLr5kImUZdK; Sun, 3 Dec 2017 12:09:09 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0105.outbound.protection.outlook.com [104.47.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50AB12711B; Sun, 3 Dec 2017 12:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=67P0bx4bUgsd5DE/ReyXmRz66OK01NUOyV8F9rFHHXE=; b=cUxN8YN7huUDF1Vi3BnXydw+56UIBna1ZCdPINbXHe4zF35JMmVsAr1/ZrCAjo5C8U0pUVel9cStqVwC+zDJ94H8hl65PyceQe8HurGT+VbqyWNjTTXUkgm8sTa1GoqDjUBZnIlVHJiDTVr2N/d+zMeqiR6ieDSVVuhXleDf/rs= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sun, 3 Dec 2017 20:09:06 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2%17]) with mapi id 15.20.0282.002; Sun, 3 Dec 2017 20:09:05 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" , multipathtcp Thread-Topic: Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQ Date: Sun, 3 Dec 2017 20:09:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [131.228.32.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 6:k1sk4ksCduj9m7rjUJFXamJxiKBTAgqbrdG/hC6d16g/nVAPN0ACivArXDXX2oxD/oniWiq/n5X1cukpAtbaZZGiNjoI1OdeZ+0nx9AIxmJU45ueLjWL/5R/1+C0FHWXv0MwhztwycX08mfGrhTwvj8a2JWPz9KCGVyRLGtORG0jOxdmNQUX2/ONeSEreB3czTwnSpMIUPMIWQrNJkuw8BZBjqhdNw95m5ZDghc7mc6qkLiWBqR8nmEasNBbMY/jUDYAI1qN2quzv+s0SiLlbEctrbABg7ZCERp0wmH+ugF53Qujx9GnhUtGAOCfi4wb6Ge51BRvVdORuUcurlm5QHe+LRK8PClP8wF+TjQ1V/Y=; 5:nTBcefqpL1Xbdws5idVXvJtD1CUE055t17JeY+oY3p9RLfnUuSGEGIMDFCDJvEdhOy9XglyKDtbKr5J7afxGCY0J26BQfDRsef6R1gvfYwgIceqn3i2BWpx64HIlm1lJfmNqcBqOSWdqoqsC5YqoQj8KuWtv7VuArxpzF0AQejU=; 24:hyqNdv8x/UOrB3XB1opUk3nM0xr5oMR39kYRiXyMEa4jUdmtUOzOxW57lMOk3DYus6NfjeyxZLOtfnlfz2DNxY3JiNAM71ciyI2mCOJYB0Y=; 7:Hg1al+hM+imUh4KQlj6qIxAdEGMyJi/14NtfdeCyOo5n4Ct6VNdKAb8ajgS3jT10JWmzEymJZTdzcgPzZRsq25IoXriZ9H0Tua8vTdXTSw3RL3Q+X5GfQkY4+1XvyMZNNKEzdM2fcs8TfqvzRdxn99wRrTqjGyqJkc7pznLY6yWqd8WCKGJxHUqHsbqxujOlbXpVHqAAa727JbWhbDmKHO1lNBly/aow4+aBmoeFaet/RFkqRkSjpGc3NCXtuBC2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 733f01e7-8356-4a62-47dc-08d53a89b4ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:AM5PR0701MB2546; x-ms-traffictypediagnostic: AM5PR0701MB2546: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2546; x-forefront-prvs: 05102978A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(366004)(39860400002)(53754006)(199003)(13464003)(189002)(3846002)(966005)(7696005)(3280700002)(2950100002)(101416001)(102836003)(110136005)(450100002)(478600001)(68736007)(6506006)(7736002)(305945005)(316002)(6116002)(53936002)(5250100002)(33656002)(53546010)(6436002)(99286004)(2900100001)(81166006)(25786009)(2940100002)(105586002)(81156014)(2501003)(86362001)(106356001)(97736004)(8936002)(74316002)(230783001)(76176011)(55016002)(66066001)(5660300001)(9686003)(3660700001)(2906002)(54356011)(8676002)(189998001)(6306002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 733f01e7-8356-4a62-47dc-08d53a89b4ad X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 20:09:05.7572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 20:09:11 -0000 Now with the correct address of the MPTCP working group... Sorry Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Nokia - DE/Stuttgart) > Sent: Sunday, December 03, 2017 9:05 PM > To: tcpm@ietf.org > Cc: mptcp@ietf.org > Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp- > converters ? >=20 > Hi all, >=20 > The chairs would like to understand if there is interest in draft-bonaven= ture- > mptcp-converters within the TCPM working group. >=20 > In principle, draft-bonaventure-mptcp-converters could be applicable to > several TCP options, not only MPTCP. The assumption is that a document > published by TCPM would be generic and apply not only to MPTCP. It is > understood that a MPTCP-specific document could be handled in the MPTCP > working group instead (which is CCed). >=20 > The TCPM charter states that the "WG mostly focuses on maintenance issues > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > interfaces that maintain TCP's utility". Assisting the deployment of new = TCP > extensions could be understood as one way to ensure TCP's utility. >=20 > The chairs therefore ask for community feedback on whether to add a new > milestone to the TCPM charter . >=20 > =A0=A0 Dec 2018 Submit document on TCP converters to the IESG for pub= lication > as an Experimental RFC >=20 > . and adopt draft-bonaventure-mptcp-converters as a starting point. >=20 > Please reply to this e-mail within the next three weeks if you are intere= sted > in working on this document in the TCPM working group (e.g., by > contributing, reviewing) and if you support its acceptance in the TCPM > working group. >=20 > Please also speak up if you have any concerns regarding accepting this > document in TCPM. >=20 > Thanks >=20 > Michael > (on behalf of the TCPM chairs) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Dec 3 12:30:18 2017 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 DE56E127011; Sun, 3 Dec 2017 12:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 OiGpw7GIKcsL; Sun, 3 Dec 2017 12:30:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 1AE26126D85; Sun, 3 Dec 2017 12:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E0TL++UeWgrJDiCormpa/JtzcIENCrjFuGExoQz3q6c=; b=kDrF1Xg2yNAe0e/WsznRvxmxZE KMnMKlG42P9CktCSuKhvPx3X9BIotgPC8mfIsxoqFv0kcPH4VWZUtS1kFENtpLkYOq1R5pGEUIwt2 1sVskC+yKcNFMzYf8Cak0NYe2XRL7gj5ITf0LAfsu0c6E+3YbrkdNdpCiZ06sWKK8mUi8PmcHuQq4 RPKqgmWBGhS/emNknqzaOIU1/3JT/ELWsl1q9eraW83FpiU7qy+gKpf5rQ6VWXD/eT3Se9yhEXZfI wFZfnUvE1py/zxxFwa9N6P1QpHIGOPMtQGLTQquEgo1yPcybE3JdrbaWCAUS6r17XdcvNoQmBFH6Z Hm/M7RIg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64009 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eLats-0040Pq-Jp; Sun, 03 Dec 2017 15:30:09 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: From: Joe Touch Message-ID: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> Date: Sun, 3 Dec 2017 12:30:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 20:30:12 -0000 On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > The TCPM charter states that the "WG mostly focuses on maintenance issues > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > interfaces that maintain TCP's utility". Assisting the deployment of new TCP > extensions could be understood as one way to ensure TCP's utility. "The client places the destination address and port number of the target Server in the payload of the SYN sent to the Converter by leveraging TCP Fast Open [RFC7413]." I disagree with any use of TCP SYN payloads as anything other than application data. At best, the mechanism attempts to re-create an extension of TCPMUX, which was deprecated for good reason. Additionally, this is claimed to be an application proxy, which would be out of scope both for TCPM and to modify the definition of the contents or directly manipulate the headers of any TCP segments. My position is as follows:     - I don't think this doc should be adopted by the WG     - Whether the doc is adopted or not, I have no interest in continuing to try to repair its significant (and IMO fatal) flaws Joe From nobody Sun Dec 3 22:28:14 2017 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 B5DB3126E01; Sun, 3 Dec 2017 22:28:12 -0800 (PST) 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_H4=-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 cicu54XgqvhY; Sun, 3 Dec 2017 22:28:10 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E419124205; Sun, 3 Dec 2017 22:28:10 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1CF6B1C07D1; Mon, 4 Dec 2017 07:28:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id EFEF5180064; Mon, 4 Dec 2017 07:28:08 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 07:28:08 +0100 From: To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQABWN+jA= Date: Mon, 4 Dec 2017 06:28:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0855E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 06:28:13 -0000 Hi Michael, all,=20 I support adoption of the draft.=20 Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Scharf, Michael (Nokia - DE/Stuttgart) > Envoy=E9=A0: dimanche 3 d=E9cembre 2017 21:09 > =C0=A0: tcpm@ietf.org; multipathtcp > Objet=A0: [multipathtcp] Working group acceptance of draft-bonaventure- > mptcp-converters ? >=20 > Now with the correct address of the MPTCP working group... >=20 > Sorry >=20 > Michael >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > > (Nokia - DE/Stuttgart) > > Sent: Sunday, December 03, 2017 9:05 PM > > To: tcpm@ietf.org > > Cc: mptcp@ietf.org > > Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp- > > converters ? > > > > Hi all, > > > > The chairs would like to understand if there is interest in draft- > bonaventure- > > mptcp-converters within the TCPM working group. > > > > In principle, draft-bonaventure-mptcp-converters could be applicable to > > several TCP options, not only MPTCP. The assumption is that a document > > published by TCPM would be generic and apply not only to MPTCP. It is > > understood that a MPTCP-specific document could be handled in the MPTCP > > working group instead (which is CCed). > > > > The TCPM charter states that the "WG mostly focuses on maintenance > issues > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > interfaces that maintain TCP's utility". Assisting the deployment of ne= w > TCP > > extensions could be understood as one way to ensure TCP's utility. > > > > The chairs therefore ask for community feedback on whether to add a new > > milestone to the TCPM charter . > > > > =A0=A0 Dec 2018 Submit document on TCP converters to the IESG for > publication > > as an Experimental RFC > > > > . and adopt draft-bonaventure-mptcp-converters as a starting point. > > > > Please reply to this e-mail within the next three weeks if you are > interested > > in working on this document in the TCPM working group (e.g., by > > contributing, reviewing) and if you support its acceptance in the TCPM > > working group. > > > > Please also speak up if you have any concerns regarding accepting this > > document in TCPM. > > > > Thanks > > > > Michael > > (on behalf of the TCPM chairs) > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Dec 3 23:00:21 2017 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 69862126BF3; Sun, 3 Dec 2017 23:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7y0MJ6agalH7; Sun, 3 Dec 2017 23:00:18 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51119124205; Sun, 3 Dec 2017 23:00:18 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id D050CA0958; Mon, 4 Dec 2017 08:00:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id B1EA940084; Mon, 4 Dec 2017 08:00:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 08:00:16 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQ///1pgD//0hNQA== Date: Mon, 4 Dec 2017 07:00:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> In-Reply-To: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.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.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 07:00:20 -0000 SGkgSm9lLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvZSBUb3VjaA0KPiBFbnZvecOpwqA6IGRpbWFuY2hl IDMgZMOpY2VtYnJlIDIwMTcgMjE6MzANCj4gw4DCoDogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAt IERFL1N0dXR0Z2FydCk7IHRjcG1AaWV0Zi5vcmc7IG11bHRpcGF0aHRjcA0KPiBPYmpldMKgOiBS ZTogW3RjcG1dIFttdWx0aXBhdGh0Y3BdIFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5jZSBvZiBkcmFm dC0NCj4gYm9uYXZlbnR1cmUtbXB0Y3AtY29udmVydGVycyA/DQo+IA0KPiANCj4gDQo+IE9uIDEy LzMvMjAxNyAxMjowOSBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkg d3JvdGU6DQo+ID4gVGhlIFRDUE0gY2hhcnRlciBzdGF0ZXMgdGhhdCB0aGUgIldHIG1vc3RseSBm b2N1c2VzIG9uIG1haW50ZW5hbmNlDQo+IGlzc3Vlcw0KPiA+IChlLmcuLCBidWcgZml4ZXMpIGFu ZCBtb2Rlc3QgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wsIGFsZ29yaXRobXMsIGFuZA0KPiA+IGlu dGVyZmFjZXMgdGhhdCBtYWludGFpbiBUQ1AncyB1dGlsaXR5Ii4gQXNzaXN0aW5nIHRoZSBkZXBs b3ltZW50IG9mIG5ldw0KPiBUQ1ANCj4gPiBleHRlbnNpb25zIGNvdWxkIGJlIHVuZGVyc3Rvb2Qg YXMgb25lIHdheSB0byBlbnN1cmUgVENQJ3MgdXRpbGl0eS4NCj4gDQo+ICAgIlRoZSBjbGllbnQg cGxhY2VzIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBwb3J0IG51bWJlciBvZiB0aGUNCj4g ICAgdGFyZ2V0IFNlcnZlciBpbiB0aGUgcGF5bG9hZCBvZiB0aGUgU1lOIHNlbnQgdG8gdGhlIENv bnZlcnRlciBieQ0KPiAgICBsZXZlcmFnaW5nIFRDUCBGYXN0IE9wZW4gW1JGQzc0MTNdLiINCj4g DQo+IEkgZGlzYWdyZWUgd2l0aCBhbnkgdXNlIG9mIFRDUCBTWU4gcGF5bG9hZHMgYXMgYW55dGhp bmcgb3RoZXIgdGhhbg0KPiBhcHBsaWNhdGlvbiBkYXRhLg0KDQpbTWVkXSBUaGUgZGF0YSB0aGF0 IGFyZSBpbnNlcnRlZCBpbiBPTkUgc2luZ2xlIFNZTiBpcyB0aGUgYXBwbGljYXRpb24gKHByb3h5 KSBkYXRhLiBXaGF0J3MgaXMgd3Jvbmcgd2l0aCB0aGF0PyANCg0KIEF0IGJlc3QsIHRoZSBtZWNo YW5pc20gYXR0ZW1wdHMgdG8gcmUtY3JlYXRlIGFuDQo+IGV4dGVuc2lvbiBvZiBUQ1BNVVgsIHdo aWNoIHdhcyBkZXByZWNhdGVkIGZvciBnb29kIHJlYXNvbi4NCg0KW01lZF0gSSBkb24ndCB1bmRl cnN0YW5kIHRoZSByZWZlcmVuY2UgdG8gVENQIHRjcG11eC4gQnV0IGV2ZW4gaWYgd2UgYXNzdW1l IHRoZXJlIGlzIGEgc2ltaWxhcml0eSBiZXR3ZWVuIHRoZSB0d28gcHJvcG9zYWxzLCBsZXQncyBh c3Nlc3Mgd2hldGhlciB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIGRlcHJlY2F0aW5nIHRjcG11 eCwgYXMgY2FsbGVkIGluIFJGQzc4MDUsIGFwcGx5IGZvciB0aGUgY29udmVydGVyIGNhc2U6DQoN CiAgICAgICogIEl0IG1vZGlmaWVzIHRoZSBUQ1AgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHNl bWFudGljcyBieSBhbHNvDQogICAgICAgICBjb21wbGV0aW5nIHRoZSB0aHJlZS13YXkgaGFuZHNo YWtlIHdoZW4gYSBzZXJ2aWNlIGlzIG5vdA0KICAgICAgICAgYXZhaWxhYmxlLg0KDQpOb3QgYXBw bGljYWJsZS4NCg0KICAgICAgKiAgSXQgcmVxdWlyZXMgYWxsIG5ldyBjb25uZWN0aW9ucyB0byBi ZSByZWNlaXZlZCBvbiBhIHNpbmdsZQ0KICAgICAgICAgcG9ydCwgd2hpY2ggbGltaXRzIHRoZSBu dW1iZXIgb2YgY29ubmVjdGlvbnMgYmV0d2VlbiB0d28NCiAgICAgICAgIG1hY2hpbmVzLg0KDQpP bmx5IFRDUCBjb25uZWN0aW9ucyB0aGF0IGFyZSBlbGlnaWJsZSB0byBhIG5ldHdvcmstYXNzaXN0 YW5jZSBzZXJ2aWNlIGFyZSBmb3J3YXJkZWQgdG8gdGhlIGNvbnZlcnRlciwgd2hpY2ggbGlzdGVu cyBvbiBhIHNlcnZpY2UgcG9ydC4gV2UgdXNlZCB0byBoYXZlIGEgZGVzaWduIHdoaWNoIGRvZXMg bm90IHJlc3RyaWN0IGNvbm5lY3Rpb25zIHRvIGJlIGJvdW5kIHRvIGEgcG9ydCBudW1iZXIsIGJ1 dCB3ZSBtb2RpZmllZCB0aGUgZGVzaWduIGFzIHBlciB5b3VyIHJlY29tbWVuZGF0aW9uLiBJZiB5 b3Ugbm93IHRoaW5rIHRoYXQgeW91ciByZWNvbW1lbmRhdGlvbiB3YXMgbm90IGEgZ29vZCBhZHZp Y2UgZm9yIHVzLCB3ZSBjYW4gZWFzaWx5IGZpeCB0aGlzLiAgDQoNCiAgICAgICogIEl0IGNvbXBs aWNhdGVzIGZpcmV3YWxsIGltcGxlbWVudGF0aW9uIGFuZCBtYW5hZ2VtZW50IGJlY2F1c2UNCiAg ICAgICAgIGFsbCBzZXJ2aWNlcyBzaGFyZSB0aGUgc2FtZSBwb3J0IG51bWJlci4NCg0KVGhpcyBv bmUgaXMgZGViYXRhYmxlIGJlY2F1c2UgaXQgaXMgcmVhbGx5IGRlcGxveW1lbnQtc3BlY2lmaWMu IEEgZGVwbG95aW5nIGluIA0KDQogICAgICAqICBUaGVyZSBhcmUgdmVyeSBsaW1pdGVkIGRlcGxv eW1lbnRzLCBhbmQgdGhlc2UgYXJlIG5vdCB1c2VkIGluDQogICAgICAgICBhbiBJbnRlcm5ldCBj b250ZXh0LiAgKFRoZSBvbmx5IHJlcG9ydGVkIHVzZSBpcyBmb3IgU0dJJ3MgRGF0YQ0KICAgICAg ICAgTWlncmF0aW9uIEZhY2lsaXR5IGluIHByaXZhdGUgbmV0d29ya3MuKQ0KDQpOb3QgYXBwbGlj YWJsZS4gDQoNCj4gDQo+IEFkZGl0aW9uYWxseSwgdGhpcyBpcyBjbGFpbWVkIHRvIGJlIGFuIGFw cGxpY2F0aW9uIHByb3h5LCB3aGljaCB3b3VsZCBiZQ0KPiBvdXQgb2Ygc2NvcGUgYm90aCBmb3Ig VENQTSBhbmQgdG8gbW9kaWZ5IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBjb250ZW50cw0KPiBvciBk aXJlY3RseSBtYW5pcHVsYXRlIHRoZSBoZWFkZXJzIG9mIGFueSBUQ1Agc2VnbWVudHMuDQo+IA0K PiBNeSBwb3NpdGlvbiBpcyBhcyBmb2xsb3dzOg0KPiDCoMKgwqAgLSBJIGRvbid0IHRoaW5rIHRo aXMgZG9jIHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSBXRw0KPiDCoMKgwqAgLSBXaGV0aGVyIHRo ZSBkb2MgaXMgYWRvcHRlZCBvciBub3QsIEkgaGF2ZSBubyBpbnRlcmVzdCBpbg0KPiBjb250aW51 aW5nIHRvIHRyeSB0byByZXBhaXIgaXRzIHNpZ25pZmljYW50IChhbmQgSU1PIGZhdGFsKSBmbGF3 cw0KDQpbTWVkXSBKb2UsIHdlIGhhdmUgdGFrZW4gaW50byBhY2NvdW50IG1hbnkgb2YgdGhlIGNv bW1lbnRzIHlvdSByYWlzZWQgaW4gdGhlIHBhc3QgKGUuZy4sIGRlZmluZSB0aGUgcHJvcG9zYWwg YXMgYW4gYXBwbGljYXRpb24gcHJveHksIG1ha2UgdXNlIG9mIGEgc2VydmljZSBwb3J0LCBiZXR0 ZXIgaW50ZWdyYXRlIHdpdGggVEZPKS4gSXQgd291bGQgYmUgaGVscGZ1bCB0byBsaXN0IHNvbWUg b2YgdGhlICJmYXRhbCBmbGF3cyIgc28gdGhhdCB3ZSBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgdGhl c2UgYXJlIG5ldyBpc3N1ZXMuIFRoYW5rIHlvdS4NCg0KPiANCj4gSm9lDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcg bGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0K From nobody Mon Dec 4 10:25:41 2017 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 39D49127BA3 for ; Mon, 4 Dec 2017 10:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95Inzsg3Dmn2 for ; Mon, 4 Dec 2017 10:25:33 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A323B127B60 for ; Mon, 4 Dec 2017 10:25:32 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id i11so15993988wmf.4 for ; Mon, 04 Dec 2017 10:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/nALGvo7RaGhHNVwEjkFYPoAa+GCdVZgsdqeVN62/OQ=; b=jR5vs56jjZJQxV5kIT6Ty0hNVx/Pa9BtXmIQ8TBNHwy0vlFY42sofAlYqM4y2/r+P/ Qncr5yZSpjvL9YypLogPt6WJZIFPChFlaZ6UZbUYJXM4+wD9TlvQH5KGpXCv3xbor7Fs s1SYQzZJckhdn/I0cxdbwTtyPnMrbfK9ITfFrjOCXVue8oqAdtceP4qCzisE+sKoD7YQ 2vIdXR4/xAzvBIo0qjz7EhCXrXtWUoQ2Wi3gWYnrlfFXdskQA4/cTV16hTP7jEcyfsiO n4MLpwPcZiBMD7IRB08l9vUPXc+kcH8tHGsJ9BE3JBkliPQ04TvjTP8nYU6zMP7ulJLQ IM/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/nALGvo7RaGhHNVwEjkFYPoAa+GCdVZgsdqeVN62/OQ=; b=Nk7UEGc6wgduq/mIltXHWVGEJF8uKnTj5xsG65cxgc+91krPGmFIvCCaTyn42/zlIu /jhNygIuE8ID16cvcWIazzda94Ef2t01CFi/OnT3TlS4jOCgZVjiNW50KOahnilW/LXN xhDn1geKxwCHurpmJIsEMbZRjwLayis7n1ESBaUw6Kzm6EVzmc5ZT6jxQg0JlEzwECtL fTVmq8QciGMu5iGLw9EzMy9yxbj7+SxTZTvC74dC++5kWci3iwC1iihVOdLtccEBOYVi 9W67OucwFVDj743/GEbk7CaCOBBCqR2CBWmYr1n7yTSM9MIiwg7IGVgSfRJm3QmNsHEP RlhQ== X-Gm-Message-State: AKGB3mLrEv0fYIFyJtyV+NvDLL7ahpcnlY1UiroSwr4up2pG2S+huyw6 5nSCU1Zuib04Hd3cQ9c9XX2nm7zE0iIaaiWBv1bi4Q== X-Google-Smtp-Source: AGs4zMa3IL/SuSQh1i81xq01mexlY9k9/A0iNCZ+NOTqgA1FOwNFADTdlKqJXU0thHrj3TZY5lwmOUqg/zVdFTt0tfk= X-Received: by 10.28.49.195 with SMTP id x186mr3540756wmx.116.1512411930780; Mon, 04 Dec 2017 10:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.16.10 with HTTP; Mon, 4 Dec 2017 10:24:50 -0800 (PST) In-Reply-To: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Yuchung Cheng Date: Mon, 4 Dec 2017 10:24:50 -0800 Message-ID: To: Joe Touch Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 18:25:35 -0000 On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch wrote: > > > > On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > The TCPM charter states that the "WG mostly focuses on maintenance issues > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > interfaces that maintain TCP's utility". Assisting the deployment of new TCP > > extensions could be understood as one way to ensure TCP's utility. > > "The client places the destination address and port number of the > target Server in the payload of the SYN sent to the Converter by > leveraging TCP Fast Open [RFC7413]." > > I disagree with any use of TCP SYN payloads as anything other than > application data. At best, the mechanism attempts to re-create an > extension of TCPMUX, which was deprecated for good reason. > > Additionally, this is claimed to be an application proxy, which would be > out of scope both for TCPM and to modify the definition of the contents > or directly manipulate the headers of any TCP segments. > > My position is as follows: > - I don't think this doc should be adopted by the WG I too do not support the adoption for similar reasons above, even though I'd love to see more usage of TFO and MPTCP. TFO today is still facing bad middle-boxes issues and demands extreme conservative heuristics to deploy (see last presentation by Praveen in tcpm). Ultimately they need to be applied by either the client or the proposed converters. > - Whether the doc is adopted or not, I have no interest in > continuing to try to repair its significant (and IMO fatal) flaws > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 4 10:50:45 2017 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 DBE78128768; Mon, 4 Dec 2017 10:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evul_uopn_jo; Mon, 4 Dec 2017 10:50:43 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E47C126DCA; Mon, 4 Dec 2017 10:50:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,359,1508828400"; d="asc'?scan'208,217";a="243570526" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 04 Dec 2017 10:50:42 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 4 Dec 2017 10:50:42 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 4 Dec 2017 10:50:41 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 4 Dec 2017 10:50:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Pafi5FST+sWnFvAhFrpmY+fVz8Bo6F2hy0KMdYdf52c=; b=Ljl1KRspFEO1qm7H0967phZprXpBMI3sXvKgGPzJ5NseeT2N/OU1/bLiV14rh1kt6VW7xctc4K0PDsGm0VXyXPOFJSCVhFbZeraqW1NT/RDD64CNfAukJqxXgud3Ssnx7oCuMqmxif4DGGowVfNYqQucyCGPCoxf5DlAsn4q6Cw= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 4 Dec 2017 18:50:40 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0282.012; Mon, 4 Dec 2017 18:50:40 +0000 From: "Eggert, Lars" To: Yuchung Cheng CC: Joe Touch , multipathtcp , "tcpm@ietf.org" Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAALeqiAAAA5tKA Date: Mon, 4 Dec 2017 18:50:40 +0000 Message-ID: <37D903B3-BE49-4F28-B7F0-8D1EFA37220F@netapp.com> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:442b:8dd2:8561:cbf9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:YV9nx7AqNFCJWr5CGkyZs0215C1A19fUwOOGUH8vB3eUoxXR3FwCIsGHWgqKS8JV6BWR844QfCv/dPrsB+515NQa4VAJPtVsrCoFVQLLuC54uCfDzuquw2JcuKBiB7d5eCgmuw95vKTlH2ABXKyjz5za2QZCpjru4xiwaZ1lWJBWuwy+GGns9gsWq0gegigTj0C2UtoheytT88Q8nm8zp7JZsD19rFl1FY+oUv/17aY1mUBLd/rtamUnD8T4MgB1fbd6RU1hcOixDba2kQYdgIHR2MFFdItXK44MxCqbWibiKEbNijfMgCD0ZEYJQROAdc97xGZN2tM97fluukg74vawukZSdu/fCfn2BncHYCk=; 5:QXzQJ/E8MLocRN0kaZKN+auMqA6RSAyEoIgcAM0iebNZP8Wf3AtYxbyKDMVb2POxQReZfDystzNcCh7Wmg45gUyM5TINv37U5iRxbpEOkPj5CA4/qPgxLiLGsfarp8ehBCklP8sj/8Afxt2a5MDdlJhGw5QzvjGINIP4yQYOzxI=; 24:lZbXNSYcuAia1drnlq52NK1ZSqOLX1hlkXdRLYZ0PWg1ecvqwNtVt+b218OFFZSzqupwfb2UKTaJK7irENk5KLf4NVSgI41x3fc58nb20iQ=; 7:+IMyb93bJA0Vu+1JmuZGez3Fmq/mI7LtRP6xBYSUT+CN04M9A4RgCuKpiGrLosKaL8xXQUCAjBGCGPBJ0i+T60QYR3KLiXNGANNsXTdqyIXWKXgFzfXA8Qw1Iwy+kExl4wi2DeBq9ma0io2yiOj2MjtqBa81/1H7JgruY2eKP3Khnw0Rk8wI2yf3N88qJ9PBcfL+19h/ft/QBr1aGPOZbfrVP14+DjbOHSs2QcVi2eK5OHEh1lyX6FZXX1m9XwSW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c3e5157-13f7-4e6b-2b1c-08d53b47ea54 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(920507027)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 051158ECBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(189002)(24454002)(199003)(377424004)(2906002)(230783001)(54906003)(106356001)(105586002)(8936002)(189998001)(86362001)(57306001)(229853002)(83716003)(36756003)(50226002)(3280700002)(25786009)(2900100001)(3660700001)(81166006)(77096006)(6486002)(6436002)(6506006)(14454004)(81156014)(8676002)(478600001)(53936002)(101416001)(236005)(54896002)(82746002)(6512007)(6916009)(33656002)(76176011)(93886005)(99286004)(6116002)(102836003)(7736002)(2950100002)(316002)(34040400001)(4001150100001)(5660300001)(4326008)(97736004)(53546010)(68736007)(6246003)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c3e5157-13f7-4e6b-2b1c-08d53b47ea54 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2017 18:50:40.0238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 18:50:45 -0000 --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C Content-Type: multipart/alternative; boundary="Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2" --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-12-4, at 19:24, Yuchung Cheng wrote: > On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch > wrote: >> On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >>> The TCPM charter states that the "WG mostly focuses on maintenance = issues >>> (e.g., bug fixes) and modest changes to the protocol, algorithms, = and >>> interfaces that maintain TCP's utility". Assisting the deployment of = new TCP >>> extensions could be understood as one way to ensure TCP's utility. >>=20 >> "The client places the destination address and port number of the >> target Server in the payload of the SYN sent to the Converter by >> leveraging TCP Fast Open [RFC7413]." >>=20 >> I disagree with any use of TCP SYN payloads as anything other than >> application data. At best, the mechanism attempts to re-create an >> extension of TCPMUX, which was deprecated for good reason. >>=20 >> Additionally, this is claimed to be an application proxy, which would = be >> out of scope both for TCPM and to modify the definition of the = contents >> or directly manipulate the headers of any TCP segments. >>=20 >> My position is as follows: >> - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above +1 Lars --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2017-12-4, at 19:24, Yuchung Cheng <ycheng@google.com> = wrote:
On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch = <touch@strayalpha.com> wrote:
On 12/3/2017 12:09 PM, = Scharf, Michael (Nokia - DE/Stuttgart) wrote:
The TCPM charter states that the "WG mostly = focuses on maintenance issues
(e.g., bug fixes) and modest = changes to the protocol, algorithms, and
interfaces that = maintain TCP's utility". Assisting the deployment of new TCP
extensions could be understood as one way to ensure TCP's = utility.

 "The client = places the destination address and port number of the
  target Server in the payload of the SYN sent to = the Converter by
  leveraging TCP Fast Open = [RFC7413]."

I disagree with any use of TCP = SYN payloads as anything other than
application data. At = best, the mechanism attempts to re-create an
extension of = TCPMUX, which was deprecated for good reason.

Additionally, this is claimed to be an application proxy, = which would be
out of scope both for TCPM and to modify = the definition of the contents
or directly manipulate the = headers of any TCP segments.

My position is = as follows:
   - I don't think this doc = should be adopted by the WG
I too do not = support the adoption for similar reasons = above

+1

Lars
= --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2-- --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlolmP8ACgkQVLXDCb9w wVeSZBAAqfsPPLrs8ngsoIDhTVbuNM2abR14bKK5cLX0nSDWGfIO0KShp5mU6T3u xd5d8HDVrGC3+aB7ZiAaOulYHmDW46WV4p/Vq84B0vVMKXReeIZ5hDnJZIGQVAP7 sRi+g09MVWtcJQka7iUp1fwxK3SkTRKw+BXiT4rZuzn5jOhHiwc+R6FAhLsO/BOW hJdV0hnUZxZGlpHA1OitBoX1wb77p2SNCt7O4JxmQI7t9Dr4yanKo8iXmquUN9Ri SSdmD4QfuQPB0j6+vojhE9iPtjOjf9LmNBubgr2uP166q+JRtwomz0TgmqZGmyx+ lAkeALtMjximP3yMUojUvkUb2B4hmYtSBjJ7PI/PkFLpVu4Ef14pMhD6cakHPCbP 0uM1JhZZXo7QdX7E+PqQNzLB9g3IWuC+EPfE9lgGbzzKYh+UMYc3C8z2Aa9II4wt TBI6RMMU8ThOZcl0B+7m1HIMlN63t5HEVMmv5d5ibiP+Y0FoTVjDCekURF+zrEYO vsRsGkDGaKbsWaSrm8TEB5pCh2u9A5zcKfFmaPVFWGvmpziPNzGsJ0jUZoNcgEtH 6zJCYwqjcQet0gf3rAkMLf4JHB69obGvBwLi1O4zB1uLmDQCxNF1cVSCY1RuRK6r Br3Yd+a2pem+GmM18sbarOXnpCwndRLGO0RE5qtORbwVo98zyL4= =5K+g -----END PGP SIGNATURE----- --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C-- From nobody Mon Dec 4 13:17:20 2017 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 57B8412711D; Mon, 4 Dec 2017 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 MrxQ2sLz_ppX; Mon, 4 Dec 2017 13:17:12 -0800 (PST) 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 17588126DD9; Mon, 4 Dec 2017 13:17:11 -0800 (PST) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0CD45278333; Tue, 5 Dec 2017 06:17:09 +0900 (JST) Received: by mail-wm0-f47.google.com with SMTP id f206so10596658wmf.5; Mon, 04 Dec 2017 13:17:08 -0800 (PST) X-Gm-Message-State: AKGB3mLh3rALpfSn0FTYa9Nh3r1Om9RgtDVbFY7eA6aXPbxL7+q8DISu jM+cSx49IQmF1mF99FCSWKNjHwzt7rglIjfkVmM= X-Google-Smtp-Source: AGs4zMaTVKsu/0Jt/U2E0zM9zkZbcGWg+KsHVy1pEVjLtAfR6Xo2ukK26hioItBi7ZA/lqgAXF/mch+OZCXFm2jDrvk= X-Received: by 10.28.24.132 with SMTP id 126mr4196697wmy.34.1512422226903; Mon, 04 Dec 2017 13:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.153 with HTTP; Mon, 4 Dec 2017 13:17:06 -0800 (PST) In-Reply-To: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Yoshifumi Nishida Date: Mon, 4 Dec 2017 13:17:06 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Cc: Joe Touch , multipathtcp , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a1146fdc895cd65055f8a3df7" Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 21:17:14 -0000 --001a1146fdc895cd65055f8a3df7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 10:24 AM, Yuchung Cheng wrote: > > > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. > I am personally thinking it will be less impactful in case of this converter, although I agree for general use of TFO. In my understanding, the converters will be deployed inside ISPs where they provide internet connections to their clients (in early deployment scenario) So, I guess TFO will be used only between their client and their cloud for this as they don't have to use TFO from the converters to servers. -- Yoshi (with no hat) --001a1146fdc895cd65055f8a3df7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 4, 2017 at 10:24 AM, Yuchung Cheng <ycheng@google.com><= /span> wrote:

TFO today is still facing bad middle-boxes issues and
demands extreme conservative heuristics to deploy (see last
presentation by Praveen in tcpm). Ultimately they need to be
applied by either the client or the proposed converters.

I am personally thinking it will be less impactful in cas= e of this converter, although I agree for general use of TFO.
In = my understanding, the converters will be deployed inside ISPs where they pr= ovide internet connections to their clients (in early deployment scenario)<= /div>
So, I guess TFO will be used only between their client and their = cloud for this as they don't have to use TFO from the converters to ser= vers.=C2=A0
--
Yoshi (with no hat)

--001a1146fdc895cd65055f8a3df7-- From nobody Mon Dec 4 16:36:05 2017 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 C69B61271FD; Mon, 4 Dec 2017 16:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 rA9Pih1zxJFm; Mon, 4 Dec 2017 16:35:55 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E2A5D1250B8; Mon, 4 Dec 2017 16:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jQefm2SCWgzbz5nWUCag2qUejybVGk4ycOgpmEuhTuk=; b=jbhp3sMG7Yoi91u3rCgWKuilH2 YUXQ/yXlnJCqTmx2zRH7M0PTUta5RVLraRHVz+cP1813Dz6x06eLz9kKbpR8HGl9TnDcPhAgaAe7y 2pXyMOWkruEobnnUW9ni+2exWuh1hlpLRSOc33l51MGaS/Wr9OUwqQ6Mkqh8Q/qBs8hUQA+W+HHEv 47FOyEnchlduGYyz5OQ75/He78zxtf7DOUEJXMyct9p2gIJ3AcKBo1bUQZr/uVz5C/mpSOeRxMmxC 732+NWvo5iaXZiwDW3OBeSrPczIQIeYFrYL1Qc8wzxl84D+68q7RxxdSWSrhvpEaiCfhmZcWV2PcU FAAHFRbw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65245 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eM1DF-000e1c-Hw; Mon, 04 Dec 2017 19:35:54 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Mon, 4 Dec 2017 16:35:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 00:35:58 -0000 Hi, Med, On 12/3/2017 11:00 PM, mohamed.boucadair@orange.com wrote: > ... >> "The client places the destination address and port number of the >> target Server in the payload of the SYN sent to the Converter by >> leveraging TCP Fast Open [RFC7413]." >> >> I disagree with any use of TCP SYN payloads as anything other than >> application data. > [Med] The data that are inserted in ONE single SYN is the application (proxy) data. What's is wrong with that? If this is an application layer proxy, then you have no direct control over segment contents. The best you can say is that you write this information to the socket. If you do that, then you are a simple TCP service, not unlike any other TCP service which uses - but does not alter - TCP, and not in-scope for TCPM. To understand why intending to insert out-of-band info in the SYN is a problem, see Sec 8.7 of draft-ietf-tcpm-tcp-edo. > ... > > My position is as follows: >     - I don't think this doc should be adopted by the WG >     - Whether the doc is adopted or not, I have no interest in > continuing to try to repair its significant (and IMO fatal) flaws > [Med] Joe, we have taken into account many of the comments you raised in the past (e.g., define the proposal as an application proxy, make use of a service port, better integrate with TFO). It would be helpful to list some of the "fatal flaws" so that we can determine whether these are new issues. Thank you. I did, above. Continuing to avoid each fatal flaw does not ensure you will find a solution that is viable. Joe From nobody Mon Dec 4 23:14:50 2017 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 6B401126CBF; Mon, 4 Dec 2017 23:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37AZuavhYjcb; Mon, 4 Dec 2017 23:14:46 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C19124234; Mon, 4 Dec 2017 23:14:46 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 63D4740B58; Tue, 5 Dec 2017 08:14:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 459AB120063; Tue, 5 Dec 2017 08:14:44 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 08:14:43 +0100 From: To: Yuchung Cheng , Joe Touch CC: multipathtcp , "tcpm@ietf.org" Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbS1LfQqYV0PDzkqfP3vT/hvFTKM0VFOQ Date: Tue, 5 Dec 2017 07:14:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08621E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> 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.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 07:14:48 -0000 Hi Yucheng,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung Cheng > Envoy=E9=A0: lundi 4 d=E9cembre 2017 19:25 > =C0=A0: Joe Touch > Cc=A0: multipathtcp; tcpm@ietf.org > Objet=A0: Re: [tcpm] [multipathtcp] Working group acceptance of draft- > bonaventure-mptcp-converters ? >=20 > On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch wrote: > > > > > > > > On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > > The TCPM charter states that the "WG mostly focuses on maintenance > issues > > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > > interfaces that maintain TCP's utility". Assisting the deployment of > new TCP > > > extensions could be understood as one way to ensure TCP's utility. > > > > "The client places the destination address and port number of the > > target Server in the payload of the SYN sent to the Converter by > > leveraging TCP Fast Open [RFC7413]." > > > > I disagree with any use of TCP SYN payloads as anything other than > > application data. At best, the mechanism attempts to re-create an > > extension of TCPMUX, which was deprecated for good reason. > > > > Additionally, this is claimed to be an application proxy, which would b= e > > out of scope both for TCPM and to modify the definition of the contents > > or directly manipulate the headers of any TCP segments. > > > > My position is as follows: > > - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above, even > though I'd love to see more usage of TFO and MPTCP. >=20 > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. >=20 [Med] I'm not sure to understand this point about "TFO today is still facin= g bad middle-boxes issues". Please note:=20 - The proposal does not interfere with the deployment of TFO and its usage = when supported by both endpoints. Better, it allows to pass safely TFO opti= on.=20 - The proposal leverages on TFO to establish 0-RTT proxied MPTCP connection= s. A first connection is established between the host and converter to retr= ieve a TFO cookie that is used for proxy-purposes. That cookie will be supp= lied by the host when including proxy-supplied data in a SYN of a subsequen= t connection.=20 > > - Whether the doc is adopted or not, I have no interest in > > continuing to try to repair its significant (and IMO fatal) flaws > > > > Joe > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 4 23:51:58 2017 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 12C06127077 for ; Mon, 4 Dec 2017 23:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nclmDbJCpO1y for ; Mon, 4 Dec 2017 23:51:55 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2179F120454 for ; Mon, 4 Dec 2017 23:51:55 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id t8so10136521wmc.3 for ; Mon, 04 Dec 2017 23:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=P1l8K7qP9q7w/DJYJz1vku3YQk1WTsadj0EUYMxMYP0=; b=ZUWxePOQpyAMwUeq2hT/QVay38phgKpKcT+nBissssa/oodTIrmSA9z7jD7SFWNKMB xt/BrUxQrusaWS1RSgHQBqVigHwNWaj9cK/c7axDoWLOySySvgeHF+PJQBOzQoLEYGMp x/G8cFLMOZeilw+xja1v9mhqLQbeaopIhCzAqfGAIq/vKGZPNsUzpNPc4LzWiB1BxxjV uwWfvgimWCKKl/ez3xBpNrbwp1lKO5ZEIWlQ4+NYVXMVEw5qaEoHu8Kb9fCgpInc3UJl j7AKvWTVUMsWQApqNkLm7psytfiUi58SyDmtTi0qmb2AlV8qL/Y9/O2FfKfGQ40d76cw MFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P1l8K7qP9q7w/DJYJz1vku3YQk1WTsadj0EUYMxMYP0=; b=koifFY0+c7bbYtybxGotREot3dL8brWxy2ELLdvoucasutH4l5TJkbzUmAQtHF1vOn 7sUUE2efeQ+uWndFgSVekiOT50LAIg/QcsjVUpQheitlZD0w7qHiKRrONeg0nuuEJpTL A8ooD6RRsEuJEFx4t6d99NrXN7R3rWYuioPnr5Z3EJQK6SW115hLI1r43u1vyhEfKCo5 v6AwzItX77LBU7X2wnc7RvLq4iePbVI5l7kd55QyvjFWSJrxK/muIzgBb1BvSot2x0VN v7CMi+5epijdwaHOYchukDgkzNbvkDjvmPrSq5pUACkXdG9ozMKcay9Cy+9pBIZyCxpC EcJg== X-Gm-Message-State: AKGB3mI0LX2/+YlRg7pKVi5zPBDnkVrLbKIbHsftJX4V4DaaHtc5qH0d Gpbm/WsLX3it7CDiJ3RkxrvylJd5svtr3Nj1BTDdGSxO0WYo6eMMvUOHLWq2ulAGh0+qpoj4seP 2s8Oq4LY= X-Google-Smtp-Source: AGs4zMaSNmguA/UVRAAhACG/HqmfeP8eodDRDqbPVw8MI6/4bOlkmEXbGmNcJrIMyNVlnWNAQa3i6A== X-Received: by 10.80.190.76 with SMTP id b12mr7021731edi.184.1512460313641; Mon, 04 Dec 2017 23:51:53 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:ad1c:4afb:58df:a198]) by smtp.gmail.com with ESMTPSA id b2sm11392336edd.26.2017.12.04.23.51.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 23:51:53 -0800 (PST) To: Yuchung Cheng , Joe Touch Cc: multipathtcp , "tcpm@ietf.org" References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Olivier Bonaventure Message-ID: <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> Date: Tue, 5 Dec 2017 08:51:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 07:51:57 -0000 Yuchung, >> >> My position is as follows: >> - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above, even > though I'd love to see more usage of TFO and MPTCP. > > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. Recent measurements show indeed that TFO does not work everywhere. However, there is a very large fraction of all the deployed IP networks where TFO works perfectly. The documented problems with TFO affect clients willing to use TFO to reach any server over the Internet. This is not the deployment scenario for the converters. Converters will either be deployed in networks that have been configured to support TFO or where clients always pass through the same (pool of) converters. In this case, a client can easily verify whether the path towards its converter is safe for TFO. If not, the conversion service would be disabled on this client. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Mon Dec 4 23:52:30 2017 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 2CC6512711D; Mon, 4 Dec 2017 23:52:29 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNOtytps4jZT; Mon, 4 Dec 2017 23:52:27 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB96120454; Mon, 4 Dec 2017 23:52:27 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 9ED1AC0B4E; Tue, 5 Dec 2017 08:52:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 80F6A1C0064; Tue, 5 Dec 2017 08:52:25 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 08:52:25 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbWD9fQqYV0PDzkqfP3vT/hvFTKM0V1SA Date: Tue, 5 Dec 2017 07:52:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@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.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 07:52:29 -0000 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBz dHJheWFscGhhLmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA1IGTDqWNlbWJyZSAyMDE3IDAxOjM2 DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNjaGFyZiwgTWljaGFlbCAoTm9r aWEgLSBERS9TdHV0dGdhcnQpOw0KPiB0Y3BtQGlldGYub3JnOyBtdWx0aXBhdGh0Y3ANCj4gT2Jq ZXTCoDogUmU6IFt0Y3BtXSBbbXVsdGlwYXRodGNwXSBXb3JraW5nIGdyb3VwIGFjY2VwdGFuY2Ug b2YgZHJhZnQtDQo+IGJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMgPw0KPiANCj4gSGksIE1l ZCwNCj4gDQo+IA0KPiBPbiAxMi8zLzIwMTcgMTE6MDAgUE0sIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gd3JvdGU6DQo+ID4gLi4uDQo+ID4+ICAgIlRoZSBjbGllbnQgcGxhY2VzIHRoZSBk ZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBwb3J0IG51bWJlciBvZiB0aGUNCj4gPj4gICAgdGFyZ2V0 IFNlcnZlciBpbiB0aGUgcGF5bG9hZCBvZiB0aGUgU1lOIHNlbnQgdG8gdGhlIENvbnZlcnRlciBi eQ0KPiA+PiAgICBsZXZlcmFnaW5nIFRDUCBGYXN0IE9wZW4gW1JGQzc0MTNdLiINCj4gPj4NCj4g Pj4gSSBkaXNhZ3JlZSB3aXRoIGFueSB1c2Ugb2YgVENQIFNZTiBwYXlsb2FkcyBhcyBhbnl0aGlu ZyBvdGhlciB0aGFuDQo+ID4+IGFwcGxpY2F0aW9uIGRhdGEuDQo+ID4gW01lZF0gVGhlIGRhdGEg dGhhdCBhcmUgaW5zZXJ0ZWQgaW4gT05FIHNpbmdsZSBTWU4gaXMgdGhlIGFwcGxpY2F0aW9uDQo+ IChwcm94eSkgZGF0YS4gV2hhdCdzIGlzIHdyb25nIHdpdGggdGhhdD8NCj4gDQo+IElmIHRoaXMg aXMgYW4gYXBwbGljYXRpb24gbGF5ZXIgcHJveHksIHRoZW4geW91IGhhdmUgbm8gZGlyZWN0IGNv bnRyb2wNCj4gb3ZlciBzZWdtZW50IGNvbnRlbnRzLiBUaGUgYmVzdCB5b3UgY2FuIHNheSBpcyB0 aGF0IHlvdSB3cml0ZSB0aGlzDQo+IGluZm9ybWF0aW9uIHRvIHRoZSBzb2NrZXQuIElmIHlvdSBk byB0aGF0LCB0aGVuIHlvdSBhcmUgYSBzaW1wbGUgVENQDQo+IHNlcnZpY2UsIG5vdCB1bmxpa2Ug YW55IG90aGVyIFRDUCBzZXJ2aWNlIHdoaWNoIHVzZXMgLSBidXQgZG9lcyBub3QNCj4gYWx0ZXIg LSBUQ1AsIGFuZCBub3QgaW4tc2NvcGUgZm9yIFRDUE0uDQo+IA0KPiBUbyB1bmRlcnN0YW5kIHdo eSBpbnRlbmRpbmcgdG8gaW5zZXJ0IG91dC1vZi1iYW5kIGluZm8gaW4gdGhlIFNZTiBpcyBhDQo+ IHByb2JsZW0sIHNlZSBTZWMgOC43IG9mIGRyYWZ0LWlldGYtdGNwbS10Y3AtZWRvLg0KDQpbTWVk XSBUaGFuayB5b3UgZm9yIHRoZSBwb2ludGVyICh3aGljaCBJJ20gdmVyeSBmYW1pbGlhciB3aXRo KSwgYnV0IEkgZmFpbGVkIHRvIGlkZW50aWZ5IHRoZSBleGFjdCB0ZXh0IHlvdSBhcmUgcG9pbnRp bmcgdG8uIA0KDQpBcyBhIHJlbWluZGVyLCB0aGUgcHJveHktZGF0YSBzdXBwbGllZCBpbiBhIFNZ TiB0byBhIGNvbnZlcnRlciBpcyBtYWRlIGFmdGVyIGEgbmVnb3RpYXRpb24gaGFwcGVuZWQgYmV0 d2VlbiBhIGhvc3QgYW5kIGEgY29udmVydGVyLiBTbywgaXQgaXMgc2FmZSB0byBzdXBwbHkgdGhh dCBwcm94eS1kYXRhIHRvIHRoZSBjb252ZXJ0ZXIuDQoNCj4gPiAgLi4uDQo+ID4NCj4gPiBNeSBw b3NpdGlvbiBpcyBhcyBmb2xsb3dzOg0KPiA+IMKgwqDCoCAtIEkgZG9uJ3QgdGhpbmsgdGhpcyBk b2Mgc2hvdWxkIGJlIGFkb3B0ZWQgYnkgdGhlIFdHDQo+ID4gwqDCoMKgIC0gV2hldGhlciB0aGUg ZG9jIGlzIGFkb3B0ZWQgb3Igbm90LCBJIGhhdmUgbm8gaW50ZXJlc3QgaW4NCj4gPiBjb250aW51 aW5nIHRvIHRyeSB0byByZXBhaXIgaXRzIHNpZ25pZmljYW50IChhbmQgSU1PIGZhdGFsKSBmbGF3 cw0KPiA+IFtNZWRdIEpvZSwgd2UgaGF2ZSB0YWtlbiBpbnRvIGFjY291bnQgbWFueSBvZiB0aGUg Y29tbWVudHMgeW91IHJhaXNlZCBpbg0KPiB0aGUgcGFzdCAoZS5nLiwgZGVmaW5lIHRoZSBwcm9w b3NhbCBhcyBhbiBhcHBsaWNhdGlvbiBwcm94eSwgbWFrZSB1c2Ugb2YgYQ0KPiBzZXJ2aWNlIHBv cnQsIGJldHRlciBpbnRlZ3JhdGUgd2l0aCBURk8pLiBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGxp c3Qgc29tZQ0KPiBvZiB0aGUgImZhdGFsIGZsYXdzIiBzbyB0aGF0IHdlIGNhbiBkZXRlcm1pbmUg d2hldGhlciB0aGVzZSBhcmUgbmV3DQo+IGlzc3Vlcy4gVGhhbmsgeW91Lg0KPiANCj4gSSBkaWQs IGFib3ZlLg0KDQpbTWVkXSBXZSBkaWQgYWxzbyBzZXJpb3VzbHkgY29uc2lkZXJlZCB0aGUgZGVz aWduIHRvIHRha2UgaW50byBhY2NvdW50IHlvdXIgaW5wdXRzLiBXaGF0IGlzIGFtYXppbmcgaXMg dGhhdCBzb21lIG9mIHRoZXNlIGlucHV0cyBhcmUgbm93IHByZXNlbnRlZCBhcyAiZmxhd3MiOiBl LmcuLCB0aGUgdXNlIG9mIGEgc2VydmljZSBwb3J0IChyZWZlciB0byB5b3VyIHBvaW50ZXIgdG8g dGNwbXV4KSBvciB0aGF0IFRGTyBpcyBicm9rZW4gaW4gcHJlc2VuY2Ugb2YgbWlkZGxlYm94ZXMu DQoNCiBDb250aW51aW5nIHRvIGF2b2lkIGVhY2ggZmF0YWwgZmxhdyBkb2VzIG5vdCBlbnN1cmUg eW91DQo+IHdpbGwgZmluZCBhIHNvbHV0aW9uIHRoYXQgaXMgdmlhYmxlLg0KDQpbTWVkXSBMaXN0 aW5nIHdoYXQgeW91IHRoaW5rIGFyZSAiZmF0YWwgZmxhd3MiIHdvdWxkIGJlIG5hdHVyYWwgaW4g YSB0ZWNobmljYWwgZGlzY3Vzc2lvbi4gQ2xhaW1pbmcgd2l0aG91dCBzaGFyaW5nL3JldmVhbGlu ZyBpcyBub3QgaGVscGZ1bCwgSU1PLiBUaGFuayB5b3UuDQoNCj4gDQo+IEpvZQ0K From nobody Tue Dec 5 06:39:19 2017 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 DCD2F1294D8; Tue, 5 Dec 2017 06:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 oeOa0jiuO9Xi; Tue, 5 Dec 2017 06:39:16 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 39941124F57; Tue, 5 Dec 2017 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bDiEIsYURJEB+xxFl3wUvT9ev25JM8h2TJXJFkxdw44=; b=aZ3tIVRZ5DHJH5g9koZP3JOhtW l5eG4EZLUqddhpYK/YEvkMDWieFPOLeVZKAo9xpAADHMgrAAAyBpJyAE7vCHBpjSHbmNKEwzHCrVY nFjLIhqRiXEVWZXU+xpvNncgdWuG+3cNPoqKDbVv5vn/ZshzSYpTLR0wllUM5Ndk26VL6kVZPBA9o 6xat2ZacSkZ/TveajaF59yRCcCsWH61LxH9fphmn+9apvliQ2XuYGFDCRktuZ7DG8kO6uD7Qi7VdP ngCQdHtyT1u2Ykq8sbWy8O97TYcmjoBXSKTpyzuamHKGQZGF5Yfn+N3yQhnxLndn26ZlAOStF7x6J c/ZiEFyA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51636 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMENO-000pk3-9Q; Tue, 05 Dec 2017 09:39:15 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Tue, 5 Dec 2017 06:39:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 14:39:18 -0000 Med, Cutting to the points: - expressing the IP/port in-band is fine; saying it is "in the SYN" directly is not     - as a user of TCP, an application-layer program does not have that control - if this is really (as you say) an application proxy" then let's assume you just indicate "send the IP/port as the first data in the stream"     - in that case, you are an application and not a change to TCP, so *out of scope for* TCPM     - in that case, you also basically undermine a given service (moving its port AND changing its stream contents) for the purpose of increasing use of some TCP options (this is where the history of TCPMUX RFC1078 is useful - see RFC7805). Either way, my view is this document should not be adopted by TCPM. Joe From nobody Tue Dec 5 12:56:51 2017 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 AE1E8128796 for ; Tue, 5 Dec 2017 12:56:39 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHdsoc9VSkge for ; Tue, 5 Dec 2017 12:56:37 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFFF1288A9 for ; Tue, 5 Dec 2017 12:56:24 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g130so20574981wme.0 for ; Tue, 05 Dec 2017 12:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fpmmGnDocJS9VKY0eLlR0EN4v8cQBnNdnf6vj1uh/4Y=; b=mlAIifq3YQ4nDuh9PfaCFo8073eEF1sV/y2jumAq8CBns7j8xp++zPKJ5g/BTXG2Mv b6TOmd5pPdb1Uf8pRWzbZigTPQpsdAAp8d6U8wYBWR4cU+hB9rfq/CYTDcANX/lhvazB SrmRpus5YRhJNv6NFWy9q7hNWvVCjLCAdXoyMo4P0l2Kvaet1AALb47WIN4nrYvNMIP1 12GBed3y56/lyt477tuBDFRmmlPlfpDx+X/sJfjCRwXF/eTnNgl+RW3PeKLLV2jopSjY XWJxDY2YOzVeh8Gir6ryJ8tk54jsxcLv1fcmIrvzFTcdUGpXT/fVb7R7QJt32GzStmVI UgvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fpmmGnDocJS9VKY0eLlR0EN4v8cQBnNdnf6vj1uh/4Y=; b=fqpa+2KEHh+gXl3nOZb1mP9f6oR+akTktJmQodCyFTDLeVwu2Fzld1hzuRfamHIJud C74EWFvZu7Sp2CwgxPKk0pCgq1N0IUpQ18RZY7eMbnz+VCw1uLRZTbSGezmvit28j/yL JGd19Ty2kYaObMecZhQzT2dRKSnUQKGhhsyxhrrwJM9HcmDfC21FRkMmSWqeFlUUSJSy LsrGz1LPGqxjIVLH/8/AeY5o0tzasdBo+RkWsZMEzDWBZeLSMaWS92L9l6aknwTB0+qv VGGIXvW8wazm+v2/ZTw1Xh1mPWuT7VSZnB992k1V2fsrw6IzAvOzqQ6ZEvbPXlOA5bIV j2FQ== X-Gm-Message-State: AKGB3mItmKKhCft8sBkTeF80PjIMFKW9yaTgbKg5vNt490m7hzL8apFA d/P3KXO/Pf4Et2o4PbYHdBhTk68leeDfS7j7LVMeqA== X-Google-Smtp-Source: AGs4zMbGx4ewPAzubKnhn0b0AyDWVqW1rOG6rtraxKGlfMBRLnr1ldDHIRHxxcq7nDGT9Sv+FPDAPWjCZr/pSDI+ZGE= X-Received: by 10.28.150.20 with SMTP id y20mr10294203wmd.118.1512507382671; Tue, 05 Dec 2017 12:56:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.48.200 with HTTP; Tue, 5 Dec 2017 12:55:41 -0800 (PST) In-Reply-To: <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> From: Yuchung Cheng Date: Tue, 5 Dec 2017 12:55:41 -0800 Message-ID: To: Olivier Bonaventure Cc: Joe Touch , multipathtcp , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3c94444a51055f9e117e" Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 20:56:40 -0000 --001a114b3c94444a51055f9e117e Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 11:51 PM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Yuchung, > >> >>> My position is as follows: >>> - I don't think this doc should be adopted by the WG >>> >> I too do not support the adoption for similar reasons above, even >> though I'd love to see more usage of TFO and MPTCP. >> >> TFO today is still facing bad middle-boxes issues and >> demands extreme conservative heuristics to deploy (see last >> presentation by Praveen in tcpm). Ultimately they need to be >> applied by either the client or the proposed converters. >> > > Recent measurements show indeed that TFO does not work everywhere. > However, there is a very large fraction of all the deployed IP networks > where TFO works perfectly. The documented problems with TFO affect clients > willing to use TFO to reach any server over the Internet. This is not the > deployment scenario for the converters. Converters will either be deployed > in networks that have been configured to support TFO or where clients > always pass through the same (pool of) converters. In this case, a client > can easily verify whether the path towards its converter is safe for TFO. > If not, the conversion service would be disabled on this client. Oliviier / Med: You are right that the converters can be engineered to work well on TFO-friendly paths, and do not interfere other TFO deployment. I was only pointing that the middle-box issues may restrict the 0-RTT benefit. I should make this clear: my comments about TFO isn't the reason to reject adoption. My rationale for the objection is similar to Joe's points. > > > > Olivier > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > --001a114b3c94444a51055f9e117e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 11:51 PM, Olivier Bonaventure = <o= livier.bonaventure@tessares.net> wrote:
Yuchung,

My position is as follows:
=C2=A0 =C2=A0 =C2=A0- I don't think this doc should be adopted by the W= G
I too do not support the adoption for similar reasons above, even
though I'd love to see more usage of TFO and MPTCP.

TFO today is still facing bad middle-boxes issues and
demands extreme conservative heuristics to deploy (see last
presentation by Praveen in tcpm). Ultimately they need to be
applied by either the client or the proposed converters.

 Recent measurements show indeed that TFO does not work everywhere. However,= there is a very large fraction of all the deployed IP networks where TFO w= orks perfectly. The documented problems with TFO affect clients willing to = use TFO to reach any server over the Internet. This is not the deployment s= cenario for the converters. Converters will either be deployed in networks = that have been configured to support TFO or where clients always pass throu= gh the same (pool of) converters. In this case, a client can easily verify = whether the path towards its converter is safe for TFO. If not, the convers= ion service would be disabled on this client.
Oliviier / M= ed:=C2=A0

You are right that the converters can be= engineered to work well on TFO-friendly paths, and do not interfere other = TFO deployment. I was only pointing that the middle-box issues may restrict= the 0-RTT benefit. I should make this clear: my comments about TFO isn'= ;t the reason to reject adoption. My rationale for the objection is similar= to Joe's points.
=C2=A0



Olivier

--

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for the= individual named. If you are not the named addressee you should not dissem= inate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited.

--001a114b3c94444a51055f9e117e-- From nobody Tue Dec 5 14:48:29 2017 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 88B9D1277BB; Tue, 5 Dec 2017 14:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgfsSk8KhoL5; Tue, 5 Dec 2017 14:48:26 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10127.outbound.protection.outlook.com [40.107.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE3E12704B; Tue, 5 Dec 2017 14:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HyrE5O125aQbbwwyGbSlBKaecIQxzAxR3r56rdzCDbU=; b=bSx5mRE3HL0EQ2dz7TNk6mF3y/46TEoSjHPZ+3D32dbAMN6K+QUIr3taWHSFGXwJQv7kqg+JGDQTTcwBDRBcxTvYJ7ft1pbQ3LFxMpqDtNplLcdgI9jfMYy7ULcfMQVBEX4BJShAV7xs6UkdqRBPZcvlCd8mvM+jw7nvIqoPZpA= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Tue, 5 Dec 2017 22:48:23 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b%18]) with mapi id 15.20.0302.007; Tue, 5 Dec 2017 22:48:23 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAAFgH7gAAk3Q4AAA8/zgAADjTugAAOdAGw Date: Tue, 5 Dec 2017 22:48:23 +0000 Message-ID: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [92.203.132.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 6:FhFqoo9Dguq0RWRjIkdlfx2k54Hh8WS1nbiVVA3LAPpsx3rVvQ3+xwA1PsVJznrb8eaBbt05fLwzs096a1iMYLf7rqzr/sJdQ/QYLqyNCi25baPxmSb3Fpo5A7BDiO867X5OJH5spxAZVHqS6qxHJ4mwA+8ivkF80BnPPnHuwds983vZ9714qKzSV+d7oidFji0NSFUr+Vlr6m1UGD5JDA3wuCo9oAOSURy2lb1VxKe0EBm/7L7l/DU5eEaABhxJZo73798v7X6+GAcgmoiKV0ind+OTli3XRjGikkOdd0v5/LQGZCPn9pVT+kjjDtDJPfJWe87vYJviwNApOotPLA81SpnDnY4O+TT0LfBl+Lc=; 5:YuB+tmdYhbOLGPIxl56vTPCypCtA1i+EOCTyE+l55piOM5H0ulwCEaDf2S2yQbciYB4V5Wb2gM0ZcWNi3SCRXECLjg9g/yO2YRVb2tiI0hyE2+SaDqloGQxwYk+6O1yzN9qHnspK9qYfe/ECKk3SaUrLOdxXoICG3IAYpebOAQU=; 24:SGbJuAIFZlP4LxTgF67vPiX0p8JQHhUzKEtu19rgOOUg8u55XnuRKlExZgyQSHGPufSFFGehFbPxhORf6HObekxwVy7i2pnHdEcoZuKv6eo=; 7:pfk5T409HjRpc3feUroStmKTCylf3Ve9qtEghf1djvk1tYEL2PVaHgTcUtNxeXK3cckeuJDB2Dqj2IUJh17z6suL2c8LqY5aUFA7hzgFRd6R0IcO6JUWtF2IuXxEZEDAS+5CTEyL8NFSXccBEuBW8Ae6X2XS+Pt+JoOpDMpMmxbPQVz8SXjuucO3iM47KeRG5odoD/Qe07G522psubfyQzerYKf8XKTUPeJtJhg+EMMHoX0ESeujXA8eUaTCYvoS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b85e838e-dc47-454e-22ed-08d53c324a14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2547; x-ms-traffictypediagnostic: AM5PR0701MB2547: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(100405760836317)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2547; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(199004)(189003)(13464003)(110136005)(53936002)(9686003)(93886005)(6506006)(2900100001)(74316002)(7736002)(305945005)(76176011)(316002)(7696005)(6436002)(2201001)(97736004)(86362001)(3660700001)(229853002)(68736007)(53546010)(5660300001)(230783001)(478600001)(55016002)(3280700002)(6116002)(3846002)(102836003)(2906002)(25786009)(14454004)(33656002)(106356001)(2501003)(2950100002)(81166006)(6246003)(99286004)(81156014)(101416001)(66066001)(8936002)(5250100002)(8676002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b85e838e-dc47-454e-22ed-08d53c324a14 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 22:48:23.0720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 22:48:28 -0000 SGkgSm9lLCBhbGwsDQoNClJlZ2FyZGluZyAiKm91dCBvZiBzY29wZSBmb3IqIFRDUE0iOiAgV2hl dGhlciBhIGRvY3VtZW50IGlzIGluIHNjb3BlIG9mIFRDUE0sIG9yIG5vdCwgZGVwZW5kcyBvbiB0 aGUgVENQTSBjaGFydGVyIHdvcmRpbmcuIEl0IGlzIHBlcmZlY3RseSB2YWxpZCB0byBxdWVzdGlv biB3aGV0aGVyIGEgZG9jdW1lbnQgaXMgaW5kZWVkIGFsbG93ZWQgYnkgdGhlIGN1cnJlbnQgY2hh cnRlci4gWWV0LCBrZWVwIGluIG1pbmQgdGhhdCB3ZSBjb3VsZCBhbHNvIGRpc2N1c3MgcmVjaGFy dGVyaW5nIFRDUE0gaWYgdGhlcmUgd2FzIGEgbmVlZC4gT2YgY291cnNlLCByZWNoYXJ0ZXJpbmcg VENQTSB3b3VsZCwgYW1vbmdzdCBvdGhlcnMsIHJlcXVpcmUgdmVyeSBzdHJvbmcgd29ya2luZyBn cm91cCBjb25zZW5zdXMgYW5kIElFU0cgYXBwcm92YWwuDQogDQpUaGUgZmlyc3QgcHJlcmVxdWlz aXRlIGZvciBhbnkgd29yayBpbiBUQ1BNIGlzIGNsZWFyIGludGVyZXN0LCBlbmVyZ3ksIGFuZCBj b25zZW5zdXMgaW4gdGhlIGNvbW11bml0eS4gRm9yIHRoZSBtb21lbnQsIHdlIHRyeSB0byB1bmRl cnN0YW5kIGlmIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgZnVsZmlsbGVkLCBvciBub3QuDQoNClRo YW5rcw0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgRGVjZW1iZXIgMDUsIDIwMTcgMzozOSBQTQ0KPiBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkNCj4gPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT47IHRjcG1AaWV0Zi5vcmc7IG11bHRpcGF0aHRjcA0KPiA8bXVs dGlwYXRodGNwQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFttdWx0aXBhdGh0Y3Bd IFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5jZSBvZiBkcmFmdC0NCj4gYm9uYXZlbnR1cmUtbXB0Y3At Y29udmVydGVycyA/DQo+IA0KPiBNZWQsDQo+IA0KPiBDdXR0aW5nIHRvIHRoZSBwb2ludHM6DQo+ IA0KPiAtIGV4cHJlc3NpbmcgdGhlIElQL3BvcnQgaW4tYmFuZCBpcyBmaW5lOyBzYXlpbmcgaXQg aXMgImluIHRoZSBTWU4iDQo+IGRpcmVjdGx5IGlzIG5vdA0KPiDCoMKgwqAgLSBhcyBhIHVzZXIg b2YgVENQLCBhbiBhcHBsaWNhdGlvbi1sYXllciBwcm9ncmFtIGRvZXMgbm90IGhhdmUgdGhhdCBj b250cm9sDQo+IA0KPiAtIGlmIHRoaXMgaXMgcmVhbGx5IChhcyB5b3Ugc2F5KSBhbiBhcHBsaWNh dGlvbiBwcm94eSIgdGhlbiBsZXQncyBhc3N1bWUgeW91IGp1c3QNCj4gaW5kaWNhdGUgInNlbmQg dGhlIElQL3BvcnQgYXMgdGhlIGZpcnN0IGRhdGEgaW4gdGhlIHN0cmVhbSINCj4gwqDCoMKgIC0g aW4gdGhhdCBjYXNlLCB5b3UgYXJlIGFuIGFwcGxpY2F0aW9uIGFuZCBub3QgYSBjaGFuZ2UgdG8g VENQLCBzbyAqb3V0IG9mDQo+IHNjb3BlIGZvciogVENQTQ0KPiDCoMKgwqAgLSBpbiB0aGF0IGNh c2UsIHlvdSBhbHNvIGJhc2ljYWxseSB1bmRlcm1pbmUgYSBnaXZlbiBzZXJ2aWNlIChtb3Zpbmcg aXRzIHBvcnQNCj4gQU5EIGNoYW5naW5nIGl0cyBzdHJlYW0gY29udGVudHMpIGZvciB0aGUgcHVy cG9zZSBvZiBpbmNyZWFzaW5nIHVzZSBvZiBzb21lDQo+IFRDUCBvcHRpb25zICh0aGlzIGlzIHdo ZXJlIHRoZSBoaXN0b3J5IG9mIFRDUE1VWCBSRkMxMDc4IGlzIHVzZWZ1bCAtIHNlZQ0KPiBSRkM3 ODA1KS4NCj4gDQo+IEVpdGhlciB3YXksIG15IHZpZXcgaXMgdGhpcyBkb2N1bWVudCBzaG91bGQg bm90IGJlIGFkb3B0ZWQgYnkgVENQTS4NCj4gDQo+IEpvZQ0K From nobody Tue Dec 5 20:26:23 2017 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 D732E1201F2; Tue, 5 Dec 2017 20:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Q2om0MYYZRxj; Tue, 5 Dec 2017 20:26:19 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6BAA21200C5; Tue, 5 Dec 2017 20:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4miNDYL4XBeKJfrqZ3wMG2m1ovoWYyHHkXZhSH/I1M8=; b=Zs4+1YUNRXGLvmuYkHxvXrvCoh PN4TzRuXr7Mb6YQnZFwZCmXhqZD7+Rgl2aYbWjjzXYqOhMKFucTh9cYfQCLgSrl/nDr1H8sNP5Z/d pAnCUVBQSIDTHxOSWavMygWTA9mVKYlpiZYVkLMrc6HRbQbqaIHbd0ptLXtEHWI+chNzmc3mOyUGX e1ZdFNupcgSAUPhfammBn0Zc2zehInl5pY/gUMtxBC0vyRP2Gft7zGR8rD/GW+HRJpY9OBydBOng/ o1Nwye8bMqOZ8dy7/FzOkFz3ZlLbTJ2a93CCWYBCJU3qktIOYCWTuz3InCsxrI6fzENbfIMYU88gY Cw95BLHg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55173 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMRHl-000oMa-Jw; Tue, 05 Dec 2017 23:26:18 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> Date: Tue, 5 Dec 2017 20:26:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 04:26:21 -0000 On 12/5/2017 2:48 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > Hi Joe, all, > > Regarding "*out of scope for* TCPM": Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. Although I appreciate that's strictly true, I doubt the charter would change to include "haiku development". By the same token, IMO, this doc falls into one of two categories: 1) if, as is, it proposes direct placement of out-of-band data in the SYN payload, I think it is a bad idea and not worth pursuing in TCPM 2) if, instead, it is corrected to explain that its use of the data channel for proxy information is simply a conventional application data path, then it would not be a "modification of TCP" at all (minor or otherwise). If that isn't clearly out of scope for TCPM, I do not know what is or ever would be (can we start haiku next, in that case?) Joe From nobody Tue Dec 5 23:47:21 2017 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 702B4126FDC for ; Tue, 5 Dec 2017 23:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhCGeOfpy23R for ; Tue, 5 Dec 2017 23:47:11 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 431801200C1 for ; Tue, 5 Dec 2017 23:47:11 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f206so5385456wmf.5 for ; Tue, 05 Dec 2017 23:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lLSrF7dtmdxQbXs/70vB2V2vMmCq0cChyLFzAQq96f4=; b=tqE2ly9cSSrbZcRg0xd5x9gDJe2KPsm7k/ewoSO//HReatJCM/kR520jjl3a7lHZOs Z3LxHn6QJxQ+8rKow6uR1AE8D4uTzYUhddyectTgGzhM5KgoNORSBrmIFDeRUwz9Lm/H U4pfVqryKrNNUpldvLIT9x+E88wBBuLrL7ltSMoUQjgdm9CxeRL73c0Y9dXdiKKfxx7E hkKyrjG4JeWBVodaRPmy5MQTvUehjEtuSG6um+TRwhvJmMA3JfWhPV5M31SxcqRhXeOs +PKCS7RkDxyE3iiFlngyU52j+0ZuEejcFjKGC3T9sSzIBIhvmziIiUeBjD9Rq85ZOcAC XucA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lLSrF7dtmdxQbXs/70vB2V2vMmCq0cChyLFzAQq96f4=; b=n7XAPGm9QVDC9LAgQsxCG2yv1IkoudvJp0ECs0017JuYTa+x6FNoQCcnb5pPVmYenW zb5tJnf2csDLECu7c6v4CaegHrmCYJ6Ceq6wWGmMhK0F3wpnmxxcHzfUX4T1//EoUTuu M6UsbBho78Q8VBrDlDtJGE4nIcVvM8jE31wQRwZUr6Fz+1J23SwDXi2AfOSspObMJfh0 uUYYCPoZYQm0WruSU7X0/fcgvvxUAICkSLXFqdJhV0PDDkQYkB0YyflmbxiXM2ecvGTa /E1NYoOElNTZR8feIBSyxDuL2pCczrq9wk9NKM3pXbY2oFmfophMGzgARZbx+jpZxY5s T+YQ== X-Gm-Message-State: AJaThX5SN4YhigNZ1U3iQI58efW3nh9SSpovuWfQw2vv0sxadTAwuHQb kFRrhOjH7Ubf+rlUPmvNAYFKqdCWgeSc+1ebOkV6hAem/1J744eZjPLItczBEyQMxNuIqGVFTBs POFqnlmr79tC1 X-Google-Smtp-Source: AGs4zMYpbfCR6aftKxV9gBP0AMqtcDdt1zvTyyIDVINqYjfUXF0XMSLnXsgmcvzce4ubkiTiyDawmQ== X-Received: by 10.80.182.138 with SMTP id d10mr38360991ede.131.1512546429510; Tue, 05 Dec 2017 23:47:09 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:b9cd:286c:bccd:7108]) by smtp.gmail.com with ESMTPSA id h56sm908922eda.97.2017.12.05.23.47.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 23:47:08 -0800 (PST) To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> From: Olivier Bonaventure Message-ID: <0ac893cf-4456-7e93-b53a-3b4162dd4983@tessares.net> Date: Wed, 6 Dec 2017 08:47:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 07:47:13 -0000 Joe, Michael, >> Regarding "*out of scope for* TCPM": Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. > Although I appreciate that's strictly true, I doubt the charter would > change to include "haiku development". > > By the same token, IMO, this doc falls into one of two categories: > > 1) if, as is, it proposes direct placement of out-of-band data in the > SYN payload, I think it is a bad idea and not worth pursuing in TCPM > > 2) if, instead, it is corrected to explain that its use of the data > channel for proxy information is simply a conventional application data > path, then it would not be a "modification of TCP" at all (minor or > otherwise). If that isn't clearly out of scope for TCPM, I do not know > what is or ever would be (can we start haiku next, in that case?) The converter draft clearly defines an application level protocol that leverages TFO. This draft defines the format of the messages that are exchanged at the beginning of the bytestream in both directions. There is no out-of-band data in the SYN. I guess that the main reason why our AD suggested to discuss this draft in the tcpm working group is that it could help the deployment of new TCP options. History shows that deploying news TCP options on client and servers is a very long process. If we can speedup or encourage this deployment, then this will be beneficial for TCP even if at this stage the main use case comes from Multipath TCP where there is a clear benefit in having Multipath TCP on a a subset of the end-to-end path. I'll let the ADs comment on whether converters are in scope of a specific working group. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Dec 6 01:35:33 2017 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 382D7126D05; Wed, 6 Dec 2017 01:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbx--eiLXEQh; Wed, 6 Dec 2017 01:35:30 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00133.outbound.protection.outlook.com [40.107.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00211126B6E; Wed, 6 Dec 2017 01:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z4HIe8m8lIy+dXvY+6Xb4BBZcetmIVgUVhyBomnGwmc=; b=M2JWJgaoYfdLO5QxLgZwepwbn1ZW1hV91Q0tFsqHf1mr96BUAo8egkMMDqSQS4p9tVvT5De8pvyojXdz0sD0AOWRwcR/KucwG3Gt/00c1uouLdAqgI3NQP358lqXqqMLnmPAfPqy78Al2n01kbASrhIqyc6o3AzcuPI58DUQo+U= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 09:35:27 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b%18]) with mapi id 15.20.0302.007; Wed, 6 Dec 2017 09:35:27 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAAFgH7gAAk3Q4AAA8/zgAADjTugAAOdAGwAA5ujIAACmFJEA== Date: Wed, 6 Dec 2017 09:35:27 +0000 Message-ID: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> In-Reply-To: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [92.203.201.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 6:+6yi+zHhLal5pjN0ZEKoh+gaClf6feS7K0PghOX9td2MGxMY7QeW0OEdNqK+WQq+yH0ukeesibRuQUGGd2p1GgCBIHTwxuFLyc5cq2pS2jmJZ1Zn6NTTIQgy/PHml967r6my4Iw0NsvkdqMsV+52MAH+3R10QQQD5qQc0T34mZXzcGfbrjoJY/6hzh0ZHQelInMMO39grYkJyvPhsUv9sZ5roeWaaMYxgUpRy9XXA06TdNGY+64ANPesFKsnCgOAhitj5k0BxSOjRRQG5NMJly1bpY8ldpFA2MKyiIcN7knB63pVcGF7q06ARXC2Wthuyvcm3uQSiR9OkfvPjYQFAtBawYT0ajeeykDoBEvd0tc=; 5:AZasUGHVuh8EC61+jkZY6kott6reupo6xV5EtEGUP1WlHG1CuDNYfcvnjxnPSo/4PQRxOc1oxBKzcNhUD+KSxTOv+1gtxSqMkbioYByBp+2mNy/aFSBQc1Q/aWJoy+oJoRuxhbw+fVRg62fCBmfAjo7o6UiLIHNU63UwAnNxbLg=; 24:GQwB6qZ7ydu+UE5IhJ+v8GU3WwKaFyiYvh9wHK8StYu3RAPUI/4v+/IahugfNrRgxJC7WYzNAVwcSPw2LL2cYj6ifzfGdk9RdzIb8+bL8UI=; 7:wn6h1d2Fn6v0FJMLQKdePVH4+47CfFkQj0h7tNyisjiAoS9pv8wR5xGDljIFP5otJBzyWL8ABrSTG7xPkEY3BjIZ5LTKvYCYmgnT4V30RJwdGUt0vlan5tB8gdC+IOscY4Ry7hKbmTP0uGtZKrgy9uHnAiSqFJb1VUhARvKgB1KStlAMcfN13x77zVTi8XwJaWVyvWhuxGdCVCNqpSKpNwdIRqyV3nNQnvuWpK2GZI86lEmIZAG5U6kTvcHxE2NV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d87f1aa0-5e5c-48d9-1086-08d53c8caf44 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2548; x-ms-traffictypediagnostic: AM5PR0701MB2548: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2548; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(199004)(189003)(110136005)(99286004)(2906002)(76176011)(53936002)(5660300001)(93886005)(316002)(305945005)(6246003)(14454004)(2900100001)(6116002)(3846002)(66066001)(68736007)(106356001)(74316002)(102836003)(478600001)(7736002)(7696005)(101416001)(2950100002)(3660700001)(33656002)(229853002)(5250100002)(6506006)(97736004)(2201001)(105586002)(81156014)(86362001)(8676002)(81166006)(25786009)(9686003)(2501003)(55016002)(3280700002)(8936002)(230783001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d87f1aa0-5e5c-48d9-1086-08d53c8caf44 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 09:35:27.5573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 09:35:32 -0000 PiAxKSBpZiwgYXMgaXMsIGl0IHByb3Bvc2VzIGRpcmVjdCBwbGFjZW1lbnQgb2Ygb3V0LW9mLWJh bmQgZGF0YSBpbiB0aGUgU1lODQo+IHBheWxvYWQsIEkgdGhpbmsgaXQgaXMgYSBiYWQgaWRlYSBh bmQgbm90IHdvcnRoIHB1cnN1aW5nIGluIFRDUE0NCg0KVGhlIElFVEYgaGFzIGFsc28gZGVjaWRl ZCB0byBzcGVjaWZ5IFRDUElOQywgd2hpY2ggYWxzbyB1c2VzIG91dC1vZi1iYW5kIGRhdGEgaW4g dGhlIHBheWxvYWQsIGFsYmVpdCBpbiBhIHZlcnkgZGlmZmVyZW50IGNvbnRleHQuIEluIHRoZSBU Q1BJTkMgY2FzZSwgdGhlIGNvbnNlbnN1cyB3YXMgdG8gbGF1bmNoIGEgbmV3IHdvcmtpbmcgZ3Jv dXAsIGdpdmVuIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBwcm90b2NvbCBhbmQgdGhlIHJlcXVpcmVk IHNlY3VyaXR5IGV4cGVydGlzZS4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhpcyBkb2N1bWVudCB3 b3VsZCBiZSBzaW1wbGVyIHRoYW4gVENQSU5DLg0KDQpNaWNoYWVsDQoNCg0KDQo= From nobody Wed Dec 6 01:55:42 2017 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 2F21E126C26; Wed, 6 Dec 2017 01:55:36 -0800 (PST) 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 cBZy9zRiYwdF; Wed, 6 Dec 2017 01:55:34 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADF81242F7; Wed, 6 Dec 2017 01:55:34 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 88B6B60CCF; Wed, 6 Dec 2017 10:55:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 697B5C0056; Wed, 6 Dec 2017 10:55:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 10:55:32 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbdbVzDKp1AXG1EiGa0ri5/iSa6M2DGYg Date: Wed, 6 Dec 2017 09:55:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@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.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 09:55:36 -0000 SGkgSm9lLCANCg0KVGhhbmsgeW91IGZvciBjbGFyaWZ5aW5nLiBUaGlzIGlzIGhlbHBmdWwuIA0K DQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhh LmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA1IGTDqWNlbWJyZSAyMDE3IDE1OjM5DQo+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9T dHV0dGdhcnQpOw0KPiB0Y3BtQGlldGYub3JnOyBtdWx0aXBhdGh0Y3ANCj4gT2JqZXTCoDogUmU6 IFt0Y3BtXSBbbXVsdGlwYXRodGNwXSBXb3JraW5nIGdyb3VwIGFjY2VwdGFuY2Ugb2YgZHJhZnQt DQo+IGJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMgPw0KPiANCj4gTWVkLA0KPiANCj4gQ3V0 dGluZyB0byB0aGUgcG9pbnRzOg0KPiANCj4gLSBleHByZXNzaW5nIHRoZSBJUC9wb3J0IGluLWJh bmQgaXMgZmluZTsgc2F5aW5nIGl0IGlzICJpbiB0aGUgU1lOIg0KPiBkaXJlY3RseSBpcyBub3QN Cj4gwqDCoMKgIC0gYXMgYSB1c2VyIG9mIFRDUCwgYW4gYXBwbGljYXRpb24tbGF5ZXIgcHJvZ3Jh bSBkb2VzIG5vdCBoYXZlIHRoYXQNCj4gY29udHJvbA0KPiANCj4gLSBpZiB0aGlzIGlzIHJlYWxs eSAoYXMgeW91IHNheSkgYW4gYXBwbGljYXRpb24gcHJveHkiDQoNCltNZWRdIEkgY29uZmlybS4g V2UgYXJlIGFkaGVyaW5nIHRvIFNlY3Rpb24gMyBvZiBSRkMxOTE5OiANCiAgICogTGlzdGVuIGZv ciBjbGllbnQgc2Vzc2lvbnMuDQogICAqIFJlY2VpdmUgZnJvbSBhIGNsaWVudCB0aGUgYWRkcmVz cyBvZiB0aGUgZmluYWwgdGFyZ2V0IHNlcnZlci4NCiAgICogU2V0dXAgYSBzZXNzaW9uIHRvIHRo ZSBmaW5hbCBzZXJ2ZXIuDQogICAqIC4uLg0KDQogdGhlbiBsZXQncyBhc3N1bWUNCj4geW91IGp1 c3QgaW5kaWNhdGUgInNlbmQgdGhlIElQL3BvcnQgYXMgdGhlIGZpcnN0IGRhdGEgaW4gdGhlIHN0 cmVhbSINCj4gwqDCoMKgIC0gaW4gdGhhdCBjYXNlLCB5b3UgYXJlIGFuIGFwcGxpY2F0aW9uIGFu ZCBub3QgYSBjaGFuZ2UgdG8gVENQLCBzbw0KPiAqb3V0IG9mIHNjb3BlIGZvciogVENQTQ0KDQpb TWVkXSBUaGlzIGlzIGFjdHVhbGx5IGEgZmFpciBjb21tZW50LiBUaGUgZG9jdW1lbnQgZG9lcyBu b3QgY2hhbmdlIFRDUCwgc3VyZS4gSXQgaXMgc2NvcGVkIGluaXRpYWxseSB0byBhc3Npc3QgZXN0 YWJsaXNoaW5nIE1QVENQIGNvbm5lY3Rpb25zIHdoZW4gc2VydmVycyBhcmUgbm90IE1QVENQLWNh cGFibGUgd2hpbGUgZW5zdXJpbmcgYSAwLVJUVCBwcm94eSBzZXJ2aWNlIGFuZCB3aXRob3V0IGlu ZHVjaW5nIGFuIG92ZXJoZWFkLiBCZWNhdXNlIHNvbWUgdm9pY2VkIHRoYXQgdGhpcyBwcm9wb3Nh bCBtYXkgYmUgZ2VuZXJhbGl6ZWQgdG8gYXNzaXN0IGRlcGxveWluZyBvdGhlciBUQ1Agb3B0aW9u cywgaGVuY2UgdGhpcyBkaXNjdXNzaW9uLiANCg0KPiDCoMKgwqAgLSBpbiB0aGF0IGNhc2UsIHlv dSBhbHNvIGJhc2ljYWxseSB1bmRlcm1pbmUgYSBnaXZlbiBzZXJ2aWNlIChtb3ZpbmcNCj4gaXRz IHBvcnQgQU5EIGNoYW5naW5nIGl0cyBzdHJlYW0gY29udGVudHMpIGZvciB0aGUgcHVycG9zZSBv ZiBpbmNyZWFzaW5nDQo+IHVzZSBvZiBzb21lIFRDUCBvcHRpb25zICh0aGlzIGlzIHdoZXJlIHRo ZSBoaXN0b3J5IG9mIFRDUE1VWCBSRkMxMDc4IGlzDQo+IHVzZWZ1bCAtIHNlZSBSRkM3ODA1KS4N Cg0KW01lZF0gSSBhbHJlYWR5IGNvbW1lbnRlZCBvbiB0Y3BtdXggYW5kIFJGQzc4MDUuIE1vc3Qg b2YgaXRlbXMgaW4gNzgwNSBkbyBub3QgYXBwbHkgdG8gdGhlIGNvbnZlcnRlciBzcGVjaWZpY2F0 aW9uLiANCg0KSWYgdGhlIG9ubHkgcmVhc29uIGlzOiANCg0KICAgICAgKiAgSXQgcmVxdWlyZXMg YWxsIG5ldyBjb25uZWN0aW9ucyB0byBiZSByZWNlaXZlZCBvbiBhIHNpbmdsZQ0KICAgICAgICAg cG9ydCwgd2hpY2ggbGltaXRzIHRoZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgYmV0d2VlbiB0d28N CiAgICAgICAgIG1hY2hpbmVzLiAgICANCg0KSSdkIGxpa2UgdG8gd2FycmFudCB0aGF0IHRoaXMg aXMgZXhhY3RseSB3aGF0IHBvcHVsYXIgcHJvdG9jb2xzIGFyZSBkb2luZyAoZS5nLiBTT0NLUyku IFNob3VsZCB0aGUgSUVURiBvYnNvbGV0ZXMgU09DS1MgZm9yIHRoYXQ/IEkgZ3Vlc3MsIG5vLiAg DQoNCj4gDQo+IEVpdGhlciB3YXksIG15IHZpZXcgaXMgdGhpcyBkb2N1bWVudCBzaG91bGQgbm90 IGJlIGFkb3B0ZWQgYnkgVENQTS4NCj4gDQo+IEpvZQ0K From nobody Wed Dec 6 06:22:50 2017 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 F1299128B8F; Wed, 6 Dec 2017 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 3OhicxWB72dX; Wed, 6 Dec 2017 06:22:41 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E2C54128B8E; Wed, 6 Dec 2017 06:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6DaWqCiS0zDVgo7cGmWHKeGqtF6FlahUBNjHTS6PAQ0=; b=tfTWoSparLq5xbSPm42QjvZeB i9twXm73iSyMJN76VKuxRaLnd1Rh897qMBRlHfpNhF1Ah+L4eu+niepH6wWmGqtGcXDetOg+c94T9 HRREl6JqzsRwSw/rDyDyo6WnMVpHrnJUzVL8CUMqj6yRTyE2swQ9iaAXM90+h5gxW/wtR1AS7i4Og wzvdYD8KDR5tuc2IDXjMcwuN+qHow6UgaJDJuIcoBYG85rziqR/Wjev6hw9Rfg78nraqYs6lcxE+M S98oTBWwtwjaJ1r1XqKa5EbMbmTBOybPsm78fHvkbbOc4l6MObVaEXV26eL0dyl9aEpfvl8o6TJIV 74gpBwsyQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59197 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMaar-001LAE-TS; Wed, 06 Dec 2017 09:22:38 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> From: Joe Touch Message-ID: <17637296-0c65-5714-5747-a0f4929326c4@strayalpha.com> Date: Wed, 6 Dec 2017 06:22:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5297C37881A30735217119C5" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 14:22:43 -0000 This is a multi-part message in MIME format. --------------5297C37881A30735217119C5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/6/2017 1:35 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >> 1) if, as is, it proposes direct placement of out-of-band data in the SYN >> payload, I think it is a bad idea and not worth pursuing in TCPM > The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context. TCPINC is a case study in bad decisions that IMO we should not try to repeat, from insufficient pushback on option squatting, to use of out-of-band data in the SYN payload, to assigning a new option to an experimental protocol, to not actually protecting TCP itself (except in a very small subset of control info). In all cases, my position on these issues has not changed and I will continue to oppose them. Joe --------------5297C37881A30735217119C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 12/6/2017 1:35 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
1) if, as is, it proposes direct placement of out-of-band data in the SYN
payload, I think it is a bad idea and not worth pursuing in TCPM

The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context.

TCPINC is a case study in bad decisions that IMO we should not try to repeat, from insufficient pushback on option squatting, to use of out-of-band data in the SYN payload, to assigning a new option to an experimental protocol, to not actually protecting TCP itself (except in a very small subset of control info).

In all cases, my position on these issues has not changed and I will continue to oppose them.

Joe

--------------5297C37881A30735217119C5-- From nobody Wed Dec 6 06:27:33 2017 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 68F4D128B8F; Wed, 6 Dec 2017 06:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 wORjerS-A-6x; Wed, 6 Dec 2017 06:27:25 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 ED333128B51; Wed, 6 Dec 2017 06:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sotAJRmdNrSUqThJ3cAD9X/uA6VQk54Yci8/9VaydmY=; b=ozXIN+RuUS8i4j/4ltRWSh1m8J PJHo8VDoSObfkMLrdOTiPcDKiL/rfglkrUyQ+8/z9WsfX3yiqLyge1i1nUkqUpBmAPbw7Gn3Iq8Cb sJTVnLjfqP8xdam9qfIsDpUkL11tbZO3EQEdBYZW7Hpq+2fsWNBwkS5hybO6fl2/Zb/oHY92rTVDP FCrms2H4r9PtPPT3O7uxUWoPaqvMAw3jwLIC9TSBcl7AyoAJ27IyMBk5Q5VbmZ+w2RH1U7jqYBDu0 ONkq5j0eXz30GquYoktVolqFI4r2M3B+7hnmrmS8wNCQDNPGCOBmJRi+n906r13HFe2G8u4+G4gk/ dSHcuACw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59219 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMafP-001Oso-U4; Wed, 06 Dec 2017 09:27:23 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 6 Dec 2017 06:27:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 14:27:26 -0000 Med, On 12/6/2017 1:55 AM, mohamed.boucadair@orange.com wrote: > [Med] I already commented on tcpmux and RFC7805. Most of items in 7805 do not apply to the converter specification. > > If the only reason is: > > * It requires all new connections to be received on a single > port, which limits the number of connections between two > machines. > > I'd like to warrant that this is exactly what popular protocols are doing (e.g. SOCKS). Should the IETF obsoletes SOCKS for that? I guess, no. TCPMUX was deprecated *as part of TCP* for these reasons. IMO, SOCKS is no better. In both cases, capable systems are better served by a tunnel than application layer proxies that provide insufficient alternatives, because they end up pushing Internet service up to Layer 7, where it will eventually need to be reinvented and the problem being solved (e.g., desire to better support TCP options) will occur again. However, as I said, there's no reason to avoid this approach if this remains at the application layer, from an process perspective. It just has no benefit or utility in being developed in TCPM. Joe From nobody Tue Dec 12 01:54:56 2017 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 4348212940B for ; Tue, 12 Dec 2017 01:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 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, SUBJ_ALL_CAPS=1.506, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNzNVI9xS2BK for ; Tue, 12 Dec 2017 01:54:52 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373201293F3 for ; Tue, 12 Dec 2017 01:54:52 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b199so15787044wme.1 for ; Tue, 12 Dec 2017 01:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8fNpNjS47yJts7ars9XTm9QNj5qK6ZUGSvuA/IAbiz8=; b=iuWsyx0I/rbYHPPp2o/kQbKco+m4PFVNxCkyTboR81fqO/OVZ+C03g/VNJi2bVdxg1 jaBWereZJde124YJNd5kixleYpm0Y7JkpYjnYlP4GKjCs+qnhw6f+J0dTFBJxRfcwKNi VtN9h2sxcvBSwxhVvP3dxYRbvatPgV8zZEOIsRo2FiV1E+qlT/Su00VpnZcEQel91nKz GLCZINPXrUblXarsS8POmM2m6YIAkWfcVNA0Ema9iW+1wy2CfqLzodMLXdAHNO77mXLj Cg979FpZKc0LEh0W4gP1vViYRhqK6jjg1p3TIvcrk8IzHGVezuZm4gu4LL/gtY85RmdS ziKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8fNpNjS47yJts7ars9XTm9QNj5qK6ZUGSvuA/IAbiz8=; b=dSgXy3SM+zXOTb34Izozid67eLBnVOVtBrPrJo8poGb09GzERRRZoOGt8R5bVqL7Ka CR0fvMNlPOG7DldBq8VyX0SanxKe9Ar/WPnuFIo6OhccUhtnvW3QlAcRTguOmLFi0vtM p0ANxyDuWtO70k8si0vrSN1s8+uKCV+JetsKhBjhFnvFwfhs9t4+SdrT5VOEPLydqYlf A8tlvIXUkiLWud196I6spb7fzXf0iBfcLjIV4mG+yNKSqHj4l33h/EzoH306hG0dVRCS shUFI8EH/9fSq7y3BdlvmJo2Jq8LunM3593ld6CbLnDVNs75Z8huAT62+16WcR+BS6eo hx/A== X-Gm-Message-State: AKGB3mK+E6Q+cQEomebGy7YT5635WABlhjpnbM2znpCcfy8Vsb9mNubo EOsWMJS5CfmtXUB4ce1xeH0= X-Google-Smtp-Source: ACJfBouOJx0ibrva/lsFPW0FBzmm6a7equg152G0ZV8bCDfLGqK8tU+pUMhUFmxiWOprVP7SWbt4dA== X-Received: by 10.80.193.9 with SMTP id l9mr2072616edf.176.1513072490651; Tue, 12 Dec 2017 01:54:50 -0800 (PST) Received: from alans-mbp.lan ([31.185.193.242]) by smtp.gmail.com with ESMTPSA id q3sm8261261edd.61.2017.12.12.01.54.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Dec 2017 01:54:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4AA2CE81-C73B-46AA-90D3-47E005F12054" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <20171127053345.GT39967@Chimay.local> Date: Tue, 12 Dec 2017 09:54:49 +0000 Cc: Olivier Bonaventure , multipathtcp , "philip.eardley@bt.com" , Yoshifumi Nishida , =?utf-8?Q?Fran=C3=A7ois_Finfe?= Message-Id: References: <20171127053345.GT39967@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] MPTCP FAST_CLOSE X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 09:54:55 -0000 --Apple-Mail=_4AA2CE81-C73B-46AA-90D3-47E005F12054 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Does anyone else have any opinions on this proposal? As said, I don=E2=80=99t personally have an issue with adding this = methodology - it=E2=80=99s just text, specifying how to behave when = receiving RST + MP_FASTCLOSE - a previously undefined behaviour. There = is no significant cost here, but equally I=E2=80=99m not keen on adding = more text for the sake of it. I don=E2=80=99t personally have the = implementation experience to feel confident on the benefit here - what = do other implementors think? Cheers, Alan > On 27 Nov 2017, at 05:33, Christoph Paasch wrote: >=20 > Hello Alan, >=20 > On 14/11/17 - 11:12:45, Alan Ford wrote: >> Hi Olivier, >>=20 >> Can you clarify what issue we are trying to solve here? Is this a = purely a matter of shutting down a connection rapidly without = maintaining state? >=20 > the main motivation is that when a host decides to force-close > an MPTCP-connection, in many cases it is due to resource-shortage = (running > out of memory). In that case, we really want to be able to get rid of = the > state as quickly as possible. Sending ACK+MP_FASTCLOSE, immediately = followed > by a RST would do the job as well, but I think the RST+MP_FASTCLOSE = option > is cleaner. >=20 >=20 > Cheers, > Christoph >=20 >>=20 >> The minimum to be compliant as written requires RSTing every subflow = bar one, then sending MP_FASTCLOSE on one subflow. The retransmit is = only a SHOULD, so you could theoretically RST that subflow after a RTO = too. Or is that RTO still too much to keep? >>=20 >> I don=E2=80=99t have an issue with adding this methodology - it does = not require any significant changes, just specifies how to behave when = receiving RST + MP_FASTCLOSE. >>=20 >> The acknowledged model was designed so that it was less likely that = any state would be left at middleboxes and at the client. This does not = ensure it was received at the client so in theory the client could sit = there not knowing the connection had gone away. However, this is no = worse than regular TCP so I don=E2=80=99t immediately see any problems = here. >>=20 >> Regards, >> Alan >>=20 >>> On 13 Nov 2017, at 14:30, Olivier Bonaventure = wrote: >>>=20 >>> Hello, >>>=20 >>> Sorry for being late with this, but the beginning of the fall = semester is always too busy for me. >>>=20 >>> During the summer, there was a discussion on the FAST_CLOSE option = that was triggered by Francois. >>>=20 >>> The current text of RFC6824bis uses the FAST_CLOSE option inside ACK = packets, but deployment experience has shown that this results in = additional complexity since the ACK must be retransmitted to ensure its = reliable delivery. >>>=20 >>> Here is a proposed update for section 3.5 that allows a sender to = either send FAST_CLOSE inside ACK or RST while a receiver must be ready = to process both. Changes are marked with * * >>>=20 >>> ------------------ >>> 3.5. Fast Close >>>=20 >>> Regular TCP has the means of sending a reset (RST) signal to = abruptly >>> close a connection. With MPTCP, a *reguler* RST only has the scope = of the >>> subflow and will only close the concerned subflow but not affect = the >>> remaining subflows. MPTCP's connection will stay alive at the data >>> level, in order to permit break-before-make handover between >>> subflows. It is therefore necessary to provide an MPTCP-level >>> "reset" to allow the abrupt closure of the whole MPTCP connection, >>> and this is the MP_FASTCLOSE option. >>>=20 >>> MP_FASTCLOSE is used to indicate to the peer that the connection = will >>> be abruptly closed and no data will be accepted anymore. The = reasons >>> for triggering an MP_FASTCLOSE are implementation specific. = Regular >>> TCP does not allow sending a RST while the connection is in a >>> synchronized state [RFC0793]. Nevertheless, implementations allow >>> the sending of a RST in this state, if, for example, the operating >>> system is running out of resources. In these cases, MPTCP should >>> send the MP_FASTCLOSE. This option is illustrated in Figure 14. >>>=20 >>> 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >>> = +---------------+---------------+-------+-----------------------+ >>> | Kind | Length |Subtype| (reserved) = | >>> = +---------------+---------------+-------+-----------------------+ >>> | Option Receiver's Key = | >>> | (64 bits) = | >>> | = | >>> = +---------------------------------------------------------------+ >>>=20 >>> Figure 14: Fast Close (MP_FASTCLOSE) Option >>>=20 >>> If Host A wants to force the closure of an MPTCP connection, *it = has two different options* : >>>=20 >>> - *Option A (ACK) : *Host A sends an ACK containing the = MP_FASTCLOSE option on one >>> subflow, containing the key of Host B as declared in the initial >>> connection handshake. On all the other subflows, Host A sends a >>> regular TCP RST to close these subflows, and tears them down. >>> Host A now enters FASTCLOSE_WAIT state. >>>=20 >>> - *Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE = option on all >>> subflows, containing the key of Host B as declared in the = initial >>> connection handshake. Host A can tear the subflows and the = connection down immediately.* >>>=20 >>>=20 >>>=20 >>> *If a host receives a packet with a valid MP_FASTCLOSE option, it = shall process it as follows :* >>>=20 >>> o Upon receipt of an *ACK* with MP_FASTCLOSE, containing the valid = key, Host B answers on the same subflow with a TCP RST and tears down = all >>> subflows. Host B can now close the whole MPTCP connection (it >>> transitions directly to CLOSED state). >>>=20 >>> o As soon as Host A has received the TCP RST on the remaining >>> subflow, it can close this subflow and tear down the whole >>> connection (transition from FASTCLOSE_WAIT to CLOSED states). = If >>> Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts >>> attempted fast closure simultaneously. Host A should reply with = a >>> TCP RST and tear down the connection. >>>=20 >>> o If Host A does not receive a TCP RST in reply to its = MP_FASTCLOSE >>> after one retransmission timeout (RTO) (the RTO of the subflow >>> where the MPTCP_RST has been sent), it SHOULD retransmit the >>> MP_FASTCLOSE. The number of retransmissions SHOULD be limited = to >>> avoid this connection from being retained for a long time, but >>> this limit is implementation specific. A RECOMMENDED number is = 3. >>> If no TCP RST is received in response, Host A SHOULD send a TCP >>> RST *with the MP_FASTCLOSE option* itself when it releases state = in order to clear any remaining state at middleboxes. >>>=20 >>> *o Upon receipt of a RST with MP_FASTCLOSE, containing the valid = key, Host B tears down all subflows. Host B can now close the whole = MPTCP connection (it transitions directly to CLOSED state).* >>>=20 >>> ---------- >>>=20 >>>=20 >>> The burden of the MP_FASTCLOSE is on the host that decides to close = the connection (typically the server, but not necessarily). The text = above allows it to opt for either ACK or RST without adding complexity = to the other side. >>>=20 >>>=20 >>> Another point that might be discussed in RFC6824bis is how a host = should react when there are all the subflows associates to a Multipath = TCP connection are in the CLOSED state, but the connection is still = alive. At this point, it is impossible to send or receive data over the = connection. It should attempt to reestablish one subflow to keep the = connection alive. >>>=20 >>>=20 >>> Olivier >>=20 --Apple-Mail=_4AA2CE81-C73B-46AA-90D3-47E005F12054 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Does anyone else have any opinions on this = proposal?

As = said, I don=E2=80=99t personally have an issue with adding this = methodology - it=E2=80=99s just text, specifying how to behave when = receiving RST + MP_FASTCLOSE - a previously undefined behaviour. There = is no significant cost here, but equally I=E2=80=99m not keen on adding = more text for the sake of it. I don=E2=80=99t = personally have the implementation experience to feel confident on the = benefit here - what do other implementors think?

Cheers,
Alan

On 27 Nov 2017, at 05:33, = Christoph Paasch <cpaasch@apple.com> wrote:

Hello = Alan,

On 14/11/17 - 11:12:45, Alan Ford = wrote:
Hi Olivier,

Can you clarify what issue we are trying to = solve here? Is this a purely a matter of shutting down a connection = rapidly without maintaining state?

the main motivation is that when a host decides to = force-close
an MPTCP-connection, in many cases it is due = to resource-shortage (running
out of memory). In that = case, we really want to be able to get rid of the
state as = quickly as possible. Sending ACK+MP_FASTCLOSE, immediately followed
by a RST would do the job as well, but I think the = RST+MP_FASTCLOSE option
is cleaner.


Cheers,
Christoph


The minimum to be compliant as written requires RSTing every = subflow bar one, then sending MP_FASTCLOSE on one subflow. The = retransmit is only a SHOULD, so you could theoretically RST that subflow = after a RTO too. Or is that RTO still too much to keep?

I don=E2=80=99t have an issue with adding this methodology - = it does not require any significant changes, just specifies how to = behave when receiving RST + MP_FASTCLOSE.

The= acknowledged model was designed so that it was less likely that any = state would be left at middleboxes and at the client. This does not = ensure it was received at the client so in theory the client could sit = there not knowing the connection had gone away. However, this is no = worse than regular TCP so I don=E2=80=99t immediately see any problems = here.

Regards,
Alan

On 13 Nov = 2017, at 14:30, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:

Hello,

Sorry for = being late with this, but the beginning of the fall semester is always = too busy for me.

During the summer, there = was a discussion on the FAST_CLOSE option that was triggered by = Francois.

The current text of RFC6824bis = uses the FAST_CLOSE option inside ACK packets, but deployment experience = has shown that this results in additional complexity since the ACK must = be retransmitted to ensure its reliable delivery.

Here is a proposed update for section 3.5 that allows a = sender to either send FAST_CLOSE inside ACK or RST while a receiver must = be ready to process both. Changes are marked with * *

------------------
3.5.  Fast Close

 Regular TCP has the means of sending a = reset (RST) signal to abruptly
 close a connection. = With MPTCP, a *reguler* RST only has the scope of the
=  subflow and will only close the concerned subflow but not affect = the
 remaining subflows.  MPTCP's connection = will stay alive at the data
 level, in order to = permit break-before-make handover between
 subflows. =  It is therefore necessary to provide an MPTCP-level
=  "reset" to allow the abrupt closure of the whole MPTCP = connection,
 and this is the MP_FASTCLOSE option.

 MP_FASTCLOSE is used to indicate to the = peer that the connection will
 be abruptly closed = and no data will be accepted anymore.  The reasons
=  for triggering an MP_FASTCLOSE are implementation specific. =  Regular
 TCP does not allow sending a RST = while the connection is in a
 synchronized state = [RFC0793].  Nevertheless, implementations allow
=  the sending of a RST in this state, if, for example, the = operating
 system is running out of resources. =  In these cases, MPTCP should
 send the = MP_FASTCLOSE.  This option is illustrated in Figure 14.

=             &n= bsp;           &nbs= p; 1 =             &n= bsp;     2 =             &n= bsp;     3
=       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=      +---------------+---------------+-------+---= --------------------+
     | =     Kind      | =    Length     |Subtype| =      (reserved) =       |
=      +---------------+---------------+-------+---= --------------------+
     | =             &n= bsp;        Option Receiver's = Key =             &n= bsp;      |
=      | =             &n= bsp;           &nbs= p;  (64 bits) =             &n= bsp;           &nbs= p;|
     | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=      +-------------------------------------------= --------------------+

=             &n= bsp; Figure 14: Fast Close (MP_FASTCLOSE) Option

 If Host A wants to force the closure of an MPTCP = connection, *it has two different options* :

=  - *Option A (ACK) : *Host A sends an ACK containing the = MP_FASTCLOSE option on one
=     subflow, containing the key of Host B as = declared in the initial
=     connection handshake.  On all the other = subflows, Host A sends a
    regular = TCP RST to close these subflows, and tears them down.
=     Host A now enters FASTCLOSE_WAIT state.

 - *Option R (RST) : Host A sends a RST = containing the MP_FASTCLOSE option on all
=     subflows, containing the key of Host B as = declared in the initial
=     connection handshake.  Host A can tear the = subflows and the connection down immediately.*



 *If a host receives a = packet with a valid MP_FASTCLOSE option, it shall process it as follows = :*

 o  Upon receipt of an *ACK* = with MP_FASTCLOSE, containing the valid key, Host B answers on the same = subflow with a TCP RST and tears down all
=     subflows.  Host B can now close the whole = MPTCP connection (it
    transitions = directly to CLOSED state).

 o =  As soon as Host A has received the TCP RST on the remaining
    subflow, it can close this subflow = and tear down the whole
=     connection (transition from FASTCLOSE_WAIT to = CLOSED states).  If
    Host A = receives an MP_FASTCLOSE instead of a TCP RST, both hosts
=     attempted fast closure simultaneously. =  Host A should reply with a
=     TCP RST and tear down the connection.

 o  If Host A does not receive a = TCP RST in reply to its MP_FASTCLOSE
=     after one retransmission timeout (RTO) (the RTO = of the subflow
    where the = MPTCP_RST has been sent), it SHOULD retransmit the
=     MP_FASTCLOSE.  The number of = retransmissions SHOULD be limited to
=     avoid this connection from being retained for a = long time, but
    this limit is = implementation specific.  A RECOMMENDED number is 3.
=     If no TCP RST is received in response, Host A = SHOULD send a TCP
    RST *with the = MP_FASTCLOSE option* itself when it releases state in order to clear any = remaining state at middleboxes.

*o =  Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, = Host B tears down all subflows. Host B can now close the whole MPTCP = connection (it transitions directly to CLOSED state).*

----------


The = burden of the MP_FASTCLOSE is on the host that decides to close the = connection (typically the server, but not necessarily). The text above = allows it to opt for either ACK or RST without adding complexity to the = other side.


Another point = that might be discussed in RFC6824bis is how a host should react when = there are all the subflows associates to a Multipath TCP connection are = in the CLOSED state, but the connection is still alive. At this point, = it is impossible to send or receive data over the connection. It should = attempt to reestablish one subflow to keep the connection alive.


Olivier


= --Apple-Mail=_4AA2CE81-C73B-46AA-90D3-47E005F12054--