Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPTCP addresses #59

Open
Admin-DataRoads opened this issue Jan 7, 2018 · 0 comments
Open

MPTCP addresses #59

Admin-DataRoads opened this issue Jan 7, 2018 · 0 comments

Comments

@Admin-DataRoads
Copy link

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.

@ghost ghost changed the title Please add MPTCP to the (to be) supported protocol list. MPTCP addresses Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant