[Ground-station] QoS: Quality of Service

[Michelle Thompson]

We're moving into the challenge of multiplexing on the transponder
with a goal of delivering Quality of Service (QoS) metrics and
policies.

This is "how do the uplink packets get properly prioritized on the
downlink, to make the most of limited resources".

These resources are spectrum, power, and time.

QoS doesn't make any of our communications channels go faster. This is
a common misconception about QoS. Here's some descriptions from
conversations this week. I would like to hear more opinions about QoS
in general, and any specific requirements that people on this list
might have.

Kenneth Finnegan writes,

"In #networking it's common to forget that QoS is mainly about
deciding which packets you'd rather drop first.

If you don't like that idea, then you just need to pony up and throw
more capacity at the problem."

Adam Thompson continues,

"In the presence of a pizza that's not big enough for all the hungry
people, QoS inhibits less-important pizza eaters.  This lets
more-important eaters-of-pizza get more pizza than their fair share,
*at the expense of the less-important eaters*.

QoS never (ever!) makes the pizza bigger - if you need more pizza, you
must still bake or buy more, or someone's going to go hungry!

Complex QoS systems might let you differentiate between e.g. crust and
topping and permit cutting the pizza into bizarre
topographies/topologies, but still can't make the pizza any bigger.

Finally, if there is enough pizza for everyone, QoS doesn't do anything useful."

If this last part sounds familiar, then you're not alone. QoS often
doesn't do anything useful... in a resource rich environment. This may
be the main reason that we sometimes hear that QoS is a "failure",
that it's "never used", or "why bother for hams since hams don't care
about this subject at all".

It is true that most amateur communications are made with acres and
acres of spectrum, with a very generous power limit (although you are
supposed to use the minimum required power) and no time limits on how
often you can try to make a contact.

When we talk about microwave broadband digital communications, it's a
different situation. And, with space channels, there are constraints.
We have less bandwidth to work with because we're on a sub-band. We
have latency, which is non-trivial for GEO or beyond. We have power
concerns and pointing requirements.

"Adaptive" QoS that does nothing until congestion forces some
decisions, at which time we sort with respect to SNR, has been our
baseline.

What we want to do when constraints are hit is what we need to better
define. Right now, we have a whiteboard design (summarized above) and
a paper about Adaptive Coding and Modulation (ACM) that was published
in AMSAT-DL and AMSAT-UK Journals.

We have the implementation guidelines from GSE as well, which address
QoS and show how to set up queues.

With a controllable downlink going out over the air, and a defined
uplink protocol, now is the time to work on exactly how to multiplex
the traffic. Evariste asked about this exact thing less than a week
ago at the FPGA meetup.

Decisions about QOS heavily affect the central part of the design, so
let's get this right.

Do you have experience implementing QoS policies? Do you have
experience with bad QoS policies as a consumer? Do you have an idea
about what you want to see this design do?

Well, you're in the right place, and we'd love to hear what you have
to say about it.

-Michelle Thompson