From nobody Thu Aug 15 13: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 9BD731200DB for ; Thu, 15 Aug 2019 13:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8MOWHi5bz6w7 for ; Thu, 15 Aug 2019 13:40:33 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 32D1C1200CC for ; Thu, 15 Aug 2019 13:40:33 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id b16so3350226wrq.9 for ; Thu, 15 Aug 2019 13:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5DMhPlFIWiE5+YfguOWHJSTNcbbUnhIVVBcpkEkiP1s=; b=h1WPUA5TcuLFMsXYDmxNu1zOUBF54VzqS96vp2CXYR57k7mmGL7e7VCOEp1CtdV5w5 Tn8oltjg+6Xw51GQIIS67Fl2O+2WYvcB/qtNkHoBQnmqDSiMUDF8gtt6wTMvz+1rPF8n XwVcjLXuTBSH+Hy0+QxejSRCoCKO84WpgdyfAq6+cECnF2GPjZ2yoJ2rKS9oTkMYvtad ENxh75TFcJGBTURMQz2JRuNjPZTByXh7oo48QGLZU8HacbvdZvHt+HglZq8MAGMPCw05 bfVtV0s0YK2fgzP3oww8U5RE+ivkoX1ZjmLSWNIbOLG8Lh6mPleUP8FQ2C+Bd7UfPTwP EFUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5DMhPlFIWiE5+YfguOWHJSTNcbbUnhIVVBcpkEkiP1s=; b=t2G//NHmvbQcVZqcGCqYKowN06l0Fnxgh/xGoofFvtBchnSYsYjZd41Z4IImAEGp/v 5aIZ6SsMIIZgTLDjs9SKSex8T08+L45cAEuWnrqmO8QHDsxhejCDz5FlvEwTwV+tdklk UKMv1/uwDgebemzG5SQsiqKzmaBNytrw04HtepdOr7SW1mjErN/v7s4hlB0vuwYj97Gw BrTpcfctN9YUO7MBdm2Q0CtLUMhcGoqGH1nYwN1xDk/5gt4Bi82XUsiDwP4UO9lzU5Dq H5FHt/Ss/WrJfl7WWQtZ/nODZ4BHPDv+gH2pqLA2P+qmYnaXDUUn29zxbs78ItwA+SC0 3zFA== X-Gm-Message-State: APjAAAVfo1Xe7dTETqhY84yg1DrLCfkm8SmieX9o5aQoLgwRYA7wYIsF TWhCG/FGb7vBQYwHwodiHlEM1PGoD96tTKBvyw8LMtLc X-Google-Smtp-Source: APXvYqxNfYkiJlc+YAw2mnvQLMU1Jc9TG2mwOuNuA8m2lIh+SybthBCwqDloAm/RDREZRyfbIx2kdAgqCF4dw2jkxk8= X-Received: by 2002:a5d:528a:: with SMTP id c10mr6815685wrv.111.1565901631622; Thu, 15 Aug 2019 13:40:31 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Thu, 15 Aug 2019 13:40:20 -0700 Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="00000000000081960905902de2d4" Archived-At: Subject: [multipathtcp] draft minutes for montreal meeting 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, 15 Aug 2019 20:40:36 -0000 --00000000000081960905902de2d4 Content-Type: text/plain; charset="UTF-8" Hi, Sorry for the delay. I uploaded a draft minutes for montreal meeting. You can take a look at the URL below. Please let the chairs know if you have corrections, suggestions or questions. https://datatracker.ietf.org/doc/minutes-105-mptcp/ Thanks, -- Yoshi & Phil --00000000000081960905902de2d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,
Sorry for the delay. I uploade= d a draft=C2=A0minutes=C2=A0for montreal me= eting.=C2=A0
You can take a look at the URL below.
Plea= se let the chairs know if you have corrections, suggestions or questions.


Thanks,
--
Yoshi & Phil
--00000000000081960905902de2d4-- From nobody Wed Aug 21 04:20: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 8E112120916 for ; Wed, 21 Aug 2019 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 iNP5jnqEaxiV for ; Wed, 21 Aug 2019 04:20:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6E1120912 for ; Wed, 21 Aug 2019 04:20:47 -0700 (PDT) Received: from tpw09926dag04h.domain1.systemhost.net (10.9.202.31) by BWP09926078.bt.com (10.36.82.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 21 Aug 2019 12:20:44 +0100 Received: from tpw09926dag12h.domain1.systemhost.net (10.9.212.36) by tpw09926dag04h.domain1.systemhost.net (10.9.202.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 21 Aug 2019 12:20:44 +0100 Received: from bwp09926077.bt.com (10.36.82.108) by tpw09926dag12h.domain1.systemhost.net (10.9.212.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 21 Aug 2019 12:20:44 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.59) by smtpe1.intersmtp.com (10.36.82.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 21 Aug 2019 12:20:42 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g7HveEwG2LAhtE+lFWwYTOmzBJrHbCrVIVwOntncHWS35Ur2gd01WwaENj3upS70hQs/9skG1FAk2ifJsPx7UzgTyZcNC5GfNKdtc6Vj3DprvSFYnRY/4Qy3Xhr+XHJZCoSrjiEuFHQJ26EQ0PzckDqYTZbWywOXjrvlHSusxZAkMoI2YmGdQoW4eLu+kFS2w6VrO7YgDCvGIX4cdw03aW5F43/K863bi2CAzjI24x47Se4MydeGcP2FhaYMY0qoXrPWEkQROFwyVabxlHf/q/tF93YrQzMlteDGRjPqmXHyYa4lOR3nqNWadAyBm33J02rfdon4kXQjGGEqfUaOuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oYBVxycVI3/MVSEBoTH0ROQofwJ89fPul7BY/jllcGE=; b=lwBjncZZRlECa20sNRtREAv2J3965d4vll9q5ewVn3vmW/ZI/zYaYoKO9sCgLWhqiy6p0W6Rw1BE6yUZwd7yR37+ndiqjtYK9/awa+MmAVPyxEYUM82hc4LFcjzdPMBa+4Crgp9y3FtfIUySDYD0nF05aaHHf1U/Tg2VMqAfNZlYvk4+9OW8NwhLmHZi1a4tFBkAW9eg9BgvytY+TkafPnHbLOv0IqzpSrY0ffs8s59pVRPpOEaKqQdZoYk+yh7xhRff8R+8l++o4KLYfoRCCUmvmmLgnkvH0+px2cKsVtMaotH7l/tBzdGhcGKzdKOt1+Rm2SI5QmgnUedQarYHSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oYBVxycVI3/MVSEBoTH0ROQofwJ89fPul7BY/jllcGE=; b=ElRjreO8hKLOoi3lfjjL5OO8ECQoGW7Vgkj63TDS4EK6pfwfgMdJWczZUI1uK6lG4g0czBpLkJIpCG7a/QDCsIfLwMqeERUlRzGhWBmPATUDvhNSDh4gSPfANGHBO2cXdvwBbNEstzkvv9x4cVANfIOeuPOroVQRYt0yaZQpsZA= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2041.GBRP123.PROD.OUTLOOK.COM (20.179.129.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 11:20:43 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3%5]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 11:20:43 +0000 From: To: , Thread-Topic: [multipathtcp] draft minutes for montreal meeting Thread-Index: AQHVU6m4MjL0SDWTiU+ZnMgcvtZpKacFfDfQ Date: Wed, 21 Aug 2019 11:20:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: dfe76110-0189-42fb-4795-08d726299b0e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2041; x-ms-traffictypediagnostic: LNXP123MB2041: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(366004)(346002)(376002)(189003)(199004)(71190400001)(71200400001)(74316002)(7696005)(54896002)(66476007)(6306002)(66446008)(99286004)(966005)(52536014)(6506007)(53546011)(5070765005)(64756008)(33656002)(14454004)(55016002)(86362001)(76116006)(236005)(102836004)(53936002)(76176011)(66556008)(4744005)(478600001)(5660300002)(9686003)(6246003)(6436002)(66946007)(316002)(110136005)(8676002)(486006)(81156014)(81166006)(186003)(11346002)(3846002)(790700001)(7736002)(476003)(2906002)(66066001)(6116002)(8936002)(256004)(446003)(25786009)(26005)(229853002)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2041; H:LNXP123MB2587.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: OWC6CSXTrdjh3B2ogNIm96brVP6Bog/4mtkxaiKHvdjq+Wv8lVqlVzLyv+83QIiuOIQ+tSj0JJgASL/OK9OQuzBIdTvpgwTQ62BEFspqEpi42R2mZ/2tFpWTYqFOqAe9pv3ySrHMQaXYPdphWkxAHKQ4RPHDXVY+GkBVF3/3+oT2qsZa1KpLRrbc+1fUSubOtCFuyuwrH7rMtDFJQijsCtJ+A46bz6SOdUID4KGy6JwA6EEGPEBaysgV33n3TsRcSn9sa2tLJBIMUBbGoffBNJq/+Nn/K+r8cei22Q+iJqV3EYx88yjBGlNLgKVz3gwIA1bEkoxlydePbufDKrgOsiK25H5wgbZLWm47OjDEphpUnM9m4qhgNQE8prgiLCTD1oBV/8vBZOZCjmGVXCgbmzyqZKQkzA1A03998XhdgeU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB2587323F99C151DDA03964AFEBAA0LNXP123MB2587GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dfe76110-0189-42fb-4795-08d726299b0e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 11:20:43.1834 (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-CrossTenant-userprincipalname: IlMONtHGotxImznnGDT9acqwcd39vKSMBjy/yv8b+kRFjQmlXh3tV8+TYJHeb9AJMRQ9hJwU4rpiMqSSVoikXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2041 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.6 X-NAI-Spam-Report: 4 Rules triggered * 0.6 -- TS_MSG_REP_20 * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6616 X-NAI-Spam-Version: 2.2.0.9309 : core <6616> : inlines <7138> : streams <1830724> : uri <2887330> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [multipathtcp] draft minutes for montreal meeting 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: Wed, 21 Aug 2019 11:20:51 -0000 --_000_LNXP123MB2587323F99C151DDA03964AFEBAA0LNXP123MB2587GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9zaGksDQooYWJvdXQgTVBUQ1AgKyBUTFMpIDw8ICAgQ2hhaXJzOg0KICAgICAgIEFueWJvZHkg aW50ZXJlc3RlZCBpbiBoZWxwaW5nIEFsYW4/DQogICAgICAgKE5vdGU6IHNvbWVvbmUgd2FzIGlu dGVyZXN0ZWQuIGJ1dCwgY2Fubm90IGlkZW50aWZ5IHRoZSBuYW1lLi4pDQo+Pg0KbXkgbm90ZXMg c2F5IOKAnFlvc2hpIGFuZCBwcmVzdW1hYmx5IE9saXZpZXLigJ0NCihhYm91dCBmdXR1cmUgb2Yg V0cpDQo8PCA/Pz86DQogICAgICAgKzEgSW4gdGhlIHBhc3QsIHRoZXJlIHdhcyBnZW5lcmFsIGlu dGVyZXN0IGluIHRoZSBhY3RpdmUgZG9jdW1lbnRzLg0KICAgICAgIFNvbWUgb2YgdGhlIGFjdGl2 ZSBpbmRpdmlkdWFsIGRyYWZ0cyBhcmUgcmVsZXZhbnQuDQo+Pg0KTXkgbm90ZXMgc2F5IFNyaQ0K cGhpbA0KDQoNCkZyb206IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5pc2hpZGENClNlbnQ6IDE1IEF1Z3Vz dCAyMDE5IDIxOjQwDQpUbzogbXVsdGlwYXRodGNwIDxtdWx0aXBhdGh0Y3BAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbbXVsdGlwYXRodGNwXSBkcmFmdCBtaW51dGVzIGZvciBtb250cmVhbCBtZWV0aW5n DQoNCg0KSGksDQpTb3JyeSBmb3IgdGhlIGRlbGF5LiBJIHVwbG9hZGVkIGEgZHJhZnQgbWludXRl cyBmb3IgbW9udHJlYWwgbWVldGluZy4NCllvdSBjYW4gdGFrZSBhIGxvb2sgYXQgdGhlIFVSTCBi ZWxvdy4NClBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZlIGNvcnJlY3Rpb25z LCBzdWdnZXN0aW9ucyBvciBxdWVzdGlvbnMuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL21pbnV0ZXMtMTA1LW1wdGNwLw0KDQpUaGFua3MsDQotLQ0KWW9zaGkgJiBQaGlsDQo= --_000_LNXP123MB2587323F99C151DDA03964AFEBAA0LNXP123MB2587GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLWlsDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLWlsO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPllvc2hpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihhYm91dCBNUFRDUCAmIzQzOyBU TFMpICZsdDsmbHQ7Jm5ic3A7Jm5ic3A7IENoYWlyczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQW55Ym9keSBpbnRlcmVzdGVkIGluIGhlbHBpbmcgQWxhbj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKE5vdGU6IHNvbWVvbmUgd2FzIGludGVyZXN0ZWQuIGJ1dCwgY2Fubm90IGlkZW50 aWZ5IHRoZSBuYW1lLi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5teSBub3RlcyBzYXkg4oCcWW9zaGkgYW5kIHByZXN1bWFibHkgT2xpdmllcuKA nTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihhYm91dCBm dXR1cmUgb2YgV0cpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Jmx0OyZsdDsgPz8/OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzEgSW4gdGhl IHBhc3QsIHRoZXJlIHdhcyBnZW5lcmFsIGludGVyZXN0IGluIHRoZSBhY3RpdmUgZG9jdW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTb21lIG9mIHRoZSBhY3RpdmUgaW5kaXZpZHVh bCBkcmFmdHMgYXJlIHJlbGV2YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+TXkgbm90ZXMgc2F5IFNyaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gbXVsdGlwYXRodGNwIFttYWlsdG86bXVsdGlwYXRodGNwLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPGI+ U2VudDo8L2I+IDE1IEF1Z3VzdCAyMDE5IDIxOjQwPGJyPg0KPGI+VG86PC9iPiBtdWx0aXBhdGh0 Y3AgJmx0O211bHRpcGF0aHRjcEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW211 bHRpcGF0aHRjcF0gZHJhZnQgbWludXRlcyBmb3IgbW9udHJlYWwgbWVldGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IGZvciB0aGUgZGVsYXkuIEkgdXBsb2Fk ZWQgYSBkcmFmdCZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1pbCI+bWludXRlczwvc3Bhbj4mbmJz cDtmb3IgbW9udHJlYWwgbWVldGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4gdGFrZSBhIGxvb2sgYXQgdGhlIFVSTCBi ZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZlIGNvcnJlY3Rpb25zLCBzdWdn ZXN0aW9ucyBvciBxdWVzdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL21pbnV0ZXMtMTA1LW1wdGNwLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv bWludXRlcy0xMDUtbXB0Y3AvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9zaGkgJmFtcDsgUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LNXP123MB2587323F99C151DDA03964AFEBAA0LNXP123MB2587GBRP_-- From nobody Wed Aug 21 08:31:59 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 3EEA9120B37 for ; Wed, 21 Aug 2019 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 DUkemHpDF8kO for ; Wed, 21 Aug 2019 08:31:55 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50095.outbound.protection.outlook.com [40.107.5.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB119120B36 for ; Wed, 21 Aug 2019 08:31:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G8ee+9mfCymlvYwI5969jZKk2yZPbeHcXjw+RUrKH5V3cnvuzmDeOkmyek/1XvlGQY7lkmX0BkMNBl1/SjYf2+jFXIG97WB0XLA3HEvTgS1AnZKtl+GFqwa23FNKT+JlCMtPrdPoPKCk0ciPIAgtdIgBMMdRRoHivZyjYeXbl3lgjzl36kPjCRV1GKwJJcmaD5kIvrnFID8pOY2XxUCoLXLEY5Ulq093ziLFSmYTFA6dkdpL7DRiKwOePkrOhJbze7+ITQTZmHSN+lUdzMo0BDlD4odBFHqEYOf373ycR+q4K7iWqHGrVvJU1v7Tt6cLnO2ryCwYIv2dQ91nNh3Xhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0JyQVd2SyZdhpFs+UBWrN7uEUksXMfWMs8yzrwYwJcI=; b=Udc5+wUhHyFVFTHuglkBL2xnkpF+ZdE8v/BMrmGXTHiXScG8Sg/4BXRCSQ4vH/eCeBDQ8VovcehZirJ2iIv2WazkRb8psu0nr59A5ExSREPqlwiezppt4Ir0Ht8fz1mAju1j+69ua5RkEwq8XqOS427b7E6hgQSJrmSkPGCcrgRKsRZaVMAM9GxiXwX4rzna8vxkAaS5LmO35D8TtKpZ86Rzc93BozyyPvNcCIsAmpLMXLXz1dKNwev/ub5FLycvK+t4OJevYvJMN9BCZX6dmafVVrLLvJoRnL8fJjWnZR1O3pnfQ+y0EUMoKjihcIP3wWzxajcvBtgB1L/xJFLPwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0JyQVd2SyZdhpFs+UBWrN7uEUksXMfWMs8yzrwYwJcI=; b=v2wOBTXp45uCkxRwkssKCwW8DjhUYvRq8vm6MaB1TnYVlCtohs9ZfrT235zXQCtH+ibCFQAFWMdAw7REnDxUs/miri/GjytrnKbKAeefXVUZsUIR9endhHx0oQAaXGm5HY480YmAVz13tra/vVdKkc9V+aq2ICoRmZ2SKdrWalo= Received: from DB7PR03MB3548.eurprd03.prod.outlook.com (52.134.98.29) by DB7PR03MB4009.eurprd03.prod.outlook.com (52.135.135.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 15:31:52 +0000 Received: from DB7PR03MB3548.eurprd03.prod.outlook.com ([fe80::256d:9d8a:8df:96fb]) by DB7PR03MB3548.eurprd03.prod.outlook.com ([fe80::256d:9d8a:8df:96fb%7]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 15:31:52 +0000 From: Olivier Bonaventure To: Yoshifumi Nishida , multipathtcp , Mathieu Jadin Thread-Topic: [multipathtcp] draft minutes for montreal meeting Thread-Index: AQHVU6m8GPHNNa5q7kK1lksknJZnXacFw8YA Date: Wed, 21 Aug 2019 15:31:52 +0000 Message-ID: <008f46d7-dd99-3158-535e-91efe1acb2f7@uclouvain.be> References: 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: PR0P264CA0226.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1e::22) To DB7PR03MB3548.eurprd03.prod.outlook.com (2603:10a6:5:4::29) 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:18fd:55b7:3c93:1ab5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44e747b2-edd2-4a2f-41e5-08d7264cb0a6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DB7PR03MB4009; x-ms-traffictypediagnostic: DB7PR03MB4009: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(189003)(199004)(36756003)(110136005)(53936002)(6246003)(86362001)(25786009)(786003)(31696002)(316002)(486006)(31686004)(99286004)(966005)(446003)(43066004)(478600001)(8676002)(81156014)(81166006)(2616005)(561944003)(476003)(8936002)(46003)(14454004)(11346002)(256004)(6436002)(102836004)(3450700001)(6306002)(76176011)(386003)(6506007)(6636002)(6512007)(64756008)(6486002)(71200400001)(71190400001)(66446008)(66556008)(66476007)(66946007)(305945005)(7736002)(2906002)(229853002)(5660300002)(6116002)(14444005)(52116002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR03MB4009; H:DB7PR03MB3548.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: 82aCFASqXQ9Lf792IMP8HUSvm5XjBgKdGxAC9nFbnrASpNWOYRwgKkyQTY8My9MtTJ4sGr9lC1M97bxcsBmh267Xp6YXbjXRl+Vd0hpo1cEkj+xKPOph8F8coX+o7ILU+od4M1sjNcEmHkrwjqMR0xpHM/C5rFjZaP+PxpeOl6YXWNMMFsBa3A1AwUG/NlbsJHVyhLMlPtfbWXSjzs2hyBCcV9B3mso4tHbyNhSEAb2Lpx4d17X3kLhVtWb8m3P796BDKZppZPZu3zN0uwsHPqsqxs0EPfrjvT3MlQyAWBV9wg5kZlTBXQyhPQs/bQNbVlUV5CxSNqfWM+KWJR2zFFaGT7MeStKRLgpUGVFA1t/S9ZVXvivdisgZgPBUiX0+xFpyaYznmLtTeb4ZhN4Tdkli9ktyrr/F3jEl9+9daGU= Content-Type: text/plain; charset="utf-8" Content-ID: <1367EFF9FA22DE40855EF9139F025936@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-Network-Message-Id: 44e747b2-edd2-4a2f-41e5-08d7264cb0a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 15:31:52.0649 (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-CrossTenant-userprincipalname: neI7tit1Qwr49QsBv+D+JWjlH04E7UrNuIHoiGPcdY2QCg6UQBSL9HUssU67A7JCz/QHvFh0gL32EsmcMAqQcIVgHcjELgcI3srE9+2phuTFtrDigRxO/GMWbxQBt/4b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR03MB4009 Archived-At: Subject: Re: [multipathtcp] draft minutes for montreal meeting 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: Wed, 21 Aug 2019 15:31:58 -0000 WW9zaGksDQoNCj4gU29ycnkgZm9yIHRoZSBkZWxheS4gSSB1cGxvYWRlZCBhIGRyYWZ0IG1pbnV0 ZXPCoGZvciBtb250cmVhbCBtZWV0aW5nLg0KPiBZb3UgY2FuIHRha2UgYSBsb29rIGF0IHRoZSBV UkwgYmVsb3cuDQo+IFBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZlIGNvcnJl Y3Rpb25zLCBzdWdnZXN0aW9ucyBvciANCj4gcXVlc3Rpb25zLg0KPiANCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDUtbXB0Y3AvDQoNClRoYW5rcyBmb3Igc2hh cmluZyB0aGVzZSBkZXRhaWxlZCBtaW51dGVzLiBJIGhhdmUgc29tZSBjb21tZW50cyBhZnRlciAN CmhhdmluZyByZWFkIHRoZW0uDQoNCg0KPiANCj4gICAgS2VpdGggTW9vcmU6DQo+ICAgICAgICBJ cyB0aGVyZSBzdXBwb3J0IGluIHRoZSByb29tIGZvciB3b3JraW5nIG9uIGEgc2VjdXJlIChlbmNy eXB0ZWQpIHZlcnNpb24NCj4gICAgICAgIG9mIE1QVENQPw0KPiANCj4gICAgQ2hhaXJzOg0KPiAg ICAgICAgU2hvdyBvZiBoYW5kczogSG93IG1hbnkgd291bGQgYmUgd2lsbGluZyB0byB3b3JrIG9u IGFuIGVuY3J5cHRlZCB2ZXJzaW9uLg0KDQpXZSBwcm9wb3NlZCBzdWNoIGEgZGVzaWduIGluIGFu IGluZm9jb20gcGFwZXIsIHNlZQ0KaHR0cHM6Ly9pbmwuaW5mby51Y2wuYWMuYmUvcHVibGljYXRp b25zL3NlY3VyZS1tdWx0aXBhdGgtdGNwLWRlc2lnbi1pbXBlbWVudGF0aW9uLmh0bWwNClRoZXJl IHdhcyBydW5uaW5nIGNvZGUgb24gTGludXggYnV0IHdlIGhhdmUgbm90IG1haW50YWluZWQgaXQg c2luY2UgDQpwdWJsaWNhdGlvbi4NCj4gDQo+ICAgIE1pcmphIChhcyBpbmRpdmlkdWFsKToNCj4g ICAgICAgIElmIHlvdSB3YW50IGVuY3J5cHRpb24sIHVzZSBRVUlDLg0KPiANCj4gICAgQ2hhaXJz Og0KPiAgICAgICAgV291bGQgd29yayBvbiBiZSBhIGJhZCBpZGVhPw0KPiAgICAgICAgKGEgY291 cGxlKSBhbmQgd2h5Pw0KPiANCj4gICAgTmljb2xhcyBQOg0KPiAgICAgICAgSSB0aGluayBpdCdz IHRvbyBoZWF2eS4gV291bGQgcmVxdWlyZSBlbmNyeXB0aW9uIG9mIG9wdGlvbnMuID4NCj4gICAg WW9zaGk6DQo+ICAgICAgICBUQ1BJTkMgd2FzIG9yaWJpbmFsbHkgaW50ZW5kZWQgdG8gYmUgdXNl ZCBmb3IgTVBUQ1AuIEJ1dCwgaXQgZG9lcyBub3QNCj4gICAgICAgIGVuY3J5cHQgb3B0aW9ucy4g RG8gd2Ugd2FudCB0byBjcmVhdGUgYW4gdXBkYXRlZCB2ZXJzaW9uPw0KPiANCj4gICAgTWlyamE6 DQo+ICAgICAgICBUaGVyZSBpcyB6ZXJvIGRlcGxveW1lbnQgb2YgVENQSU5DLiBJIHdvdWxkIHN1 Z2dlc3QgdG8gZmlyc3QgZ2V0DQo+ICAgICAgICBkZXBsb3ltZW50IGV4cGVyaWVuY2UuDQoNCklm IHBlb3BsZSB3YW50IHRvIGV4cGVyaW1lbnQgd2l0aCBvdXIgaW1wbGVtZW50YXRpb24sIHRoaXMg c2hvdWxkIGJlIA0KcG9zc2libGUuIE15IHBlcnNvbmFsIHZpZXdwb2ludCBpcyB0aGF0IGFkZGlu ZyBmdWxsIHNlY3VyaXR5IHRvIE1QVENQIGlzIA0KcHJvYmFibHkgdG9vIGRpZmZpY3VsdCBhdCB0 aGlzIHN0YWdlIGlmIHRoZSBvYmplY3RpdmUgaXMgdG8gaGF2ZSBhIA0KZGVwbG95YWJsZSBzb2x1 dGlvbi4NCj4gDQo+ICAgIE1hcmt1czoNCj4gICAgICAgIFdpbGwgdGhlcmUgYmUgYW5vdGhlciBt ZWV0aW5nIGF0IElFVEYgMTA2Pw0KPiANCj4gICAgQ2hhaXJzOg0KPiAgICAgICAgTm8gZGVjaXNp b24gaGFzIGJlZW4gbWFkZSBzbyBmYXIuDQo+IA0KPiAgICBBbGFuIEZvcmQgKG9uIEphYmJlcik6 DQo+ICAgICAgICBNUFRDUCArIFRMUyB3YXMgcHJvcG9zZWQgc29tZSB0aW1lIGFnby4NCj4gDQo+ ICAgIFlvc2hpOg0KPiAgICAgICAgU29tZW9uZSB3YW50cyB0byByZXZpdmUgdGhpcz8NCj4gDQo+ ICAgIEFsYW4gRm9yZCAob24gSmFiYmVyKToNCj4gICAgICAgIElmIHNvbWVvbmUgaXMgaW50ZXJl c3RlZCwgSSB3b3VsZCBjb250cmlidXRlLiBUaGUgcHJvcG9zYWwgd2FzIHRvIHVzZQ0KPiAgICAg ICAgVExTIGtleSBleHRyYWN0aW9uIGZvciB0aGUgc2Vzc2lvbiBzZWN1cml0eS4gSXQgd2FzIG9u bHkgYSA0IHBhZ2UgZHJhZnQNCj4gICAgICAgIGluIC0wMC4gSWYgdGhlcmUgd2FzIGludGVyZXN0 IGluIGVuY3J5cHRpb24gYXQgdHJhbnNwb3J0IGxldmVsLCBJIHdvdWxkDQo+ICAgICAgICBzdWdn ZXN0IHRvIHVzZSB0aGlzIGFzIGEgc3RhcnRpbmcgcG9pbnQuDQo+IA0KPiAgICBNaXJqYToNCj4g ICAgICAgIElmIHRoZXJlIGlzIGludGVyZXN0LCBicmluZyBpdCB0byB0aGUgVExTIHdvcmtpbmcg Z3JvdXAuDQo+IA0KPiAgICBNYXJjZWxvOg0KPiAgICAgICAgVExTIGlzIHVzZWQgYXMgaXQgaXMu DQo+IA0KPiAgICBNaXJqYToNCj4gICAgICAgIFRMUyBtYXkgbm90IGJlIGhhcHB5IGFib3V0IGFu IGludGVyZmFjZSB0byBleHBvc2UgdGhlIGtleXMuDQoNCldlIGFsc28gaGFkIGFuIGltcGxlbWVu dGF0aW9uIG9mIHRoaXMgYXBwcm9hY2guIElmIHdvdWxkIHByb2JhYmx5IG5lZWQgDQp0byBiZSB1 cGRhdGVkIG5vdyB0aGF0IFRMUyAxLjMgaGFzIGJlZW4gcHVibGlzaGVkIGFuZCB0aGF0IGtUTFMg aXMgDQphdmFpbGFibGUgaW4gdGhlIExpbnV4IGtlcm5lbC4gSW4gYSBudXRzaGVsbCwgdGhlIGlk ZWEgd2FzIHRvIGRlcml2ZSB0d28gDQphZGRpdGlvbmFsIFRMUyBrZXlzIChpLmUuIGRpZmZlcmVu dCBrZXlzIHRoYW4gdGhlIG9uZXMgdXNlZCB0byANCmF1dGhlbnRpY2F0ZSBhbmQgZW5jcnlwdCBk YXRhKSBhbmQgZ2l2ZSB0aGVtIHRvIE1QVENQIHRvIHJlcGxhY2UgdGhlIA0Ka2V5cyB0aGF0IGFy ZSBleGNoYW5nZWQgZHVyaW5nIHRoZSBoYW5kc2hha2UuIFRoaXMgaW1wcm92ZXMgdGhlIHNlY3Vy aXR5IA0Kb2YgdGhlIGFkZGl0aW9uIG9mIG5ldyBzdWJmbG93cyBidXQgZG9lcyBub3QgY291bnRl ciBhdHRhY2tzIHdoZXJlIGFuIA0KYXR0YWNrZXIgbW9kaWZpZXMgZW5jcnlwdGVkIHBheWxvYWRz Lg0KDQpJIGNhbiBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGlmIHRoZXJl IGlzIGludGVyZXN0Lg0KDQoNCk9saXZpZXINCg0K From nobody Wed Aug 21 09:30:11 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 103C5120C32 for ; Wed, 21 Aug 2019 09:30:10 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRUmGcXlD7mb for ; Wed, 21 Aug 2019 09:30:08 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 255F1120BD2 for ; Wed, 21 Aug 2019 09:30:08 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7LGROJ5038164; Wed, 21 Aug 2019 09:30:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=5DopQ8RpSkdemc53Q/PzAwcUKZ0VIufbvRYLmt6FwGc=; b=PzmJW5O/Ar+1Ygmf2L/CIqWbmA0ueAA33SC7ff/qC9RQMB7LYNGpDow4bB7ULmbwH5sB nghKBjsG7B2f4QecbRVTZJYSl1vrs6HrHkgfdNvGdZe67xXc9B0rE6M7CsBffL0cWAth Wy0kf6EQsfovwXSJuWGiuBttWa6jLglASeNekK6XTUWgV67qjGZn5w8hP2pytC/0POh/ yieAGrd/kFKe3AwDuKHRAdT2hWbIrtH7dukHXS4ohbcUtL2RZT1T4HT+7taocZUX7e5C 0gBzrowyJvzTzOSh5BRJybkN5KlxSw3OJhLzI/UXIp7ln9pNN332pcAF0jGEnry6+aZk 4Q== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2uegk10py9-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 21 Aug 2019 09:30:05 -0700 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWL00K5PHU4D480@mr2-mtap-s03.rno.apple.com>; Wed, 21 Aug 2019 09:30:04 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWL00600HTZRE00@nwk-mmpp-sz13.apple.com>; Wed, 21 Aug 2019 09:30:04 -0700 (PDT) X-Va-A: X-Va-T-CD: 772dd47e94105b6916a0f4f153438e87 X-Va-E-CD: aaf9a206e6a9da61f8e3973146981c7c X-Va-R-CD: cac8f984c4dc83592c78d697d9fa2dd0 X-Va-CD: 0 X-Va-ID: 426a8057-bdff-4ef5-a9ec-263b50fdefdc X-V-A: X-V-T-CD: 772dd47e94105b6916a0f4f153438e87 X-V-E-CD: aaf9a206e6a9da61f8e3973146981c7c X-V-R-CD: cac8f984c4dc83592c78d697d9fa2dd0 X-V-CD: 0 X-V-ID: d30fb3a8-2e5a-4d8f-9e73-150953b5c957 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-21_05:,, signatures=0 Received: from localhost ([17.192.155.217]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWL005FLHTPW6C0@nwk-mmpp-sz13.apple.com>; Wed, 21 Aug 2019 09:29:49 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 21 Aug 2019 09:29:48 -0700 From: Christoph Paasch To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp Message-id: <20190821162948.GP5994@MacBook-Pro-64.local> References: <192f0914-3f3a-9a76-71ec-059bf159d14c@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.11.4 (2019-03-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-21_05:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00 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: Wed, 21 Aug 2019 16:30:10 -0000 Hello, jumping in on this thread a bit late. Please see inline: On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote: > Hi Olivier, > > On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure < > olivier.bonaventure@uclouvain.be> wrote: > > > Yoshi, > > > > > > 3: I am still not very sure the usage of SRL options for graceful > > > > subflow closing. I might want to see some texts in the draft to > > > > understand how this can be better than FIN exchange on subflows. > > > > > > When a client sends a FIN, it indicates that it will not send data > > > anymore on this subflow. When it sends a SRL option with 0, it > > > indicates > > > to the server that it does not want to receive anymore data on this > > > subflow. We can provide some text if we agree on this use case. > > > > > > Right. I can image the following 3 situations on the client side. > > > > > > 1: client doesn't need to receive any more packets from server > > > 2: client doesn't want sender to send more data, but wants to receive > > > data on the fly. > > > 3: client wants to close the connection when sender finishes sending data > > > > > > I think RST will work for 1: and we can use FIN for 3 > So, in my > > understanding, this approach tries to address 2:. > > > I just would like to understand how much this kind of situations happen. > > > > Consider a video or audio streaming application running on a smartphone. > > Smartphone has WiFi and cellular but user wants to limit use of cellular > > and force server to use low quality when streaming over cellular. > > When smartphone is attached to both WiFi and cellular, it can send SRL > > with a bandwidth of 0 over cellular. Here, it would be nice to be able to close the cellular subflow. The reason is the following: If we are not sending any packets on that cellular subflow (because we set the SRL to 0), after some time the subflow will become dis-functional because the NAT/Firewall-mapping has expired. So, keeping subflows at 0 for an extended period will cause trouble. > > If the smartphone moves, and leaves WiFi, then it could send a SRL at 1 > > Mbps to limit throughput. > > > > This dynamic control of the throughput on the incoming subflows would > > work well if a client can adapt its SRL to the current network conditions. > > > > OK. I think this would be a nice example for the usages of SRL and I > understand. > But, I am thinking that it might not be helping graceful closing much. > Anyway, the closing is not a major part of the draft. I personally think > removing it might be a choice when we don't have strong use cases. Could the SRL-option have a bit that says "and when you reached 0-rate, please close the subflow" ? Sure, we could simply on the receiver-side, wait until the subflow quiesces and then close it with a RST. However, if that RST gets lost, the subflow will hang on the sender-side for quite a while. Cheers, Christoph From nobody Thu Aug 22 01:25: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 929C1120236 for ; Thu, 22 Aug 2019 01:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MuyQcM1RBY_c for ; Thu, 22 Aug 2019 01:25:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD39812022E for ; Thu, 22 Aug 2019 01:24:56 -0700 (PDT) Received: from tpw09926dag05f.domain1.systemhost.net (10.9.202.24) by BWP09926077.bt.com (10.36.82.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 22 Aug 2019 09:23:48 +0100 Received: from tpw09926dag06e.domain1.systemhost.net (10.9.202.21) by tpw09926dag05f.domain1.systemhost.net (10.9.202.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 22 Aug 2019 09:22:55 +0100 Received: from bwp09926081.bt.com (10.36.82.112) by tpw09926dag06e.domain1.systemhost.net (10.9.202.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 22 Aug 2019 09:22:55 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.50) by smtpe1.intersmtp.com (10.36.82.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 22 Aug 2019 09:22:34 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OF/hE0isxCbKyOQ9C4bVC+YALfGlViBJe89TyRyrNYdZNY2tL53GldYl4GKU2tgQSmqLUOgPYT51PzrMlEuGXEmZCK/vr+2E2TClL97toe9CrUOBbddmH1G76Fvr9dR5dxRx5od/AzJBblV/A13EUMxjI0g+JioVx4rkIn5G20UzVdXI3S/r0j9Ew22Fz5aYzAsRDxm4JBfQrk13sQ11tW2hbvWlnRy16i014DpPZhMxBV3XNgVxJJFbdrXVm1Yj0fMk26OgTCPY6VjP0foKX4Zcug07LxSJ8OhggkBIqbM+yjGrtSqU6GzW0wBld2yWZOwmrwA5x8jWAc53l3xF5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MBBVhsmsmDX6Y6CXsF3OThh2pz5FBLidtwtpSQ85P1c=; b=SKPRryrS5C9Qw1qKCOw7sINVMC1G8khK1juYOL37/TzhBhLotgT9G1ehQLSBj3Gx4ULqLgUzbwpa/EuA782MwuUhA5qnLMyimRGO9e0FnTEyWOIJ083913V8v+cYM1cW+bfKmAPIVbjrV1Vhb8BVSD+svZIjH6pEDFpxs5b1ThsO5ECPgjiel7Kgr2LZOWG861sw3DkhVlps7Hnb6HxYQ+k4/6uaUIBaYmYkIl4WrSCSGQLa2XngFG7a3RJ1ouIMsN80CmMfpjBCVIpbM8ijbDMhhx7Z3h+25jW3EKUVtXUpIjyRh9fv6CphvxzfJkFi+EYkBcTWdHcCwvVAq62P5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MBBVhsmsmDX6Y6CXsF3OThh2pz5FBLidtwtpSQ85P1c=; b=YMPljZUdJWNxz0vYqYbPtXdyYWtTqAcG9KpZHx2b5vLagCYmpGwJ/orO9/41Ts9oky5L+bzj+gamJqGP426PF/eQ7GP0bg4eDS3WbrL+BmMDmHyNuFvJihgcAYpInxXK+t4b6zGKtaXtNodS22RE/Qy3O+4WCp27Q+O1O46iC/0= Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM (20.179.128.78) by LNXP123MB2265.GBRP123.PROD.OUTLOOK.COM (20.179.130.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Thu, 22 Aug 2019 08:22:52 +0000 Received: from LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3]) by LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM ([fe80::4fc:dcd0:dba3:89d3%5]) with mapi id 15.20.2178.020; Thu, 22 Aug 2019 08:22:52 +0000 From: To: Thread-Topic: Future of the MPTCP Working group Thread-Index: AdVYwMTUoaoE3I9qT8ua7nd7dbGaZQ== Date: Thu, 22 Aug 2019 08:22:52 +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: [217.33.61.67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ce58f1d-0294-4775-5f6e-08d726d9ecf8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:LNXP123MB2265; x-ms-traffictypediagnostic: LNXP123MB2265: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(199004)(189003)(256004)(606006)(7696005)(33656002)(66066001)(86362001)(8936002)(8676002)(81166006)(81156014)(14454004)(99286004)(66446008)(64756008)(66556008)(66476007)(966005)(66946007)(71190400001)(6916009)(476003)(486006)(53936002)(76116006)(3846002)(316002)(186003)(52536014)(7736002)(478600001)(14444005)(74316002)(236005)(5660300002)(25786009)(9686003)(790700001)(6116002)(55016002)(54896002)(6306002)(71200400001)(102836004)(6436002)(2906002)(26005)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2265; H:LNXP123MB2587.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: H7tCBAyf0IEoLIKkI0eqJy4bNDNpF80+4m3u+oQCVTNSR9fxWdzaWHc8OAWqioS8NIHWqLNjPXvNyCme1qaA1IAKXU6QjNiIohjMySlrZnAwvoGcDZJnWpZdWDcvNGaWZwnMoc+Ni6EJxuJkhGhbPZN5N3m8MwOgnVa/frixB/tD3AsIohLSGtOWStgYKZcpn/iZC4pVD6hRdk1Rf5j6QSSwOHU3uACZqU2ES8cTkS94BfyDv4kiDfLGr8f07XQq/VGGYfYHS4nHKznAc37ixlv8pNAho2Q2I+ey79+34PnfiYH5R2qEJv4OoELNbJU5L5MxRp4lovSWf1XXsxqNeTXrwRqljwAIipKNokTbbhVPiw8NAq4La++5PoP2Fy2zmBl04ZsBbP2+Q54SIi7LsbcCnqWwikNpLMyR1Ly03YM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB25873DB1982E6BCAF7E356CDEBA50LNXP123MB2587GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1ce58f1d-0294-4775-5f6e-08d726d9ecf8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 08:22:52.1103 (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-CrossTenant-userprincipalname: 7YnIiO6bSXKF+HPOyR87BYSlsBhm9TqaLx4Bhy7Tzh8AoU9uHLfQFMPGKha/769LxyYVBHPTmlbKEwKDMABtmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2265 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 2.1 X-NAI-Spam-Report: 5 Rules triggered * 2 -- TS_MSG_REP_30 * 0.1 -- THREAD_INDX_INVALD_VAL * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6617 X-NAI-Spam-Version: 2.2.0.9309 : core <6617> : inlines <7138> : streams <1830808> : uri <2887853> X-OriginatorOrg: bt.com Archived-At: Subject: [multipathtcp] Future of the MPTCP Working group 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, 22 Aug 2019 08:25:03 -0000 --_000_LNXP123MB25873DB1982E6BCAF7E356CDEBA50LNXP123MB2587GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For people not in the WG meeting in Montreal, and also after a couple of pr= ivate comments, we wanted to summarise our perspective about the future of = the working group. With the completion of the protocol bis, our (revised) charter is essential= ly complete. We've already published RFC 8041 (Use Cases and Operational Ex= perience with Multipath TCP), as well as RFC 7430 (Analysis of Residual Thr= eats and Possible Fixes for Multipath TCP (MPTCP)). The middlebox item turn= ed into the 0-RTT Converters work in tcpm (which is in WG last call). Excel= lent work! Having completed the charter, the options are to re-charter or close. Note = that closing the WG can be considered the default option. Re-chartering is = possible (subject to the usual approvals procedure), but needs an increase = on the current energy levels, in particular we would need a few topics - on= each of which a group of people want to contribute, in terms of design, im= plementation and review (as well as the usual consensus to do work). Note e= ven if the WG is closed, at least some MPTCP work could continue - for inst= ance, work that is a 'minor extension' of MPTCP, or its maintenance, could = be done in TCPM (under its current charter). As a data point, there are currently the following active individual drafts= : 1. Multipath TCP extension for Robust Session Establishment 2. Initial-Path Selection for Connection Establishment in Multipath T= CP 3. Privacy threats and possible countermeasures for Multipath-TCP (MP= TCP) 4. TFO support for Multipath TCP 5. 5G Session Continuity Support in MPTCP 6. Multipath TCP Inactivity Time Option 7. Multipath TCP Subflow Rate Limit Option 8. Extended Socket APIs to control subflow priority in Multipath TCP 9. One Way Latency Considerations for MPTCP 10. A Stochastic Optimal Scheduler for Multipath Transmission Control Pro= tocol (MPTCP) Also - again just as a data point - #3 has authors from multiple institutio= ns, as do #8 & #9, whilst #1 & #2 look to be addressing a similar problem (= I know the authors now plan to collaborate). In addition, we believe there = are several people interested in a more secure version of MPTCP (and expire= d individual drafts such as draft-bonaventure-mptcp-tls). So these might be= topics on which a group of people want to contribute, in terms of design, = implementation and review. For efforts to generate extra energy and collabo= ration, please make sure they're visible to us and on the mailing list, wel= l before the Singapore IETF. On a related point, there was a discussion in tsvarea about "Where to do mu= ltipath work in the IETF?" https://datatracker.ietf.org/meeting/105/materia= ls/minutes-105-tsvarea-00 which finished with Mirja saying "I think the com= munity needs to propose something here, please work on that if you're inter= ested and think you can scope it in a reasonable way." Best wishes, Phil and Yoshi --_000_LNXP123MB25873DB1982E6BCAF7E356CDEBA50LNXP123MB2587GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For people not in the WG meeting in Montreal, and also after a cou= ple of private comments, we wanted to summarise our perspective about the f= uture of the working group.

With the completion of the protocol bis, our (revised) charter is = essentially complete. We’ve already published RFC 8041 (Use Cases and= Operational Experience with Multipath TCP), as well as RFC 7430 (Analysis of Residual Threats and Possible Fixes for M= ultipath TCP (MPTCP)). The middlebox item turned into the 0-RTT Converters = work in tcpm (which is in WG last call). Excellent work!

Having completed the charter, the options are to re-charter or clo= se. Note that closing the WG can be considered the default option. Re-chart= ering is possible (subject to the usual approvals procedure), but needs an increase on the current energy levels, = in particular we would need a few topics - on each of which a group of peop= le want to contribute, in terms of design, implementation and review (as we= ll as the usual consensus to do work). Note even if the WG is closed, at least some MPTCP work could conti= nue – for instance, work that is a ‘minor extension’ of M= PTCP, or its maintenance, could be done in TCPM (under its current charter)= .

As a data point, there are currently the following active individu= al drafts:

1.       Multipath TCP extension for Robust Session Establis= hment

2.       Initial-Path Selection for Connection Establishment= in Multipath TCP

3.       Privacy threats and possible countermeasures for Mu= ltipath-TCP (MPTCP)

4.       TFO support for Multipath TCP

5.       5G Session Continuity Support in MPTCP

6.       Multipath TCP Inactivity Time Option

7.       Multipath TCP Subflow Rate Limit Option =

8.       Extended Socket APIs to control subflow priority in= Multipath TCP

9.       One Way Latency Considerations for MPTCP

10.   A Stochastic Optimal Scheduler for Multipath Transm= ission Control Protocol (MPTCP)

Also – again just as a data point - #3 has authors from mult= iple institutions, as do #8 & #9, whilst #1 & #2 look to be address= ing a similar problem (I know the authors now plan to collaborate). In addition, we believe there are several people interest= ed in a more secure version of MPTCP (and expired individual drafts such as= draft-bonaventure-mptcp-tls). So these might be topics on which a group of= people want to contribute, in terms of design, implementation and review. For efforts to generate extra energy= and collaboration, please make sure they’re visible to us and on the= mailing list, well before the Singapore IETF.

On a related point, there was a discussion in tsvarea about “= ;Where to do multipath work in the IETF?” https://datatracker.ietf.org/meeting/105/materials/minutes-105-tsvarea-00 which finished with Mirja saying “I think the community needs to p= ropose something here, please work on that if you're interested and think y= ou can scope it in a reasonable way.”

Best wishes,

Phil and Yoshi

--_000_LNXP123MB25873DB1982E6BCAF7E356CDEBA50LNXP123MB2587GBRP_-- From nobody Mon Aug 26 00:27:50 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 DBA0B1200FB for ; Mon, 26 Aug 2019 00:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zU1ZJxb6MkYz for ; Mon, 26 Aug 2019 00:27:47 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 C4B44120019 for ; Mon, 26 Aug 2019 00:27:46 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id z1so14229429wru.13 for ; Mon, 26 Aug 2019 00:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=abNLM/AN3jdB4s3FM6snfEoCGz21e3GL9wDILVWGo90=; b=Qcg+oXsuJRBvVwGJ7JJ601syvPJyBkWvNsGv1PHp0Qj4O+nRsCElhoMG9dQc4TK4ou 10aDht93AV75Xx/bJ1weZRuEbiijIX6fR9M6LbmyogJBWRDloJDF2YiaZ1vvtYY/REaM TkHKhofK/eD+fjJ8z3NzZSt7UkaJngnEVCud+UG89tj8ecIV9pPUaRKtliXfbx90DkOl /7BF5rHg5gRW+RjseKjT0+S/E7p/Kc36vrJ/DN2ImNbOvwzgxw644brJ2BRcJ0Hh+IKH 7XCeCLEFaXv98SAxWT9lD53j26Kp4aXDzEk6w8EKHGA+qqOymg6x2L14V2pzsJetBTZE p0PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=abNLM/AN3jdB4s3FM6snfEoCGz21e3GL9wDILVWGo90=; b=WMKPx/F1V+mgBJu59iCOIFbixWB+RqcuKE/W+X3TEDIFB93u8BqfHX3nlA1QdgcHBl 9XNP6hkZOOJ+790MQSc1EoG5hGoz9EOtC020lyhSfpwzKo0EZ2FXmzE5wajPe1IjFFbg 3m6Uu6WZyw7JSygb0O28Maz0ruMig3bpSkJ8w1eHnk+8556u2JXqE45gwnEpXsTIWAEI 0F3ZxtW0zY/4Zvz5Ct8X5Jo1kt4e9kJC/KYJGT5vPoPjAAfyGmhOGs9VZOpA9UVnLYI8 8SUkDhlzaL3TOiUyLaWLVkoqyrL2bjvIuvAUlJyxoLTRf0N+es2BdYWJ2bTO86ihCae2 WAKw== X-Gm-Message-State: APjAAAUyoLvjkrzgKETmLPYqwI1+yND86FtSviBgs5fSntPx41v43cCr xul+ndzhf6YnAIIygA1n1H33+hsYEHUZvkUuRpY= X-Google-Smtp-Source: APXvYqyWNDtilGV3aw2jK6yMJTcirfp7FTg/joEfxNKT/JVp7lBLQpj2+wuJWi3POcVOwSvnVX5cxFI10G4YY+mLBXE= X-Received: by 2002:adf:ce05:: with SMTP id p5mr20373364wrn.197.1566804465368; Mon, 26 Aug 2019 00:27:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 26 Aug 2019 00:27:34 -0700 Message-ID: To: philip.eardley@bt.com Cc: multipathtcp Content-Type: multipart/alternative; boundary="0000000000009742920591001707" Archived-At: Subject: Re: [multipathtcp] draft minutes for montreal meeting 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, 26 Aug 2019 07:27:49 -0000 --0000000000009742920591001707 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Phil, Thanks for the info. I have uploaded an updated version. -- Yoshi On Wed, Aug 21, 2019 at 4:20 AM wrote: > Yoshi, > > (about MPTCP + TLS) << Chairs: > > Anybody interested in helping Alan? > > (Note: someone was interested. but, cannot identify the name..) > > >> > > my notes say =E2=80=9CYoshi and presumably Olivier=E2=80=9D > > (about future of WG) > > << ???: > > +1 In the past, there was general interest in the active documents= . > > Some of the active individual drafts are relevant. > > >> > > My notes say Sri > > phil > > > > > > *From:* multipathtcp [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of > *Yoshifumi Nishida > *Sent:* 15 August 2019 21:40 > *To:* multipathtcp > *Subject:* [multipathtcp] draft minutes for montreal meeting > > > > > > Hi, > > Sorry for the delay. I uploaded a draft minutes for montreal meeting. > > You can take a look at the URL below. > > Please let the chairs know if you have corrections, suggestions or > questions. > > > > https://datatracker.ietf.org/doc/minutes-105-mptcp/ > > > > Thanks, > > -- > > Yoshi & Phil > --0000000000009742920591001707 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil,

Thanks for the info. I have uploaded an updated version.
--
Yoshi

Yoshi,

(about MPTCP + TLS) <<=C2=A0=C2=A0 Cha= irs:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Anybody= interested in helping Alan?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Note: = someone was interested. but, cannot identify the name..)

>>=C2=A0

my notes say =E2=80=9CYoshi and presumably O= livier=E2=80=9D

(about future of WG)

<< ???:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +1 In t= he past, there was general interest in the active documents.<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Some of= the active individual drafts are relevant.

>>=C2=A0

My notes say Sri

phil

=C2=A0

=C2=A0

From: multipathtcp [mailto:multipathtcp-bo= unces@ietf.org] On Behalf Of Yoshifumi Nishida
Sent: 15 August 2019 21:40
To: multipathtcp <multipathtcp@ietf.org>
Subject: [multipathtcp] draft minutes for montreal meeting=

=C2=A0

=C2=A0

Hi,

Sorry for the delay. I uploaded a draft=C2=A0minutes<= /span>=C2=A0for montreal meeting.=C2=A0

You can take a look at the URL below.<= /p>

Please let the chairs know if you have corrections, = suggestions or questions.

=C2=A0

=C2=A0

Thanks,

--

Yoshi & Phil

--0000000000009742920591001707-- From nobody Mon Aug 26 00:28:24 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 2137D1200FB for ; Mon, 26 Aug 2019 00:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IjQ9BmShOkQu for ; Mon, 26 Aug 2019 00:28:21 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 24EB6120019 for ; Mon, 26 Aug 2019 00:28:21 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id q12so14206879wrj.12 for ; Mon, 26 Aug 2019 00:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qzuktThGAvMIeERUcowe0/TLLLOGF1LIq780O1JZtqQ=; b=Z9MssZKStn5NYjWzZixPRj1Wq7f/FdhuoqCXnGZR6TSF9FDGjUGy5e9/8+wI4iHcNq hHLy6jpBN89lBWglEMHDYX6+jzBKU7jMUPXnceJ+RKJ3AZz2bXeaw2YlC1VCbqQh22fJ 9c6sDTiIoy0I+qJZbjYKQOmZ+GzVNSYsqgAEZCn/ZH2mFRkZX6OvMUPGa+SoTCup9vQp o03xusKlY08Wp6cWjtPJnGao6w3t0O1vW5kJd6NWE25xcX/q4p+eEFwqW2JWLztZlq+O TR8gRwaU4k0O1lUj4tzgo7c6l149V/to9j8HHaLzKMmWq6AVDwRfht2fLPPWUOQlzmNg YGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qzuktThGAvMIeERUcowe0/TLLLOGF1LIq780O1JZtqQ=; b=dwooFVV6C1h6mwcspBiyHpPH07eZWDVTud50IWlqXiOGLK8ntRM2Z/j0yG5a6A3iUi CxpmX2tjbIrQqUvJnZDWLnFZYGwZAibkwqJNB3aqENoWQ56IN8Sf6gyxqnGVv5XlKzIp WxEeZJGuD7bmh0KvGSv2VM68xXkGTHqLp8cB+b9M2JVAiilCI0LTGduMmv6xLidj9tNK DqPIWKeMHXDhB9Fdy5rIe+qS5kuge88y/n3IWdT4hzhU3GKTpriV+meeoOqjG/PlW6nI QS9pFXMqVTuG4MABcK1h/SM2ZJvTrgJ+26PNfz8JyZn167GRcQ2hWsFldwnqJc7yL9VH ikbw== X-Gm-Message-State: APjAAAWz1c2vVzI1tKQYJZXlxdbGgGRdGNG36JsJDNpruvdWVnBRrKF1 pAD/2q11mJuaQHtXlJl2ixaBjIuob2lmYIhZViFIkQ== X-Google-Smtp-Source: APXvYqwAUNPMjPG5eTgyj0c0JwMAhTbiY41Ch0Op4exdj7Mm62EevyM6gM3MPLIGchKHkfTK37EmjljefVJYV9zIzGs= X-Received: by 2002:adf:dbcd:: with SMTP id e13mr19688874wrj.314.1566804499759; Mon, 26 Aug 2019 00:28:19 -0700 (PDT) MIME-Version: 1.0 References: <008f46d7-dd99-3158-535e-91efe1acb2f7@uclouvain.be> In-Reply-To: <008f46d7-dd99-3158-535e-91efe1acb2f7@uclouvain.be> From: Yoshifumi Nishida Date: Mon, 26 Aug 2019 00:28:08 -0700 Message-ID: To: Olivier Bonaventure Cc: multipathtcp , Mathieu Jadin Content-Type: multipart/alternative; boundary="000000000000a40782059100195c" Archived-At: Subject: Re: [multipathtcp] draft minutes for montreal meeting 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, 26 Aug 2019 07:28:23 -0000 --000000000000a40782059100195c Content-Type: text/plain; charset="UTF-8" Hi Olivier, Thanks for the reply. On Wed, Aug 21, 2019 at 8:31 AM Olivier Bonaventure < olivier.bonaventure@uclouvain.be> wrote: > Yoshi, > > > Sorry for the delay. I uploaded a draft minutes for montreal meeting. > > You can take a look at the URL below. > > Please let the chairs know if you have corrections, suggestions or > > questions. > > > > https://datatracker.ietf.org/doc/minutes-105-mptcp/ > > Thanks for sharing these detailed minutes. I have some comments after > having read them. > > > > > Keith Moore: > > Is there support in the room for working on a secure (encrypted) > version > > of MPTCP? > > > > Chairs: > > Show of hands: How many would be willing to work on an encrypted > version. > > We proposed such a design in an infocom paper, see > > https://inl.info.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html > There was running code on Linux but we have not maintained it since > publication. > Thanks for the pointer. I think this is an interesting approach. As far as I know this has not been presented at the WG yet, not written in an I-D. Am I correct? > > > Mirja (as individual): > > If you want encryption, use QUIC. > > > > Chairs: > > Would work on be a bad idea? > > (a couple) and why? > > > > Nicolas P: > > I think it's too heavy. Would require encryption of options. > > > Yoshi: > > TCPINC was oribinally intended to be used for MPTCP. But, it does > not > > encrypt options. Do we want to create an updated version? > > > > Mirja: > > There is zero deployment of TCPINC. I would suggest to first get > > deployment experience. > > If people want to experiment with our implementation, this should be > possible. My personal viewpoint is that adding full security to MPTCP is > probably too difficult at this stage if the objective is to have a > deployable solution. > Thanks for the inputs. Just to be clear, is this approach to extend ENO as described in the infocomm paper? -- Yoshi --000000000000a40782059100195c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Olivier,

Thanks for the r= eply.

On Wed, Aug 21, 2019 at 8:31 AM Olivier Bonaventure <olivier.bonaventure= @uclouvain.be> wrote:
Yoshi,

> Sorry for the delay. I uploaded a draft minutes=C2=A0for montreal meet= ing.
> You can take a look at the URL below.
> Please let the chairs know if you have corrections, suggestions or > questions.
>
> https://datatracker.ietf.org/doc/minutes-105= -mptcp/

Thanks for sharing these detailed minutes. I have some comments after
having read them.=C2=A0


>
>=C2=A0 =C2=A0 Keith Moore:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is there support in the room for working on= a secure (encrypted) version
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 of MPTCP?
>
>=C2=A0 =C2=A0 Chairs:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Show of hands: How many would be willing to= work on an encrypted version.

We proposed such a design in an infocom paper, see
https://inl.in= fo.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html
There was running code on Linux but we have not maintained it since
publication.

As far as I know this has = not been presented at the WG yet, not written in an I-D. Am I correct?

>
>=C2=A0 =C2=A0 Mirja (as individual):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you want encryption, use QUIC.
>
>=C2=A0 =C2=A0 Chairs:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Would work on be a bad idea?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a couple) and why?
>
>=C2=A0 =C2=A0 Nicolas P:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think it's too heavy. Would require e= ncryption of options. >
>=C2=A0 =C2=A0 Yoshi:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TCPINC was oribinally intended to be used f= or MPTCP. But, it does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 encrypt options. Do we want to create an up= dated version?
>
>=C2=A0 =C2=A0 Mirja:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 There is zero deployment of TCPINC. I would= suggest to first get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 deployment experience.

If people want to experiment with our implementation, this should be
possible. My personal viewpoint is that adding full security to MPTCP is probably too difficult at this stage if the objective is to have a
deployable solution.

Thanks for the inp= uts.
Just to be clear, is this approach to extend ENO as describe= d in the infocomm paper?
--
Yoshi
--000000000000a40782059100195c-- From nobody Mon Aug 26 00:31:38 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 67075120019 for ; Mon, 26 Aug 2019 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1d9RqIV809_A for ; Mon, 26 Aug 2019 00:31:33 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 F1BB71200FB for ; Mon, 26 Aug 2019 00:31:32 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id g17so14279645wrr.5 for ; Mon, 26 Aug 2019 00:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9i/ZN1LrJJLaOjWxfAyre+Y4mOKY+qazObjtw0LzDY=; b=ccl789CXXXwRVxUzpqquEhTRxl3DsoyEeto78RKR1J8zIS7kD3tWMn5xvsm0PBAlZq uTH+A6mkj2x+IBMsvSt/iZIHINJ3iMmjvzWIRaQAolLq7CC/TixMMUPQewF7eNqinpgP zU9c4GO3WdyHEy+lXt6FRZ9KZC0Mq62uAKnqWg4i3bP+kXnDc7nln4JYFEAMsJH6hz45 SkitzBFqN5U3AHIngrk3MGXV0GGvSTWt/v4vetB/TiXOZPI0zMGFguSfN6LlN6vrATsh crUThmi6sLyNIVubPFOxIQ3K2RXt5tFegIRCr54RqbkfBLYzmqzQr9mBefVVI8aU0ACJ rAZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9i/ZN1LrJJLaOjWxfAyre+Y4mOKY+qazObjtw0LzDY=; b=NrQfk37ztOzEBgEk/gCm+BMS5JtJfvwXTJFkPOuWBZG/Z7Qwho4seQe9WEoyGkXATN VVzMdtzp0EipNz6LCpYYWAPDxuAs0bGdRxK6fEVtqJtqFih8fbGRz31OoWKXhTnLD9jm KCGKgQcGYb/yvpVGAl0rceI1aEbqqKMF2HGJ6qIALrmvZbGm/ZYPULfuJfe0QEYn5Sk2 RFySkopBd00VCZ8gOGhYZfNRylwdvRTQaguahBO3lFFTcvc1Hconwrko67O738CJjsA6 X5rlKvVQ8+80BCguH+tNBABbi4+C0wKunjUTrDSii9WEB5MA5nOo8+xWR0b7ssGSCiWS 8bUQ== X-Gm-Message-State: APjAAAUAShVkUk8e+LfLYjXbFJAmQNFpebWX850psqySHfFDMdAVmuFz 7gBO0SY4ppMaKIWsqbLPwHeDvIorfmDhhTvAzR6O2A== X-Google-Smtp-Source: APXvYqzfAvTZpO+qnEBuk9BsvF+2wfr56r7o+rvHhI/5/8hkYgwW++hKOJ/POTKUWWQ8BJQZIpsWIOwE2zDXscmTX2Q= X-Received: by 2002:adf:d08e:: with SMTP id y14mr20123602wrh.309.1566804691556; Mon, 26 Aug 2019 00:31:31 -0700 (PDT) MIME-Version: 1.0 References: <192f0914-3f3a-9a76-71ec-059bf159d14c@uclouvain.be> <20190821162948.GP5994@MacBook-Pro-64.local> In-Reply-To: <20190821162948.GP5994@MacBook-Pro-64.local> From: Yoshifumi Nishida Date: Mon, 26 Aug 2019 00:31:20 -0700 Message-ID: To: Christoph Paasch Cc: Olivier Bonaventure , multipathtcp Content-Type: multipart/alternative; boundary="000000000000129cf705910025ce" Archived-At: Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00 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, 26 Aug 2019 07:31:36 -0000 --000000000000129cf705910025ce Content-Type: text/plain; charset="UTF-8" Hi Christoph, On Wed, Aug 21, 2019 at 9:30 AM Christoph Paasch wrote: > Hello, > > jumping in on this thread a bit late. Please see inline: > > On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote: > > Hi Olivier, > > > > On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure < > > olivier.bonaventure@uclouvain.be> wrote: > > > > > Yoshi, > > > > > > > > 3: I am still not very sure the usage of SRL options for > graceful > > > > > subflow closing. I might want to see some texts in the draft > to > > > > > understand how this can be better than FIN exchange on > subflows. > > > > > > > > When a client sends a FIN, it indicates that it will not send > data > > > > anymore on this subflow. When it sends a SRL option with 0, it > > > > indicates > > > > to the server that it does not want to receive anymore data on > this > > > > subflow. We can provide some text if we agree on this use case. > > > > > > > > Right. I can image the following 3 situations on the client side. > > > > > > > > 1: client doesn't need to receive any more packets from server > > > > 2: client doesn't want sender to send more data, but wants to receive > > > > data on the fly. > > > > 3: client wants to close the connection when sender finishes sending > data > > > > > > > > I think RST will work for 1: and we can use FIN for 3 > So, in my > > > understanding, this approach tries to address 2:. > > > > I just would like to understand how much this kind of situations > happen. > > > > > > Consider a video or audio streaming application running on a > smartphone. > > > Smartphone has WiFi and cellular but user wants to limit use of > cellular > > > and force server to use low quality when streaming over cellular. > > > When smartphone is attached to both WiFi and cellular, it can send SRL > > > with a bandwidth of 0 over cellular. > > Here, it would be nice to be able to close the cellular subflow. The reason > is the following: If we are not sending any packets on that cellular > subflow > (because we set the SRL to 0), after some time the subflow will become > dis-functional because the NAT/Firewall-mapping has expired. > > So, keeping subflows at 0 for an extended period will cause trouble. > I think it's ok for an implementation to close the subflow here if they prefer. But, I am not sure if we need to standardize this behavior. I think if the client really wants not to use cellular, it can just close the subflow by itself. I am guessing sending SRL 0 could mean something more. For example, the client wants to use the cellular for sending as it will send very small amount, but not for receiving due to the volume of data, or the client wants to stop using the cellular for a certain amount of time. In the latter case, the client will need to send keep-alive at a certain period to avoid NAT timeout, though. Thanks, -- Yoshi --000000000000129cf705910025ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christoph,

On Wed, Aug 21, 2019 at 9:30 AM Christop= h Paasch <cpaasch= @apple.com> wrote:
Hello,

jumping in on this thread a bit late. Please see inline:

On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote:
> Hi Olivier,
>
> On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure <
> = olivier.bonaventure@uclouvain.be> wrote:
>
> > Yoshi,
> >
> > >=C2=A0 =C2=A0 =C2=A0 > 3: I am still not very sure the usa= ge of SRL options for graceful
> > >=C2=A0 =C2=A0 =C2=A0 > subflow closing. I might want to se= e some texts in the draft to
> > >=C2=A0 =C2=A0 =C2=A0 > understand how this can be better t= han FIN exchange on subflows.
> > >
> > >=C2=A0 =C2=A0 =C2=A0When a client sends a FIN, it indicates t= hat it will not send data
> > >=C2=A0 =C2=A0 =C2=A0anymore on this subflow. When it sends a = SRL option with 0, it
> > >=C2=A0 =C2=A0 =C2=A0indicates
> > >=C2=A0 =C2=A0 =C2=A0to the server that it does not want to re= ceive anymore data on this
> > >=C2=A0 =C2=A0 =C2=A0subflow. We can provide some text if we a= gree on this use case.
> > >
> > > Right. I can image the following 3 situations on the client = side.
> > >
> > > 1: client doesn't need to receive any more packets from = server
> > > 2: client doesn't want sender to send more data, but wan= ts to receive
> > > data on the fly.
> > > 3: client wants to close the connection when sender finishes= sending data
> > >
> > > I think RST will work for 1: and we can use FIN for 3 > S= o, in my
> > understanding, this approach tries to address 2:.
> > > I just would like to understand how much this kind of situat= ions happen.
> >
> > Consider a video or audio streaming application running on a smar= tphone.
> > Smartphone has WiFi and cellular but user wants to limit use of c= ellular
> > and force server to use low quality when streaming over cellular.=
> > When smartphone is attached to both WiFi and cellular, it can sen= d SRL
> > with a bandwidth of 0 over cellular.

Here, it would be nice to be able to close the cellular subflow. The reason=
is the following: If we are not sending any packets on that cellular subflo= w
(because we set the SRL to 0), after some time the subflow will become
dis-functional because the NAT/Firewall-mapping has expired.

So, keeping subflows at 0 for an extended period will cause trouble.

I think it's ok for an implementation to = close the subflow here if they prefer.
But, I am not sure if we n= eed to standardize this behavior.

I think if the c= lient really wants not to use cellular, it can just close the subflow by it= self.
I am guessing sending SRL 0 could mean something more. For = example, the client wants to use the cellular for sending as it will send v= ery small amount, but not for receiving due to the volume of data, or the c= lient wants to stop using the cellular for a certain amount of time.=C2=A0 = In the latter case, the client will need to send keep-alive at a certain pe= riod to avoid NAT timeout, though.

Thanks,
--
Yoshi
--000000000000129cf705910025ce-- From nobody Mon Aug 26 10:31:29 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 04B3F120842 for ; Mon, 26 Aug 2019 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZBe8syyRY3K for ; Mon, 26 Aug 2019 10:31:25 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 C751712008B for ; Mon, 26 Aug 2019 10:31:25 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7QHRBbG043483; Mon, 26 Aug 2019 10:31:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=M0x5U0sDZEXEHMhEw3tiK+/da79+cMVyMCNmRHZdRz8=; b=RAghKyqipLA/5yyBeAciuZfOp7a1+K5qOCG11vOObA5tmB8P6+Cm/ZkFbkjXoNqtCYPu 1EM4DZz4jTjOWsxIvgGfWU+mp7sjTobtCJ/GZ/9SnqJeX8Xq+QhX7g+wb5fh3deS+K66 6rdHBe1wUGH01si7MLuTNbAMmCdZnBivohNbp6PbAoOv67sLBclzidhmnUC6o3oBlMbw 5suwptxXVCFDI2YZIL2uJOYxUSCB7FBctuKWYvCoWetYtMDfqUoepVWZ9L3A45jYZzgo kGURFfFRp7ojcbeIaeIKVJgGYBH2WF0VSe2QBFTwcNYmSGvJvI0oP/WuS5mCCIAXa0fs 2Q== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2uknfmth63-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 26 Aug 2019 10:31:24 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWU00BKQU0B42A0@mr2-mtap-s01.rno.apple.com>; Mon, 26 Aug 2019 10:31:23 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWU00300TPUHL00@nwk-mmpp-sz10.apple.com>; Mon, 26 Aug 2019 10:31:23 -0700 (PDT) X-Va-A: X-Va-T-CD: 772dd47e94105b6916a0f4f153438e87 X-Va-E-CD: aaf9a206e6a9da61f8e3973146981c7c X-Va-R-CD: cac8f984c4dc83592c78d697d9fa2dd0 X-Va-CD: 0 X-Va-ID: 3343786c-a28c-4b93-9bb2-1bf27c4374b9 X-V-A: X-V-T-CD: 772dd47e94105b6916a0f4f153438e87 X-V-E-CD: aaf9a206e6a9da61f8e3973146981c7c X-V-R-CD: cac8f984c4dc83592c78d697d9fa2dd0 X-V-CD: 0 X-V-ID: bbc518bf-621b-44ff-89b8-6391ff6a5081 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-26_08:,, signatures=0 Received: from localhost ([17.192.155.217]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWU001IGTZR8A10@nwk-mmpp-sz10.apple.com>; Mon, 26 Aug 2019 10:31:03 -0700 (PDT) Sender: cpaasch@apple.com Date: Mon, 26 Aug 2019 10:31:03 -0700 From: Christoph Paasch To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp Message-id: <20190826173103.GO5994@MacBook-Pro-64.local> References: <192f0914-3f3a-9a76-71ec-059bf159d14c@uclouvain.be> <20190821162948.GP5994@MacBook-Pro-64.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.11.4 (2019-03-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-26_08:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00 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, 26 Aug 2019 17:31:28 -0000 Hello Yoshi, On 26/08/19 - 00:31:20, Yoshifumi Nishida wrote: > Hi Christoph, > > On Wed, Aug 21, 2019 at 9:30 AM Christoph Paasch wrote: > > > Hello, > > > > jumping in on this thread a bit late. Please see inline: > > > > On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote: > > > Hi Olivier, > > > > > > On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure < > > > olivier.bonaventure@uclouvain.be> wrote: > > > > > > > Yoshi, > > > > > > > > > > 3: I am still not very sure the usage of SRL options for > > graceful > > > > > > subflow closing. I might want to see some texts in the draft > > to > > > > > > understand how this can be better than FIN exchange on > > subflows. > > > > > > > > > > When a client sends a FIN, it indicates that it will not send > > data > > > > > anymore on this subflow. When it sends a SRL option with 0, it > > > > > indicates > > > > > to the server that it does not want to receive anymore data on > > this > > > > > subflow. We can provide some text if we agree on this use case. > > > > > > > > > > Right. I can image the following 3 situations on the client side. > > > > > > > > > > 1: client doesn't need to receive any more packets from server > > > > > 2: client doesn't want sender to send more data, but wants to receive > > > > > data on the fly. > > > > > 3: client wants to close the connection when sender finishes sending > > data > > > > > > > > > > I think RST will work for 1: and we can use FIN for 3 > So, in my > > > > understanding, this approach tries to address 2:. > > > > > I just would like to understand how much this kind of situations > > happen. > > > > > > > > Consider a video or audio streaming application running on a > > smartphone. > > > > Smartphone has WiFi and cellular but user wants to limit use of > > cellular > > > > and force server to use low quality when streaming over cellular. > > > > When smartphone is attached to both WiFi and cellular, it can send SRL > > > > with a bandwidth of 0 over cellular. > > > > Here, it would be nice to be able to close the cellular subflow. The reason > > is the following: If we are not sending any packets on that cellular > > subflow > > (because we set the SRL to 0), after some time the subflow will become > > dis-functional because the NAT/Firewall-mapping has expired. > > > > So, keeping subflows at 0 for an extended period will cause trouble. > > > > I think it's ok for an implementation to close the subflow here if they > prefer. > But, I am not sure if we need to standardize this behavior. > > I think if the client really wants not to use cellular, it can just close > the subflow by itself. The problem is that the client can only do half-closed subflow by sending a FIN. The way one would do this is: Set SRL to 0. Wait for quite a bit until the subflow "calmed down". Send a FIN and see that the sequence-number in the corresponding ACK of the peer is the same as the rcv_nxt [1]. This indicates that the peer stopped sending. Now, the client can close the subflow with a RST. [1] If that's not the case, it means the peer hasn't reached SRL-0 yet. Now the client can just wait and eventually kill the flow with a RST and hope that no data-in-flight is being lost that way. > I am guessing sending SRL 0 could mean something more. For example, the > client wants to use the cellular for sending as it will send very small > amount, but not for receiving due to the volume of data, or the client > wants to stop using the cellular for a certain amount of time. In the > latter case, the client will need to send keep-alive at a certain period to > avoid NAT timeout, though. Agreed - that is the main use-case of SRL 0. What is missing for my use-case is a way for the client to tell the server to gracefully close the subflow. The reason for that can simply be because WiFi has improved again and cell isn't needed anymore. The current way to signal that is by killing the subflow with a RST which results in loss of the in-flight-data. That loss degrades the overall connection-quality as the data needs to be retransmitted over WiFi again. Using SRL-0 is a half-baked way to get there. It allows to "calm down" the subflow but isn't yet 100% safe as the client never knows when the server actually reached the 0-rate. Ideally, if we could use one of the reserved bits of the SRL-option for that it would achieve the same goal. Cheers, Christoph