Re: [multipathtcp] (2) Regarding rate control at a subflow level
Nagesh shamnur <nagesh.shamnur@huawei.com> Mon, 20 May 2019 09:19 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 EA1B01200D7 for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 02:19:21 -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 g9tKnty1pQWr for <multipathtcp@ietfa.amsl.com>; Mon, 20 May 2019 02:19:19 -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 0E564120020 for <multipathtcp@ietf.org>; Mon, 20 May 2019 02:19:19 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 61FDF907BDBF5CACC756; Mon, 20 May 2019 10:19:17 +0100 (IST)
Received: from DGGEMA421-HUB.china.huawei.com (10.1.198.154) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 May 2019 10:19:16 +0100
Received: from DGGEMA524-MBX.china.huawei.com ([169.254.7.203]) by dggema421-hub.china.huawei.com ([10.1.198.154]) with mapi id 14.03.0415.000; Mon, 20 May 2019 17:19:01 +0800
From: Nagesh shamnur <nagesh.shamnur@huawei.com>
To: "madhan.raj@samsung.com" <madhan.raj@samsung.com>
CC: Alexander Frömmgen <Alexander@froemmgen.de>, Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>, Ashutosh prakash <ashutosh.prakash@huawei.com>
Thread-Topic: RE:(2) [multipathtcp] Regarding rate control at a subflow level
Thread-Index: AdUMWULM15YYbMauQ2OybE7pkHW5IQAPgMiAADT36AAASbErAAAWfYcQ
Date: Mon, 20 May 2019 09:19:00 +0000
Message-ID: <4AC96705FB868F42B2075BA50F806DEB569AD36F@dggema524-mbx.china.huawei.com>
References: <AF0CC935-D114-45DC-868B-7A677892A17B@froemmgen.de> <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <CGME20190518191703epcas1p24eaa19af192057d9f2808cbd49fa7aab@epcms5p1> <20190520062634epcms5p1578632bf8a791eefe970bb7678e96625@epcms5p1>
In-Reply-To: <20190520062634epcms5p1578632bf8a791eefe970bb7678e96625@epcms5p1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.156.80]
Content-Type: multipart/related; boundary="_004_4AC96705FB868F42B2075BA50F806DEB569AD36Fdggema524mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Q_ods4PiTx20Izz4oaTTwxR_t58>
Subject: Re: [multipathtcp] (2) 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:19:22 -0000
From: Madhan Raj Kanagarathinam [mailto:madhan.raj@samsung.com] Sent: 20 May 2019 11:57 To: Nagesh shamnur <nagesh.shamnur@huawei.com> Cc: Alexander Frömmgen <Alexander@froemmgen.de>; Olivier Bonaventure <olivier.bonaventure@uclouvain.be>; multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com> Subject: RE:(2) [multipathtcp] Regarding rate control at a subflow level Dear Nagesh, 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. >> There are quite some research going on SBR and related areas. But if there has to options exchanged (or control), it has to be secured to protect from mangling. Another challenge is that estimating the bandwidth and frequent changing might also be overhead in wireless. In my research work, to control the same, we throttle the UE RTT by introducing additional delay and controlling the path manager. There are few methods of ACK throttling as well which might help the same. So I would suggest indirect control instead of direct option exchanged. Madhan, Thanks for taking note of the problem. Using control channel was one of the alternative which I thought and I agree it might not be the best one. But the issue is genuine and needs to be addressed. Regarding the protecting the header from maligning, it is true for any other as well which is part of MPTCP right? Any indirect control IMO would still be a patchy solution rather than directly addressing the problem, right? Regards, Madhan --------- Original Message --------- Sender : Alexander Frömmgen <Alexander@froemmgen.de<mailto:Alexander@froemmgen.de>> Date : 2019-05-19 00:47 (GMT+5:30) Title : 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. 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 _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org<mailto:multipathtcp@ietf.org> https://www.ietf.org/mailman/listinfo/multipathtcp [cid:image001.gif@01D50F1A.69955BA0] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNTIwMDYyNjM0ZXBjbXM1cDE1Nzg2MzJiZjhhNzkxZWVmZTk3MGJiNzY3OGU5NjYyNSZyZWNpcGllbnRBZGRyZXNzPW5hZ2VzaC5zaGFtbnVyQGh1YXdlaS5jb20_]
- [multipathtcp] Regarding rate control at a subflo… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Olivier Bonaventure
- Re: [multipathtcp] Regarding rate control at a su… Alexander Frömmgen
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Christoph Paasch
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (2) Regarding rate control at … philip.eardley
- Re: [multipathtcp] (4) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… Gregory Detal
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] (4) Regarding rate control at … philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] Regarding rate control at a su… Olivier Bonaventure
- Re: [multipathtcp] (2) Regarding rate control at … Madhan Raj Kanagarathinam
- Re: [multipathtcp] Regarding rate control at a su… philip.eardley
- Re: [multipathtcp] Regarding rate control at a su… Nagesh shamnur
- Re: [multipathtcp] (4) Regarding rate control at … philip.eardley
- Re: [multipathtcp] (2) (4) Regarding rate control… Madhan Raj Kanagarathinam