MP_PRIO support

[matttbe]

As defined in RFC8684:

Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.
In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [RFC6356]. It is expected, however, that other use cases will appear.
For instance, one possibility is an "all-or-nothing" approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the "overflow" case). Such choices would be most likely based on the monetary cost of links but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [RFC6897].
The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party and may have to pay for metered incoming bandwidth.
To enable this behavior, the MP_JOIN option (see Section 3.2) contains the "B" bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated that B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0).
In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as a backup should now take priority over all remaining subflows). Therefore, the MP_PRIO option, shown in Figure 11, can be used to change the "B" flag of the subflow on which it is sent.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----+-+
  |     Kind      |     Length    |Subtype|(rsv)|B|
  +---------------+---------------+-------+-----+-+

Figure 11: Change Subflow Priority (MP_PRIO) Option

Another use of the MP_PRIO option is to set the "B" flag on a subflow to cleanly "retire" its use before closing it and removing it with REMOVE_ADDR (Section 3.4.2) -- for example, to support make-before-break session continuity, where new subflows are added before the previously used subflows are closed.
It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host.

https://www.rfc-editor.org/rfc/rfc8684.html#sec_policy

If needed, new tickets can be created to track: receiver/sender side only and packetdrill support.

• kernel: feature support
• kernel: selftests
• modification of iproute2 → See issue iproute2: change backup mode (MP_PRIO) for active connections #158
• and ideally packetdrill tests

(Feature from the initial roadmap)

[matttbe]

Support in MPTCP has been added by @geliangtang , thanks!

• a56be1d: mptcp: add the outgoing MP_PRIO support

• 661b20b: mptcp: add the incoming MP_PRIO support

• ef8d413: mptcp: add set_flags command in PM netlink

• bda492f: selftests: mptcp: add set_flags command in pm_nl_ctl

• cdd087e: mptcp: add the mibs for MP_PRIO

• 6a9e7c4: selftests: mptcp: add the MP_PRIO testcases

• 5b9a807: "squashed" in "mptcp: add the outgoing MP_PRIO support"

The remaining bit is the modification of iproute2 (and ideally packetdrill tests :) )

[matttbe]

Assigning to @dcaratti as well for the Packetdrill part ;-)
Thanks for that!

[matttbe]

iproute2 support has been moved to a new issue: #158
We can then close this one.