Subject: Re: [PANRG] Question regarding multi-link work

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Apr 2022 10:16:44 -0500

Hi, Jens,

On Thu, Mar 24, 2022 at 12:00 PM Jens Finkhaeuser <[email-masked]> wrote:

> Hi all,
>
> I'm new to the lists (tsvwg and panrg), and have been pointed here for
> multi-path related topics. I have a question if there is interest in
> something.
>
> A couple of years ago I created a very simple tunneling protocol with
> multi-link capabilities. From that I started writing a paper, which never
> ended up getting published. I was wondering if that paper might generate
> some interest as an internet draft, in which case I'd put effort into
> converting it.
>
> The work was borne out of experiences with MP-TCP for tunneling on the one
> hand, and requirements from drone communications links on the other. In
> particular, the latter requires very fast fail- or switchover between
> links, while the tunneling application makes TCP a little less than ideal.
>
> In its concrete (prototype) implementation, the protocol is UDP-based, so
> is probably comparable to MP-UDP efforts (at first glance).
>
> However, the paper concerns itself quite deliberately with the abstract
> state machine(s) and messages. As such it does not place any requirements
> on UDP/IP addressing and could just as easily be applied to serial links,
> Ethernet or any communications channel that can be identified somehow. In
> fact, I would consider its main contribution that it is as agnostic of the
> message transport as I deemed possible. This is also why I have been
> avoiding the "path" term a little.
>
> Similarly, it is not particularly concerned with bidirectional
> communications. It takes the view that a multi-link is established if at
> least one egress and one ingress link is viable.
>
> Since multi-path concerns have been discussed here, I can see few better
> places to take this. But with how far removed the paper is from any
> protocols in development at the IETF, I still wanted to sound out interest
> before taking on the work in converting this into an Internet draft.
>

Speaking only as one participant in PANRG, I think PANRG is a fine place,
at least to start, because the multipath work in IETF (at the transport
layer) is pretty much tied to a specific protocol that's being multi-pathed
- Multipath TCP is in TCPM, Multipath QUIC is in QUIC, Multipath DCCP is in
TSVWG, and if a new home for SCTP is created, as was discussed in
TSVAREA last week, that would be a fourth home.

And, surprising literally no one, I'm interested in learning more about
your thoughts.

I didn't see a link to your work-in-progress - could you share it, whether
with me or with PANRG?

Best,

Spencer

> Thank you for your initial feedback!
>
> Jens
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>

---

From: Jens Finkhaeuser <[email-masked]>
Date: Sat, 02 Apr 2022 14:14:08 +0000

Hi all,
thank you for the feedback.

I'll take that as an "invitation" (not that it's needed, strictly speaking) to convert the paper to draft form, so we can have a conversation about it. There is currently no public link available; this would make one available.

> And, surprising literally no one, I'm interested in learning more about your thoughts.

I have provided more context elsewhere, and should contribute some of that to a draft started by others on identifier vs. locator semantics for addressing... so this is the short version for now.

"Drone" is a pretty vague concept ranging from military drones to toys; under EU legislation, the "specific" category sits somewhere in the middle and offers commercial opportunities. There are many use-cases envisioned, but the highlights are:

1.  Starting and landing often involve control handover between control stations as well as radio link handover between e.g. satellite and ground based radios.
2.  Drones can be fixed wing or multicopter; fixed wing can land at over 100km/h, which requires radio with low latency and high range - and still handover protocols should require few roundtrips to not stress those margins too much.
3.  The use-cases can be BVLOS (Beyond Visual Line of Sight) or RPAS (Remote Pilot Assisted). The latter means transferring camera and control data, which requires high bandwidth in addition to the low latency. It also implies that some data (e.g. camera) can be transported more lossy than others (e.g. control).
4.  Anything that flies over people's heads needs failover, some regulations require distinct radio technologies for this.
5.  Anything that's supposed to deliver a pizza must be cheap; for that reason, targetting COTS (commercial off the shelf) radio hardware and systems built on top of it is sensible. Another point in that favour are SWaP (Size, Weight and Power) considerations; you essentially want flying mobile phones to facilitate communications and little more.

>From the above, it basically follows that the best starting point is to build on IP (because COTS hardware ends up supporting it), to aim at a lightweight tunnel (so no TCP) to support lossy and lossless semantics.
In addition to the visual line of sight considerations, there are also radio line of sight considerations, so communication endpoints should have relatively aggressive control over their local interpretation of whether a link supports comms or does not - by which I mean that each endpoint should be able to make quick decisions on its own whether it considers each path/link to the other endpoint viable.

It took some swirling around to arrive at the point that maybe the best view then is to consider the set of ingress and egress links, and consider the overall thing established if there's at least one of either. That makes for a relatively good separation into per-link ingress and egress and an overall connection state machine (of course, events from one feed into the other).

Between this and a full protocol for everyday use there's a bit of a gap, in particular with how identification interacts with this. For that purpose I've been poking around in tm-rid@ .

The architecture going with it has similarity to MP-TCP or others; there is a scheduling component that makes real-time decisions on which packet to send over which egress, and a management component that for detecting new links or disturbances that state machines may catch too late (radio degradation), which then feeds that in terms of simple priorities to the scheduler.

Personally, I think that the drone problem space is just demanding enough that it's worth capturing the resulting requirements; a fair few protocols I see under discussion on various lists have less stringent views. Second, I think that the abstract state machines make for a good discussion basis, because they represent a model of thinking about these requirements that is somewhat independent of any specific protocol.

In terms of a concrete protocol, we have one that's sufficient for R&D and would actually work somewhat in production. But it has gaps (see above). I'm working on something complementary in parallel, and hope to combine them in the future. That is something I would really like to write a draft for, when that time comes.

Hope that helps (for now)!

Jens