I'm Sam Kumar, a PhD student at UC Berkeley, and
I'll tell you about our research on
performance TCP for low-power wireless networks.
This work was published at NSDI 2020, and it's in
collaboration with Michael Anderson,
Youngsun Kim, and David Culler.
In this preview talk, I'll give an overview of
our main results and provide the context
to understand why they're important.
At the IRTF meeting next week, I'll give a longer
talk where I'll explain our experiments
and results in more depth.
I'm going to begin by giving a brief history of
research in low-pans, or low-power wireless
personal area networks, to put our work in
context.
Low-pan research began in the late 1990s, and at
this point in time, researchers deliberately
cast away the internet architecture based on the
idea that low-pans might be too different
from regular networks or too extreme for it to
directly apply.
This allowed the early protocols and systems in
this space to tackle the challenges of
low-pans directly, without being constrained by
the internet architecture.
About a decade later, IP, the internet protocol,
was introduced in low-pans, largely enabled
by the 6-low-pan adaptation layer.
What happened here is that researchers found ways
to take techniques developed in the earlier
networks that didn't conform to any particular
standard or architecture, and make them work
within an IP-based architecture.
This caught on, and in a few years, IP became
standard in this space.
But surprisingly, the adoption of IP did not
include TCP.
For example, OpenThread, an open-source low-pan
stack released by Nest and used in the smart
home space, didn't even support TCP.
And instead, the community went in the direction
of developing application-specific UDP-based
protocols such as CoAP.
Now, low-pans still have not achieved the same
kind of widespread adoption that we've
seen in other wireless protocols, like Wi-Fi.
And a natural question is whether the next step
towards getting that kind of broad adoption
is to use not only IP, but also TCP and the
broader set of IP-based protocols.
In that context, our work completes the
transition of low-pans to an IP-based
architecture by
showing how to make TCP work well in low-pans,
and a research artifact is TCP-LP, a performant
TCP stack for low-pans.
So what do I mean by performant?
Well, one metric is goodput, which is the amount
of bandwidth that an application is
able to get over a TCP connection.
There have been a few prior attempts to use TCP
in this space, usually based on simplified
embedded TCP stacks.
And in contrast, our work, TCP-LP, achieves
significantly higher goodput.
In fact, we can calculate a theoretical upper
bound on goodput based on how fast the radio
can send out packets and the overhead of headers
and ACKs and so on.
And our work comes quite close to this upper
bound.
Since we published our work, OpenThread, the open-source
low-pan stack I mentioned earlier
that's used in some smart home products, recently
added support for TCP, directly based
on our research.
In fact, it uses TCP-LP as its TCP implementation,
and our research significantly influenced
the Thread Network Standard, which OpenThread implements.
I was fortunate to have been involved in this
process, and I am hopeful that the adoption
of TCP will help low-pan technology gain more
adoption.
Now that I've given that brief preview, I'm going
to take a step back and give some more
background on what low-pans exactly are.
And I'll do that by comparing low-pans with other
networks that you might be more familiar
with.
Wi-Fi provides a host with internet connectivity
via an access point.
Bluetooth is like a cable replacement channel, a
wireless USB of sorts.
In contrast, a low-pan aims to provide
connectivity to various embedded devices at the
same level
as, for example, Wi-Fi, while operating within
the constraints of low power, for example,
having to transmit data over multiple wireless
hops to achieve connectivity over a large
area.
Low-pans are useful for a variety of applications,
for example, scientific applications like
environmental monitoring, structural monitoring,
and it's also been used in the indoor space.
And recently, there's been a push to apply it to
the smart home and IoT space.
Now while low-pans are useful, they also come
with a set of challenges.
One set of challenges comes from the resource
constraints of the embedded hosts that typically
have limited CPU and RAM.
For example, they might run on a Cortex-M
processor and have only a few tens of kilobytes
of RAM.
What that means is that you cannot use something
like Linux on these devices.
Instead, you have to use an embedded operating
system that's specialized to work within those
resource constraints.
Another set of challenges comes from the link
layer.
For example, IEEE 8.2.15.4, an example of a low-pan
link layer, has an MTU of only a
few hundred bytes.
In order to achieve connectivity over a large
area, you need to transmit data over multiple
wireless hops.
Finally, the energy constraints bring forth
another set of challenges.
In order to achieve a long battery life on these
devices, you have to duty cycle the
radio.
That means that your radio is typically off for
99% of the time.
And then, say 1% of the time, you turn on your
radio and only then can you receive packets.
Now, to provide an obvious unillusion, we need
some careful scheduling at the link layer
in order to make sure that a packet is only sent
to a device when its radio is on.
So as I mentioned earlier, the adoption of IP in
this space did not include TCP, and
that's no accident.
It's because researchers expected that TCP would
perform poorly due to the challenges
of low-pans.
In particular, there's a perception that TCP is
too heavy to operate within the resource
constraints of the embedded hosts.
There's a perception that TCP's features, in
particular its connection-orientedness,
aren't necessary and just bring additional
overhead for low-pan applications.
And finally, there's the wireless-TCP problem,
the idea that TCP may interpret wireless losses
as congestion and therefore back off and perform
poorly.
Now, central to our research was understanding
TCP's performance, so we investigated these
issues by actually running TCP in a low-pan and
studying its performance.
We found that out of the box, TCP indeed performs
poorly, but not due to these expected reasons.
The actual reasons were different.
One reason was that low-pans have a small MTU,
which results in high header overhead,
which eats away at your good button.
Second, we found that hidden terminals are a
serious problem for TCP when running over
multiple wireless hops.
And we found that the link-leer scheduling
designed to allow low-pans to run at a low-duty
cycle interacted poorly with TCP.
Now there's a big difference between the issues
on the left and the issues on the right.
The issues on the left, if they were to exist,
would be fundamental.
There's no direct way to adapt TCP to overcome
those issues.
In contrast, the issues on the right are fixable
within the paradigm of TCP via fairly
straightforward
techniques.
So in our research, we show why the reasons on
the left don't actually apply, we show
how to address the actual reasons for poor
performance on the right, and our overall
conclusion is that TCP can perform well in low-pans
after all.
To say a little more about our observations about
why the expected reasons don't apply,
what we found is that the connection state of TCP
uses much less memory than the data
buffers, and you need the data buffers in order
to support any high-bandwidth bulk transfer
protocol.
So the complexity of TCP as a protocol does not
actually contribute much to the resource
overheads.
Second, we found that many of the overheads of
TCP, for example, the overheads of connection
setup, can be mitigated by a fairly
straightforward technique such as using long-lived
connections
and batching data into large batches when you
send it out.
And perhaps most interestingly, we found that the
wireless TCP problem doesn't actually
cause a huge issue in this space, and the reason
is because the low bandwidth of the
network means that you have a small bandwidth
delay product, which means that you can transmit
data at full speed even with a small congestion
window.
And as a result, TCP can recover to a full window
quickly after a packet loss, and in
fact can operate at a full congestion window most
of the time.
Now, to address the actual challenges that cause
poor performance, we developed a set
of techniques that directly address the three
challenges of low-bands that I outlined earlier.
Some of these techniques have to do with
implementation, others have to do with the actual
operation
of TCP over the network.
In this preview talk, I'm not going to go in-depth
into these techniques, but in the
longer talk I'll give next week at the IRTF
meeting, I'll give more details on exactly
what these techniques are and what they mean for
TCP over low-bands.
In summary, we implemented TCP-LP, a full-scale
TCP stack for low-band devices.
We explained why the expected reasons for poor
performance don't apply.
We show how to address the actual reasons for
poor TCP performance.
And we showed that, once these issues are
resolved, TCP performs comparably to low-band
specialized protocols.
Thank you for listening.