8 ms·

I'm not a networking expert, but does this require system changes/support on the other end of the connection?

jlmendezbonini 13y ago
No, I don't think so. Everything seems to imply that no modification is needed at the application layer. Additionally, one of the researchers goals behind the technology is to support unmodified applications. Here's a presentation from the team's website http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
- simon_vetter 13y ago
  It will, however, require changes at the kernel level.
- signa11 13y ago
  apllications use just the socket api for their interactions with the n/w stack. there is no change there, and hence the "unmodified applications" part. from the mptcp paper, we have the following : In brief, here is how MPTCP works. MPTCP is nego- tiated via new TCP options in SYN packets, and the end- points exchange connection identifiers; these are used later to add new paths—subflows—to an existing con- nection. Subflows resemble TCP flows on the wire, but they all share a single send and receive buffer at the end- points. MPTCP uses per subflow sequence numbers to detect losses and drive retransmissions, and connection- level sequence numbers to allow reordering at the re- ceiver. Connection-level acknowledgements are used to implement proper flow control. so yes, both endpoints need to support mptcp for this to work.
- spetsnaz 13y ago
  Here is a video where they show it running, droping wifi and network connections. http://www.youtube.com/watch?v=VWN0ctPi5cw http://www.youtube.com/watch?v=VWN0ctPi5cw
- songgao 13y ago
  If iOS is exposing the API, I believe it should at least provide a parameter whether it should be a MPTCP or a classic TCP. Sometimes you don't need that reliable trasmission; using MPTCP would cause unnecessary cellular data usage.
  - lambda 13y ago
    Multipath TCP could be used for smoothly handing over from the slower, more expensive, less-reliable cellular system, to the faster, cheaper, more reliable WiFi. Without multipath TCP, you have to drop and restart each connection, which in some applications can cause hiccups, latency, or even complete loss of state. Of course, all of this depends on server-side MPTCP support as well, which most systems don't ship with out of the box.
    - songgao 13y ago
      Right. What I'm saying is that, by keeping alive both path, you need to use some traffic. Although when there's WiFi available, you are primarily using WiFi, there are traffic going through cellular network in order to keep the path alive.
      - signa11 13y ago
        would be really cool if slower / more expensive connections could ultimately be drained, and the whole data transfer just switches over to a single more faster connection. edit-1: note that this is not the same as subflow 'deletion' that would happen if an access mechanism was not available at all. edit-2: section-3.4 of the mptcp paper indicates that FIN has a more limited 'no more data on this subflow' semantics. so, in theory it should be possible to do just that. would be so much better to not go the ANDSF route at all ;)
        songgao 13y ago
        Hey! I didn't go into that deep! So if FIN is used in a subflow, does it terminate that path? Is it possible to wake this path up again?
simon_vetter 13y ago
Yes, both endpoints will need to support it. Support for MPTCP is advertised through a TCP option during the setup phase of the connection. One of three things can happen: - Both endpoints support MPTCP and announce it through the MPTCP option : MPTCP will be used. Subflows will be set-up if possible (i.e. if additional addresses are present on at least one of the endpoint) - One of the endpoints (say an ios7 device) supports it, but the other (say a webserver) doesn't : the server will ignore the MPTCP option (which it doesn't understand) and a normal, single path TCP connection will be used. - None of the endpoints support it, thus no MPTCP option will be sent, normal TCP will be used.
- shawkinaw 13y ago
  Perhaps this is why (according to the article) the usage in iOS is limited to Siri and navigation.
- yalogin 13y ago
  From what I read one of the main design decisions was to make sure the nodes along the route do not drop the packets which means it will be a TCP packet for all intents and purposes. So why should the other end change in this case?
  - delinka 13y ago
    It's less about routing and more about connections. Typically, your client makes a single TCP connection for HTTP communication, all data requested on that connection is communicated on that connection. With a supporting server, multiple TCP connections can be used for the same HTTP connection. This doesn't help with transfer speed, but it improves TCP's ability to route around failure. One of your multiple TCP connections goes out, and another one (presumably on a different route) continues handling data transfer. With regular old TCP, the connection tends to fail and has to be re-established. Pointless Pontification: since TCP was designed to route around failure, multi-connection TCP sounds to me like an adaptation of technology to the "demands of business." What I mean is network operators seem to want to centralize their networks to reduce costs instead of distributing them to make them robust, thus the technologists are attempting to work around this "failure."

No, I don't think so. Everything seems to imply that no modification is needed at the application layer. Additionally, one of the researchers goals behind the technology is to support unmodified applications. Here's a presentation from the team's website http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf

simon_vetter 13y ago
It will, however, require changes at the kernel level.
signa11 13y ago
apllications use just the socket api for their interactions with the n/w stack. there is no change there, and hence the "unmodified applications" part. from the mptcp paper, we have the following : In brief, here is how MPTCP works. MPTCP is nego- tiated via new TCP options in SYN packets, and the end- points exchange connection identifiers; these are used later to add new paths—subflows—to an existing con- nection. Subflows resemble TCP flows on the wire, but they all share a single send and receive buffer at the end- points. MPTCP uses per subflow sequence numbers to detect losses and drive retransmissions, and connection- level sequence numbers to allow reordering at the re- ceiver. Connection-level acknowledgements are used to implement proper flow control. so yes, both endpoints need to support mptcp for this to work.
spetsnaz 13y ago
Here is a video where they show it running, droping wifi and network connections. http://www.youtube.com/watch?v=VWN0ctPi5cw http://www.youtube.com/watch?v=VWN0ctPi5cw
songgao 13y ago
If iOS is exposing the API, I believe it should at least provide a parameter whether it should be a MPTCP or a classic TCP. Sometimes you don't need that reliable trasmission; using MPTCP would cause unnecessary cellular data usage.
- lambda 13y ago
  Multipath TCP could be used for smoothly handing over from the slower, more expensive, less-reliable cellular system, to the faster, cheaper, more reliable WiFi. Without multipath TCP, you have to drop and restart each connection, which in some applications can cause hiccups, latency, or even complete loss of state. Of course, all of this depends on server-side MPTCP support as well, which most systems don't ship with out of the box.
  - songgao 13y ago
    Right. What I'm saying is that, by keeping alive both path, you need to use some traffic. Although when there's WiFi available, you are primarily using WiFi, there are traffic going through cellular network in order to keep the path alive.
    - signa11 13y ago
      would be really cool if slower / more expensive connections could ultimately be drained, and the whole data transfer just switches over to a single more faster connection. edit-1: note that this is not the same as subflow 'deletion' that would happen if an access mechanism was not available at all. edit-2: section-3.4 of the mptcp paper indicates that FIN has a more limited 'no more data on this subflow' semantics. so, in theory it should be possible to do just that. would be so much better to not go the ANDSF route at all ;)
      - songgao 13y ago
        Hey! I didn't go into that deep! So if FIN is used in a subflow, does it terminate that path? Is it possible to wake this path up again?

simon_vetter 13y ago

Yes, both endpoints will need to support it. Support for MPTCP is advertised through a TCP option during the setup phase of the connection. One of three things can happen: - Both endpoints support MPTCP and announce it through the MPTCP option : MPTCP will be used. Subflows will be set-up if possible (i.e. if additional addresses are present on at least one of the endpoint) - One of the endpoints (say an ios7 device) supports it, but the other (say a webserver) doesn't : the server will ignore the MPTCP option (which it doesn't understand) and a normal, single path TCP connection will be used. - None of the endpoints support it, thus no MPTCP option will be sent, normal TCP will be used.

shawkinaw 13y ago
Perhaps this is why (according to the article) the usage in iOS is limited to Siri and navigation.
yalogin 13y ago
From what I read one of the main design decisions was to make sure the nodes along the route do not drop the packets which means it will be a TCP packet for all intents and purposes. So why should the other end change in this case?
- delinka 13y ago
  It's less about routing and more about connections. Typically, your client makes a single TCP connection for HTTP communication, all data requested on that connection is communicated on that connection. With a supporting server, multiple TCP connections can be used for the same HTTP connection. This doesn't help with transfer speed, but it improves TCP's ability to route around failure. One of your multiple TCP connections goes out, and another one (presumably on a different route) continues handling data transfer. With regular old TCP, the connection tends to fail and has to be re-established. Pointless Pontification: since TCP was designed to route around failure, multi-connection TCP sounds to me like an adaptation of technology to the "demands of business." What I mean is network operators seem to want to centralize their networks to reduce costs instead of distributing them to make them robust, thus the technologists are attempting to work around this "failure."