Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10
Nagesh shamnur <nagesh.shamnur@huawei.com> Fri, 12 July 2019 13:14 UTC
Return-Path: <nagesh.shamnur@huawei.com>
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 E1ED01200C5 for <multipathtcp@ietfa.amsl.com>; Fri, 12 Jul 2019 06:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8B-tzHKhGQoj for <multipathtcp@ietfa.amsl.com>; Fri, 12 Jul 2019 06:14:50 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C8A1C120045 for <multipathtcp@ietf.org>; Fri, 12 Jul 2019 06:14:49 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 303CD90F7396EDC2A31C for <multipathtcp@ietf.org>; Fri, 12 Jul 2019 14:14:47 +0100 (IST)
Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 14:14:46 +0100
Received: from dggeme761-chm.china.huawei.com (10.3.19.107) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 12 Jul 2019 21:14:44 +0800
Received: from dggeme761-chm.china.huawei.com ([10.6.66.35]) by dggeme761-chm.china.huawei.com ([10.6.66.35]) with mapi id 15.01.1591.008; Fri, 12 Jul 2019 21:14:44 +0800
From: Nagesh shamnur <nagesh.shamnur@huawei.com>
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: multipathtcp Digest, Vol 125, Issue 10
Thread-Index: AQHVOKekdmqLj3wk7U6pOv8FBDy0NabG8QQg
Date: Fri, 12 Jul 2019 13:14:44 +0000
Message-ID: <2c70c4c508744700b19379179f5ecea0@huawei.com>
References: <mailman.1484.1562932056.8637.multipathtcp@ietf.org>
In-Reply-To: <mailman.1484.1562932056.8637.multipathtcp@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.156.80]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/LHAWrNKia9P64g4BUVFXrXOZkv0>
Subject: Re: [multipathtcp] multipathtcp Digest, Vol 125, Issue 10
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 13:14:53 -0000
Hi Med, I have a question regarding this point " to use a given subflow only where there is a need to grab more resources (that is, don?t use this subflow if data can be placed on other subflows)." MP_PRIO option with 'b' bit can be used to achieve the same, then why need new option? Regards, Nagesh S -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of multipathtcp-request@ietf.org Sent: 12 July 2019 17:18 To: multipathtcp@ietf.org Subject: multipathtcp Digest, Vol 125, Issue 10 Send multipathtcp mailing list submissions to multipathtcp@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/multipathtcp or, via email, send a message with subject or body 'help' to multipathtcp-request@ietf.org You can reach the person managing the list at multipathtcp-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of multipathtcp digest..." Today's Topics: 1. Re: Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt (mohamed.boucadair@orange.com) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Jul 2019 11:47:28 +0000 From: <mohamed.boucadair@orange.com> To: Viet Hoang Tran <hoang.tran@uclouvain.be>, multipathtcp <multipathtcp@ietf.org> Subject: Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt Message-ID: <787AE7BB302AE849A7480A190F8B93302EACB063@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="utf-8" Hi Hoang, all, Thank you for igniting this work. FWIW, we used to have this requirement in draft-nam-mptcp-deployment-considerations (with cellular networks in mind): ?For cases where some access networks are subject to a volume quota, it is desirable to support a signal to indicate to a remote peer how it must place data into available subflows?. The rate-limit option as currently defined may not be adequate. I would like an option which allows to tell a remote peer, for example: ? to use a given subflow only where there is a need to grab more resources (that is, don?t use this subflow if data can be placed on other subflows). ? ?here is my suggested inbound traffic distribution ratio among established subflows?. ? ?here is the maximum data that can be placed in a given subflow?. Did you consider those schemes? Cheers, Med --------- Original Message --------- Sender : Viet Hoang Tran <hoang.tran@uclouvain.be> Date : 2019-07-09 14:35 (GMT+5:30) Title : [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt We submitted two drafts on Subflow Rate Limit Option and Inactivity Time Option (https://tools.ietf.org/html/draft-hoang-mptcp-inactivity-time-00) Feedbacks and suggestions are more than welcomed. Thanks, Hoang & Olivier ________________________________________ From: internet-drafts@ietf.org <internet-drafts@ietf.org> Sent: Monday, 8 July 2019 16:28 To: Viet Hoang Tran; Olivier Bonaventure; Olivier Bonaventure Subject: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt A new version of I-D, draft-hoang-mptcp-sub-rate-limit-00.txt has been successfully submitted by Viet-Hoang Tran and posted to the IETF repository. Name: draft-hoang-mptcp-sub-rate-limit Revision: 00 Title: Multipath TCP Subflow Rate Limit Option Document date: 2019-07-08 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-hoang-mptcp-sub-rate-limit-00.txt Status: https://datatracker.ietf.org/doc/draft-hoang-mptcp-sub-rate-limit/ Htmlized: https://tools.ietf.org/html/draft-hoang-mptcp-sub-rate-limit-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoang-mptcp-sub-rate-limit Abstract: This document defines a new MPTCP Option that enables hosts to request their peers to limit the maximum transfer rate on a per- subflow basis. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp [cid:image001.png@01D538B4.F419FBF0] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNzA5MTY0MDM2ZXBjbXM1cDQ3YzY2MzJiNTM3MmQ0MDliYjI2YTMwMGNlYTMzYmUzZSZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__] -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/20190712/1e2caade/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: image001.png URL: <https://mailarchive.ietf.org/arch/browse/multipathtcp/attachments/20190712/1e2caade/attachment.png> ------------------------------ Subject: Digest Footer _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp ------------------------------ End of multipathtcp Digest, Vol 125, Issue 10 *********************************************
- Re: [multipathtcp] multipathtcp Digest, Vol 125, … Nagesh shamnur
- Re: [multipathtcp] multipathtcp Digest, Vol 125, … mohamed.boucadair