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

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Mon, 08 July 2019 15:29 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 9156212018E for <multipathtcp@ietfa.amsl.com>; Mon, 8 Jul 2019 08:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_HI=-5, 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=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 ueRp1gpwoh4h for <multipathtcp@ietfa.amsl.com>; Mon, 8 Jul 2019 08:29:34 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE54120297 for <multipathtcp@ietf.org>; Mon, 8 Jul 2019 08:28:47 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20190708152845epoutp0314a0fc6f2adb7a647eef844b73d51d9b~veCvg9F2B0118001180epoutp03A for <multipathtcp@ietf.org>; Mon, 8 Jul 2019 15:28:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20190708152845epoutp0314a0fc6f2adb7a647eef844b73d51d9b~veCvg9F2B0118001180epoutp03A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1562599725; bh=Yzh6n6dIGaxvsmpjx/XaXfkASwgNbUV+X08zHqe1Vkw=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=Icj+o/X6UhqxIJ85KrrquW3ZvqU5wXbN6YcB6muaHh7MI7v24fgbDuWRfhdQYBrC6 wufvDiItslieI2Aoh3sik3Rz6bUrUFjaxswZjWW8lht+v3A0ustES9kvMGyQFIf/F/ g6sdLHc29vxilyz8jI150rK04SiUIaDaIHc/6+h4=
Received: from epsmges5p1new.samsung.com (unknown [182.195.42.73]) by epcas5p2.samsung.com (KnoxPortal) with ESMTP id 20190708152844epcas5p2ea29750ea94f8e1f4252a7da91c0390c~veCuedwId0178601786epcas5p2s; Mon, 8 Jul 2019 15:28:44 +0000 (GMT)
X-AuditID: b6c32a49-59fff70000000fe7-83-5d23612cc683
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 0D.25.04071.C21632D5; Tue, 9 Jul 2019 00:28:44 +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: "philip.eardley@bt.com" <philip.eardley@bt.com>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <LNXP123MB2587C129351B465D4F3263C1EBF60@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20190708152843epcms5p5bc96a48495e2850eba6fd4cd9ad3bbd7@epcms5p5>
Date: Mon, 08 Jul 2019 20:58:43 +0530
X-CMS-MailID: 20190708152843epcms5p5bc96a48495e2850eba6fd4cd9ad3bbd7
Content-Type: multipart/related; boundary="=_NamoWEC-ximfy62rfd"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsWy7bCmhq5OonKswccnEhafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4v2cCa8GfmRwVq3e+ZGtgfPuPvYuRg0NC wERi23HJLkYuDiGB3YwS87d+ZASJ8woISvzdIQxiCgv4Szy7DWRyApUoSOy9spMJxBYWsJLo n32TFcRmE7CQWLh5G1hcRMBY4nj7CTYQmxnIfvi0gx3ElhDglZjR/pQFwpaW2L58KyOIzSkQ I7FyyX5miLioxM3Vb9lh7PfH5jNC2CISrffOQtUISjz4uZsR4nopiVsbuEGulxCYzShxdNlj FghnM6NE4+V+NogGc4llP6aB2bwCvhKtCyaDDWURUJU4cGMBK0SNi8TJf1vZIY52kLhx7hYj hM0n0fv7CRPMAzvmwdgqEkvnHIY6SEri/9NdUEd7SLxb1scGCc/5bBIHFt9lmcAoNwsRpLOQ rICwFSWmdD9kh7A1JFrnzIWybSRmXz/GgqlGTaJ7zTbmBYzsqxglUwuKc9NTi00LDPNSy/WK E3OLS/PS9ZLzczcxgtOJlucOxlnnfA4xCnAwKvHwCgQqxwqxJpYVV+YeYlQBmvVow+oLjFIs efl5qUoivPvcgdK8KYmVValF+fFFpTmpxYcYpTlYlMR5J7FejRESSE8sSc1OTS1ILYLJMnFw SjUwLlrDfc6LNfuh176YLYnzToU3FR88e3JfYZTJyQjJTzbcMaFPHxxRCf6VXPNh2gTn4ODJ +5+F7Hn6VHSt8nl7066eshNHe4wSkqrrdi/bVZXyz6Bl6/mtOxN4J+SfMOF59WpG3JLaDN68 7vnb/+77eGiD4PXjXh0lwqtm/txjrr3/5alEp8MyrEosxRmJhlrMRcWJAC39/pMvAwAA
X-CMS-RootMailID: 20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821
References: <LNXP123MB2587C129351B465D4F3263C1EBF60@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <LO2P123MB196591A5E12A32D82202905FEB140@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM> <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> <20190531091849epcms5p5cceb35136a723a5ff2fc10e6b2468473@epcms5p5> <20190604075437epcms5p8b1c851232b9dbc9b1f522114eda97ac0@epcms5p8> <LNXP123MB258764ABF651F33AAB09186DEBEA0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <CGME20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821@epcms5p5>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/FgoPz5TtlnY8sN2F2WB0JBZkq1E>
Subject: Re: [multipathtcp] (2) (4) 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, 08 Jul 2019 15:29:40 -0000

Phil,

In-line below [Mad]. Most of the suggestions are Smartphones (UE user equipment) specific.

 

In 2 – I’m quite intrigued by the suggestion of a fixed ratio between the subflows

This is in specific to server that uses RR scheduler. The RR scheduler, can receive the feedback about the current UE (user equipment) parameters and schedule the packet accordingly. Here we send the ratio of scheduling rather than the actual bandwidth.

10:1 rather than taking account of actual congestion & bandwidth available?

Indeed, the RR scheduler doesn’t consider actual congestion and BDP. RR scheduler if not widely used though (in commercial level). But client assisted RR, can have significant enhancement.

[phil] So I think that (for downstream traffic) the server gets a hint from the client about the maximum capacities of each of the interfaces (I assume this is what you mean by “client assisted RR” – is that right?) (I assume this is a one-off hint, rather than an on-going signal that reflects changes in the spare capacity of each interface.).  I agree this is better than having no info, but presumably not (?nearly?) as good as getting info about the current congestion and BDP. It also creates the problem about how to signal this hint from the client to the server (whereas MP/TCP already provides a signal for congestion).

[Mad] Yes, right.

 So my question is why people would follow for this approach? I feel like I must be missing something, it seems to require a new signal and give worse performance – but perhaps it is simpler to implement?

[/phil2]

[Mad] Yes, the implementation would be simple and can be cross-layer controlled. It would be experimental (similar to RR). We can ignore this, as it would not be real time scenario.

 

In 3 – can we discuss this scenario a bit more. I don’t understand your example with 500Mbps 5G why a party wants to control the rate. 

This is very important case in mobile user perceptive.

-       When Mobile data is 500Mbps, Wi-Fi is 50Mbps. The ratio is around 10:1. Most of data would be consumed over 5G. Neither user not the network operator would prefer this.

-       Most of the countries has CAPPED the maximum data which can be consumed over mobile data with high speed (FUP). Exhausting the data over 5G, though Wi-Fi is available, might be overhead for users. As the operator doesn’t control, at the client (smartphones) we can control the mobile data rate i.e. reduce the mobile speed so that Wi-Fi data is consumed more.

 

I can see that the flinck throughput guidance might be useful (end to end with the server or with an explicit proxy)

 

Yes, I think this can be solution that can handle all the cases. But, we can incorporate SBR inside the MPTCP option, rather than introducing a completely new TCP option (which can be possibly stripped by middlebox).

 

[phil] I can partly understand the scenario. But some things that I think should be taken into account:-

[1] surely a capped max data rate over 5G is a contractual /policy setting, so the operator already know the value and thus it doesn’t need to be signalled? ;

[Mad] The data can be controlled by UE as well. Though operator provide up to 1Gbps. The UE might like to control the data rate (or can be obfuscated as well). Consider an example, the user wants to limit the download speed of specific application using Data Usage APP.

 

[2] the capping limit surely applies to all the mobile client’s traffic (and may include some non-MP/TCP traffic), which will be going to many different servers ;

 

[Mad] The system wide setting can be simply implemented/controlled using TC or Linux queues. The case is specific to MPTCP apps. As you mentioned, non MPTCP servers would still be privileged with full speed (May be some other way?). But in Android Smartphones, the MPTCP is proxy based and mostly enabled for all the application.

 

[3] limiting the mobile data rate to a particular value solves the problem of using too much mobile data to some extent–  but I think ideally you’d like something more flexible which….

[4] can potentially reflect user preferences (eg for this app at this moment I’m prepared to use up more of my mobile data)

[Mad] Indeed, we increase the priority app by reducing the non-priority one (may be background). Our  another research inline to this example
https://ieeexplore.ieee.org/document/7564972" rel="nofollow">https://ieeexplore.ieee.org/document/7564972

 

[5] and potentially reflect operator preferences /knowledge (eg at the moment the DSL has a low throughput so operator needs to allow more to be sent on the mobile interface, in order to hit a 20Mbps target contractual rate)

[6] and potentially reflect knowledge /preferences about relative costs (eg satellite is much more expensive than wired DSL. I guess this info is reasonably static)

[Mad] Agreed

 

Re [1] & [2] see Gregory’s email, which says to enforce this at the HAG

 

It would be great to discuss this list (essentially requirements / scenarios / assumptions) and delete /modify /add to it. I think it will help the next stage of Multipath at the IETF (MPTCP & MP-QUIC)

Thanks

Phil

 

[/phil2]

 

 

 

Regards,

Madhan

 

 

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

Sender : philip.eardley@bt.com <philip.eardley@bt.com>

Date : 2019-07-08 20:36 (GMT+5:30)

Title : RE: [multipathtcp] (4) Regarding rate control at a subflow level

 

Hi,

Just wondering if there are any follow-ups on this discussion?

Thanks

phil

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 18 June 2019 10:29
To: madhan.raj@samsung.com
Cc: multipathtcp@ietf.org; ashutosh.prakash@huawei.com; cpaasch=40apple.com@dmarc.ietf.org; nagesh.shamnur@huawei.com
Subject: Re: [multipathtcp] (4) Regarding rate control at a subflow level

 

Sorry for the delay in following up, been away. In-line below [phil2]

 

From: Madhan Raj Kanagarathinam [mailto:madhan.raj@samsung.com]
Sent: 04 June 2019 08:55
To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
Cc: nagesh.shamnur@huawei.com; cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be; multipathtcp@ietf.org; ashutosh.prakash@huawei.com
Subject: RE:(4) [multipathtcp] Regarding rate control at a subflow level

 

Phil,

In 2 – I’m quite intrigued by the suggestion of a fixed ratio between the subflows

This is in specific to server that uses RR scheduler. The RR scheduler, can receive the feedback about the current UE (user equipment) parameters and schedule the packet accordingly. Here we send the ratio of scheduling rather than the actual bandwidth.

10:1 rather than taking account of actual congestion & bandwidth available?

Indeed, the RR scheduler doesn’t consider actual congestion and BDP. RR scheduler if not widely used though (in commercial level). But client assisted RR, can have significant enhancement.

[phil] So I think that (for downstream traffic) the server gets a hint from the client about the maximum capacities of each of the interfaces (I assume this is what you mean by “client assisted RR” – is that right?) (I assume this is a one-off hint, rather than an on-going signal that reflects changes in the spare capacity of each interface.).  I agree this is better than having no info, but presumably not (?nearly?) as good as getting info about the current congestion and BDP. It also creates the problem about how to signal this hint from the client to the server (whereas MP/TCP already provides a signal for congestion).

 So my question is why people would follow for this approach? I feel like I must be missing something, it seems to require a new signal and give worse performance – but perhaps it is simpler to implement?

[/phil2]

 

In 3 – can we discuss this scenario a bit more. I don’t understand your example with 500Mbps 5G why a party wants to control the rate. 

This is very important case in mobile user perceptive.

-       When Mobile data is 500Mbps, Wi-Fi is 50Mbps. The ratio is around 10:1. Most of data would be consumed over 5G. Neither user not the network operator would prefer this.

-       Most of the countries has CAPPED the maximum data which can be consumed over mobile data with high speed (FUP). Exhausting the data over 5G, though Wi-Fi is available, might be overhead for users. As the operator doesn’t control, at the client (smartphones) we can control the mobile data rate i.e. reduce the mobile speed so that Wi-Fi data is consumed more.

 

I can see that the flinck throughput guidance might be useful (end to end with the server or with an explicit proxy)

 

Yes, I think this can be solution that can handle all the cases. But, we can incorporate SBR inside the MPTCP option, rather than introducing a completely new TCP option (which can be possibly stripped by middlebox).

 

[phil] I can partly understand the scenario. But some things that I think should be taken into account:-

[1] surely a capped max data rate over 5G is a contractual /policy setting, so the operator already know the value and thus it doesn’t need to be signalled? ;

[2] the capping limit surely applies to all the mobile client’s traffic (and may include some non-MP/TCP traffic), which will be going to many different servers ;

[3] limiting the mobile data rate to a particular value solves the problem of using too much mobile data to some extent–  but I think ideally you’d like something more flexible which….

[4] can potentially reflect user preferences (eg for this app at this moment I’m prepared to use up more of my mobile data)

[5] and potentially reflect operator preferences /knowledge (eg at the moment the DSL has a low throughput so operator needs to allow more to be sent on the mobile interface, in order to hit a 20Mbps target contractual rate)

[6] and potentially reflect knowledge /preferences about relative costs (eg satellite is much more expensive than wired DSL. I guess this info is reasonably static)

 

Re [1] & [2] see Gregory’s email, which says to enforce this at the HAG

 

It would be great to discuss this list (essentially requirements / scenarios / assumptions) and delete /modify /add to it. I think it will help the next stage of Multipath at the IETF (MPTCP & MP-QUIC)

Thanks

Phil

 

[/phil2]

 

Regards,

Madhan

 

 

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

Sender : philip.eardley@bt.com <philip.eardley@bt.com>

Date : 2019-06-03 18:58 (GMT+5:30)

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

 

Madhan,

Let me see if I can understand the scenarios further.

In 1 – presumably there is nothing to solve

In 2 – I’m quite intrigued by the suggestion of a fixed ratio between the subflows. Why would this be a good idea? It seems to imply ignoring real-time congestion information. Is the idea that (say) the Wifi is ~10Mbps and LTE ~1Mbps, so it’s considered simpler to divide on fixed ratio 10:1 rather than taking account of actual congestion & bandwidth available?

Also I don’t understand your comment about this approach being useful when there is a large difference in RTT between subflows – surely then it’s best to restrict each flow to using one of the subflows, otherwise all flows suffer the delay of the longest RTT and we need big buffers.

If I get it right, this ‘fixed ratio’ approach is also suggested in 3GPP TR23.793 - although I find the draft doc a bit unclear whether it’s talking about steering or splitting, ie choosing one access for a new flow vs dividing one flow across accesses.

[3GPP TR23.793 v16.0.0 (Dec 2018) – work in progress – “Study on access traffic steering, switch and splitting support in the 5G system architecture (Release 16)” https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3254" rel="nofollow">https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3254 ]

 

In 3 – can we discuss this scenario a bit more. I don’t understand your example with 500Mbps 5G why a party wants to control the rate.

I suppose, continuing my example below where the operator wants to deliver a 20Mbps service (& the DSL capacity a bit less than this), then the operator may want a hard limit at 20Mbps. But in this case I guess the operator can configure the gateway at this limit, at least for downlink traffic, so no signalling is needed.

So I guess it’s some other scenario?

I can see that the flinck throughput guidance might be useful (end to end with the server or with an explicit proxy)

 

Thanks,

phil

From: Madhan Raj Kanagarathinam [mailto:madhan.raj@samsung.com]
Sent: 31 May 2019 10:19
To: Nagesh shamnur <nagesh.shamnur@huawei.com>; Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>; cpaasch=40apple.com@dmarc.ietf.org; olivier.bonaventure@uclouvain.be
Cc: multipathtcp@ietf.org; Ashutosh prakash <ashutosh.prakash@huawei.com>
Subject: RE:(2) [multipathtcp] Regarding rate control at a subflow level

 

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" rel="nofollow">https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp" rel="nofollow">https://www.ietf.org/mailman/listinfo/multipathtcp