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

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Tue, 04 June 2019 07:54 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 BD7EB120105 for <multipathtcp@ietfa.amsl.com>; Tue, 4 Jun 2019 00:54:44 -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 zQcGIRSDIPKo for <multipathtcp@ietfa.amsl.com>; Tue, 4 Jun 2019 00:54:41 -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 016A112006A for <multipathtcp@ietf.org>; Tue, 4 Jun 2019 00:54:40 -0700 (PDT)
Received: from epcas5p2.samsung.com (unknown [182.195.41.40]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20190604075438epoutp03ce019dc25b9ef6275dba6cc7190ff2db~k76im0w5t1503115031epoutp03I for <multipathtcp@ietf.org>; Tue, 4 Jun 2019 07:54:38 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20190604075438epoutp03ce019dc25b9ef6275dba6cc7190ff2db~k76im0w5t1503115031epoutp03I
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1559634878; bh=mp78I4v0v/rTEvdHj3edwzJEiTe6AfU9uS0Cm9rRwFQ=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=F6IcY8ilQwfYUdOm60XA19zImnsbW6XfDGoRGuK2yXGhhZS9BpYKggC9bYd+cYBuN N42dKT+wFIuTLVE+B9SntjXgN89gRjldrzIvRcRWU5Fi4C0w9Pv1TCDXGLEFfoxF9I u4HdOPFqCSFPKlQaKDSiHBHZsPCT64biPAnc2PAw=
Received: from epsmges5p2new.samsung.com (unknown [182.195.42.74]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20190604075437epcas5p39a6bec127071c2332474fd748c773038~k76h4G-Vc3216232162epcas5p3Y; Tue, 4 Jun 2019 07:54:37 +0000 (GMT)
X-AuditID: b6c32a4a-973ff70000000fe2-53-5cf623bd919f
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p2new.samsung.com (Symantec Messaging Gateway) with SMTP id A6.9D.04066.DB326FC5; Tue, 4 Jun 2019 16:54:37 +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: "nagesh.shamnur@huawei.com" <nagesh.shamnur@huawei.com>, "cpaasch=40apple.com@dmarc.ietf.org" <cpaasch=40apple.com@dmarc.ietf.org>, "olivier.bonaventure@uclouvain.be" <olivier.bonaventure@uclouvain.be>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "ashutosh.prakash@huawei.com" <ashutosh.prakash@huawei.com>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <LO2P123MB196591A5E12A32D82202905FEB140@LO2P123MB1965.GBRP123.PROD.OUTLOOK.COM>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20190604075437epcms5p8b1c851232b9dbc9b1f522114eda97ac0@epcms5p8>
Date: Tue, 04 Jun 2019 13:24:37 +0530
X-CMS-MailID: 20190604075437epcms5p8b1c851232b9dbc9b1f522114eda97ac0
Content-Type: multipart/related; boundary="=_NamoWEC-qnafd8wxk9"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsWy7bCmhu5e5W8xBi2TtS1+3JK22LjvCJvF 59XX2SzmvbjEanGj4QeLxbK1Kxgd2Dzavkxm8jix7AqrR8uRt6weS5b8ZPJ4dew7SwBrFJdN SmpOZllqkb5dAlfGtC8FBYe7WSt6/zxgamC88Iuli5GTQ0LARGLHxu+MXYxcHEICuxklPn09 A+RwcPAKCEr83SEMUiMs4CGx9fN5NhBbSEBBYu+VnUwQcSuJ/tk3WUFsNgELiYWbt4HFRQSM JY63n2ADmckscJhJ4suHd2wQy3glZrQ/hVosLbF9+VawXZwCMRLPeu0hwqISN1e/ZYex3x+b zwhhi0i03jvLDGELSjz4uRusVUJASuLWBm6QVRICsxklji57zALhbGaUaLzcD7XXXGLZj2lg Nq+Ar8TR5ZPAbBYBVYmp0+awQtS4SPx5uRoszizgILHl4xQmCJtPovf3EyaY+3fMg7FVJJbO OQx1kJTE/6e7oI72kHi3rI8NEqDbWSRON01mn8AoNwsRprOQrICwFSWmdD9kh7A1JFrnzIWy bSRmXz/GgqlGVeLXgSWsCxjZVzFKphYU56anFpsWGOWllusVJ+YWl+al6yXn525iBCclLa8d jMvO+RxiFOBgVOLhrRD/GiPEmlhWXJl7iFEFaNajDasvMEqx5OXnpSqJ8Cbe/hIjxJuSWFmV WpQfX1Sak1p8iFGag0VJnHcS69UYIYH0xJLU7NTUgtQimCwTB6dUA2Nal/+at9bfLedW2gdv P8x/d2q4asWBoIC7eZwlhiWZEy78r00+wzjzj8XdmmOvuxPz3IxVzsQ7G1ok5TDM/Hk54lDO 13dOdWwLlxl8n/PB5XpN3uP2DyF31yRvvNOgInec42NGvK700buy1bqPj/Z3x2lf8kz68KY1 cf7a7yF3zstlL+1n/6fEUpyRaKjFXFScCADR0z93UgMAAA==
X-CMS-RootMailID: 20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821
References: <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> <CGME20190531051947epcas2p3d0f9cf16916e319a8878bb0f0daf0821@epcms5p8>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/2AdhnVRvsSLeL-NGD-MjZOsLhDM>
Subject: Re: [multipathtcp] (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: Tue, 04 Jun 2019 07:54:45 -0000

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.

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).

 

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

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