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

[Gregory Detal <[e-mail]>]

Hi Phil,

On Thu, May 30, 2019 at 7:53 PM <[e-mail]> wrote:

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


This is exactly the type of deployments that we have on the field.


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


There are 2 possible levels: (1) macro: create a subflow when the load
reaches the DSL rate and (2) micro: schedule packets first on the DSL
subflow.
For (1) the CPE monitors the load on the DSL link  If the load is lower
than a minimum threshold, then no subflow is established over the LTE
network. If the load is above a maximum threshold, the CPE creates an
additional subflow over the LTE network. Note that (2) is always enabled as
as soon as the 2 subflows are available, the packet scheduler becomes
important. It first tries to fill the DSL link and once it is full, it
overflows over the LTE subflow.
We have deployments where (1) and (2) are enabled and others where only (2)
is enables. What is always important for a customer is that a Speedtest
always display the aggregated speed. In the first deployment mode, the
speed is increased in the middle of the test while with the second mode the
boost is observed directly.


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


This corresponds to the currently deployed Hybrid Access Networks.


> and deployments where there's only the proxy in the network (ie MPTCP is
> in the multi-interface phone).


This corresponds to the future ATSSS service in 5G networks that
will leverage the 0-rtt convert protocol that was started in the mptcp
working group and is now discussed within the tcpm working group.


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


Our experience shows that the scheduler that prioritises the DSL link is
sufficient to ensure that the traffic automatically moves to the DSL
network when the load decreases.


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

The Ookla speedtest is considered as the reference tool by customer and
typically opens n parallel TCP connections to saturate the available
network. Each of these connections typically creates and additional subflow
and both the DSL and the LTE link are used and tested. As said above, when
using the second deployment mode, both the DSL and the aggregated speed can
be seen but is is often tricky to tune properly. It could therefore be
interesting to think about a different and more reliable methodology to
measure hybrid access networks.


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

Looking at the downstream traffic, it seems that you need to limit the rate
of the incoming traffic towards a specific IP address. This can be
implemented on the internet facing side of a HAG. This way, the total rate
of the DSL+LTE is limited because the split of the traffic is done in the
HAG (DSL is filled first). This can be done locally on the HAG and does not
require any MPTCP signalling. If IPv4 and IPv6 are used, then the rate
should apply to all the addresses assigned to the same CPE.


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

It is possible to add signaling to MPTCP and MPQUIC, but those signals
operate on a per-connection basis. It is difficult to have a signal that
affects a group of connections. Another point that needs to be addressed is
the trust of the device that sends the signal. In an hybrid access network,
should the CPE send inside an MPTCP option the maximum rate at which the
HAG should deliver data ? If you trust all CPEs, maybe, but if customers
can select their own CPE or modify them, there are some risks which such
signals...


>
> 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]>
> Cc: [e-mail]; Ashutosh prakash <[e-mail]>;
> Nagesh shamnur <[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]
> https://www.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>


-- 
[image: Tessares SA] <http://www.tessares.net> Gregory Detalº | Co-Founder
& CTO
[e-mail] | [phone] <gregory.detal%40tessares.net>
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
<https://www.google.com/maps?q=1+Avenue+Jean+Monnet,+1348+Ottignies-Louvain-la-Neuve,+Belgium>

ºTRAAL Consulting SPRL

-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>