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

  • fuzz
    replied
    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.

    Leave a comment:


  • pepoluan
    replied
    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...

    Leave a comment:


  • 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:

Working...
X