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

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Fri, 31 May 2019 09:18 UTC

Return-Path: <madhan.raj@samsung.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 CAD84120052 for <multipathtcp@ietfa.amsl.com>; Fri, 31 May 2019 02:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.287
X-Spam-Level:
X-Spam-Status: No, score=-6.287 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samsung.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 vqLzDGkDfz72 for <multipathtcp@ietfa.amsl.com>; Fri, 31 May 2019 02:18:54 -0700 (PDT)
Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739A11200EC for <multipathtcp@ietf.org>; Fri, 31 May 2019 02:18:53 -0700 (PDT)
Received: from epcas5p3.samsung.com (unknown [182.195.41.41]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20190531091850epoutp04adf55e547bb172c4f0253167ad620e5c~jue6vsTKe0916509165epoutp04C for <multipathtcp@ietf.org>; Fri, 31 May 2019 09:18:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20190531091850epoutp04adf55e547bb172c4f0253167ad620e5c~jue6vsTKe0916509165epoutp04C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1559294330; bh=ravMkAmWHMPOeSLeRLFqeIq8Ostyzo5UJ1MjVatkjXk=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=aTdytiQgQgAxBC3vBz7cDPjlv2ghY4Y0Aflg7PRCEj/FRr3xpECJdVylU5PeAtt2Y tdhstsIx6xKqeDAwedZmxm1/DpBccLo7vkObJsxRX/Vhr1gV7GuyEUTOGC/PqHfJ0p AburrX9KdKroeCyfGtBw7wmP/kzYdgtNfETh8v0Y=
Received: from epsmges5p3new.samsung.com (unknown [182.195.42.75]) by epcas5p4.samsung.com (KnoxPortal) with ESMTP id 20190531091850epcas5p421f606069526d57dd566abe385b6b440~jue6NHAA21570315703epcas5p4L; Fri, 31 May 2019 09:18:50 +0000 (GMT)
X-AuditID: b6c32a4b-78bff70000000fe3-b8-5cf0f17a08c5
Received: from epcas5p3.samsung.com ( [182.195.41.41]) by epsmges5p3new.samsung.com (Symantec Messaging Gateway) with SMTP id EE.1E.04067.A71F0FC5; Fri, 31 May 2019 18:18:50 +0900 (KST)
Mime-Version: 1.0
Reply-To: madhan.raj@samsung.com
Sender: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
From: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
To: Nagesh shamnur <nagesh.shamnur@huawei.com>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "cpaasch=40apple.com@dmarc.ietf.org" <cpaasch=40apple.com@dmarc.ietf.org>, "olivier.bonaventure@uclouvain.be" <olivier.bonaventure@uclouvain.be>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, Ashutosh prakash <ashutosh.prakash@huawei.com>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <4AC96705FB868F42B2075BA50F806DEB569B1298@dggema524-mbx.china.huawei.com>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20190531091849epcms5p5cceb35136a723a5ff2fc10e6b2468473@epcms5p5>
Date: Fri, 31 May 2019 14:48:49 +0530
X-CMS-MailID: 20190531091849epcms5p5cceb35136a723a5ff2fc10e6b2468473
Content-Type: multipart/related; boundary="----D_syj3MnVLlnNClgka26ja3N5-ezFktgjWOC_A_Tild3XBlf=_1415d_"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsWy7bCmpm7Vxw8xBsdOslj8uCVtsXHfETaL z6uvs1nMe3GJ1eJGww8Wi2VrVzA6sHm0fZnM5HFi2RVWj5Yjb1k9liz5yeTx6th3lgDWKC6b lNSczLLUIn27BK6MT2tSCt6fZq6Y3jaFrYHxy37mLkZODgkBE4m2zVdZuxi5OIQEdjNKfFz5 Dsjh4OAVEJT4u0MYpEZYwENi8pbJjCC2kICCxN4rO5kg4lYS/bNvsoLYbAIWEgs3b2MCmSMi 8J1R4uz0JWBFzAKpEhv+rGKCWMYrMaP9KQuELS2xfflWsKGcAmESe7+uZoeIi0rcXP0Wzn5/ bD4jhC0i0XrvLNTRghIPfu5mBLlTQkBK4tYGbpC9EgKzGSWOLnvMAuFsZpRovNzPBtFgLrHs xzQwm1fAV+Jx+2+wBSwCqhIfVvyAWuYicbDpJQvE0VkSS06cY4Sw+SR6fz+Be2DHPBhbRWLp nMNQB0lJ/H+6C2qOh8S7ZX1skBBdyCzx++R1pgmMcrMQgToLyQoIW0Oidc5cdghbUWJK90Mo 20Zi9vVjLJjiqhK/DixhXcDIvopRMrWgODc9tdi0wDgvtVyvODG3uDQvXS85P3cTIzgtaXnv YNx0zucQowAHoxIPr8DB9zFCrIllxZW5hxhVgGY92rD6AqMUS15+XqqSCO/fFx9ihHhTEiur Uovy44tKc1KLDzFKc7AoifNOYr0aIySQnliSmp2aWpBaBJNl4uCUamDsffOPb03/3uI7qT2l 2SvunOlUjQxbE+B9Ydu+JkuXmJ+p4eXzDB+x7uavZb2eY35m88fqi/sXHFeWEamd3rNiW/TM 4Gl3+5sZX1zSTjuon5AdVDvFKvt1eTjntxNbA6yfvDX8O8eiWdB54c0WlUOszPtrMhd1/5gd IrHIZcf9gEdpAmsYrSWVWIozEg21mIuKEwFJwyLXUwMAAA==
X-CMS-RootMailID: 20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821
References: <4AC96705FB868F42B2075BA50F806DEB569B1298@dggema524-mbx.china.huawei.com> <4AC96705FB868F42B2075BA50F806DEB56995EF6@dggema524-mbx.china.huawei.com> <4f40e635-2a80-20ec-c991-8a7a61ef327a@uclouvain.be> <20190520135014.GG41806@MacBook-Pro-64.local> <LO2P123MB1965EA246F2652E9D5C47731EB180@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM> <CGME20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821@epcms5p5>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/RMuMx2Tk7pfORFxWhFAVH29nsB8>
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: Fri, 31 May 2019 09:18:59 -0000

Hi,

There are multiple usecases and even for smartphones, the users and also the operators prefer using Wi-Fi (unlicensed) to LTE (licensed and costly).

How exactly are we going to achieve the same is the question. The problem is not introducing a signalling (or an option) but how/when do we set this value.

There can be multiple sub-cases

1) User wants to use the subflows only if max value in primary or preferred subflow doesn't reach.

Ex: If Wi-Fi can fetch 100Mbps speed, the use of LTE wouldn't even be required.

2) Assisted Round-Robin : The provided subflows can decide the ration and inform the RR scheduler. The Server can schedule accordingly.

Ex: The ratio of Wi-Fi(10Mbps) to LTE(1Mbps) speed as 10:1  and the scheduler can adapt based on this value.

This would be highly useful in cases where  RTT difference between subflows are high. When high, SPTCP performs better than MPTCP.

3) Hard control on the bandwidth: This case the user wants to force limit to bandwidth.

Ex: In 5G, the mobile data speed can be over 500Mbps and would tend to use only mobile data (not Wi-Fi). Here, one of the subflow alone can try to control the rate.

 

The main problem (at least in wireless) is that, we cannot predict the exact available bandwidth. There are predictions based on multiple values however it is very dynamic.

In my https://patents.google.com/patent/US20170339257A1/en" target="_blank" rel="nofollow">previous work, we targeted video streaming case alone. As we can predict the bandwidth required for video streaming (based on quality), we controlled in the UE side (my controlling RTT and subflow creation) to maximize the user over Wi-Fi.

 

How about reusing the SBR (https://tools.ietf.org/html/draft-flinck-mobile-throughput-guidance-04" rel="nofollow">https://tools.ietf.org/html/draft-flinck-mobile-throughput-guidance-04), as this already provides (subflow level or) per connection level control.

 

Regards,

Madhan

 

 

--------- Original Message ---------

Sender : Nagesh shamnur <nagesh.shamnur@huawei.com>;

Date : 2019-05-31 10:49 (GMT+5:30)

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

 

Hi Phil,
	I am glad the problem is being discussed upon.  One more possible usecase is for load balancing to achieve one or a set of clients doesn't hog the entire bandwidth available on the server side. Though the links to server supports the bandwidth but still chooses to limit the bandwidth. I agree, this is left best to be dealt with congestion control algorithm to achieve the bandwidth sharing, but there can be cases where the application decides to limit the bandwidth to avoid possibly overload kind of scenarios.

Regards,
Nagesh S

-----Original Message-----
From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] 
Sent: 30 May 2019 23:23
To: cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be
Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>;; Nagesh shamnur <nagesh.shamnur@huawei.com>;
Subject: RE: [multipathtcp] Regarding rate control at a subflow level

I think the use case a hybrid operator could be interested in is the following. Similar to Alexander's use case.

We want to provide a particular customer with broadband access that is faster than their DSL alone can provide, for instance to meet some minimum rate to meet a target of say 20Mbps. The rate can't quite be met by DSL, therefore cellular or even satellite is used as a top-up. DSL capacity is much cheaper than cellular /satellite, therefore the ideal scheduler would favour DSL. It would react reasonably quickly to increased total load above the DSL rate (but not so fast that the instantaneous rate from a variable rate source 'kicks in' the cellular when the rate over a slightly longer time can be met by DSL). Note that the DSL rate is not completely static.  It supports deployments with a proxy in the home gateway and in the network (under the control of the operator), and deployments where there's only the proxy in the network (ie MPTCP is in the multi-interface phone). Possible to ensure that an individual flow goes over only one access. Downward direction (from network to house) more important than upward.  In a long-running session using a lot of bandwidth, because the amount of other traffic varies, it may be that this session sometimes uses just the DSL and sometimes is spread over both accesses. On a minor point, ideally a speed test should measure the rate correctly (I don’t mean the scheduler identifies a speed test and favours it; rather, ideally the speed test shouldn’t eg measure just the DSL rate - alternatively re-define the speed test). 

So in terms of Olivier's question below, I think this means that the limit is about the total and not per subflow. 

In terms of mechanism, I'm open to whatever is most suitable. I'm very interested if the best method would mean that ideally some new functionality is added to the MPTCP standard (and by implication to MP-QUIC).

Best wishes,
phil


-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch
Sent: 20 May 2019 14:50
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>;
Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>;; Nagesh shamnur <nagesh.shamnur@huawei.com>;
Subject: Re: [multipathtcp] Regarding rate control at a subflow level

Hello,

On 17/05/19 - 09:59:54, Olivier Bonaventure wrote:
> 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 ?

another use-case for rate-control I see is when a client wants to tell a sender to gracefully close a subflow.

- Sending a TCP-RST results in packet-loss of the in-flight data.
- Reducing the window is going to stall the whole connection because the window is shared.
- Setting MP_PRIO also won't work because none might want to drain a secondary
  subflow even if the "primary" subflow is having severe packet-loss.

Thus, a "maximum-rate" option on a per-subflow level would allow to send the rate to 0, which would drain the subflow.


Christoph

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNTMxMDkxODQ5ZXBjbXM1cDVjY2ViMzUxMzZhNzIzYTVmZjJmYzEwZTZiMjQ2ODQ3MyZyZWNpcGllbnRBZGRyZXNzPW11bHRpcGF0aHRjcEBpZXRmLm9yZw__" border="0" width="0" height="0">