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

[<[e-mail]>]

Hi,
Just wondering if there are any follow-ups on this discussion?
Thanks
phil

From: multipathtcp [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 18 June 2019 10:29
To: [e-mail]
Cc: [e-mail]; [e-mail]; cpaasch=[e-mail]; [e-mail]
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:[e-mail]]
Sent: 04 June 2019 08:55
To: Eardley,PL,Philip,TUD1 R <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; cpaasch=[e-mail]<mailto:cpaasch=[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

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 ]

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:[e-mail]]
Sent: 31 May 2019 10:19
To: Nagesh shamnur <[e-mail]<mailto:[e-mail]>>; Eardley,PL,Philip,TUD1 R <[e-mail]<mailto:[e-mail]>>; cpaasch=[e-mail]<mailto:cpaasch=[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Ashutosh prakash <[e-mail]<mailto:[e-mail]>>
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 previous work<https://patents.google.com/patent/US20170339257A1/en>, 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), as this already provides (subflow level or) per connection level control.



Regards,

Madhan





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

Sender : Nagesh shamnur <[e-mail]<mailto:[e-mail]>>

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

Sent: 30 May 2019 23:23

To: cpaasch=[e-mail]<mailto:cpaasch=[e-mail]>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; Ashutosh prakash <[e-mail]<mailto:[e-mail]>>; Nagesh shamnur <[e-mail]<mailto:[e-mail]>>

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:[e-mail]] On Behalf Of Christoph Paasch

Sent: 20 May 2019 14:50

To: Olivier Bonaventure <[e-mail]<mailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]>; Ashutosh prakash <[e-mail]<mailto:[e-mail]>>; Nagesh shamnur <[e-mail]<mailto:[e-mail]>>

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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/multipathtcp

_______________________________________________

multipathtcp mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/multipathtcp

[cid:image001.png@01D535A7.031C6220]
[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=madhan.raj&do=bWFpbElEPTIwMTkwNjA0MDc1NDM3ZXBjbXM1cDhiMWM4NTEyMzJiOWRiYzliMWY1MjIxMTRlZGE5N2FjMCZyZWNpcGllbnRBZGRyZXNzPXBoaWxpcC5lYXJkbGV5QGJ0LmNvbQ__]