From nobody Tue Apr 9 06:33:05 2019 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 DCBBC120305 for ; Tue, 9 Apr 2019 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=bt.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 AiCRNZEq1kAF for ; Tue, 9 Apr 2019 06:33:01 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6F51207F4 for ; Tue, 9 Apr 2019 06:33:01 -0700 (PDT) Received: from tpw09926dag08g.domain1.systemhost.net (10.9.202.43) by BWP09926084.bt.com (10.36.82.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 9 Apr 2019 14:32:40 +0100 Received: from tpw09926dag17e.domain1.systemhost.net (10.9.212.17) by tpw09926dag08g.domain1.systemhost.net (10.9.202.43) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Apr 2019 14:32:57 +0100 Received: from bwp09926082.bt.com (10.36.82.113) by tpw09926dag17e.domain1.systemhost.net (10.9.212.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 9 Apr 2019 14:32:57 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.54) by smtpe1.intersmtp.com (10.36.82.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 9 Apr 2019 14:32:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/aMbDaf5Hi8s8TZc86dK7bDIwVFHsZbHIDo6XYI+bc=; b=4cYFVMeT2QSEJ3Wx1Qq+wNDxVRqRfbJOD+K/p0fodCGVQW1yUN1nHlpKScIhzy5OIPPCd12ccEO/O03kmkwNvbUpaKKj4P1I49pZpUOd2zSB1g1aQ2o8yhq935OPdJTv0ufXuYVm6LWgMeMqEGA1JgzDD5uUL1MuyoUGw9ekopM= Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM (20.176.157.10) by LO2P123MB1952.GBRP123.PROD.OUTLOOK.COM (20.176.156.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Tue, 9 Apr 2019 13:32:56 +0000 Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::7940:b11d:fe0c:9f2f]) by LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::7940:b11d:fe0c:9f2f%5]) with mapi id 15.20.1792.009; Tue, 9 Apr 2019 13:32:56 +0000 From: To: Thread-Topic: RFC6824bis code available Thread-Index: AQHU7tgeo07eZaQ140afGCaNkqNEBg== Date: Tue, 9 Apr 2019 13:32:56 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [81.146.50.57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2aa3012-422c-4eb6-2cc7-08d6bcefe06b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:LO2P123MB1952; x-ms-traffictypediagnostic: LO2P123MB1952: x-ms-exchange-purlcount: 1 x-antispam-2: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(366004)(39860400002)(199004)(189003)(7696005)(6916009)(106356001)(2351001)(5640700003)(316002)(105586002)(99286004)(86362001)(6436002)(5660300002)(19627405001)(74316002)(26005)(102836004)(486006)(14454004)(6606003)(966005)(6506007)(4744005)(606006)(66066001)(7116003)(476003)(478600001)(8936002)(52536014)(81166006)(71190400001)(8676002)(81156014)(71200400001)(25786009)(6116002)(1730700003)(3846002)(21615005)(54896002)(1015004)(236005)(9686003)(6306002)(68736007)(186003)(53936002)(2906002)(55016002)(97736004)(2501003)(7736002)(256004)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1952; H:LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yGjBCjkfIAwVie+NvnJm4UVBJqSp18Xg8kOsGa/Qt9mJ2HI68lg0pnvvL9MYV6EZyE4UcSvZygv2AiFjGgscheCkQqQy9s7C2bSdTkcaFphbuJD+zQtH19wqbBnyulXT1cp3FNLwzQUThdSBUbciBHQuNrQgQHwXpiOv9wzPv2fyxR4YZcSBYtLziqg7Y7VYNqqyRUjkb00AMDTr9qPC5BVvhjY3zYdXp0iJ78B96ctGSP1gBxUeE9MpRx+sh9ADqfQI55pIKJCNhwozMT4I5Wq/BDfLwJNa6wj0PICJI+YR0PUg2MERDCF+kV09v7TOOAfycMWqlr8fmMKLQSbe60KkpDOY9ZCGboKt0tLGUWs4oAdApx3T9j+CbuIjBakbBgu+lGrjJ9f+ot4YqXc6zCVuPRnaEMp9LLRzrxi9C9s= Content-Type: multipart/alternative; boundary="_000_LO2P123MB1965F9D012479939464F5285EB2D0LO2P123MB1965GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2aa3012-422c-4eb6-2cc7-08d6bcefe06b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 13:32:56.7179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1952 X-OriginatorOrg: bt.com Archived-At: Subject: [multipathtcp] RFC6824bis code available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 13:33:04 -0000 --_000_LO2P123MB1965F9D012479939464F5285EB2D0LO2P123MB1965GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To follow up on the good news from Prague - the RFC6824bis code is now avai= lable. https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2019-04/msg00003.html Many thanks to Christoph and Apple for writing the code and agreeing to rel= ease it. It would be excellent if some people could test it out. Although the bis do= cument is now with Mirja (publication requested), if issues are discovered,= at the moment it's not too late to make changes or clarifications. Best wishes, phil --_000_LO2P123MB1965F9D012479939464F5285EB2D0LO2P123MB1965GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To follow up on the good news fro= m Prague - the RFC6824bis code is now available.

https://sympa-2.sipr.ucl.ac.be/sy= mpa/arc/mptcp-dev/2019-04/msg00003.html


Many thanks to Christoph and Appl= e for writing the code and agreeing to release it.


It would be excellent if some peo= ple could test it out. Although the bis document is now with Mirja (publica= tion requested), if issues are discovered, at the moment it's not too = late to make changes or clarifications. 


Best wishes,

phil

--_000_LO2P123MB1965F9D012479939464F5285EB2D0LO2P123MB1965GBRP_-- From nobody Fri Apr 12 09:40:37 2019 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 74195120670; Fri, 12 Apr 2019 09:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfhzEgwUH8dm; Fri, 12 Apr 2019 09:40:26 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 EDA6B120395; Fri, 12 Apr 2019 09:40:22 -0700 (PDT) Received: from 200116b82c2d0c00555562f7a1ad4d5a.dip.versatel-1u1.de ([2001:16b8:2c2d:c00:5555:62f7:a1ad:4d5a]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hEzDw-0007Ax-4i; Fri, 12 Apr 2019 18:40:20 +0200 From: Mirja Kuehlewind Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> Date: Fri, 12 Apr 2019 18:40:19 +0200 Cc: multipathtcp@ietf.org To: draft-ietf-mptcp-rfc6824bis.all@ietf.org X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1555087226;dc0a5bd4; X-HE-SMSGID: 1hEzDw-0007Ax-4i Archived-At: Subject: [multipathtcp] AD review is coming X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:40:34 -0000 Hi authors, hi shepherd/Phil, Just wanted to quickly let you know that I=E2=80=99ve started the IETF = last call just now in order to hopefully get this document on the = telechat in 3 weeks.=20 I=E2=80=99ve not finished my AD review completely but I am nearly done = and convinced that this doc is ready to start IETF last call. So far I = have only some editorial or smallish comments and nits which I will send = in detail beginning of next week and can be address during or after IETF = last call. Only one request for now (mostly with an eye on the IESG evaluation): = The draft says that changes are made which are not backward compatible = (see sec 3.1). That=E2=80=99s fine, however, it would be good to also = explain a little bit in the draft as well as in the shepherd write up = (!) why this is okay. My understanding is that in case of a v0 server = the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable and = that this is acceptable in current deployment situation. Please confirm = and at least update the write-up accordingly as soon as possible! Thanks! Mirja From nobody Fri Apr 12 09:57:41 2019 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E97A1120376; Fri, 12 Apr 2019 09:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: mptcp-chairs@ietf.org, multipathtcp@ietf.org, philip.eardley@bt.com, Philip Eardley , ietf@kuehlewind.net, draft-ietf-mptcp-rfc6824bis@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155508825088.16951.6227948364597097521.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2019 09:57:30 -0700 Archived-At: Subject: [multipathtcp] Last Call: (TCP Extensions for Multipath Operation with Multiple Addresses) to Proposed Standard X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:57:31 -0000 The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'TCP Extensions for Multipath Operation with Multiple Addresses' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1842/ https://datatracker.ietf.org/ipr/1843/ https://datatracker.ietf.org/ipr/3242/ The document contains these normative downward references. See RFC 3967 for additional information: rfc6182: Architectural Guidelines for Multipath TCP Development (Informational - IETF stream) From nobody Mon Apr 15 09:55:21 2019 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 8AABF120099; Mon, 15 Apr 2019 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-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 XZIgNRmE0G40; Mon, 15 Apr 2019 09:55:18 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 C7C8A12000F; Mon, 15 Apr 2019 09:55:17 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id s15so22852397wra.12; Mon, 15 Apr 2019 09:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hTaDfKp0DapHs8XfiDZ3PtaQCAxLgMWFjzUmzLVBcew=; b=QH3g5EiYPxe/tpvIL3PUYpMLSPB+OX///ynLI1AO/NMXQEZcBVZjyAKiiVGL1RKKje kQeMpVuNiWKnYds8nPezQccwUlVm6X2qfS49blUlmqAJEEUxIr4kT6wQVcau5pustC+0 tyojKJDZ/ezIJljaNUSpHIru+uhfJCUFeYGhjWV57iymgUMUPmtssgvrlbOw+atPdEoM 86l2HqaOWmw9SXCjUgkT0cxK7Kzwinh4RFgCm//EhgnL01LRPw3YUfZSvdCV/oHWjP1H Fn+oozC+J8928L1/WPl55k5Oxa5jZusV4hWwig8+SXZ42n70+zzqaxttHuMRxLDumO5E ULmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hTaDfKp0DapHs8XfiDZ3PtaQCAxLgMWFjzUmzLVBcew=; b=Oy0zWh2p/HM/nSYsIrDHxiWtYpCQRs+/n4nxLqWrR+75CLiWpc1Mk4YCOhKzHVqVW0 5djFQy5bb8oTgEt2jDSdeqJUNSgDUJt+PhQ37xQiI+ZlSZT3E7X12LdVFGa5D9yC83hf nJWK/Fm4Dkceru8rr3f4DHoFphxnyi29NNEfD46g30xRTS/xiPHb/v4r91n6NIiaKN+V rt5OJl8WKd97TRRGCOzL4ktxIrtCucCis+Arh6qlsfDXOF4gdWpC3FhOGBaY6PXH1ktN kgXKMYX1pp0JnFeNduQEwYhxVmWcQcmtGxDDRTCL/sw6CNHdAnoRqh5ioxvGQ0IicxSF FyUw== X-Gm-Message-State: APjAAAUMfrKSqGQvQ0uSKKgJVNfBNP1OX4wcWuYWDTFw7yxWhq8/A1Hu ASc20GvyeYQivC7BacE2G9AUH8zI X-Google-Smtp-Source: APXvYqw8P6Fm4vAe0V3RqvKHHi8OZDlJGQwE6/GM61zNCrUZba41tO1c/ifqtFxMd6E8Qxs7IYSG2g== X-Received: by 2002:a5d:68cd:: with SMTP id p13mr12696815wrw.22.1555347316221; Mon, 15 Apr 2019 09:55:16 -0700 (PDT) Received: from [172.20.10.2] (188.29.164.153.threembb.co.uk. [188.29.164.153]) by smtp.gmail.com with ESMTPSA id q8sm21058663wmq.35.2019.04.15.09.55.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Apr 2019 09:55:15 -0700 (PDT) From: Alan Ford Message-Id: <5C08EA72-1AF7-4466-9070-B3F98E7D3017@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_332D42D5-381E-4A98-A96E-25083BF8E909" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 15 Apr 2019 17:55:11 +0100 In-Reply-To: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> Cc: draft-ietf-mptcp-rfc6824bis.all@ietf.org, multipathtcp@ietf.org To: Mirja Kuehlewind References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [multipathtcp] AD review is coming X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 16:55:19 -0000 --Apple-Mail=_332D42D5-381E-4A98-A96E-25083BF8E909 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, To be clear, you are looking for some rationale in the draft text as = well? The technical discussion of the fallback process is given in = Section 3.1: The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0 [RFC6824]. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. In return, in its MP_CAPABLE option, the receiver will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. There is a caveat though with respect to this version negotiation with old listeners that only support v0. A listener that supports v0 expects that the MP_CAPABLE option in the SYN-segment includes the initiator's key. If the initiator however already upgraded to v1, it won't include the key in the SYN-segment. Thus, the listener will ignore the MP_CAPABLE of this SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE, thus leading to a fallback to regular TCP. An initiator MAY cache this information about a peer and for future connections, MAY choose to attempt using MPTCP v0, if supported, before recording the host as not supporting MPTCP. But you would like to see some discussion mentioning the migration from = Experimental to Proposed Standard? And the benefits it brings? Would = that cover it? Many thanks, Alan > On 12 Apr 2019, at 17:40, Mirja Kuehlewind = wrote: >=20 > Hi authors, hi shepherd/Phil, >=20 > Just wanted to quickly let you know that I=E2=80=99ve started the IETF = last call just now in order to hopefully get this document on the = telechat in 3 weeks.=20 >=20 > I=E2=80=99ve not finished my AD review completely but I am nearly done = and convinced that this doc is ready to start IETF last call. So far I = have only some editorial or smallish comments and nits which I will send = in detail beginning of next week and can be address during or after IETF = last call. >=20 > Only one request for now (mostly with an eye on the IESG evaluation): = The draft says that changes are made which are not backward compatible = (see sec 3.1). That=E2=80=99s fine, however, it would be good to also = explain a little bit in the draft as well as in the shepherd write up = (!) why this is okay. My understanding is that in case of a v0 server = the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable and = that this is acceptable in current deployment situation. Please confirm = and at least update the write-up accordingly as soon as possible! >=20 > Thanks! > Mirja >=20 >=20 >=20 --Apple-Mail=_332D42D5-381E-4A98-A96E-25083BF8E909 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mirja,

To be clear, = you are looking for some rationale in the draft text as well? The = technical discussion of the fallback process is given in Section = 3.1:
   The MP_CAPABLE exchange in this specification =
(v1) is different to
   that specified in v0 [RFC6824].  If a host supports multiple versions
   of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
   highest version number it supports.  In return, in its MP_CAPABLE
   option, the receiver will signal the version number it wishes to use,
   which MUST be equal to or lower than the version number indicated in
   the initial MP_CAPABLE.  There is a caveat though with respect to
   this version negotiation with old listeners that only support v0.  A
   listener that supports v0 expects that the MP_CAPABLE option in the
   SYN-segment includes the initiator's key.  If the initiator however
   already upgraded to v1, it won't include the key in the SYN-segment.
   Thus, the listener will ignore the MP_CAPABLE of this SYN-segment and
   reply with a SYN/ACK that does not include an MP_CAPABLE, thus
   leading to a fallback to regular TCP.  An initiator MAY cache this
   information about a peer and for future connections, MAY choose to
   attempt using MPTCP v0, if supported, before recording the host as
   not supporting MPTCP.
But you would like to see some discussion = mentioning the migration from Experimental to Proposed Standard? And the = benefits it brings? Would that cover it?

Many = thanks,
Alan

On 12 Apr 2019, at 17:40, Mirja Kuehlewind = <ietf@kuehlewind.net> wrote:

Hi = authors, hi shepherd/Phil,

Just wanted to = quickly let you know that I=E2=80=99ve started the IETF last call just = now in order to hopefully get this document on the telechat in 3 weeks. =

I=E2=80=99ve not finished my AD review = completely but I am nearly done and convinced that this doc is ready to = start IETF last call. So far I have only some editorial or smallish = comments and nits which I will send in detail beginning of next week and = can be address during or after IETF last call.

Only one request for now (mostly with an eye on the IESG = evaluation): The draft says that changes are made which are not backward = compatible (see sec 3.1). That=E2=80=99s fine, however, it would be good = to also explain a little bit in the draft as well as in the shepherd = write up (!) why this is okay. My understanding is that in case of a v0 = server the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable = and that this is acceptable in current deployment situation. Please = confirm and at least update the write-up accordingly as soon as = possible!

Thanks!
Mirja




= --Apple-Mail=_332D42D5-381E-4A98-A96E-25083BF8E909-- From nobody Tue Apr 16 03:05:16 2019 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 22D9612047E for ; Tue, 16 Apr 2019 03:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 Lce_X2P3fgLI for ; Tue, 16 Apr 2019 03:05:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A40120128 for ; Tue, 16 Apr 2019 03:05:09 -0700 (PDT) Received: from tpw09926dag15h.domain1.systemhost.net (10.9.212.39) by RDW083A009ED65.bt.com (10.187.98.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 16 Apr 2019 11:02:31 +0100 Received: from tpw09926dag18h.domain1.systemhost.net (10.9.212.42) by tpw09926dag15h.domain1.systemhost.net (10.9.212.39) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Apr 2019 11:05:06 +0100 Received: from RDW083A009ED65.bt.com (10.187.98.35) by tpw09926dag18h.domain1.systemhost.net (10.9.212.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 16 Apr 2019 11:05:06 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.54) by smtpe1.intersmtp.com (62.239.224.236) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 16 Apr 2019 11:02:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LawxRTyAI46Ho3e3lmKPquNxrTNIcjiqJ/wMsRcQPmg=; b=mccT6kCecouptcdtK424pHB/mRh5XJdacCmXBoxLqKa2DrjNrPu27zN3lEr8b6dh7Lel2qjys+dKlJ/jOQZXqc+fWaCyPLTPviAOf5G/HJ7guAEg3NuI1MRhqSjkCW4TdvwcOydnyx0LrTsAO0AdMCzw0s+k6cI8cCshGC6QAeI= Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM (20.176.157.10) by LO2P123MB1887.GBRP123.PROD.OUTLOOK.COM (20.176.154.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Tue, 16 Apr 2019 10:05:05 +0000 Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::7940:b11d:fe0c:9f2f]) by LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::7940:b11d:fe0c:9f2f%5]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 10:05:05 +0000 From: To: Thread-Topic: MPTCP WG minutes - draft Thread-Index: AdT0OcKjuZY10X+FSKSpns4gjqcfow== Date: Tue, 16 Apr 2019 10:05:04 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 127af6f1-d85e-438b-d1ff-08d6c252ff90 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:LO2P123MB1887; x-ms-traffictypediagnostic: LO2P123MB1887: x-antispam-2: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(346002)(376002)(189003)(199004)(486006)(71200400001)(97736004)(71190400001)(476003)(8936002)(8676002)(81166006)(106356001)(52536014)(25786009)(2351001)(105586002)(1730700003)(81156014)(478600001)(55016002)(561944003)(6506007)(53946003)(256004)(14444005)(6116002)(790700001)(3846002)(6306002)(102836004)(54896002)(9686003)(86362001)(186003)(5660300002)(4326008)(53936002)(66066001)(26005)(316002)(68736007)(99286004)(33656002)(2906002)(6916009)(7736002)(5640700003)(74316002)(14454004)(7696005)(6436002)(2501003)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1887; H:LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ek9fwhjgXIjJshoeqWdL85nsfJW+zZCafDzzNuiK32nA2WLXNkYpuXEudwZ/i6egGqAP+jLU0b20fjQo9dGGb6ajPTn9hbAA9QFGk4NtCBPsCnMOmYiVG3RWy0noNrc6auMl9hkL/WydW6SNoopaCKR3Ildnrep4Eas4pLkfU3qKfmJ85UnNC7O9waN04j3zx88rox4k83nuM1Ni/Khjz3egW1v045+D7DqOY8u/qxkO9Qr/ULZDev1TOcEQ70CuCPib42dvaRZOS+jnef7oMNGHyN3bHuZFi7Mk/udnX876IVPW0fcwD9vqpxx4bevejlI12ru9sKcpDRxOFwdkcuMDKk7Z+jv6+FlrnkO1XZDqmLlXqPbStTsjq0oKsKLUPcU88wmfz1r3UUvmO/rWEBF75t8qN9Hzs4qzGLpFic4= Content-Type: multipart/alternative; boundary="_000_LO2P123MB1965B4686737AFF0B42288BEEB240LO2P123MB1965GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 127af6f1-d85e-438b-d1ff-08d6c252ff90 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 10:05:04.9090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1887 X-OriginatorOrg: bt.com Archived-At: Subject: [multipathtcp] MPTCP WG minutes - draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 10:05:15 -0000 --_000_LO2P123MB1965B4686737AFF0B42288BEEB240LO2P123MB1965GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the draft minutes for our WG meeting in Prague. Please let us know= any corrections. Thank-you to the minute takers - I think Anna & Xavier, please shout if I r= emember wrong! Thanks Phil & Yoshi -- 1. WG status (chair) 2. Implementation news (Christoph) - Now have approval to open source the handshake - Mainline Linux kernel: growing community (RedHat, Intel, Thesaurus), maki= ng progress, will get there eventually, have support from Linux maintainers - Apache traffic server allows to enable MPTCP 3. Deployment updates 3.1. Results from the monitoring of MPTCP-based hybrid access networks - Ol= ivier Bonaventure See slides for overview of talk Q & A Q Use of transparent proxy, do you need converter (Rahul Jadhav) A. CPE sees all the traffic, no need there. HAG may use a converter or be t= ransparent. With transparent proxy on the HAG, all traffic must go through = the HAG. Otherwise use a converter. Q. Can converter be extended with policy support for scheduling (Rahul Jadh= av) A. Network operators control the policy Q. Shown employment is not consistent with 3GPP Rel 16 (Florin Baboescu?) Q. Specific scheduler used in deployment (Marcus Amend) A. Scheduler and path manager prioritize DSL network Q. In results, could you get 1G with single TCP flows. (Marcus Amend) A. Was with multiple flows Q. CPU overhead? (Marcus Amend) A. Really depend on the CPE Q. Need complement to TCP? It is hard to explain to customers if the benefi= t is for TCP only, this is why we propose a multipath UDP to complement MPT= CP (Marcus Amend) A. BBF does also GRE approach, will see how QUIC will be supported Q. What is the issue with using MPTCP for tunneling IP traffic (Florin Babo= escu?) A. MPTCP will give you reliability and delay for applications that do not n= eed it. 3.2. Multi-path Transport Deployment on Smartphone Apps - Zhen Cao See slides for overview of talk Q & A Q. Can set ECN CE mark on the path you do not want the server to use (to im= plicitly tell server which path is preferred, eg toll-free) (Lars Eggert) Does ECN work with MPTCP? (Zhen) Yes (Stuart Cheshire) Using ECN will reduce the cwnd for when you need it (Anna Brunstrom) Need this functionality for other things (Marcus Amend) Do not need more functionality in MPTCP (Lars) Need to better understand the problem before we decide solution More discussion on the mailing list would be helpful, there were already a = thread discussing this; Q. Why do you need MPTCP for mice flow. A. For better latency Q. Low latency path should naturally be the "best" path selected, so will n= ot need anything special for path management to handle this (Lars) A. Ok, got your point; At least we agree on the scenario and the problem ex= ists. Q How often does this happen (Ben) A. With full mesh all the time Q. ATSSS slide not fully correct, only cover Rel. 15. (Florin) A. Thanks, please send them to the list as the group is not fully aware of = what's happening in 3GPP. 4. Individual drafts 4.1. Initial-Path Selection for Connection Establishment in Multipath TCP -= Jianjian Zhu See slides for overview of talk Q & A Q. This caching is already discussed in bis draft (Alan Ford) Q. RSSI is not enough, suggest to look at MAMS draft (Florin) Q CQI is what we use in mobile (Chris Seal) Q Selection of initial interface important, but is independent of MPTCP. Th= ere is the same problem in QUIC. This should not be designed for MPTCP only= . (Christoph) This is happy eyeballs in narrow scope, please look at that if not familiar= . WiFi assist to prefer one interface. (Stuart Cheshire) Yes, this should be general solution. There will be PIPC side meeting (perf= ormance implications of path characteristics). (Zhen) Agree, it is a general issue, but think we should not limit multipath proto= cols to single path at start-up (Marcus) Keying attacks is a problem for happy eyeballs in MPTCP context (Alan Ford) 4.2. Generic Path-Manager Support with eBPF - Viet-Hoang Tran (remote) See slides for overview of talk Q & A 4.3. 5G Session Continuity Support in MPTCP - Xavier de Foy 5. See slides for overview of talk Q & A Q Multi-access PDN is introduced in 3GPP Rel. 16, not well mapped to talk, = also all terminals know their address (Florin) A. Need to support continuity of addresses known at client but not at serve= r Q. Key proposal is communicating session continuity type to remote peer? (S= ri) A. Not really, it is one of the possible solutions but there are other opti= ons Q. This information is not enough, need additional information, need to ana= lyze A. Actually in this particular solution the initial IP address index is als= o communicated to the remote peer, not only the session continuity type. Q Any data quantifying when you do nothing (Lars Eggert) A. No Q. Suggest we discuss this when we have data and know if there is a problem Q. Do you plan to get data (Phil) A. Do not have access to 5G network yet Any data even simulation may be useful, start with data (Lars) Q. For 3GPP we have clear items that have priority, would like to have focu= s on this, this is not one of them (Florin) Let's talk later to see how to best convey this to group (Phil) 5. Potential future topics for WG 5.1. Brief summary of Monday's side meeting 5.2. TAPS multipath support - Anna Brunstrom 5.3. Open discussion Welcome input on API. Open issue on improving granularity of info (Apple us= e enum and 3 modes eg interactive, aggregation) (Tommy) Path manager and scheduler is a challenge because you often have two compet= ing goals, reduce cost and improve performance. Ok on the client you can ma= ke this trade-off, but needs to be communicated to the server. We currently= know who we talk to and configure a policy for a particular service, This = is not a general solution, so some signalling from client to server would b= e very useful. (Christoph) Have you tried using ECN approach suggested by Lars? (Phil) Can perhaps support throughput, but does not work for latency (Christoph) Can we perhaps solve some of these issues in more general context, will app= ly to multipath QUIC as well at some time or any multipath protocol Think it is important to collect path scheduling algorithms in informationa= l document (Markus) Issue is not only on handset, also on proxy that may implement load balanci= ng scheme (Florin) Would be useful to tease this problem apart (Lars) Hear a lot of interesting issues, but they seem like research issues. Also = some minor extensions, that could be done in tcpm. Also hear discussion on = interfaces, this links to TAPS Not only research issues, also experiences from operational experience. Als= o need connection to BBF and 3GPP Can be handled in other groups (Mirja) Much easier if we have a group collecting MPTCP experts (Zhen) Concerned we are missing other experts here like congestion control. (Mirja= ) Do have issue if a terminal or proxy need to implement a policy, we have ve= ry clear requirements here. (Florin) For ATSSS we have a side channel for policies, right (Christoph) Issue is how to use the policy as I understand (Florin) Think we should have informational document on scheduling and path manageme= nt for BBF and 3GPP to know. Do you think this is research? (Markus) This topic is relevant for other protocols as well, we will find a home for= this document (Mirja) Closing a wg is not a threat to close the work, perhaps we should have a ge= neral wg on multipath (Tommy) Agree a generic multipath group could be good. IEEE, 3GPP want to use IETF = protocols, timeframe is ~ Dec 2019. (Florin) Do not understand why we should close a group when we have issues to solve = (Zhen) Group has finished its charter, then we normally close. The mailing list ca= n stay open. (Mirja) --_000_LO2P123MB1965B4686737AFF0B42288BEEB240LO2P123MB1965GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are the draft minutes for our WG meeting in Prague. Please le= t us know any corrections.

Thank-you to the minute takers – I think Anna & Xavier, = please shout if I remember wrong!

Thanks

Phil & Yoshi

--

 <= /span>

1. WG status (chair)=

 <= /span>

2. Implementation news (Chr= istoph)

- Now have approval to open= source the handshake

- Mainline Linux kernel: gr= owing community (RedHat, Intel, Thesaurus), making progress, will get there even= tually, have support from Linux maintainers

- Apache traffic server allows to enabl= e MPTCP

 <= /span>

3. Deployment updates

3.1. Results from the monit= oring of MPTCP-based hybrid access networks - Olivier Bonaventure

See slides for overview of = talk

 <= /span>

Q & A

 <= /span>

Q Use of transparent proxy,= do you need converter (Rahul Jadhav)<= /p>

A. CPE sees all the traffic, no need there. HAG may use a converter or be tra= nsparent. With transparent proxy on the HAG, all traffic must go through the HAG. Otherwise use a co= nverter.

 <= /span>

Q. Can converter be extende= d with policy support for scheduling (Rahul Jadhav)=

A. Network operators control the policy

 <= /span>

Q. Shown em= ployment is not consistent with 3GPP Rel 16 (Florin Baboescu?)

 <= /span>

Q. Specific scheduler used = in deployment (Marcus Amend)

A. Scheduler and path manag= er prioritize DSL network

 <= /span>

Q. In results, could you ge= t 1G with single TCP flows. (Marcus Amend)

A. Was with multiple flows<= /span>

 <= /span>

Q. CPU overhe= ad? (Marcus Amend)

A. Really depend on the CPE=

 <= /span>

Q. Need complement to TCP? It is hard to explain to customers if the benefit is for TCP only= , this is why we propose a multipath UDP to complement MPTCP (Marcus Amend)

A. BBF doe= s also GRE approach, will see how QUIC will be supported 

 <= /span>

Q. What is the issue with using MPTCP for tunneling IP traffic (Florin Baboescu?)

A. MPTCP will give you reli= ability and delay for applications that do not need it.

 <= /span>

3.2. Multi-path Transport D= eployment on Smartphone Apps - Zhen Cao =

See slides for overview of = talk

 <= /span>

Q & A

 <= /span>

Q. Can set ECN CE mark on t= he path you do not want the server to use (t= o implicitly tell server which path is preferred, eg toll-free) (Lars Eggert)

Does ECN work with MPTCP? (= Zhen)

Yes (Stuart Cheshire)

Using ECN will reduce the c= wnd for when you need it (Anna Brunstrom)

Need this functionality for= other things (Marcus Amend)

Do not need more functional= ity in MPTCP (Lars)

Need to better understand t= he problem before we decide solution

More discussion on the mailing li= st would be helpful, there were already a thread discussing this; 

 <= /span>

Q. Why do you need MPTCP fo= r mice flow. 

A. For better latency

 <= /span>

Q. Low latency path should = naturally be the "best" path selected, so will not need anything special for path management to handle this (Lars)

A. Ok, got your point; At least we agree on the scenario and the problem exists. 

Q  How often does this= happen (Ben)

A. With full mesh all the t= ime

 <= /span>

Q. ATSSS slide not fully co= rrect, only cover Rel. 15. (Florin)

A. Thanks, please send them to the list as the group is not fully aware of what's hap= pening in 3GPP. 

 <= /span>

 <= /span>

4. Individual drafts <= /span>

4.1. Initial-Path Selection= for Connection Establishment in Multipath TCP - Jianjian Zhu 

See slides for overview of = talk

 <= /span>

Q & A

Q. This caching is already = discussed in bis draft (Alan Ford)

 <= /span>

Q. RSSI is not enough, sugg= est to look at MAMS draft (Florin)

Q CQI is what we use in mob= ile (Chris Seal)

 <= /span>

Q Selection of initial inte= rface important, but is independent of MPTCP. There is the same problem in QUIC. This should not be designed for MPTCP o= nly. (Christoph)

This is happy eyeballs in n= arrow scope, please look at that if not familiar. WiFi assist to prefer one interface. (Stuart Cheshire)

Yes, this should be general= solution. There will be PIPC side meeting (performance implications of path characteri= stics). (Zhen) 

Agree, it is a general issue, but think we should not limit multipath protocols to single path at= start-up (Marcus)

Keying attacks is a problem= for happy eyeballs in MPTCP context (Alan Ford)<= /o:p>

 <= /span>

 <= /span>

4.2. Generic Path-Manager S= upport with eBPF - Viet-Hoang Tran (remote) <= /o:p>

See slides for overview of = talk

 <= /span>

Q & A

 <= /span>

4.3. 5G Session Continuity = Support in MPTCP - Xavier de Foy 5. 

See slides for overview of = talk

 <= /span>

Q & A

 <= /span>

Q Multi-access PDN is intro= duced in 3GPP Rel. 16, not well mapped to talk, also all terminals know their address (Florin)

A. Need to support continuity of addresses known at client but not a= t server 

 <= /span>

Q. Key proposal is communicating session continuity type to remote peer? (Sri)

A. Not really, it is one of the possible solutions but there are other options

Q. This information is not enough, need additional information, need to analyze<= span style=3D"font-size:9.0pt;font-family:"Courier New";color:bla= ck">

A. Actually in this particu= lar solution the initial IP address index is also communicated to the remote peer, not only the session continuity type.

 <= /span>

Q Any data quantifying when= you do nothing (Lars Eggert)

A. No

Q. Suggest we discuss this = when we have data and know if there is a problem<= /o:p>

Q. Do you plan to get data (Phil)

A. Do not have access to 5G= network yet

Any data even simulation ma= y be useful, start with data (Lars)

 <= /span>

Q. For 3GPP we have clear i= tems that have priority, would like to have focus on this, this is not one of them (Florin)

Let's talk later to see how= to best convey this to group (Phil)

 <= /span>

 <= /span>

5. Potential future topics = for WG

5.1. Brief summary of Monda= y’s side meeting

5.2. TAPS multipath support= – Anna Brunstrom

5.3. Open discussion <= /span>

 <= /span>

Welcome input on API. Open issue on imp= roving granularity of info (Apple use enum and 3 modes eg interactive, aggregation) (Tommy)<= /p>

Path manager and scheduler = is a challenge because you often have two competing goals, reduce cost and improve perfor= mance. Ok on the client you can make this trade-off, but needs to be commun= icated to the server. We currently know who we talk to and configure a policy for a particular s= ervice, This is not a general solution, so some signalling from client to s= erver would be very useful. (Christoph)

Have you tried using ECN ap= proach suggested by Lars? (Phil)

Can perhaps support through= put, but does not work for latency (Christoph)

Can we perhaps solve s= ome of these issues in more general context, will apply to multipath QUIC as well at some time or any multipath protoco= l

Think it is important to co= llect path scheduling algorithms in informational document (Markus)

Issue is not only on handset, also on proxy that may implement load balancing scheme (Florin)

Would be useful to tease th= is problem apart (Lars)

Hear a lot of interesting i= ssues, but they seem like research issues. Also some minor extensions, that could be done in tcpm. Also hear discussion on inte= rfaces, this li= nks to TAPS

Not only research issues, a= lso experiences from operational experience. Also need connection to BBF and 3GPP

Can be handled in other gro= ups (Mirja)

Much easier if we have a gr= oup collecting MPTCP experts (Zhen)

Concerned we are missing ot= her experts here like congestion control. (Mirja)

 <= /span>

Do have issue if a terminal= or proxy need to implement a policy, we have very clear requirements here. (Florin)

For ATSSS we have a side ch= annel for policies, right (Christoph)<= /p>

Issue is how to use the pol= icy as I understand (Florin)

 <= /span>

Think we should have inform= ational document on scheduling and path management for BBF and 3GPP to know. Do you think this is research? (Mark= us)<= /span>

This topic is relevant for = other protocols as well, we will find a home for this document (Mirja)

Closing a wg is not a threa= t to close the work, perhaps we should have a general wg on multipath (Tommy)

Agree a generic multipath g= roup could be good. IEEE, 3GPP want to use IETF protocols, timeframe is ~ Dec 2019. = (Florin)

Do not understand why we sh= ould close a group when we have issues to solve (Zhen)

Group has finished its char= ter, then we normally close. The mailing list can stay open. (Mirja)<= /o:p>

 <= /span>

 =

 

--_000_LO2P123MB1965B4686737AFF0B42288BEEB240LO2P123MB1965GBRP_-- From nobody Tue Apr 16 04:17:31 2019 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 C75191205D5; Tue, 16 Apr 2019 04:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wuqCB76nKL9A; Tue, 16 Apr 2019 04:17:27 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 600CC1204AA; Tue, 16 Apr 2019 04:17:27 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.158]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hGM5b-0007Mk-Dc; Tue, 16 Apr 2019 13:17:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <5C08EA72-1AF7-4466-9070-B3F98E7D3017@gmail.com> Date: Tue, 16 Apr 2019 13:17:22 +0200 Cc: draft-ietf-mptcp-rfc6824bis.all@ietf.org, multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> <5C08EA72-1AF7-4466-9070-B3F98E7D3017@gmail.com> To: Alan Ford X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1555413447;2e1f50cd; X-HE-SMSGID: 1hGM5b-0007Mk-Dc Archived-At: Subject: Re: [multipathtcp] AD review is coming X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 11:17:30 -0000 Hi Alan, Yes, I was looking also for eventually a tiny update to the doc (while = it would be most important to mention this in the write-up). I think the = one thing that could be added below, is one more sentence or maybe even = halve a sentence saying that this fallback to plain TCP (instead of v0) = is okay, as general deployment is low and there is also an expectation = that server get updated first or entities using MPTCP today actually = have some control to update both client and server. Or whatever you = think is right to say. So the question to answers is why is it okay that = fallback is to plain TCP instead of v0=E2=80=A6? Mirja > On 15. Apr 2019, at 18:55, Alan Ford wrote: >=20 > Hi Mirja, >=20 > To be clear, you are looking for some rationale in the draft text as = well? The technical discussion of the fallback process is given in = Section 3.1: > The MP_CAPABLE exchange in this specification (v1) is different to > that specified in v0 [RFC6824]. If a host supports multiple = versions > of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the > highest version number it supports. In return, in its MP_CAPABLE > option, the receiver will signal the version number it wishes to = use, > which MUST be equal to or lower than the version number indicated = in > the initial MP_CAPABLE. There is a caveat though with respect to > this version negotiation with old listeners that only support v0. = A > listener that supports v0 expects that the MP_CAPABLE option in the > SYN-segment includes the initiator's key. If the initiator however > already upgraded to v1, it won't include the key in the = SYN-segment. > Thus, the listener will ignore the MP_CAPABLE of this SYN-segment = and > reply with a SYN/ACK that does not include an MP_CAPABLE, thus > leading to a fallback to regular TCP. An initiator MAY cache this > information about a peer and for future connections, MAY choose to > attempt using MPTCP v0, if supported, before recording the host as > not supporting MPTCP. >=20 > But you would like to see some discussion mentioning the migration = from Experimental to Proposed Standard? And the benefits it brings? = Would that cover it? >=20 > Many thanks, > Alan >=20 >> On 12 Apr 2019, at 17:40, Mirja Kuehlewind = wrote: >>=20 >> Hi authors, hi shepherd/Phil, >>=20 >> Just wanted to quickly let you know that I=E2=80=99ve started the = IETF last call just now in order to hopefully get this document on the = telechat in 3 weeks.=20 >>=20 >> I=E2=80=99ve not finished my AD review completely but I am nearly = done and convinced that this doc is ready to start IETF last call. So = far I have only some editorial or smallish comments and nits which I = will send in detail beginning of next week and can be address during or = after IETF last call. >>=20 >> Only one request for now (mostly with an eye on the IESG evaluation): = The draft says that changes are made which are not backward compatible = (see sec 3.1). That=E2=80=99s fine, however, it would be good to also = explain a little bit in the draft as well as in the shepherd write up = (!) why this is okay. My understanding is that in case of a v0 server = the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable and = that this is acceptable in current deployment situation. Please confirm = and at least update the write-up accordingly as soon as possible! >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>=20 >=20 From nobody Tue Apr 16 06:12:49 2019 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 21B3A12016B; Tue, 16 Apr 2019 06:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgamCncybrrr; Tue, 16 Apr 2019 06:12:45 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140100.outbound.protection.outlook.com [40.107.14.100]) (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 7D9AC12002E; Tue, 16 Apr 2019 06:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RvdzXgrhjlUu9Pa/0WagopIIOPli7UX0a7QAIeegLwg=; b=f108iCWnq1GVzhoHcs6HgrI9RkRDBpgB369dxAbu2Z54KqZDj9/ncKYccGToAENVDYrodMME8qaKaNCbP22QHOtSsNLanpKShjRB0su0653c4zH7+ZlnIHbJuQpL30ljhJa7eltiVyr6QHFiE0R+e3TJFJ0sFSXd/e6C1vxRCeo= Received: from VE1PR03MB5824.eurprd03.prod.outlook.com (10.255.158.81) by VE1PR03MB5869.eurprd03.prod.outlook.com (10.255.159.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Tue, 16 Apr 2019 13:12:42 +0000 Received: from VE1PR03MB5824.eurprd03.prod.outlook.com ([fe80::5018:fcbe:76e3:7dfb]) by VE1PR03MB5824.eurprd03.prod.outlook.com ([fe80::5018:fcbe:76e3:7dfb%6]) with mapi id 15.20.1792.018; Tue, 16 Apr 2019 13:12:42 +0000 From: Olivier Bonaventure To: Mirja Kuehlewind , Alan Ford CC: "draft-ietf-mptcp-rfc6824bis.all@ietf.org" , "multipathtcp@ietf.org" Thread-Topic: AD review is coming Thread-Index: AQHU8U51f/7AT+ZU1ESzRJjHjmQY1aY9dV2AgAEz8gCAACA3AA== Date: Tue, 16 Apr 2019 13:12:42 +0000 Message-ID: <9050cf85-c0d8-0e1f-d3b5-ae5a2c10afa2@uclouvain.be> References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> <5C08EA72-1AF7-4466-9070-B3F98E7D3017@gmail.com> In-Reply-To: Reply-To: Olivier Bonaventure Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0003.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::15) To VE1PR03MB5824.eurprd03.prod.outlook.com (2603:10a6:803:110::17) authentication-results: spf=none (sender IP is ) smtp.mailfrom=olivier.bonaventure@uclouvain.be; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:6a8:308f:2:807b:1361:8c1:4744] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7485102-776c-48eb-3910-08d6c26d3530 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:VE1PR03MB5869; x-ms-traffictypediagnostic: VE1PR03MB5869: x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(136003)(39860400002)(189003)(199004)(51444003)(99286004)(478600001)(6486002)(3450700001)(229853002)(6436002)(52116002)(2906002)(305945005)(53936002)(6512007)(14454004)(7736002)(6116002)(105586002)(106356001)(186003)(25786009)(4326008)(76176011)(386003)(6506007)(46003)(36756003)(102836004)(31696002)(486006)(71190400001)(256004)(97736004)(71200400001)(3480700005)(86362001)(14444005)(786003)(476003)(54906003)(110136005)(316002)(2616005)(74482002)(11346002)(8936002)(8676002)(81166006)(81156014)(6246003)(31686004)(68736007)(43066004)(446003)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1PR03MB5869; H:VE1PR03MB5824.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uclouvain.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LHzeBDuyZ/lGjHvBFoKicAg8DG6hbj2yfOAvZqXwdvwjdWq8FX/OZm7aUWUyosAKLfkse1GFSF/LK1yDT+RRttGhrd1aQkbuXl1lJO+dqJzA+JKwR2HXer5hJSCeWLMNyLCetWyAM1Mq44VjQuLKkx+oHvSLaiHn0rQRj7abvGHKCc1aO2K+iGrtNMZEqrR7RCHliwLQCS5gc6+AxvXAxOXwGuqG0b/90xZYXc8iABkFiUv1E4HW3FZK5bGfrqSTKhMSSoSdJli1dW8cDkdyS/NVDATAFGeRy1+fwcjRFwHOBHuQn3bKbLIq7SPBZzZRhnf1s5W/0ajTdcp8whEztRTJs23jCX13O26K1RpixnrS0b7aJEjKMnEUyxuvSuoqF085SW0gvnanVtExMcsKa1xc7A0mi/3lCCp00j6y+lM= Content-Type: text/plain; charset="utf-8" Content-ID: <5B56A1DC02C933428BAE3BF8A458597A@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-Network-Message-Id: c7485102-776c-48eb-3910-08d6c26d3530 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 13:12:42.1972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR03MB5869 Archived-At: Subject: Re: [multipathtcp] AD review is coming X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 13:12:48 -0000 TWlyamEsDQo+IA0KPiBZZXMsIEkgd2FzIGxvb2tpbmcgYWxzbyBmb3IgZXZlbnR1YWxseSBhIHRp bnkgdXBkYXRlIHRvIHRoZSBkb2MgKHdoaWxlIGl0IHdvdWxkIGJlIG1vc3QgaW1wb3J0YW50IHRv IG1lbnRpb24gdGhpcyBpbiB0aGUgd3JpdGUtdXApLiBJIHRoaW5rIHRoZSBvbmUgdGhpbmcgdGhh dCBjb3VsZCBiZSBhZGRlZCBiZWxvdywgaXMgb25lIG1vcmUgc2VudGVuY2Ugb3IgbWF5YmUgZXZl biBoYWx2ZSBhIHNlbnRlbmNlIHNheWluZyB0aGF0IHRoaXMgZmFsbGJhY2sgdG8gcGxhaW4gVENQ IChpbnN0ZWFkIG9mIHYwKSBpcyBva2F5LCBhcyBnZW5lcmFsIGRlcGxveW1lbnQgaXMgbG93IGFu ZCB0aGVyZSBpcyBhbHNvIGFuIGV4cGVjdGF0aW9uIHRoYXQgc2VydmVyIGdldCB1cGRhdGVkIGZp cnN0IG9yIGVudGl0aWVzIHVzaW5nIE1QVENQIHRvZGF5IGFjdHVhbGx5IGhhdmUgc29tZSBjb250 cm9sIHRvIHVwZGF0ZSBib3RoIGNsaWVudCBhbmQgc2VydmVyLiANCg0KVG9kYXksIHRoZSBsYXJn ZXN0IGRlcGxveW1lbnRzIGFyZSA6DQotIEFwcGxlIChtYWlubHkgdGhlaXIgb3duIHNlcnZpY2Vz LCBidXQgdGhpcmQgcGFydHkgYXBwcyB3aWxsIGFwcGVhcikNCi0gS1QvLi4uIHVzaW5nIFNPQ0tT IHByb3hpZXMNCi0gSHlicmlkIEFjY2VzcyBuZXR3b3JrcyAod2hlcmUgTVBUQ1AgaXMgdXNlZCBi ZXR3ZWVuIENQRXMgYW5kIHByb3hpZXMpDQoNCkh1YXdlaSBoYXMgc3RhcnRlZCB0byBkZXBsb3kg TVBUQ1AgaW4gYW4gZW5kLXRvLWVuZCBtYW5uZXIgaW4gQ2hpbmEuDQoNCkluIERlY2VtYmVyLCBh IHptYXAgc2NhbiBvZiB0aGUgZW50aXJlIElQdjQgc3BhY2Ugb25wb3J0IDQ0MyByZXZlYWxlZCAN CnRoYW4gb25seSBhYm91dCAxMGsgaG9zdHMgd2VyZSByZXNwb25kaW5nIHdpdGggYSB2YWxpZCBN UF9DQVBBQkxFLiBNYW55IA0Kb2YgdGhlc2Ugd2VyZSBDUEUgcm91dGVycyB0aGF0IGhhZCBNUFRD UCBlbmFibGVkIGFuZCBzdXJwcmlzaW5nbHkgb3BlbiANCmh0dHBzIHNlcnZlcnMuDQoNCj4gT3Ig d2hhdGV2ZXIgeW91IHRoaW5rIGlzIHJpZ2h0IHRvIHNheS4gU28gdGhlIHF1ZXN0aW9uIHRvIGFu c3dlcnMgaXMgd2h5IGlzIGl0IG9rYXkgdGhhdCBmYWxsYmFjayBpcyB0byBwbGFpbiBUQ1AgaW5z dGVhZCBvZiB2MOKApj8NCg0KSSB0aGluayB0aGF0IHRoaXMgd291bGQgbWFrZSBzZW5zZSBnaXZl biB0aGUgbGltaXRlZCBkZXBsb3ltZW50IG9mIE1QVENQIA0Kc2VydmVycy4NCg0KDQpPbGl2aWVy DQo= From nobody Tue Apr 16 08:43:08 2019 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 6D0171209F5; Tue, 16 Apr 2019 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5bhj60nirb6z; Tue, 16 Apr 2019 08:42:43 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 D7CAC120A82; Tue, 16 Apr 2019 07:08:23 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.158]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hGOl3-0002dL-4E; Tue, 16 Apr 2019 16:08:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> Date: Tue, 16 Apr 2019 16:08:20 +0200 Cc: multipathtcp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> To: draft-ietf-mptcp-rfc6824bis.all@ietf.org X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1555423703;42c9214d; X-HE-SMSGID: 1hGOl3-0002dL-4E Archived-At: Subject: [multipathtcp] AD review detailed comments [was: Re: AD review is coming] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 15:42:55 -0000 Hi again, Here are the more detailed comment of my review as promised. Most of = these comments are editorial, however, there are a few comments on use = of normative language as well as clarifications and also one point about = specifying the registration policy for the new registry (comment 13 = below) which really must be address in the next version. Thanks! Mirja ---------------------------- 1) Sec 3.1: =E2=80=9CIf a responder does not support (or does not want = to support) any of the initiator's proposals, it can respond without an MP_CAPABLE option, thus forcing a fallback to regular TCP.=E2=80=9D I wonder if this should be normative: =E2=80=9C=E2=80=A6it MUST = respond without an MP_CAPABLE option=E2=80=A6=E2=80=9D..? 2) Sec 3.3.1: =E2=80=9C=E2=80=A6 and any later data for that sequence = space should be ignored.=E2=80=9D Maybe SHOULD? 3) Sec 3.3.2: =E2=80=9CIf the DSN received is 32 bits, it is valid for the implementation to choose whether to send a 32-bit or 64-bit Data ACK.=E2=80=9D Maybe =E2=80=9C=E2=80=A6 the implementation MAY choose whether to = send=E2=80=A6=E2=80=9D 4) Sec 3.3.3: I guess if there is only one subflow it is probably safe = to send the TCP FIN together with a DATA_FIN (as an optimisation), or = would there be a reason to not do that? Should that be mentioned in the = text? 5) Sec 3.3.8: Is the reference to ECN really needed? I feel that this = idea is hard to understand without further context. 6) Sec 3.6: Maybe I missed it that but it seems that the error codes = =E2=80=9CUnacceptable performance=E2=80=9D is not further used in the = document while I would think further guidance might be needed.=20 7) Sec 3.7: Minor editorial point I noticed here but there might be = other cases: =E2=80=9CIf lost options on data packets occur on any other subflow = apart from the initial subflow=E2=80=A6=E2=80=9D Not sure if =E2=80=9Cinitial=E2=80=9D is correct here because if you = move you may not have the initial subflow anymore=E2=80=A6 I guess it = would be something like =E2=80=9Call expect one=E2=80=9D here=E2=80=A6 8) Sec 3.9.2: I wondering about this text, given this is a bis doc and = we have an deployment experience report: =E2=80=9CWe expect that experience gathered from deployments will = provide further guidance on this, and will be affected by particular = application characteristics (which are likely to change over time). = [=E2=80=A6] Results from experimental deployments are needed in order to = verify the correctness of this proposal.=E2=80=9D Maybe just rephrase it say something like =E2=80=9CWe got some = experience but more is needed/there is no generics solution.=E2=80=9D.. = or just remove=E2=80=A6 9) Maybe section 3.9.2 should also say again that receiving a second = ADD_ADDRESS (with the same ID) is a request from the other end to open a = subflow immediately? 10) Sec 3.9.3: Should learned information really be cached = =E2=80=9Cforever=E2=80=9D, or should the text maybe says also something = about retrying after some time=E2=80=A6? 11) Sec 8.1: =E2=80=9CThis document defines one additional subtype (ADD_ADDR) and updates the references to this document for all sub- types except ADD_ADDR, which is deprecated.=E2=80=9D What? 12) Also sec 8.1: RFC6824 also has this half-sentence: =E2=80=9Cfuture assignments are to be defined by Standards Action as = defined by [25].=E2=80=9D which got lost in this document. However, given this document obsoletes = RFC6824 it should probably also mention the assignment policy for this = registry. 13) Sec 8.3. doesn=E2=80=99t specify an assignment policy. 14) Given RFC6824 will be obsoleted by this spec, it does not to be = listed in the reference section. Nits: - Sec 3.3.6: s/if it so desired for reliability reasons./if it is = desired for reliability reasons./ - Sec 3.3.&: s/Multiple retransmissions are triggers that/Multiple = retransmissions are triggered that/ or actually s/Multiple retransmissions are triggers that/If = multiple retransmissions are triggered that/ - Sec 3.7: s/Middlebox interferance/Middlebox interference/ - Sec 3.9.2: s/If the the same ports are used on all subflows/If the = same ports are used on all subflows/ > On 12. Apr 2019, at 18:40, Mirja Kuehlewind = wrote: >=20 > Hi authors, hi shepherd/Phil, >=20 > Just wanted to quickly let you know that I=E2=80=99ve started the IETF = last call just now in order to hopefully get this document on the = telechat in 3 weeks.=20 >=20 > I=E2=80=99ve not finished my AD review completely but I am nearly done = and convinced that this doc is ready to start IETF last call. So far I = have only some editorial or smallish comments and nits which I will send = in detail beginning of next week and can be address during or after IETF = last call. >=20 > Only one request for now (mostly with an eye on the IESG evaluation): = The draft says that changes are made which are not backward compatible = (see sec 3.1). That=E2=80=99s fine, however, it would be good to also = explain a little bit in the draft as well as in the shepherd write up = (!) why this is okay. My understanding is that in case of a v0 server = the connection will =E2=80=9Cjust" fall-back to non-MPTCP capable and = that this is acceptable in current deployment situation. Please confirm = and at least update the write-up accordingly as soon as possible! >=20 > Thanks! > Mirja >=20 >=20 >=20 From nobody Thu Apr 18 08:34:52 2019 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 A59A012034C; Thu, 18 Apr 2019 08:34:50 -0700 (PDT) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 n7OWOHnvWodU; Thu, 18 Apr 2019 08:34:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F7E120178; Thu, 18 Apr 2019 08:34:46 -0700 (PDT) Received: from tpw09926dag05f.domain1.systemhost.net (10.9.202.24) by RDW083A009ED65.bt.com (10.187.98.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Apr 2019 16:32:08 +0100 Received: from tpw09926dag09h.domain1.systemhost.net (10.9.202.48) by tpw09926dag05f.domain1.systemhost.net (10.9.202.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Apr 2019 16:34:43 +0100 Received: from bwp09926085.bt.com (10.36.82.116) by tpw09926dag09h.domain1.systemhost.net (10.9.202.48) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 18 Apr 2019 16:34:43 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.58) by smtpe1.intersmtp.com (10.36.82.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 18 Apr 2019 16:34:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=axiK+G3cb2JXYHalMqTSztbdtYnzv2JGLpuvdBPctmw=; b=AUUMYwQShNo3PpmwiEiObR47LI7X6LrET9YAjinB+zkPtL/ot0B5MpfPwnF9jhC6HInxdmiG+OiTcwzEFzRlRDavDQpBFDaPtKhXZ7ZnZDcogpWlrI5fyvrKTWhFa8jQNKMNa0AqZ8ULIP4FQ67mpRW9nJirkpZNmA6zF3TTG8E= Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM (20.176.157.10) by LO2P123MB1966.GBRP123.PROD.OUTLOOK.COM (20.176.157.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Thu, 18 Apr 2019 15:34:43 +0000 Received: from LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::f4db:9f33:1c69:76c]) by LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM ([fe80::f4db:9f33:1c69:76c%4]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 15:34:42 +0000 From: To: , CC: , Thread-Topic: AD review is coming Thread-Index: AQHU8U58LcQ78HaJsEyceWecaWPcqKY9dV2AgAEz8gCAA2f4UA== Date: Thu, 18 Apr 2019 15:34:42 +0000 Message-ID: References: <11187BAE-5E91-410D-9BDA-33F8A60D2458@kuehlewind.net> <5C08EA72-1AF7-4466-9070-B3F98E7D3017@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a2ffd6a-01c3-4c7d-a2b4-08d6c41360fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LO2P123MB1966; x-ms-traffictypediagnostic: LO2P123MB1966: x-antispam-2: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(13464003)(25786009)(9686003)(8676002)(55016002)(66066001)(11346002)(14444005)(476003)(256004)(446003)(3480700005)(486006)(5660300002)(71190400001)(52536014)(6246003)(71200400001)(14454004)(26005)(478600001)(186003)(6436002)(305945005)(68736007)(76176011)(6506007)(7736002)(102836004)(53546011)(110136005)(97736004)(4326008)(2906002)(8936002)(33656002)(229853002)(81166006)(99286004)(74316002)(81156014)(7696005)(6116002)(316002)(3846002)(54906003)(86362001)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1966; H:LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 55ib8z9LePmTgOPng9yKWbVfO7cpafO4NYuff3PiahROGJseeh25tdpuXt9vtux5so4Kc+XePEK6ZncaO0dVxIvPW+HgTM0bcAiW5o/9zIDpHVkJ4eQHa45EBRmE9Ctt/4YsJa542Fc42616E9S7QbqUwqLaBXnUvXrjZd+JpyjObYB3dEE9YIMrhrbGoTlmbknmQYcy5HZOSJhATsiDgWLE9adeMNXNPrZBqr3qalTX1JLfKNLNW4OrWAFS2tGrzv2xQq8ZRdFdxPrhnVncV7gUuXlzoPJkCM+r1eafP6RVQLgGCYTj2vCVwgFdhd6VECoSj0Xkv+Q/pnTG6OhFpklvnGTGD6i6fiKQktIbe3AbH6bXJ2H/ugVI/eEHxQ6RLobddCiyvszlKegImM5Zc5KSJO2oKjpYjoXn3O2dUoI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a2ffd6a-01c3-4c7d-a2b4-08d6c41360fa X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 15:34:42.8594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1966 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [multipathtcp] AD review is coming X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:34:51 -0000 QWJvdXQgDQo+ICAgIFRodXMsIHRoZSBsaXN0ZW5lciB3aWxsIGlnbm9yZSB0aGUgTVBfQ0FQQUJM RSBvZiB0aGlzIFNZTi1zZWdtZW50IGFuZA0KPiAgICByZXBseSB3aXRoIGEgU1lOL0FDSyB0aGF0 IGRvZXMgbm90IGluY2x1ZGUgYW4gTVBfQ0FQQUJMRSwgdGh1cw0KPiAgICBsZWFkaW5nIHRvIGEg ZmFsbGJhY2sgdG8gcmVndWxhciBUQ1AuICBBbiBpbml0aWF0b3IgTUFZIGNhY2hlIHRoaXMNCj4g ICAgaW5mb3JtYXRpb24gYWJvdXQgYSBwZWVyIGFuZCBmb3IgZnV0dXJlIGNvbm5lY3Rpb25zLCBN QVkgY2hvb3NlIHRvDQo+ICAgIGF0dGVtcHQgdXNpbmcgTVBUQ1AgdjAsIGlmIHN1cHBvcnRlZCwg YmVmb3JlIHJlY29yZGluZyB0aGUgaG9zdCBhcw0KPiAgICBub3Qgc3VwcG9ydGluZyBNUFRDUC4N Cg0KSSB0aGluayBvbmUgcHJvYmxlbSBpcyB0aGUgcGhyYXNlICJ0aHVzIGxlYWRpbmcgdG8gYSBm YWxsYmFjayB0byByZWd1bGFyIFRDUCIsIHdoaWNoIGlzIGEgYml0IG1pc2xlYWRpbmcuIFN1Z2dl c3QgZGVsZXRpbmcgYW5kIGFkZGluZyBtb3JlIGV4cGxhbmF0aW9uIG9uIHRoZXNlIGxpbmVzOg0K DQpUaHVzLCB0aGUgbGlzdGVuZXIgd2lsbCBpZ25vcmUgdGhlIE1QX0NBUEFCTEUgb2YgdGhpcyBT WU4tc2VnbWVudCBhbmQgcmVwbHkgd2l0aCBhIFNZTi9BQ0sgdGhhdCBkb2VzIG5vdCBpbmNsdWRl IGFuIE1QX0NBUEFCTEUuIFRoZSBpbml0aWF0b3IgTUFZIGNob29zZSB0byBpbW1lZGlhdGVseSBm YWxsIGJhY2sgdG8gVENQIG9yIE1BWSBjaG9vc2UgdG8gYXR0ZW1wdCBhIGNvbm5lY3Rpb24gdXNp bmcgTVBUQ1AgdjAgKGlmIHRoZSBpbml0aWF0b3Igc3VwcG9ydHMgdjApLCBpbiBvcmRlciB0byBk aXNjb3ZlciB3aGV0aGVyIHRoZSBsaXN0ZW5lciBzdXBwb3J0cyB0aGUgZWFybGllciB2ZXJzaW9u IG9mIE1QVENQLiBJbiBnZW5lcmFsIGEgTVBUQ1AgdjAgY29ubmVjdGlvbiBpcyBwcmVmZXJyZWQg dG8gYSBUQ1Agb25lLCBob3dldmVyIGluIGEgcGFydGljdWxhciBkZXBsb3ltZW50IHNjZW5hcmlv IGl0IG1heSBiZSBrbm93biB0aGF0IHRoZSBsaXN0ZW5lciBpcyB1bmxpa2VseSB0byBzdXBwb3J0 IE1QVENQdjAgYW5kIHNvIHRoZSBpbml0aWF0b3IgbWF5IHByZWZlciBub3QgdG8gYXR0ZW1wdCBh IHYwIGNvbm5lY3Rpb24uIA0KQW4gaW5pdGlhdG9yIE1BWSBjYWNoZSBpbmZvcm1hdGlvbiBmb3Ig YSBwZWVyIGFib3V0IHdoYXQgdmVyc2lvbiBvZiBNUFRDUCBpdCBzdXBwb3J0cyBpZiBhbnksIGFu ZCB1c2UgdGhpcyBpbmZvcm1hdGlvbiBmb3IgZnV0dXJlIGNvbm5lY3Rpb24gYXR0ZW1wdHMuDQoN CnBoaWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pcmphIEt1ZWhsZXdp bmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XSANClNlbnQ6IDE2IEFwcmlsIDIwMTkgMTI6 MTcNClRvOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBnbWFpbC5jb20+DQpDYzogZHJhZnQtaWV0Zi1t cHRjcC1yZmM2ODI0YmlzLmFsbEBpZXRmLm9yZzsgbXVsdGlwYXRodGNwQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogQUQgcmV2aWV3IGlzIGNvbWluZw0KDQpIaSBBbGFuLA0KDQpZZXMsIEkgd2FzIGxv b2tpbmcgYWxzbyBmb3IgZXZlbnR1YWxseSBhIHRpbnkgdXBkYXRlIHRvIHRoZSBkb2MgKHdoaWxl IGl0IHdvdWxkIGJlIG1vc3QgaW1wb3J0YW50IHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgd3JpdGUt dXApLiBJIHRoaW5rIHRoZSBvbmUgdGhpbmcgdGhhdCBjb3VsZCBiZSBhZGRlZCBiZWxvdywgaXMg b25lIG1vcmUgc2VudGVuY2Ugb3IgbWF5YmUgZXZlbiBoYWx2ZSBhIHNlbnRlbmNlIHNheWluZyB0 aGF0IHRoaXMgZmFsbGJhY2sgdG8gcGxhaW4gVENQIChpbnN0ZWFkIG9mIHYwKSBpcyBva2F5LCBh cyBnZW5lcmFsIGRlcGxveW1lbnQgaXMgbG93IGFuZCB0aGVyZSBpcyBhbHNvIGFuIGV4cGVjdGF0 aW9uIHRoYXQgc2VydmVyIGdldCB1cGRhdGVkIGZpcnN0IG9yIGVudGl0aWVzIHVzaW5nIE1QVENQ IHRvZGF5IGFjdHVhbGx5IGhhdmUgc29tZSBjb250cm9sIHRvIHVwZGF0ZSBib3RoIGNsaWVudCBh bmQgc2VydmVyLiBPciB3aGF0ZXZlciB5b3UgdGhpbmsgaXMgcmlnaHQgdG8gc2F5LiBTbyB0aGUg cXVlc3Rpb24gdG8gYW5zd2VycyBpcyB3aHkgaXMgaXQgb2theSB0aGF0IGZhbGxiYWNrIGlzIHRv IHBsYWluIFRDUCBpbnN0ZWFkIG9mIHYw4oCmPw0KDQpNaXJqYQ0KDQoNCj4gT24gMTUuIEFwciAy MDE5LCBhdCAxODo1NSwgQWxhbiBGb3JkIDxhbGFuLmZvcmRAZ21haWwuY29tPiB3cm90ZToNCj4g DQo+IEhpIE1pcmphLA0KPiANCj4gVG8gYmUgY2xlYXIsIHlvdSBhcmUgbG9va2luZyBmb3Igc29t ZSByYXRpb25hbGUgaW4gdGhlIGRyYWZ0IHRleHQgYXMgd2VsbD8gVGhlIHRlY2huaWNhbCBkaXNj dXNzaW9uIG9mIHRoZSBmYWxsYmFjayBwcm9jZXNzIGlzIGdpdmVuIGluIFNlY3Rpb24gMy4xOg0K PiAgICBUaGUgTVBfQ0FQQUJMRSBleGNoYW5nZSBpbiB0aGlzIHNwZWNpZmljYXRpb24gKHYxKSBp cyBkaWZmZXJlbnQgdG8NCj4gICAgdGhhdCBzcGVjaWZpZWQgaW4gdjAgW1JGQzY4MjRdLiAgSWYg YSBob3N0IHN1cHBvcnRzIG11bHRpcGxlIHZlcnNpb25zDQo+ICAgIG9mIE1QVENQLCB0aGUgc2Vu ZGVyIG9mIHRoZSBNUF9DQVBBQkxFIG9wdGlvbiBTSE9VTEQgc2lnbmFsIHRoZQ0KPiAgICBoaWdo ZXN0IHZlcnNpb24gbnVtYmVyIGl0IHN1cHBvcnRzLiAgSW4gcmV0dXJuLCBpbiBpdHMgTVBfQ0FQ QUJMRQ0KPiAgICBvcHRpb24sIHRoZSByZWNlaXZlciB3aWxsIHNpZ25hbCB0aGUgdmVyc2lvbiBu dW1iZXIgaXQgd2lzaGVzIHRvIHVzZSwNCj4gICAgd2hpY2ggTVVTVCBiZSBlcXVhbCB0byBvciBs b3dlciB0aGFuIHRoZSB2ZXJzaW9uIG51bWJlciBpbmRpY2F0ZWQgaW4NCj4gICAgdGhlIGluaXRp YWwgTVBfQ0FQQUJMRS4gIFRoZXJlIGlzIGEgY2F2ZWF0IHRob3VnaCB3aXRoIHJlc3BlY3QgdG8N Cj4gICAgdGhpcyB2ZXJzaW9uIG5lZ290aWF0aW9uIHdpdGggb2xkIGxpc3RlbmVycyB0aGF0IG9u bHkgc3VwcG9ydCB2MC4gIEENCj4gICAgbGlzdGVuZXIgdGhhdCBzdXBwb3J0cyB2MCBleHBlY3Rz IHRoYXQgdGhlIE1QX0NBUEFCTEUgb3B0aW9uIGluIHRoZQ0KPiAgICBTWU4tc2VnbWVudCBpbmNs dWRlcyB0aGUgaW5pdGlhdG9yJ3Mga2V5LiAgSWYgdGhlIGluaXRpYXRvciBob3dldmVyDQo+ICAg IGFscmVhZHkgdXBncmFkZWQgdG8gdjEsIGl0IHdvbid0IGluY2x1ZGUgdGhlIGtleSBpbiB0aGUg U1lOLXNlZ21lbnQuDQo+ICAgIFRodXMsIHRoZSBsaXN0ZW5lciB3aWxsIGlnbm9yZSB0aGUgTVBf Q0FQQUJMRSBvZiB0aGlzIFNZTi1zZWdtZW50IGFuZA0KPiAgICByZXBseSB3aXRoIGEgU1lOL0FD SyB0aGF0IGRvZXMgbm90IGluY2x1ZGUgYW4gTVBfQ0FQQUJMRSwgdGh1cw0KPiAgICBsZWFkaW5n IHRvIGEgZmFsbGJhY2sgdG8gcmVndWxhciBUQ1AuICBBbiBpbml0aWF0b3IgTUFZIGNhY2hlIHRo aXMNCj4gICAgaW5mb3JtYXRpb24gYWJvdXQgYSBwZWVyIGFuZCBmb3IgZnV0dXJlIGNvbm5lY3Rp b25zLCBNQVkgY2hvb3NlIHRvDQo+ICAgIGF0dGVtcHQgdXNpbmcgTVBUQ1AgdjAsIGlmIHN1cHBv cnRlZCwgYmVmb3JlIHJlY29yZGluZyB0aGUgaG9zdCBhcw0KPiAgICBub3Qgc3VwcG9ydGluZyBN UFRDUC4NCj4gDQo+IEJ1dCB5b3Ugd291bGQgbGlrZSB0byBzZWUgc29tZSBkaXNjdXNzaW9uIG1l bnRpb25pbmcgdGhlIG1pZ3JhdGlvbiBmcm9tIEV4cGVyaW1lbnRhbCB0byBQcm9wb3NlZCBTdGFu ZGFyZD8gQW5kIHRoZSBiZW5lZml0cyBpdCBicmluZ3M/IFdvdWxkIHRoYXQgY292ZXIgaXQ/DQo+ IA0KPiBNYW55IHRoYW5rcywNCj4gQWxhbg0KPiANCj4+IE9uIDEyIEFwciAyMDE5LCBhdCAxNzo0 MCwgTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4gd3JvdGU6DQo+PiANCj4+ IEhpIGF1dGhvcnMsIGhpIHNoZXBoZXJkL1BoaWwsDQo+PiANCj4+IEp1c3Qgd2FudGVkIHRvIHF1 aWNrbHkgbGV0IHlvdSBrbm93IHRoYXQgSeKAmXZlIHN0YXJ0ZWQgdGhlIElFVEYgbGFzdCBjYWxs IGp1c3Qgbm93IGluIG9yZGVyIHRvIGhvcGVmdWxseSBnZXQgdGhpcyBkb2N1bWVudCBvbiB0aGUg dGVsZWNoYXQgaW4gMyB3ZWVrcy4gDQo+PiANCj4+IEnigJl2ZSBub3QgZmluaXNoZWQgbXkgQUQg cmV2aWV3IGNvbXBsZXRlbHkgYnV0IEkgYW0gbmVhcmx5IGRvbmUgYW5kIGNvbnZpbmNlZCB0aGF0 IHRoaXMgZG9jIGlzIHJlYWR5IHRvIHN0YXJ0IElFVEYgbGFzdCBjYWxsLiBTbyBmYXIgSSBoYXZl IG9ubHkgc29tZSBlZGl0b3JpYWwgb3Igc21hbGxpc2ggY29tbWVudHMgYW5kIG5pdHMgd2hpY2gg SSB3aWxsIHNlbmQgaW4gZGV0YWlsIGJlZ2lubmluZyBvZiBuZXh0IHdlZWsgYW5kIGNhbiBiZSBh ZGRyZXNzIGR1cmluZyBvciBhZnRlciBJRVRGIGxhc3QgY2FsbC4NCj4+IA0KPj4gT25seSBvbmUg cmVxdWVzdCBmb3Igbm93IChtb3N0bHkgd2l0aCBhbiBleWUgb24gdGhlIElFU0cgZXZhbHVhdGlv bik6IFRoZSBkcmFmdCBzYXlzIHRoYXQgY2hhbmdlcyBhcmUgbWFkZSB3aGljaCBhcmUgbm90IGJh Y2t3YXJkIGNvbXBhdGlibGUgKHNlZSBzZWMgMy4xKS4gVGhhdOKAmXMgZmluZSwgaG93ZXZlciwg aXQgd291bGQgYmUgZ29vZCB0byBhbHNvIGV4cGxhaW4gYSBsaXR0bGUgYml0IGluIHRoZSBkcmFm dCBhcyB3ZWxsIGFzIGluIHRoZSBzaGVwaGVyZCB3cml0ZSB1cCAoISkgd2h5IHRoaXMgaXMgb2th eS4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGluIGNhc2Ugb2YgYSB2MCBzZXJ2ZXIgdGhlIGNv bm5lY3Rpb24gd2lsbCDigJxqdXN0IiBmYWxsLWJhY2sgdG8gbm9uLU1QVENQIGNhcGFibGUgYW5k IHRoYXQgdGhpcyBpcyBhY2NlcHRhYmxlIGluIGN1cnJlbnQgZGVwbG95bWVudCBzaXR1YXRpb24u IFBsZWFzZSBjb25maXJtIGFuZCBhdCBsZWFzdCB1cGRhdGUgdGhlIHdyaXRlLXVwIGFjY29yZGlu Z2x5IGFzIHNvb24gYXMgcG9zc2libGUhDQo+PiANCj4+IFRoYW5rcyENCj4+IE1pcmphDQo+PiAN Cj4+IA0KPj4gDQo+IA0KDQo= From nobody Fri Apr 19 13:16:31 2019 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 ADCE91200E6 for ; Fri, 19 Apr 2019 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjYhpi0UpjGZ for ; Fri, 19 Apr 2019 13:16:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E4012004A for ; Fri, 19 Apr 2019 13:16:23 -0700 (PDT) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E697A29C06C for ; Sat, 20 Apr 2019 05:16:20 +0900 (JST) Received: by mail-wm1-f49.google.com with SMTP id z11so7349042wmi.0 for ; Fri, 19 Apr 2019 13:16:20 -0700 (PDT) X-Gm-Message-State: APjAAAU7ZDKPRpn4FmDyoY1RUqJcpJxlR19d/09rFPit+hmFbDUkiArg RiVJnfNkwzPqsAQUsDunkCKQA0axMM+NyGxCHss= X-Google-Smtp-Source: APXvYqxslP3d2hJj7DoLrfm/SOzDQ3y/GvpPcKf7Q3vgmuAuEQnj+SpdU7aEV593zaiUsRhf+1ck8ahnXNp1olBkfXA= X-Received: by 2002:a7b:c94c:: with SMTP id i12mr3793875wml.115.1555704978690; Fri, 19 Apr 2019 13:16:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 19 Apr 2019 13:16:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="000000000000a15af00586e7ca39" Archived-At: Subject: Re: [multipathtcp] MPTCP WG minutes - draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 20:16:30 -0000 --000000000000a15af00586e7ca39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I've uploaded a draft minute on the following URL. https://datatracker.ietf.org/doc/minutes-104-mptcp/ Please let us know if you have correction or questions, etc. Thanks! -- Yoshi & Phil On Tue, Apr 16, 2019 at 3:05 AM wrote: > Here are the draft minutes for our WG meeting in Prague. Please let us > know any corrections. > > Thank-you to the minute takers =E2=80=93 I think Anna & Xavier, please sh= out if I > remember wrong! > > Thanks > > Phil & Yoshi > > -- > > > > 1. WG status (chair) > > > > 2. Implementation news (Christoph) > > - Now have approval to open source the handshake > > - Mainline Linux kernel: growing community (RedHat, Intel, Thesaurus), > making progress, will get there eventually, have support from Linux > maintainers > > - Apache traffic server allows to enable MPTCP > > > > 3. Deployment updates > > 3.1. Results from the monitoring of MPTCP-based hybrid access networks - > Olivier Bonaventure > > See slides for overview of talk > > > > Q & A > > > > Q Use of transparent proxy, do you need converter (Rahul Jadhav) > > A. CPE sees all the traffic, no need there. HAG may use a converter or be > transparent. With transparent proxy on the HAG, all traffic must go > through the HAG. Otherwise use a converter. > > > > Q. Can converter be extended with policy support for scheduling (Rahul > Jadhav) > > A. Network operators control the policy > > > > Q. Shown employment is not consistent with 3GPP Rel 16 (Florin Baboescu?) > > > > Q. Specific scheduler used in deployment (Marcus Amend) > > A. Scheduler and path manager prioritize DSL network > > > > Q. In results, could you get 1G with single TCP flows. (Marcus Amend) > > A. Was with multiple flows > > > > Q. CPU overhead? (Marcus Amend) > > A. Really depend on the CPE > > > > Q. Need complement to TCP? It is hard to explain to customers if the > benefit is for TCP only, this is why we propose a multipath UDP to > complement MPTCP (Marcus Amend) > > A. BBF does also GRE approach, will see how QUIC will be supported > > > > Q. What is the issue with using MPTCP for tunneling IP traffic (Florin > Baboescu?) > > A. MPTCP will give you reliability and delay for applications that do not > need it. > > > > 3.2. Multi-path Transport Deployment on Smartphone Apps - Zhen Cao > > See slides for overview of talk > > > > Q & A > > > > Q. Can set ECN CE mark on the path you do not want the server to use (to > implicitly tell server which path is preferred, eg toll-free) (Lars > Eggert) > > Does ECN work with MPTCP? (Zhen) > > Yes (Stuart Cheshire) > > Using ECN will reduce the cwnd for when you need it (Anna Brunstrom) > > Need this functionality for other things (Marcus Amend) > > Do not need more functionality in MPTCP (Lars) > > Need to better understand the problem before we decide solution > > More discussion on the mailing list would be helpful, there were already = a > thread discussing this; > > > > Q. Why do you need MPTCP for mice flow. > > A. For better latency > > > > Q. Low latency path should naturally be the "best" path selected, so will > not need anything special for path management to handle this (Lars) > > A. Ok, got your point; At least we agree on the scenario and the problem > exists. > > Q How often does this happen (Ben) > > A. With full mesh all the time > > > > Q. ATSSS slide not fully correct, only cover Rel. 15. (Florin) > > A. Thanks, please send them to the list as the group is not fully aware > of what's happening in 3GPP. > > > > > > 4. Individual drafts > > 4.1. Initial-Path Selection for Connection Establishment in Multipath TCP > - Jianjian Zhu > > See slides for overview of talk > > > > Q & A > > Q. This caching is already discussed in bis draft (Alan Ford) > > > > Q. RSSI is not enough, suggest to look at MAMS draft (Florin) > > Q CQI is what we use in mobile (Chris Seal) > > > > Q Selection of initial interface important, but is independent of MPTCP. > There is the same problem in QUIC. This should not be designed for MPTCP > only. (Christoph) > > This is happy eyeballs in narrow scope, please look at that if not famili > ar. WiFi assist to prefer one interface. (Stuart Cheshire) > > Yes, this should be general solution. There will be PIPC side meeting > (performance implications of path characteristics). (Zhen) > > Agree, it is a general issue, but think we should not limit multipath > protocols to single path at start-up (Marcus) > > Keying attacks is a problem for happy eyeballs in MPTCP context (Alan For= d) > > > > > > 4.2. Generic Path-Manager Support with eBPF - Viet-Hoang Tran (remote) > > See slides for overview of talk > > > > Q & A > > > > 4.3. 5G Session Continuity Support in MPTCP - Xavier de Foy 5. > > See slides for overview of talk > > > > Q & A > > > > Q Multi-access PDN is introduced in 3GPP Rel. 16, not well mapped to > talk, also all terminals know their address (Florin) > > A. Need to support continuity of addresses known at client but not at > server > > > > Q. Key proposal is communicating session continuity type to remote peer? = ( > Sri) > > A. Not really, it is one of the possible solutions but there are other > options > > Q. This information is not enough, need additional information, need to > analyze > > A. Actually in this particular solution the initial IP address index is > also communicated to the remote peer, not only the session continuity typ= e. > > > > Q Any data quantifying when you do nothing (Lars Eggert) > > A. No > > Q. Suggest we discuss this when we have data and know if there is a probl= em > > Q. Do you plan to get data (Phil) > > A. Do not have access to 5G network yet > > Any data even simulation may be useful, start with data (Lars) > > > > Q. For 3GPP we have clear items that have priority, would like to have > focus on this, this is not one of them (Florin) > > Let's talk later to see how to best convey this to group (Phil) > > > > > > 5. Potential future topics for WG > > 5.1. Brief summary of Monday=E2=80=99s side meeting > > 5.2. TAPS multipath support =E2=80=93 Anna Brunstrom > > 5.3. Open discussion > > > > Welcome input on API. Open issue on improving granularity of info (Apple > use enum and 3 modes eg interactive, aggregation) (Tommy) > > Path manager and scheduler is a challenge because you often have two > competing goals, reduce cost and improve performance. Ok on the client yo= u > can make this trade-off, but needs to be communicated to the server. We > currently know who we talk to and configure a policy for a particular > service, This is not a general solution, so some signalling from client t= o > server would be very useful. (Christoph) > > Have you tried using ECN approach suggested by Lars? (Phil) > > Can perhaps support throughput, but does not work for latency (Christoph) > > Can we perhaps solve some of these issues in more general context, will > apply to multipath QUIC as well at some time or any multipath protocol > > Think it is important to collect path scheduling algorithms in > informational document (Markus) > > Issue is not only on handset, also on proxy that may implement load > balancing scheme (Florin) > > Would be useful to tease this problem apart (Lars) > > Hear a lot of interesting issues, but they seem like research issues. Als= o > some minor extensions, that could be done in tcpm. Also hear discussion o= n > interfaces, this links to TAPS > > Not only research issues, also experiences from operational experience. > Also need connection to BBF and 3GPP > > Can be handled in other groups (Mirja) > > Much easier if we have a group collecting MPTCP experts (Zhen) > > Concerned we are missing other experts here like congestion control. > (Mirja) > > > > Do have issue if a terminal or proxy need to implement a policy, we have > very clear requirements here. (Florin) > > For ATSSS we have a side channel for policies, right (Christoph) > > Issue is how to use the policy as I understand (Florin) > > > > Think we should have informational document on scheduling and path > management for BBF and 3GPP to know. Do you think this is research? (Mark > us) > > This topic is relevant for other protocols as well, we will find a home > for this document (Mirja) > > Closing a wg is not a threat to close the work, perhaps we should have a > general wg on multipath (Tommy) > > Agree a generic multipath group could be good. IEEE, 3GPP want to use > IETF protocols, timeframe is ~ Dec 2019. (Florin) > > Do not understand why we should close a group when we have issues to solv= e > (Zhen) > > Group has finished its charter, then we normally close. The mailing list > can stay open. (Mirja) > > > > > > > --000000000000a15af00586e7ca39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I've uploaded a dr= aft minute on the following URL.


Please let us know if you have correction or questions, etc= .
Thanks!
--
Yoshi & Phil

<= /div>


On Tue, Apr 16, 2019 at 3:05 AM <philip.eardley@bt.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Here are the draft minutes for our WG meeting in Pra= gue. Please let us know any corrections.

Thank-you to the minute takers =E2=80=93 I think Ann= a & Xavier, please shout if I remember wrong!

Thanks

Phil & Yoshi

--

=C2=A0

1. W= G status (chair)

=C2=A0

2. I= mplementation news (Christoph)

- No= w have approval to open source the handshake=

- Ma= inline Linux kernel: growing community (RedHat, Intel, Thesaurus), making prog= ress, will get there eventually, have support from Linux maintainers=

- Apache traffic= server allows to enable MPTCP

=C2=A0

3. D= eployment updates

3.1.= Results from the monitoring of MPTCP-based hybrid access networks - Olivie= r Bonaventure

See = slides for overview of talk

=C2=A0

Q &a= mp; A

=C2=A0

Q Us= e of transparent proxy, do you need converter (Rahul Jadhav)<= span style=3D"font-size:9pt;font-family:"Courier New";color:black= ">

A. CPE sees all the traffic, no need there. HAG may use a converter or be tra= nsparent. With transparent proxy on the HAG, all traffic must go through th= e HAG. Otherwise use a converter.

=C2=A0

Q. C= an converter be extended with policy support for scheduling (Rahul Jadhav)<= /span>

A. N= etwork operators control the policy

=C2=A0

Q. S= hown em<= span style=3D"font-size:9pt;font-family:"Courier New";color:black= ">ployment is not consistent with 3GPP Rel 16 (Florin Baboescu?)<= /p>

=C2=A0

Q. S= pecific scheduler used in deployment (Marcus Amend)=

A. S= cheduler and path manager prioritize DSL network<= u>

=C2=A0

Q. I= n results, could you get 1G with single TCP flows. (Marcus Amend)

A. W= as with multiple flows

=C2=A0

Q. C= PU overhead? (Marcus Amend)

A. R= eally depend on the CPE

=C2=A0

Q. N= eed complement to TCP? It is hard to explain to customers if th= e benefit is for TCP only, this is why we propose a multipath UDP to comple= ment MPTCP (Marcus Amend)

A. B= BF does also GRE approac= h, will see how QUIC will be supported=C2=A0

=C2=A0

Q. W= hat is the issue with using MPTCP for tunneling IP traffic (Florin Baboescu?)

A. M= PTCP will give you reliability and delay for applications that do not need it.

=C2=A0

3.2.= Multi-path Transport Deployment on Smartphone Apps - Zhen Cao=C2=A0=

See = slides for overview of talk

=C2=A0

Q &a= mp; A

=C2=A0

Q. C= an set ECN CE mark on the path you do not want the server to use (to implicitly tell server which path is preferred, = eg toll-free) (Lars Eggert)<= u>

Does= ECN work with MPTCP? (Zhen)

Yes = (Stuart Cheshire)=

Usin= g ECN will reduce the cwnd for when you need it (Anna Brunstrom)

Need= this functionality for other things (Marcus Amend)=

Do n= ot need more functionality in MPTCP (Lars)

Need= to better understand the problem before we decide solution

More dis= cussion on the mailing list would be helpful, there were already a thread d= iscussing this;=C2=A0

=C2=A0

Q. W= hy do you need MPTCP for mice flow.=C2=A0

A. F= or better latency

=C2=A0

Q. L= ow latency path should naturally be the "best" path selected, so = will not need anything special for path management to handle this (Lars)

A. O= k, got your point; At least we agree on the scenario and the problem exists.=C2=A0

Q=C2= =A0 How often does this happen (Ben)<= /p>

A. W= ith full mesh all the time

=C2=A0

Q. A= TSSS slide not fully correct, only cover Rel. 15. (Florin)=

A. T= hanks, please send them to the list as the group is not fully aware of what's= happening in 3GPP.=C2=A0

=C2=A0

=C2=A0

4. I= ndividual drafts=C2=A0

4.1.= Initial-Path Selection for Connection Establishment in Multipath TCP - Jia= njian Zhu=C2=A0

See = slides for overview of talk

=C2=A0

Q &a= mp; A

Q. T= his caching is already discussed in bis draft (Alan Ford)<= u>

=C2=A0

Q. R= SSI is not enough, suggest to look at MAMS draft (Florin)<= u>

Q CQ= I is what we use in mobile (Chris Seal)

=C2=A0

Q Se= lection of initial interface important, but is independent of MPTCP<= /span>. There is the same problem in QUIC. This should not be designed for MPTCP o= nly. (Christoph)=

This= is happy eyeballs in narrow scope, please look at that if not famil= iar<= span style=3D"font-size:9pt;font-family:"Courier New";color:black= ">. WiFi assist to prefer one interface. (S= tuart Cheshire)

Yes,= this should be general solution. There will be PIPC side meeting (performance implic= ations of path characteristics).= (Zhen)=C2=A0

Agre= e, it is a general issue, but think we should not limit multipath protocols to single path at= start-up (Marcus)

Keyi= ng attacks is a problem for happy eyeballs in MPTCP context (Alan Ford)

=C2=A0

=C2=A0

4.2.= Generic Path-Manager Support with eBPF - Viet-Hoang Tran (remote)=C2=A0

See = slides for overview of talk

=C2=A0

Q &a= mp; A

=C2=A0

4.3.= 5G Session Continuity Support in MPTCP - Xavier de Foy 5.=C2=A0

See = slides for overview of talk

=C2=A0

Q &a= mp; A

=C2=A0

Q Mu= lti-access PDN is introduced in 3GPP Rel. 16, not well mapped to talk, also all terminals know their addre= ss (Florin)

A. Need to support continuity of addresses = known at client but not at server=C2=A0

=C2=A0

Q. K= ey proposal is communicating session continuity type to remote peer? (Sri)<= u>

A. N= ot really, it is one of the possible solution= s but there are other options

Q. This information is not enough, need additional information, need to analyze<= span style=3D"font-size:9pt;font-family:"Courier New";color:black= ">

A. A= ctually in this particular solution the initial IP address index is also communicated to the remote peer, not only the session continuity type.

=C2=A0

Q An= y data quantifying when you do nothing (Lars Eggert)

A. N= o

Q. S= uggest we discuss this when we have data and know if there is a problem

Q. D= o you plan to get data (Phil)

A. D= o not have access to 5G network yet

Any = data even simulation may be useful, start with data (Lars)=

=C2=A0

Q. F= or 3GPP we have clear items that have priority, would like to have focus on this, this is not one of them (Florin)

Let&= #39;s talk later to see how to best convey this to group (Phil)

=C2=A0

=C2=A0

5. P= otential future topics for WG

5.1.= Brief summary of Monday=E2=80=99s side meeting<= /u>

5.2.= TAPS multipath support =E2=80=93 Anna Brunstrom<= u>

5.3.= Open discussion=C2=A0

=C2=A0

Welcome input on= API. Open issue on improving granularity of info (Apple use enum and 3 mod= es eg interactive, aggregation) (Tommy)=

Path= manager and scheduler is a challenge because you often have two competing goals, reduce cost and improve perfor= mance. Ok on the client you can make this trade-off, but needs to be commun= icated to the ser= ver. We currently know who we talk to and configure a policy for a particular s= ervice, This is not a general solution, so some signalling from client to s= erver would be very useful. (Christoph)

Have= you tried using ECN approach suggested by Lars? (Phil)=

Can = perhaps support throughput, but does not work for latency (Christoph)

Can = we perhaps solve some of these issues in more general context, will apply to multipath QUIC as well at some time or any multipath protoco= l

Thin= k it is important to collect path scheduling algorithms in informational document (Markus= )

Issu= e is not only on han= dset, also on proxy that may implement load balancing scheme (Florin)

Woul= d be useful to tease this problem apart (Lars)

Hear= a lot of interesting issues, but they seem like research issues. Also some minor extensions, that could be done in tcpm. Also hear discussion on inte= rfaces, this links to TAPS<= /p>

Not = only research issues, also experiences from operational experience. Also need connection to BBF and 3GPP

Can = be handled in other groups (Mirja)

Much= easier if we have a group collecting MPTCP experts (Zhen)=

Conc= erned we are missing other experts here like congestion control. (Mirja)

=C2=A0

Do h= ave issue if a terminal or proxy need to implement a policy, we have very clear requirements here. (Florin)

For = ATSSS we have a side channel for policies, right (Christoph)<= span style=3D"font-size:9pt;font-family:"Courier New";color:black= ">

Issu= e is how to use the policy as I understand (Florin)=

=C2=A0

Thin= k we should have informational document on scheduling and path management for BBF and 3GPP to know. Do you think this is research? (Markus)<= u>

This= topic is relevant for other protocols as well, we will find a home for thi= s document (Mirja)

Clos= ing a wg is not a threat to close the work, perhaps we should have a genera= l wg on multipath (Tommy)

Agre= e a generic multipath group could be good. IEEE, 3GPP want to use IETF protocols, timeframe is ~ Dec 2019. (Florin)

Do n= ot understand why we should close a group when we have issues to solve (Zhe= n)

Grou= p has finished its charter, then we normally close. The mailing list can stay open. (Mirja)=

=C2=A0

=C2=A0

=C2=A0

--000000000000a15af00586e7ca39-- From nobody Tue Apr 23 01:31:10 2019 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 86C1712023C; Tue, 23 Apr 2019 01:31:09 -0700 (PDT) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailbox.org header.b=AxkkVNjC; dkim=pass (2048-bit key) header.d=mailbox.org header.b=mqqGzO6I 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 BPAzsX4FlMyK; Tue, 23 Apr 2019 01:31:07 -0700 (PDT) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 01E801202D2; Tue, 23 Apr 2019 01:31:06 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 002F3A10A7; Tue, 23 Apr 2019 10:31:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :subject:subject:references:in-reply-to:message-id:from:from :date:date:received; s=mail20150812; t=1556008262; bh=wBbzxLi/97 6kMNLDmlaCUvSODNvOADi+Upu3gpF8uHw=; b=AxkkVNjCMjgsBMqlcYKG/MSkgO E8npUHuZbDs316mKJ06eOt2kW7zRamJD4tDXwYYmul0J4nkf3TslzMZiKQTAtBTO kry6J+ZcNH4j6FfJaMoRdo7d+HYoUBsvYrzI+Reo+8RupzfUa1Vf8wOXAsCtRUim 02ceXLU7O0spILPLoQyPOzl6zqa8uOSs6ZIi9ipdESInQ4lVG1c5nMf2TABCpv64 ipLg70EN1LAy2ASsfTppR/DQ3Z3Xn3jgazVl+UjnmxMtp3vWAbAjGvFUy5RVp9dK rDWj1qHNh9bkCH3EojQLnB916OTdmAw8x3UEN/Tfc1MvwjnmUttf9VKwgNmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1556008263; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bMCM8hoYiLsiosJp4nlLLu9T1cIvk449rniYOo00X/o=; b=mqqGzO6I5J72o+ekdKv3tbCMhAiUMfiOvmyY4bs1ws2VSpaUpRRnehU9/OB5ATsbMs0K6y luuj/WrXQ22ptIvN/f8AekI1KNjypoR2aSWwSZoiTqLLW5JHovrDMw3Pms9CPeDXdBylFu t04fhdv3amTJhgNvTXQEMwqifhH8BHCKArbRu2E8N42yHK3vXUsub/ESgytQ4BwBwgRVPA NvRXgTJDOFIzUEx4VVCNP94OAaYjgmPHn/hpnbHIndznHoEH7cTVR7kpHNdS7seSsJVU+O BwXcoZVXR45im3FjCjXh+4hMNvuOWDOudD5f+edCjJqFmQcbodp2nT/JWTBYFQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id FZeHOLESM2rO; Tue, 23 Apr 2019 10:31:02 +0200 (CEST) Date: Tue, 23 Apr 2019 10:31:01 +0200 (CEST) From: Klemens Schragel To: draft-ietf-mptcp-rfc6824bis.all@ietf.org Cc: multipathtcp@ietf.org Message-ID: <1727071574.54811.1556008261822@office.mailbox.org> In-Reply-To: <1749087198.10105.1552294615030@office.mailbox.org> References: <1749087198.10105.1552294615030@office.mailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium Archived-At: Subject: [multipathtcp] Key Exchange X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:31:10 -0000 Hi all, (sorry for potential double-notification, after Mirja's mail I noti= ced I probably used the wrong mailing list) The motivation for (changing) the key exchange concept is expressed only in= the Appendix: =E2=80=9C Appendix E. Changes from RFC6184 [...] o Connection initiation, through the exchange of the MP_CAPABLE MPTCP option, is different from RFC6824. In order to permit servers to act statelessly, the SYN doesn't include A's key (it is still sent in the ACK). =E2=80=9C I would expect this ("servers to act statelessy") to be mentioned also some= where in the main text and not just in the appendix, especially considering= that this different behavior (with regards to experimental v0) is introduc= ed in the currend draft-version as a caveat for version negotiation. Someth= ing like this: =E2=80=9C 3.1. Connection Initiation [...] The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0 [RFC6824] to support server statelessness (see Appedix E). [...] =E2=80=9D (ideally there should be also an own section elaborating the motivation in = more detail; to me it seems a bit in contrast to the tendency I see to tune= toward minimum RTT communication. But I guess it's a bit late for that) Thanks and rgds, Klemens From nobody Fri Apr 26 02:52:09 2019 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDE012019F; Fri, 26 Apr 2019 02:51:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: multipathtcp@ietf.org, draft-ietf-mptcp-rfc6824bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ines Robles Message-ID: <155627231588.6796.18228205076376708862@ietfa.amsl.com> Date: Fri, 26 Apr 2019 02:51:55 -0700 Archived-At: Subject: [multipathtcp] Genart last call review of draft-ietf-mptcp-rfc6824bis-13 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 09:51:56 -0000 Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-mptcp-rfc6824bis-13 Reviewer: Ines Robles Review Date: 2019-04-26 IETF LC End Date: 2019-04-26 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written and clear to understand. I found the document quite complete. The document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. I have some minor questions for the authors. Major issues: Not found Minor issues: Not found Nits/editorial comments: Section 1.1 " the working group imposed..." --> " mptcp working group imposed..." Some Comments/Questions: - Section 1.4: "...A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1." --> would it be "initiated from B2"? or you mean B1 following the example showed in Figure 2? - For Figure 5 (Pag.24), Figure 6(Pag.26) and Figure 11(Pag.40): would it be correct to add "(rsv)" in the empty field (between "Subtype" and "B" fields) as showed in Figure 12 (Pag. 44).? - Section 8.1: "This document defines one additional subtype (ADD_ADDR) and updates the references to this document for all subtypes except ADD_ADDR, which is deprecated.": - It seems that the additional subtype is MP_TCPRST and not ADD_ADDR, comparing table 2 between this draft and RFC6824. - Would it be correct state instead of "ADD_ADDR deprecated" to "ADD_ADDR modified"? In Appendix E states; "The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option." Thanks for this document, Ines. From nobody Sun Apr 28 01:32:25 2019 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5504912008C; Sun, 28 Apr 2019 01:32:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang via Datatracker To: Cc: multipathtcp@ietf.org, draft-ietf-mptcp-rfc6824bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sheng Jiang Message-ID: <155644033824.21052.11987414225889464637@ietfa.amsl.com> Date: Sun, 28 Apr 2019 01:32:18 -0700 Archived-At: Subject: [multipathtcp] Opsdir last call review of draft-ietf-mptcp-rfc6824bis-13 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 08:32:19 -0000 Reviewer: Sheng Jiang Review result: Has Nits Hi, OPS-DIR, Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This standard track document presents a set of extensions to traditional TCP to support multipath operation. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824. This document is clear and well written. There are a small Nit. Reviewer: Sheng Jiang Review result: Has NITs Major issue: not found. Minor issue: not found. Nits: Downref: Normative reference to an Informational RFC: RFC 6182. Regards, Sheng