Hello everybody, my name is Natalia Romo and
welcome to the presentation of the paper CC85,
an implementation of the VBR congestion control
algorithm for DCCP and its impact over multipath
scenarios. This presentation is divided in four
sections. I'm going to start with an
introduction where I explain the motivation and
the objective of this research, following
with the description of the design, the
evaluation, to finalize with the conclusion and
the future
work. So the multi-connectivity and hybrid access
technologies have been an active research
topic during the last years as they enable the
simultaneous use of heterogeneous networks
and this brings some advantages like capacity
aggregation, reliability and flexible resource
management. Following this interest, many
solutions have already been developed and
some of them are already under standardization,
like it is the case of the Broadband Forum
Standard for Hybrid Access and the ATSSS
specification which first appeared in the early
2016 of
the 3GPP standard. This specification has already
defined MPTCP as a solution for traffic
splitting but it is limited only to the reliable
and in-order transport of traffic, which means
it is not suitable for any real-time service or
application and it's also not suitable
for the transport of GWT. On that basis, the MPTCP
protocol was developed to provide a
multipath solution capable of transport non-reliable
traffic. MPTCP extends the datagram congestion
control protocol to support multipath sessions.
As I said, it provides a reliable transport
of data, it is connection-oriented and congestion-controlled.
In addition, a framework was developed which
combines the MPTCP protocol with other functions
like scheduling, reordering and virtual network
interfaces to enable the transport of any IP
traffic across multiple access networks.
This framework has already been tested and
evaluated and evaluation results show that
the latency difference among the paths available
has a strong impact on the end-to-end performance.
Also the latency difference has a strong
dependence on the congestion control used within
the
framework. Right now, the TCCP has three
congestion control standardizers, which are CCAD2,
CCAD3
and CCAD4. And all of them are based on existing
TCP loss-based congestion control algorithms.
Having all these in mind, the target of this
research was to improve the MPTCP framework
by extending the TCP protocol with a new
congestion control algorithm. The algorithm
selected
was VBR, which was initially developed for TCP
and which has also shown quite good results
in terms of maintaining a low latency while
achieving a high throughput.
VBR defines two conditions to achieve an optimal
point of operation. The first condition is
that the amount of data in flight has to be equal
to the bandwidth delayed product. And
the second condition is that the bottleneck
packet arrival must match the bottleneck
bandwidth.
To fulfill these two conditions, VBR initially
estimates the values of the bottleneck bandwidth
and the round-trip propagation time to later use
these values to calculate three control
parameters, which are the congestion window, the
pacing rate and the send quantum.
The way these parameters are updated and the way
the whole protocol behaves is ruled by
this state machine depicted in this figure. In
the startup state, the sending rate will
increase rapidly until the pipe is detected to be
full. Once this detection is made, the
sending rate will be reduced to drain any
possible queue to finally go into a probe
bandwidth state, where the amount of data in
flight is slightly increased from time
to time to probe for more available bandwidth.
From any of these three states, the algorithm
can go to the RTT state, where the data in flight
is reduced to probe for lower RTTs.
We implemented VBR version 1 for the CCP using
the congestion control identifier CC85. It
was deployed within the Linux kernel version 4.14
and it is also available as open source
in a GitHub repository. The development of all
the functions related to the state machine
and the estimation of the path parameters follow
the VBR standards. And we also reuse
and adapt the code from the VBR TCP
implementation in the Linux kernel. In addition
to that,
the TCP standard defines, specifies that CCAD
profile has to define some other aspects like
the format of the acknowledgement packets, the
timing of their generation and how they
are congestion controlled. All these definitions
were taken from the CCAD2. That means that
we use acknowledgement vectors and also
acknowledgement rate.
Apart from that, there are many functions which
are part of the TCP protocol and not
of the TCP, which corresponds to the tracking of
the packets in flight and also to the
acknowledgement
generation. These functions were also taken from
the CCAD2. And we also took some other
ideas to verify the application limited periods.
Finally, to integrate the congestion control
algorithm with the Multipath framework, we
need to provide some information to the scheduler
and reordering functions that I have mentioned
before. The information that we provide is
congestion window, packets in flight for the
schedulers and RTT estimation for the reordering
algorithms. To test this implementation, we
use two schedulers from all the list of schedulers
available, which are ChippsPathFirst and RoundRobin.
ChippsPathFirst allocates packets based on a predefined
path priority and RoundRobin
alternates packets sending through all the
available paths. For the case of the reordering,
we use the active fix, which reads packet
sequence numbers to verify an order arrival.
When a gap is detected, the packets are buffered
until the missing packets arrive or until
a fixed time expires.
Now let's go with the evaluation. The topology
used during the evaluation corresponds to
this figure. We deployed this topology under a
virtual environment and also under a physical
environment. And we set up two testing scenarios,
a single path where the two hosts are
interconnected
only through the red line and the multipath where
the hosts are interconnected through
all the links available. The metrics that we
measured were end-to-end latency and received
throughput.
For the single path scenario, we initially
compared the behavior of Qubic and VBR for
TCP to have a reference baseline to later compare
the behavior of CC82 and CC85. We
set a transmitting sending rate of 15 megabits
and we limited the bandwidth available in
the path in the middle of the test. Here in the
plots, we can see the results corresponding
to the latency and the received throughput for
TCP and the CCP. As we can see after the
bandwidth change, both VBR and CC85 show latencies
way lower in comparison to Qubic and CC82.
In the case of the multipath scenario, we did two
tests. The initial one was sending
UDP traffic. We used a similar scheme to the
single path scenario, limiting the bandwidth
in the middle of the test. We used the cheapest
path first scheduler and the active fixed
array ordering. Here we can see the latency
comparison and also the throughput distribution
among the paths for both CC82 and CC85 and the
aggregated throughput. As we can see here
in the first seconds, the cheapest by first
algorithm only sends data through one of the
paths which is the prioritized path. And once the
bandwidth is limited, the congestion control
algorithm detects this congestion and informs to
the scheduler. And at this point, the scheduler
starts transmitting through the secondary path.
We can see that the CC85 reacts quite
faster than the CC82. And we can also see that
for the CC82, the primary path remains
congested which leads to higher latencies. In
this multipath scenario, we also decided
to test a TCP traffic, taking into account that
this framework should be also capable
of transporting quick traffic and these two
protocols have some similar behaviors. So
for this test, we didn't set a fixed transmitting
rate. We let TCP to send as much as possible,
but we limited the bandwidth path to 10 megabits
per second. As we can see here, the response
in terms of throughput is more or less similar
for both CC82 and CC85, but CC85 shows better
results in terms of latency. Finally, to conclude
all this work, we managed
to prove that CC85 has a clear benefit with
respect to CC82 in the multipath scenario,
as in all the cases, it reduces the latency,
avoiding head-of-line blocking, and also
minimizing
the reordering effort. We also managed to
implement VBR congestion control as a new
CCID for the DCCP protocol, proving that the
conceptual background of VBR also works for
DCCP. And we also integrated our approach into a
multipath access framework that can
be applied either to the 5G HTSS context or to
the hybrid access scenario. As future work,
we intend to make more extensive testing of the
algorithm, adding some other variables
and constraints like concurrent flows to evaluate
fairness, path delay, and packet loss. We
also want to implement the VBR version 2 of the
algorithm, and we also want to standardize
the implementation of VBR for DCCP as a new CCID
profile under IETF. That is all for now.
Thank you very much for your attention.
[END]