MPTCP addresses

The issue proposes experimental MPTCP and optional i2p support but names no files, tests, or implementation entry points. Start by reviewing the repository's protocol table and any prior related discussions. Done would require an agreed multiaddr representation and corresponding supported protocol behavior.

Data Roads Foundation projects have an interest in utilizing MultiPath TCP (MPTCP) connections between our partner cooperative's mesh nodes, edge caches, and VPN gateways -- especially in regard to our Unwatch.Me project. Multipath erasure, RAIL, or network coded UDP connections will probably be used instead in the future (to avoid repeat sends during congestion loss); but MPTCP already has kernel level support so it is usable today.

Optional addendum request: In addition to onion tunnels, we also have an interest in utilizing i2p tunnels where available, with the potential for load balancing or secret sharing between both.

In the multiaddr use case where CID or metadata records contain multiple multiaddr paths to the same content or transform set, similar to a Magnet URI or Metalink, then even where MPTCP is not implemented on the underlying platform this could be used to show a difference between separate content servers, vs. lone servers which merely have multiple accessible address and TCP pathways into the same hardware. This distinction may become important for load balancing in high performance or low latency tolerance distributed applications, for example real time multiplayer online games.

The protocol table entry could be shortened to mtcp if that is desirable.

Hopefully this site and post will address any objections to adding this "experimental" protocol to the supported list:

http://blog.multipath-tcp.org/blog/html/2017/01/04/experimental.html

As the MPTCP RFC 6824 linked in the post specifies the ability to send and receive an arbitrary number of accessible TCP/IP address:port pairs on each end of a given MPTCP session or flow connection, this /mtcp/ prefix could be interpreted to assume that an arbitrary number of (ip4|ip6/<address-value>/<port-num>/)+ 3-tuples will follow in the multiaddr sequence -- and that repeating tcp/ for each would be inefficiently redundant. Of course the multi-multiaddr use case summarized above could point to a different pattern, such as /mp/(<ip-version>/<address-value>/<protocol>/<port-num>)+ -- wherein the MultiPath nested protocol-per-path mix can be completely arbitrary per node, and the use of MPTCP becomes an optional and platform specific multi-multiaddr implementation detail.

I look forward to discussing all practical options here with anyone interested. Please point me to any prior related discussions I may have missed in my search.