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

Hi Phil,
	Generally for the downlink traffic, server tries to share the available bandwidth among all the available connections (flows and subflows) and this would be achieved by Congestion control algorithm. Any algorithm would try to scale up to pipe limit. If server needs to throttle the speed then it wouldn't be possible with congestion control algorithm alone and server can realize the same with many ways and one of them would be to ask application on the server side to slow down the packet sending rate.
	How will server achieve the same to tell client side to throttle speed? Dropping packets on server side implicitly or explicitly can achieve it, but IMO it is not the best way. 

Regards,
Nagesh S

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

Nagesh,

Thanks, interesting to hear about an upstream use case. Would be good to explore the scenario in a bit more detail. 
As you say, the congestion control algorithm can be used to stop one connection starving others (ie server / network-side drop packets to slow down a connection). I think you're hinting that this may not be good enough in all scenarios (<< but there can be cases where the application decides to limit the bandwidth to avoid possibly overload kind of scenarios.>>) - would you explain this a bit more please?
I'm trying to understand what benefit we might gain from some extra signalling (whether of preferences, a rate to limit to, or whatever) and therefore whether it's something we should think about doing. 

Thanks
phil

ps Sorry for delay, been away.
-----Original Message-----
From: Nagesh shamnur [mailto:nagesh.shamnur@huawei.com]
Sent: 03 June 2019 14:07
To: 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: [multipathtcp] Regarding rate control at a subflow level

Hi Phil,
	The idea is about controlling the rate on the uplink rather than the downlink and the decision to limit the bandwidth is made at the server since, server can control the downlink traffic rate to all the clients connected to it, but the uplink limit needs to be pushed to the client. 	

Regards,
Nagesh S

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

Nagesh,
Could you explain your scenario a bit more please? Not sure I get it right.  Is this about uplink? Is the application decision to limit the bandwidth made at the client or at the server, and does the network have a role (either in the decision making or supplying info)?
Thanks
phil

-----Original Message-----
From: Nagesh shamnur [mailto:nagesh.shamnur@huawei.com]
Sent: 31 May 2019 06:19
To: 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: [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