Hello, my name is Marcus Pieske. I work as a PhD
student at Karlstad University in Sweden and I'm
going to present to you the outcome of work done
on multipath scheduling in the context of multipath
transport layer tunneling.
This presentation is organized into three parts.
The first will introduce you to the main
motivation for this work, which is the plan built
in multipath support in 5G.
Secondly, I will present the multipath package
scheduler we have been working with and the issue
we have found with it.
Lastly, you will see the modifications made to
this scheduler and the performance improvements
they enable.
But first, let's begin with the multipath support
in 5G networks.
This multipath architecture goes by the name of
Access Traffic Steering Switching and Splitting
or ATSSS and is supposed to offer transparent
multipath support.
This multipath framework would allow for the
simultaneous usage of cellular networks with
other wireless access such as Wi-Fi.
For TCP, the idea is to enable this by splitting
the end-to-end TCP into regular TCP between the
server and a proxy and multipath TCP between that
proxy and a user.
For non-TCP traffic, a transport layer multipath
tunnel may be used instead.
The latter case is of course the focus of our
work and this presentation and we use this topology
to illustrate a typical scenario.
So assuming downlink traffic, data originate at a
server possibly using a transport layer protocol
that support congestion control such as for
instance QUIC regardless of if it's reliable or
unreliable.
Data then arrives at the previously mentioned
proxy where it is passed into our multipath
tunnel and encapsulated with each path then
having its own congestion control.
The data is then scheduled over multiple paths
based on the state of the congestion control of
those paths as well as other path information
that may be obtained from the corresponding
transport layer instance.
This may seem straightforward enough but the
existence of nested congestion control loops and
the interaction between these and the multipath
scheduler can and do cause problems that need to
be addressed.
That brings us to the second part of this
presentation where I describe the particular
scheduler we have been working with.
Since ATS-SS would allow for the usage of Wi-Fi
alongside the cellular access, a scheduler that
is able to express a preference for the cheaper
Wi-Fi becomes attractive.
This is true for users as well as telecom
operators, both of whom may reduce costs by offloading
traffic onto the Wi-Fi whenever possible.
One scheduler designed to deliver traffic
distribution in this manner is the cheapest path
first scheduler.
The basic idea behind this is to rank order the
paths by cost in ascending order and to schedule
packets over the cheapest path until the amount
of in-flight data match the size of the
congestion window.
At which point the scheduler instead attempts to
schedule packets over the subsequent path.
The problem with this is how first is defined.
If first means until the congestion window is
full, as I previously stated, it will tend to
lead to a full utilization of the primary path,
which is what we want, but also to congestion,
which is troublesome for more reasons than just
the increased delay.
As it turns out, the congestion will also delay
or completely preclude the utilization of the
secondary path.
The extent to which this is a problem will depend
on the potential for congestion on the primary
path.
Basically, anything that reduce congestion on the
primary path has the potential to alleviate this
problem.
A simple example will hopefully illustrate the
issue.
In this case, we are running a user space multipath
tunnel with each individual path being managed by
a TCP instance in the Linux kernel.
The topology previously shown is set up in Mininet
with the capacity of each path being 50 megabits
per second and with a moderate delay asymmetry.
A download is initiated using a greedy TCP
application.
Thus, in this case, we tunnel TCP Neurino over
TCP BBR as it offers an easy analysis.
Finally, we have a first in first out queue at
the bottleneck, which is large enough to hold the
congestion window that BBR will tend to output.
Please also note that the throughput in this plot
are stacked and that we therefore would like to
see the throughput reach the 100 megabits per
second line.
The event highlighted here is a reduction in the
server congestion window, which is expected from
time to time as it's part of the normal
congestion control cycle for TCP Neurino.
This in turn is followed by a reduction in
throughput.
This may seem in order, but it's actually quite
bad as seen when taking a closer look at the
state of the network.
After the event shown in the previous slide, the
primary path is likely at least somewhat congested.
While the secondary path is unused.
If we treat the two paths as a single path for
the purposes of analysis, we have both congestion
and underutilization, which is something that you
do not expect to see at the same time.
This is obviously a malign state and can be
thought of as kind of a bad distribution of the
server congestion window over these two paths.
So this brings us to the third and final part
where I show you the modifications made to this
scheduler to overcome this problem.
The basic idea is to redistribute the server
congestion window to maximize the throughput.
The first step is to determine the bandwidth
delay product of the primary path.
With the delay in this case being the minimum
delay.
We then introduce what we call a live congestion
window, which is a fraction of the full window
ranging from the BDP to the full window.
The scheduler is then changed to act on the live
congestion window instead of the full congestion
window.
Finally, we manage the live congestion window by
periodically increasing it if there are packets
in the scheduling queue and decreasing it
otherwise.
Returning to the example shown previously and
using the same configuration, except for the new
scheduler.
We see that we no longer have a problem with the
utilization of the secondary path.
However, we still see periodic reductions in the
server congestion window.
So why then is the throughput so good?
The answer is that the scheduler compensates for
the smaller congestion window, which it infers
from the scheduling queue size by reducing the
live congestion window.
The net effect of this adjustment is that the
server congestion window pivots from the bottleneck
buffer of the primary path where it was causing
congestion to in-flight over the secondary path
where it instead increases the throughput.
One may conclude from this simple example that
the improved scheduler is able to maintain full
utilization by departing from the behavior of
default CPF when necessary.
Although one cannot be certain from these plots
alone, it is a good guess that the utilization of
the secondary path would have been poor after the
highlighted event had standard CPF been used.
A more detailed evaluation is available in the
paper.
In it, we look at multiple end-to-end congestion
control algorithms, multiple topologies, and
different tunnel protocols.
Regardless of the configuration used, the default
CPF scheduler exhibits the same issue, which is
subsequently solved by our modification, again,
regardless of the configuration.
Future work will include a better integration
with the BBR tunnel, whereby the BDP can be
learned from the BBR state as opposed to just
inferred.
This is actually critical as this scheduler will
misbehave if it uses a bad estimation of the BDP,
and in particular, the split flows needlessly if
the BDP is underestimated.
We are also evaluating this in a switching
scenario as opposed to the splitting scenario
illustrated here.
That concludes this presentation. Thank you for
your attention.