You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Please add MPTCP to the (to be) supported protocol list.
MPTCP addresses
Mar 15, 2019
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 utilizingi2p
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 repeatingtcp/
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.
The text was updated successfully, but these errors were encountered: