IETF Logo Mail Archive

Re: [multipathtcp] Regarding rate control at a subflow level

Nagesh shamnur <nagesh.shamnur@huawei.com> Mon, 20 May 2019 09:10 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 86808120106 for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 02:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SL21xljq7AK4 for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 02:10:54 -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 D9C37120041 for <multipathtcp@ietf.org>; Mon, 20 May 2019 02:10:53 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 10AF82F1C48ECEFCEF96; Mon, 20 May 2019 10:10:52 +0100 (IST)
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 May 2019 10:10:43 +0100
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 20 May 2019 10:10:43 +0100
Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 20 May 2019 10:10:42 +0100
Received: from DGGEMA524-MBX.china.huawei.com ([169.254.7.203]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0415.000; Mon, 20 May 2019 17:10:33 +0800
From: Nagesh shamnur <nagesh.shamnur@huawei.com>
To: Alexander Frömmgen <Alexander@froemmgen.de>, Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
CC: Ashutosh prakash <ashutosh.prakash@huawei.com>
Thread-Topic: [multipathtcp] Regarding rate control at a subflow level
Thread-Index: AdUMWULM15YYbMauQ2OybE7pkHW5IQAPgMiAADT36AAAYCNzwA==
Date: Mon, 20 May 2019 09:10:32 +0000
Message-ID: <4AC96705FB868F42B2075BA50F806DEB569AD35D@dggema524-mbx.china.huawei.com>
References: <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de>
In-Reply-To: <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de>
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: multipart/alternative; boundary="_000_4AC96705FB868F42B2075BA50F806DEB569AD35Ddggema524mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Cw4n37IzmbzeDPuhlDHWpp74ybk>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level
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: Mon, 20 May 2019 09:10:56 -0000

From: Alexander Frömmgen [mailto:Alexander@froemmgen.de]
Sent: 19 May 2019 00:47
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>; Nagesh shamnur <nagesh.shamnur@huawei.com>; multipathtcp@ietf.org
Cc: Ashutosh prakash <ashutosh.prakash@huawei.com>
Subject: Re: [multipathtcp] Regarding rate control at a subflow level

Hi,

We experimented with different schedulers that implement related behaviour, e.g., to only use cellular data if a target throughput can't be provided otherwise and only transfer the fraction of data on the cellular path that is required to achieve the target throughput (which is effectively a kind of dynamic rate limiting). See https://progmp.net for further information.
                Sure, thanks for the update. Will look into it.

Best,

Alexander
Am 17. Mai 2019 11:59:54 MESZ schrieb Olivier Bonaventure <olivier.bonaventure@uclouvain.be<mailto:olivier.bonaventure@uclouvain.be>>:

Dear Nagesh,

                 Greetings. In case of Mobile deployments of MPTCP,
though the data rates are getting cheaper, still it would be wise not to
run the cellular path to full limit but to throttle to a certain extent
considering cost in mind or if server wants to limit the client at
subflow level, then I couldn’t find the support for the same in the
specification.

We have developed several prototypes that include this capability in the
Linux kernel.

So, while going through the discussion archives, could
only find that, the peer(server) can throttle the speed for the entire
connection by publishing a smaller receiver window rather than for a
particular subflow. I feel, it would be a good idea if the peers can
exchange this information using the control packets.

We could imagine an MPTCP option that provides the maximum rate on a
per-subflow level, but I was wondering whether the use case is not to
limit the bandwidth on the smartphone at the link level (i.e. multiple
tcp connections or udp flows) and not at the subflow level. Could you
precise your use case for the subflow level ?

Thanks


Olivier

________________________________

multipathtcp mailing list
multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
https://www.ietf.org/mailman/listinfo/multipathtcp

v2.23.0 | Report a Bug | By Email