Hey, I'm Tong Meng. Today I'm here to share our
progress and thoughts on greater Internet
deployment of scavenger congestion control. It
follows our previous work, PCC Proteus
from SIGCOMM 2020, where we explore scavenger
priority for Internet transport.
It is inspired by the surging amount of Internet
applications, and in the meanwhile, the fair
sharing objective in most previous congestion
control protocols. Specifically, the applications
shown here all require network bandwidth
resources to accomplish data transfer. However,
their
users usually have different timing requirements.
For applications with inelastic timing
requirements,
their data transfer should complete as soon as
possible. But there are also elastic timing
applications, such as system and software updates.
They often run in the background,
even obvious to users if it takes longer time. So
when applications of the two kinds compete
with each other, we can allocate more bandwidth
to those inelastic timing ones, while overall,
users of both types are happy with their
experience. This is also considered to be the
main implementation
scenario for scavenger in current limited
literature. Then, on that basis, we think
there is another important category of
applications, such as online video streaming.
They have opportunistic
elasticity. To illustrate that, let's look at a
motivating example. Here, Alice watches
a YouTube movie on her laptop under a wireless
router, while a system update is running silently
in the background. And Alice does not need any
feature in the update anytime soon. Apparently,
the video streaming flow may have primary
priority, with the update flow being a scavenger,
so that Alice may enjoy both higher video quality
and no rebound. Moreover, an online
video has the largest encoding bit rates. Corresponding
to that, if the throughput is
more than enough to support that best QE, the
video streaming flow can also conditionally
lower its priority to scavenger. And furthermore,
when Alice's video playback buffer is almost
full, the risk of having a rebuffer is relatively
low. And in that case, the streaming flow
can opportunistically switch to scavenger
priority for a short time period. In both
cases, the update flow runs faster without
impacting video QE. In practice, this may
become even more valuable, because the competing
traffic might not just be a software update.
There might be, for example, a second video flow
trying to start quickly. That said, by
enabling flexible and dynamic switch between the
scavenger and primary priorities, we can
further extend the scavenger use cases and
increase the network-wide utility. Therefore,
in our recent work, we propose PCC Proteus. In
summary, it is based on the PCC utility
framework, where each priority corresponds to a
dedicated utility function. Then, with
a modular architecture, all the priorities are
contained in the utility module and share
the same read control algorithm. Therefore, the
scavenger and primary priorities are implemented
in the same protocol. That inherently enables PCC
Proteus to support dynamic priority switch.
However, several factors are restricting larger-scale
deployments of scavenger congestion control.
From the perspective of implementation, the
existing scavenger protocols have limited
availability, especially in widely deployed
transport datapacks, such as Linux Kernel
and QUIC. To be detailed, the uTorrent
implementation of LabBats is limited to the
application itself.
The LabBat++ implementation on Windows Server is
not open source. Our PCC Proteus is previously
tested with UDT, which is not even deployed in
practice. More importantly, previous scavengers,
such as LabBats, are implemented differently,
separate from primary protocols, making it
non-trivial to enforce opportunistic priority
switch.
So in this work, we first push forward the open-source
implementations of scavenger protocols.
We port PCC Proteus to QUIC, which is becoming
increasingly popular with the IETF's standardization
progress. For convenience of academia research
and performance measurements, we also provide
our own LabBat++ implementation by branching off
the uTorrent LabBat codebase.
For benchmarking purposes, we compare the impact
of LabBat, LabBat++, and the Proteus
QUIC scavenger to BBR and QUIC using a
combination of MahiMahi bottleneck setups. The
figure
presents the CDF of primary flow throughput ratio.
When the primary flow uses BBR, we can see LabBat++
does have improved performance compared
with LabBat, and it is even similar to our QUIC
Proteus scavenger. But for QUIC, a QUIC
flow achieves 5.6% higher throughput, competing
with Proteus QUIC than with LabBat++.
In addition, to accommodate the dynamic priority
switch with real applications, we envision
an interface between the application and the
transport datapad. Specifically, these are
the existing common interfaces for congestion
control implementation. The congestion controller
observes packet reception results based on the
received ACKs and instances of retransmission
timeouts, and enforces different pacing rates or
congestion windows to the network interface
card.
However, throughout the above process, the
congestion controller is obvious to actual
application requirements, which are necessary to
determine the appropriate transport priority.
So we claim that, to convey such application
requirements, another interface between the
application and transport datapad is needed.
When deploying scavenger congestion control, this
interface is responsible for priority
control, including two tasks, priority selection
and priority switch. The first task, priority
selection, is to inform the congestion controller
which priority to use in real-time.
There are several different ways to implement
that with the application transport interface.
First, a priority controller can be contained
within the congestion control protocol. It
takes the input of real-time QoE through the
interface and outputs the selected priority.
Or a priority controller can be implemented
together with the application. For example,
when designing adaptive bit rate algorithm in
video streaming, the developer can directly
determine the priority to use besides the video
bit rate selection. In this case, the
app transport interface will be used for explicit
priority notification.
Next, with the dynamically selected transport
priorities, the congestion controller needs
to switch between scavenger and primary. This is
easy for our QCC proteus, because as we
mentioned, different priorities in proteus are
simply different function APIs under the
same protocol. Thus, it only needs a binary flag
to determine which function API to call.
In comparison, the priority switch is not as
convenient if the scavenger protocols are
separately implemented from the primary protocols,
like the case of LabBet.
But we think it is possible to leverage multipath
transport as a workaround. As shown here,
the sender can use different subpaths specific to
primary and scavenger priorities, respectively.
It can then direct traffic to one of the subpaths
according to the selected priority.
Ultimately, we hope the scavenger congestion
control can attract more interest, so that
our envisioned priority control based on the
interface between application and transport
datapath could be accepted or implemented in
practice. And the corresponding implementation
will also be an important future work.
Due to limited time, that's all I want to present
here. Thank you all for listening.
We definitely look forward to questions,
suggestions, and criticisms. Thanks.
>> Thanks, everyone.
>> Bye.