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

  • #21
    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.

    Comment


    • #22
      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.

      Comment


      • #23
        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.

        Comment


        • #24
          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.

          Comment


          • #25
            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).

            Comment


            • #26
              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

              Comment


              • #27
                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?

                Comment


                • #28
                  Originally posted by Jakobson View Post

                  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.
                  MPTCP is still TCP, though: a streaming protocol and not a message-oriented protocol, with "head of the line" blocking that often necessitates complex workaround...

                  But I digress; it seems outside Telephony & WAN systems no one realizes the benefits of a reliable message-oriented protocol...

                  Comment


                  • #29
                    Originally posted by pepoluan View Post

                    MPTCP is still TCP, though: a streaming protocol and not a message-oriented protocol, with "head of the line" blocking that often necessitates complex workaround...

                    But I digress; it seems outside Telephony & WAN systems no one realizes the benefits of a reliable message-oriented protocol...
                    I have been using Pragmatic General Multicast, it's been great. And don't underestimate what the some of the industry is trying with QUIC, HTTP/3, etc, over UDP.

                    Comment

                    Working...
                    X