[Ground-station] MPTCP, network coding, ICN, and satellites!

Michelle Thompson mountain.michelle at gmail.com
Mon Feb 25 09:11:21 PST 2019


One of the books I picked up at Information Theory and Applications
Conference was Network and Protocol Architectures for Future Satellite
Systems.

Ok that was a lot of Words!

The book is mainly about the changes already starting to happen for
high-throughput satellites. Continued integration of the terrestrial
support network and the increasing bandwidth of the satellites means that
decisions need to be made and problems solved! Exciting stuff.

In some systems, the satellite network and the terrestrial network are
pretty much separated. Things go through gateways and terrestrial uses all
the old familiar protocols.

Current and future networks integrate the space and terrestrial links. The
first problem you run into is that TCP views long latency links as
congestion and does what it's good at and slows things down. Breaking up
the long paths into smaller links is usually what's done, but at the
expense of breaking some fundamental behavior and doing what's essentially
a hack. It's either that or a special box at the boundary, which incurs
other problems.

The second problem is one of rapidly increasing throughput requirements.
For satellite paths affected by weather, the first line of defense to
preserve the link is something we're implementing with Phase 4 Ground:
adaptive coding and modulation. For big commercial networks this is
necessary but insufficient. In addition to ACM, redundant flexible links
are used.

In the mix to address these things is something called MPTCP, or multi-path
TCP. This is already in your linux kernel, and is how Siri is able to
answer you so quickly. MPTCP is an evolution of TCP with the following
goals. Higher throughput than TCP while not costing too many resources. Do
no harm to other TCP flows. Take as much load as possible off of congested
paths.

Traffic is split up into sub-flows. Both ends have to have the extension.
Why do all this? Because of all the stuff in your way at the transport
layer.

There is a load balancing algorithm called OLIA that is Pareto-optimal.
This means that nothing can get better with the load balancing without
making some aspect worse. It's as fair as it's going to get, nothing is
left on the table. This is a pretty trick achievement!

Another innovation is network coding. In traditional systems (like ours)
the data is source coded (created and compressed) and then a decision is
made about how much channel coding is required for it to make it to
receiving stations. This is nontrivial stuff (as we know) but the coding
doesn't change along the way.

Network coding allows intermediate nodes (like in a mesh network) to
re-encode packets to improve capacity - especially multicast capacity,
reduce bandwidth requirements for data replication, and reduce
file-downloading in peer-to-peer.

Network coding was originally proposed to specifically help multicast data
delivery. It best works when there is a single source. This may not be a
great match up for Phase 4 Ground, but one of the goals here is to open
things up and break them down so that we as amateurs are awake, aware, and
alert of what's going on in communications.

Another movement in the big satellite world (and networking in general) is
something called Information Centric Networking (ICN).

Ok so check this out.

ICN decouples information from the source. Information is named, addressed,
and matched independent of its location. It can be located anywhere on the
network.

Information retrieval becomes receiver-driven. No data can be received
unless it is explicitly requested by the receiver.

There is a publish/subscribe model here, but it's not the publish/subscribe
of the application layer that we might be familiar with. We're more
accustomed to thinking of publish/subscribe as publishing being the actual
transmission of data, and subscribing indicating that we want to get
something in the future. Getting previously published data may be optional,
or impossible.

In ICN, the publish part is only announcing the availability of information
to the network. Subscriptions by default only refer to information already
available. Possibly future info as well. Publication and subscription are
decoupled in both time and space. Publishers don't know about subscribers.
Subscribers don't know about publishers. They just get their stuff from
whatever cache has it.

This is super great for mobile radios.

There was a discussion about security and how ICN evades deep packet
inspection and is more resilient to denial of service attacks.

So is there anything in here that we need to know about? Yes, because it
helps us understand where we're going in the industry when we talk to
people about rideshares and launches.

Yes, because the ICN approach may increase the number of simultaneous users
in a Phase 4 Network. We want people to have watch lists and alerts when
users are online that they want to communicate with. Does this style of
networking help with that? Nothing needs to change in the DVB-S2/X frame,
but could the publish/subscribe model be considered as a possible GSE
function?

If you're interested in learning more about any of this, write me and I'll
help however I can to find the best resources or maybe even a project
related to P4G to work on. :+)

More soon!
-Michelle W5NYV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190225/5cab7c6b/attachment.html>


More information about the Ground-Station mailing list