Announcement

Collapse
No announcement yet.

Multipath TCP Support Is Working Its Upstream - First Bits Landing With Linux 5.6

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multipath TCP Support Is Working Its Upstream - First Bits Landing With Linux 5.6

    Phoronix: Multipath TCP Support Is Working Its Upstream - First Bits Landing With Linux 5.6

    We've already been looking forward to Linux 5.6 with already there being a lot of good stuff coming and now it's even more exciting: at least the prerequisites have been merged overnight for Multipath TCP (MPTCP) support!..

    http://www.phoronix.com/scan.php?pag...-Multipath-TCP

  • pal666
    replied
    Originally posted by discordian View Post
    Someone tell them that they are reinventing sctp,which is available on Linux for ages.
    did someone already tell you to read documentation before posting stupid suggestions?

    Leave a comment:


  • pal666
    replied
    Originally posted by Etherman View Post
    I have two wifi networks configured in my home. One 5 GHz and one 2.4 GHz. Wan is 250 MBit.
    Speedtest over cable gives ~252 Mbit/s, speedtest over my 5 GHz wifi gets around 160 Mbit/s
    Does this make so I can use one 5 GHz and one 2.4 GHz adapter in my computer for better wifi performance?
    Does router need the support for it too?
    i think your case can be solved by mimo on router and computer

    Leave a comment:


  • GreenReaper
    replied
    This is a good development. For a time I did something slightly similar by hosting IPv4 over cable and IPv6 over ADSL - to ameliorate limited upstream bandwidth of 10Mbps + 7Mbps.

    it worked, but it was not an ideal solution, and it only allowed me to use the full upstream bandwidth to serve multiple clients, not individual clients (unless they chose IPv4 for some connections and IPv6 for others, which is not that likely).

    Leave a comment:


  • Neuro-Chef
    replied
    Originally posted by GrayShade View Post
    If I'm reading the slides right, both the client and server need to support MPTCP, but not the middleboxes like your router (although you would need to disable any packet mangling features like "game mode" that some routers have).
    That's not the intended usecase for end users, but you could of course build some sort of VPN setup that tunnels over mutiple wifi connections to a local router via MTCP, at least when the hardware allows using those (wifi) connections at the same time.

    Leave a comment:


  • Jakobson
    replied
    Originally posted by pepoluan View Post

    Well, RFC 6951 defines how to encapsulate SCTP over UDP, and IIRC WebRTC also encapsulates SCTP over UDP.

    But yeah, most apps will need to be rwritten to at least try using SCTP first and fall back to TCP.

    Too bad. I *really* like all the concepts that underlies SCTP design.
    With SCTP you can use only one path at time. Also to start using an alternative connection takes some time. With MPTCP is possible to use all paths simultaneously.

    Leave a comment:


  • pepoluan
    replied
    Originally posted by Henning View Post

    The main issue with SCTP is that the internet contains too many "Middle Boxes" that throw away anything that isn't TCP, UDP or ICMP... in some cases even high datarate UDP is blocked or throttled.

    They had to redesign MPTCP so that each stream looks practically exactly like a normal TCP stream to prevent the internet from messing with it.

    The current state of new protocols in the internet is "use UDP and build on top of it"... otherwise it will just not work. HTTP3/QUIC is done over UDP for the same reason.
    Well, RFC 6951 defines how to encapsulate SCTP over UDP, and IIRC WebRTC also encapsulates SCTP over UDP.

    But yeah, most apps will need to be rwritten to at least try using SCTP first and fall back to TCP.

    Too bad. I *really* like all the concepts that underlies SCTP design.

    Leave a comment:


  • Henning
    replied
    Originally posted by discordian View Post
    Someone tell them that they are reinventing sctp,which is available on Linux for ages.
    The main issue with SCTP is that the internet contains too many "Middle Boxes" that throw away anything that isn't TCP, UDP or ICMP... in some cases even high datarate UDP is blocked or throttled.

    They had to redesign MPTCP so that each stream looks practically exactly like a normal TCP stream to prevent the internet from messing with it.

    The current state of new protocols in the internet is "use UDP and build on top of it"... otherwise it will just not work. HTTP3/QUIC is done over UDP for the same reason.

    Leave a comment:


  • fitzie
    replied
    Originally posted by loganj View Post
    is this for LAN only? is it even useful for regular user with or without a router?
    If you had a phone with wifi and mobile connection it could use both at the same time. outside of that use case, it is really for helping computers within datacenters which seek to optimize network utilization, efficiency and redundancy.

    Leave a comment:


  • fitzie
    replied
    Originally posted by fuzz View Post

    How exactly is it enabled? Kernel upgrade/flag?
    First both kernels will need support, and they will likely not attempt Mptcp by default, but there will be a setting to attempt mptcp by default. it is an option inside the tcp handshake, so it could be attempted without any penalty if the peer doesn't support it.

    Leave a comment:

Working...
X