Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Little-Heralded New iOS 7 Feature: Multipath TCP

timothy posted about a year ago | from the this-way-and-that dept.

IOS 172

Olivier Bonaventure writes "Besides changes in UI, multitasking and other features that the press discusses, iOS7 also includes support for Multipath TCP. Multipath TCP is a major extension to TCP that is able to use different interfaces for the same connection. Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel. iOS7 changes that, with millions of Multipath-TCP enabled devices that can switch from 3G to WiFi without losing existing TCP connections. This is not yet the case on iOS7, which currently seems to only enable it for SIRI, but other use cases will likely appear in the future."

cancel ×

172 comments

Sorry! There are no comments related to the filter you selected.

closed source triumphs again (-1)

Anonymous Coward | about a year ago | (#44893261)

suck it, nerd.

Re:closed source triumphs again (5, Informative)

CanHasDIY (1672858) | about a year ago | (#44893277)

Missed the whole, "Until now, Multipath TCP has been mainly used by researchers with a modified Linux kernel," part did ya?

Re:closed source triumphs again (4, Interesting)

slash.jit (2893213) | about a year ago | (#44893313)

How could Tim Cook forgot to present this feature ?

Re:closed source triumphs again (5, Insightful)

nine-times (778537) | about a year ago | (#44893435)

Maybe because:

This is not yet the case on iOS7, which currently seems to only enable it for SIRI

If it's just for Siri, then at this point, it's still a highly technical feature that the user won't be able to see obvious benefits from. Apple generally won't present technical features in their Keynote unless they can explain how users will benefit.

Re:closed source triumphs again (-1)

Anonymous Coward | about a year ago | (#44893665)

Because on the fly switching from 3g to wifi is so fucking hard.

Re:closed source triumphs again (3, Informative)

Anonymous Coward | about a year ago | (#44894281)

Yes, it really actually is extremely hard. Even detecting when a TCP connection has died is extremely hard, and ends up coming down to "try to ping them every few seconds and see if it gets there" type hacks, which have high latency of detection.

Re:closed source triumphs again (1)

CODiNE (27417) | about a year ago | (#44894421)

I'd imagine they'll gradually add it to services they control such as maps, iMessage, FaceTime and lastly iCloud.

With that final addition it would probably be an added feature of iOS 8.0 or 9.0 and extended to developers. Once they pick it up and the idea becomes more widely known hopefully it'll spur adoption in Apache and web browsers.

It's real annoying when I'm in the passenger seat looking for directions and we drive past a McDonalds or Starbucks and my page loading stalls as it jumps on the known network. Or when leaving the house and it goes from wifi to cellular.

Keynote for Dummies (1)

mynameiskhan (2689067) | about a year ago | (#44893647)

For dummies, Cook presents, silence is the rest.

Re:closed source triumphs again (-1)

Anonymous Coward | about a year ago | (#44893397)

nope, i didn't miss the part about it being in a "modified" Linux kernel meaning it's not even in the main Linux tree yet meanwhile everyone with an iPhone is now enjoying the benefits of multipath tcp. suck it, nerd.

Re:closed source triumphs again (1)

Stratus311 (894962) | about a year ago | (#44893737)

meanwhile everyone with an iPhone is now enjoying the benefits of multipath tcp.

...in Siri.

Obvious troll is obvious.

Re:closed source triumphs again (1)

Anonymous Coward | about a year ago | (#44893903)

Um, they're still benefiting. Even if it's only in Siri.

And Apple gets a widespread beta test that no one knows about, but most people will participate in.

Re:closed source triumphs again (2)

ozbon (99708) | about a year ago | (#44894287)

Don't they get that anyway, every time they release a new iOS?

(And yes, I know, MS do the same thing with v1 of any of their Windows OS's - never trust 'em 'til SP1 comes out)

Re:closed source triumphs again (-1)

Anonymous Coward | about a year ago | (#44894117)

Missed the whole "millions of iOS devices" vs "a half a dozen otherwise crappy linux boxes only used in academia" part didya?

MORON.

Re:closed source triumphs again (0)

Anonymous Coward | about a year ago | (#44894271)

Shut up Ballmer!

Maybe ... (0)

Anonymous Coward | about a year ago | (#44893271)

Maybe they can use this to speed up the lethargic Safari iOS 7 delivered. I had better performance in Safari from my iPhone 3G than I do with this slug on my 5.

Re:Maybe ... (2)

Camembert (2891457) | about a year ago | (#44893375)

I think that indeed Safari is a bit slower in IOS7 than it was on IOS6 (on ipad 2, already an older machine). In general the look and feel of IOS7 is appealing. Still not explored everything of course.

Re:Maybe ... (2, Informative)

Bengie (1121981) | about a year ago | (#44893553)

Safari is typically forced to use HTTP1.0 with no pipelining because it doesn't implement the standard correctly. Because of this, it has to create new connections for each object which requires a 3-way handshake over a high latency connection.

It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.

Re:Maybe ... (0)

Anonymous Coward | about a year ago | (#44894261)

Keep in mind it also requires a 3 way handshake over low, lower and no latency connections too. Not just the high latency ones.

Re:Maybe ... (5, Informative)

bill_mcgonigle (4333) | about a year ago | (#44894295)

It does officially support HTTP1.1, but most servers detect Safari and use HTTP1.0 instead.

I haven't hit this problem myself on any of our large websites, but googling yields this [tech.vg.no] , which seems to indicate that the problem may be on caching proxies. I haven't seen it with Linux Virtual Server (using Direct Routing), Apache, Squid, or Apache Traffic Server (with pipelining support enabled).

Re:Maybe ... (1)

cyberchondriac (456626) | about a year ago | (#44894753)

Try Dolphin. I've been pretty happy with that.

AND IT IS GOOD !! (-1)

Anonymous Coward | about a year ago | (#44893287)

Let there be LIGHT !!

You're Not Making Sense (5, Informative)

Anonymous Coward | about a year ago | (#44893319)

The headline says IOS7 has it, but the synopsis says that it doesn't yet.

The reality is that for Multipath TCP to work, both ends of the connect must be Multipath TCP capable. That is NOT the case in 99.999% of connections.

It seems that Apple has made Siri multipath TCP capable, ergo... What all this means to you or me is, not much, but hopefully a more reliable Siri connection and response. That means she might ask you if you want her to search the web for you more quickly than in the past.

Re:You're Not Making Sense (3, Insightful)

Anonymous Coward | about a year ago | (#44893335)

As you said yourself, both ends needs to be MTCP aware. Apple controling its servers can implement/activate on the ones hosting SIRI.
But for Safari to show MTCP behavior, it means that the webserver should also support MTCP and it seems none do.

Re:You're Not Making Sense (3, Interesting)

Anonymous Coward | about a year ago | (#44893447)

An interesting feature to push for my employer. Getting our servers to support MPT would mean much of the internet will support it.

No, I don't work for MS. I work for Akamai.

Re:You're Not Making Sense (1)

MightyYar (622222) | about a year ago | (#44893481)

I wonder if an enterprising developer could make a browser that works like Silk on Kindles or Opera Mini, where it sends a modified version of the page to the device. Then they could enable MTCP on their own server if iOS will let them enable it for their app.

Re:You're Not Making Sense (2, Interesting)

Anonymous Coward | about a year ago | (#44893509)

(Anonymous to preserve modding)

In most cases the web server would receive two requests from two different IP addresses, one per path, with the same session cookies. Let's say one request for the HTML and one for the CSS. That would be enough to serve the right content without any modification to the code on the web server. But I bet that some webapps will be extremely confused by those two addresses. Time to start designing them without the assumption of one-IP-per-session, even inside the same burst of requests?

Re:You're Not Making Sense (0)

Anonymous Coward | about a year ago | (#44893743)

This is at the TCP level, not the application level. The TCP packets are sent on multiple IP addresses and the server's tcp stack has to merge them back together.

As it is, your phone can change ip addresses (wifi/cellular) so that's nothing new.

Re:You're Not Making Sense (1)

ggraham412 (1492023) | about a year ago | (#44893439)

But the map of the world with all of the pretty dots on it makes a convincing case otherwise. How could it be wrong? [/sarcasm]

Re: You're Not Making Sense (1)

Anonymous Coward | about a year ago | (#44893615)

Why would both ends of the connection have to be multi tcp compatable? It sounds to me that only the device connecting to multiple tcp connections would need to supports that. So what this would mean, I would think, is that the lock up of Siri when I leave work and it still has a connection to the wifi at work, but is too faint to reach the internet, it would switch to 3G or LTE faster and not give the spinning circle for a extended period to the point that I home button out of it and re-Siri whatever I was looking for

Re: You're Not Making Sense (2)

Richy_T (111409) | about a year ago | (#44894301)

Because packets coming from another interface look like they're coming from a different device and will have a different 4-tuple.

Re: You're Not Making Sense (2, Informative)

Anonymous Coward | about a year ago | (#44894307)

As linked by the article, Multipath TCP is a way for a device to use several different interfaces for a single connection. This works by forming several ordinary TCP connections to the one endpoint - one for each different interface. These connections are associated by the endpoints, so that packets can be sent down either connection to get to the other end. They may be connected through entirely different networks, and take very different paths, but because the endpoints know they're related, everything can be put back into the proper order and used like a normal connection.

Like TCP, both the endpoints need to know how to speak the protocol. The network in between does not.

If only one of the endpoints knows how to do multipath TCP, the connections aren't properly associated, and it becomes just like 2 ordinary, independent connections - they can be made, but you can't split the packets between the two.

An odd way to speed up Siri (5, Insightful)

s.o.terica (155591) | about a year ago | (#44893337)

I can understand that Apple wants to speed up Siri (the latency on Siri can be horrible, even over a fast WiFi connection), but why do it this way rather than enabling simultaneous client-side speech recognition a la Google Now (even in the Google app on iOS)?

Google's method allows the speech recognition process to appear instantaneous. On a Nexus 4, Google Now recognizes speech almost as fast as you can speak.

Siri on the other hand can often take several seconds to understand a request, even under iOS 7. To me, this more than anything else is what diminishes the user experience.

Re:An odd way to speed up Siri (1)

Sockatume (732728) | about a year ago | (#44893467)

IIRC they've implemented this in Dictation on MacOS, so it might not be too far away.

Re:An odd way to speed up Siri (0)

Anonymous Coward | about a year ago | (#44893487)

My guess is... Patents.

Re:An odd way to speed up Siri (1)

danomatika (1977210) | about a year ago | (#44893547)

Because Google Now utilizes an enhanced Qualcomm ARM chip with a "contexual computing processor" so the voice recognition is done largely in hardware on the phone (http://www.itproportal.com/2013/07/25/motorolas-new-x8-arm-chip-underpinning-the-always-on-future-of-android) :

> The CCP is billed as adept at processing sensor data from the device and using it in the always-on display features of the new Motorola handsets. L-NLP monitors > the microphone input, noise cancellation, and runs speech recognition to make the phone a hands-free device.

The new iPhone's don't have that, so they have to keep with the "record audio, send to server" method.

Re:An odd way to speed up Siri (1)

gl4ss (559668) | about a year ago | (#44893595)

doesn't it just detect that it is speech? having not that much to do with if it's processed into text on the phone or elsewhere.

Re:An odd way to speed up Siri (1)

jon3k (691256) | about a year ago | (#44893679)

It was faster before the new coprocessor.

Re:An odd way to speed up Siri (1)

jon3k (691256) | about a year ago | (#44893685)

I should clarify: It was faster than Siri, even BEFORE the new coprocessor.

Re: An odd way to speed up Siri (0)

Anonymous Coward | about a year ago | (#44893775)

Only on the Moto X. There isn't any kind of specialized hardware in any other phone that support Google Now, and yet it's faster than Siri.

P.s. the coprocessor in the Moto X is here to enable it to recognize speech all the time, and to save battery in the meanwhile. Not to speed-up recognizing.

Re:An odd way to speed up Siri (0)

Anonymous Coward | about a year ago | (#44893793)

Because Google Now utilizes an enhanced Qualcomm ARM chip with a "contexual computing processor" so the voice recognition is done largely in hardware on the phone (http://www.itproportal.com/2013/07/25/motorolas-new-x8-arm-chip-underpinning-the-always-on-future-of-android) :

No. It works quite fast on my Galaxy Nexus and Nexus 7 FHD. Neither have this contexual computing processor. That only exists in the Moto X, Droid Mini, Droid Ultra, and Droid Maxx.

Software can leverage hardware when present, but the hardware doesn't drive the entire software experience.

Re:An odd way to speed up Siri (0)

Anonymous Coward | about a year ago | (#44893999)

It helps but isn't required.

The Google iOS app performs the recognition client-side not server-side. The chip is good enough, they just don't use it.

Re:An odd way to speed up Siri (1)

Anonymous Coward | about a year ago | (#44893551)

I don't know why Apple chose to do it this way, but one one possible reason is for (potentially) better quality speech recognition... It's unnatural and error prone to comprehend speech as a sequential two step "word recognition then semantic analysis" process; the better way to do it the human way where word recognition is intimately integrated with semantic analysis such that disambiguation of unclear words can take advantage of semantic context. Since Siri is implemented remotely, it therefore makes sense for the word recognition part to also be remote.

Re:An odd way to speed up Siri (2)

larwe (858929) | about a year ago | (#44893593)

The semantic engine is part of all modern speech recognition libraries (grammar hints are used, and the application provides the grammar based on what commands it expects to receive). And by "all modern speech recognition libraries" I basically mean Nuance, since they own the field and buy anyone who does anything interesting in it.

Re:An odd way to speed up Siri (1)

Grizzley9 (1407005) | about a year ago | (#44893645)

Siri on the other hand can often take several seconds to understand a request, even under iOS 7. To me, this more than anything else is what diminishes the user experience.

And this is why I don't use it. The network lag to get a response, while usually quick, is slow enough that I'd rather not wait most of the time for simple, quick tasks. If it had on-board recognition and processing instead of throwing it to Apple servers it would be much more useful (to me), as long as it's on-board results were good. Now I just use it mainly to dictate long text messages or while in the car.

For Siri to really start to be more useful it will need to be always on like some of those Android phones and it will need to understand context more. For instance, you can program in only your "home" and "work" for locations. Anything else though is not understood unless you substitute something in for one of those. "Remind me when I get to Target to get eggs" Siri:"I don't know who Target is" or it is a simple reminder that has nothing to do with location based services. I would have to change my "work" to the stores/destinations address and use the term 'work' when talking about it.

Re:An odd way to speed up Siri (2)

immaterial (1520413) | about a year ago | (#44894037)

Or you could, I don't know, add Target to your contacts? You can refer to any location in your contacts, not just your own home or work. It *would* be nice if it could seach for nearby addresses, such that if you don't have a contact for your local Target, it'll find the address anyway.

Re:An odd way to speed up Siri (0)

Anonymous Coward | about a year ago | (#44894569)

I really don't notice any network lag in iOS7, on my 4S. I definitely did in iOS6, but it's much better now.

Android does it all on the server. (1)

YesIAmAScript (886271) | about a year ago | (#44893805)

It does recognize you said "google" to start recognition, but assuming you pressed the button to start instead of that, it's all done on the server. Even on the Moto X, the processor just figures out that you said the trigger phrase, the recognition of the natural-language speech you say after that is all done on the server.

If you don't believe me, just try it when your phone only has an EDGE connection some time.

Google just has better feedback, they seem to have a better design.

Re:An odd way to speed up Siri (1)

stenvar (2789879) | about a year ago | (#44894243)

but why do it this way rather than enabling simultaneous client-side speech recognition a la Google Now (even in the Google app on iOS)?

Google can do that because they have developed two separate speech recognition engines themselves, one for phones and another for servers. Apple is simply licensing Nuance speech recognition, and they get whatever Nuance can give them.

Good idea, but ... (3, Informative)

Anonymous Coward | about a year ago | (#44893353)

Multipath TCP is a very cool idea, but there are lots of barriers keeping people from really using it. Those barriers have jack shit to do with peoples' own computers, and everything to do with everyone else they want to talk to, whose machines aren't expecting a single conversation to be taking place with two different addresses.

If I could get away with it, I would be delighted to have my home router use several different ISPs, wrapped together. Sure, I can do that now, but not at the individual connection level.

Re:Good idea, but ... (1)

hendrikboom (1001110) | about a year ago | (#44893441)

Bittorrent could do use muultiple paths, even if the other end(s) weren't specially rigged for it.

The others would just see you as several bittorrent sites.

-- hendrik

Re:Good idea, but ... (3, Informative)

pak9rabid (1011935) | about a year ago | (#44893735)

Bittorrent does this at the application layer, meaning it's only applicable to that specific application. Multipath TCP accomplishes this at the transport layer, meaning existing applications don't specifically have to be coded to support this, they would just need minor changes (if any) to make use of it. See the OSI model [wikipedia.org] for more info.

Re:Good idea, but ... (1)

hendrikboom (1001110) | about a year ago | (#44894769)

Yes, of course Bittorrent is at a different layer, and it's not all that suited to streams of data, which TCP handles (or have I missed something?) But it's capable of handling multiple connections more or less as a side effect of it being a protocol between multiple hosts.

In the original ARPAnet, though, didn't packets wander through the net more or less on their own? I suspect that gave the effect of ganging several TCP streams together. But those were simpler days, with a smaller net that had smaller routing problems.

-- hendrik

Re:Good idea, but ... (2, Insightful)

Anonymous Coward | about a year ago | (#44893463)

Mod parent up. Whoever wrote the summary does not understand how TCP works. You can't just switch client IP at random between packets. TCP connections are end-to-end. This is why this is an *extension* and is not really used anyway.

Heck, most semi-safe protocols (eg. game interactive content) have some sort of connection tracking that involves client's IP address to prevent interference and/or hijacking. Multipath wouldn't work there either.

Re:Good idea, but ... (0)

Anonymous Coward | about a year ago | (#44893769)

A properly done multipath protocol (I didn't look at the actual one, so I don't know if it does) would announce all possible IPs on the initial handshake. Then the other side could distinguish between a packet from the same multipath, and a packet from an unrelated address.

Re:Good idea, but ... (0)

Anonymous Coward | about a year ago | (#44893991)

How could a phone, that's hopping Wifi & cellular stations, *know* all possible IPs it's going to have?

Re:Good idea, but ... (1)

mlts (1038732) | about a year ago | (#44893563)

Another downside is that sometimes I don't data to go through a LTE link if it is expensive. On iOS 7, this is controllable on an app basis, but having a switch to allow/disallow it would be nice.

Multipath TCP would be extremely useful though regardless.

What I wonder about would be adding some form of crypto between the endpoints. That way, unless the attacker could watch all connections at the same time, the traffic would be useless. Perhaps Diffie-Hellman key negotiations that use all multiple links to set up a key. Of course, some connections can be marked more secure than others (say one has fast WAN bandwidth, but an extremely slow LAN link), so the machines can sync keys along the slow, secure link while doing the most of their communication encrypted via the fast, insecure one.

Re:Good idea, but ... (2)

drinkypoo (153816) | about a year ago | (#44893689)

Apparently it is theoretically possible to extend IPSEC to work with multipath. No idea if this has actually happened or not.

Re:Good idea, but ... (1)

x0ra (1249540) | about a year ago | (#44894135)

Please, don't try to extend IPSEC. Just burn the damn thing for good...

Re:Good idea, but ... (1)

Megane (129182) | about a year ago | (#44893875)

I'm doing good just to have my DHCP at home assign the same fixed IP to both the wired and wireless interfaces of my laptops. That way I get a limited sort of multipath, where the laptop will default to using the wired if it's connected, and the TCP stacks will see the same IP coming from a different MAC address on the same LAN. Once I've done the big file transfer that I dug out the wired cable for, if it falls out, neither I nor the computers involved care.

Re:Good idea, but ... (1)

Anonymous Coward | about a year ago | (#44894183)

There's no barrier to people having it running, though. An MPTCP implementation figures out during the three-way handshake whether the other side also knows about MPTCP, and if it doesn't, MPTCP seamlessly falls back to TCP.

merhaba (-1)

Anonymous Coward | about a year ago | (#44893431)

Parmakhesabi.com [parmakhesabi.com]

IPv6 (1, Interesting)

hendrikboom (1001110) | about a year ago | (#44893451)

Anybody know if IPv6 is any better in this regard?

-- hendrik

Re:IPv6 (0)

Anonymous Coward | about a year ago | (#44893495)

Not inherently.

Re:IPv6 (0)

Anonymous Coward | about a year ago | (#44893619)

There was an attempt to do something like this in ipv6, called Shim6. Shim6 proposed that end sites not be given thier own ip space if they multihomed...instead shim6 proposed that end sites would get an IP block from each of their IPSs, and assign and IPs from each of those ISPs blocks to all their end hosts. The end hosts would then have multiple IPs, and would negotiate with any server they reached out to in order to figure out which IP to use for the connection

Shim6 has been deprecated, though. It is not something that anyone is going to implement.

Re:IPv6 (5, Informative)

shreak (248275) | about a year ago | (#44893667)

Multipath TCP is implemented through TCP options so everything happens above the base IP (v4 or v6) layer. There's not specific advantage with IPv6. It can even happen transparently with one link over IPv4 (say wifi) and another link going over IPv6 (like your mobile bearer).

Major extension to TCP? (0)

Anonymous Coward | about a year ago | (#44893499)

Major extension to TCP, when you can already route a message through multiple paths over the internet?
Sounds more like a major extension to the kernel to me.

Re:Major extension to TCP? (1)

shreak (248275) | about a year ago | (#44893707)

multipath TCP doesn't really have anything to do with message routing. It's just an extension that allows multiple TCP connections to be bound together but presented to the application layer as a single socket. One use case would be where you're sitting at a coffee shop streaming over wifi and you walk away and lose the connection because you walk out of range of the wifi network and break your TCP connection. With multipath TCP you'd have established a connection over both wifi and mobile networks to support that connection. When the wifi drops out the everything will just go over the mobile network and your TCP connection is never lost.

Re:Major extension to TCP? (1)

StripedCow (776465) | about a year ago | (#44893997)

But let's say I connect from A to B over the normal (wired) internet. The packet goes through router X or router Y. Then, when X fails, the message may be routed through Y or the other way around.

Same with multipath: when wifi fails, use mobile network, and vice versa.

No modification of TCP necessary!

Only the kernel (it has to set up "virtual" routers for wifi and mobile).

Re:Major extension to TCP? (5, Interesting)

shreak (248275) | about a year ago | (#44894105)

You're right but consider this scenario. You're at a coffee shop that offers wifi and you also have mobile network. You're streaming something to your phone which naturally prefers the wifi network. You get up and walk away and lose wifi. The TCP connection is lost, even though you have a perfectly good moble network also available. The TCP connection needs to be reestablished.

With multipath TCP in the same scenario your phone would have the option of setting up two TCP connections, one over each network. It would present a single socket to the streaming application (who is none the wiser). The multipath TCP socket sends packets over both networks (using whatever spread it feels appropriate). When you walk out of the coffee shop and lose the wifi the multipath TCP socket would stop using the dead network and only use the good network (mobile in this case). No loss in connection.

Re:Major extension to TCP? (1)

StripedCow (776465) | about a year ago | (#44894321)

So, you are saying that when you have a stable connection from A to B through X, and X goes dead, your connection drops even though there is another route through Y?

In that case, I'd say TCP contains some serious design error.

Re:Major extension to TCP? (0)

Anonymous Coward | about a year ago | (#44894649)

mmmm arrogance. so delicious.

out of curiosity, have you implemented anything even approaching the complexity of TCP? i hope not, because undeserved arrogance is the tastiest of all. lucky for me it's so common on the internet!

Re:Major extension to TCP? (1)

statusbar (314703) | about a year ago | (#44894727)

In this example, X and Y are each providing a different subnet address. Your device just moved to a different network and now has a different IP address. This is not a design error but an appropriate design. Multipath TCP is a standard that allows your device to have uninterrupted mobility.

Re:Major extension to TCP? (1)

CastrTroy (595695) | about a year ago | (#44894481)

Yeah, but if you're streaming something wouldn't it be better just to have like a big buffer? If your connection dies, you keep grabbing data out of the buffer, and in the meantime, the connection is re-established on a working network. You could easily store 5 minutes of audio in memory incase your connection drops. With phones now having gigabytes of memory, having 10 megs dedicated to an audio buffer isn't a lot to ask. Even if you're streaming video, you could easily store up enough of the video for the amount of time that you would lose a connection for.

Re:Major extension to TCP? (1)

vux984 (928602) | about a year ago | (#44894315)

But let's say I connect from A to B over the normal (wired) internet.

Slow down cowboy. What is "A" and "B"?
They are IP addresses.

The packet goes through router X or router Y.

Correct.

Same with multipath: when wifi fails, use mobile network, and vice versa.

No, In the A-B scenario above there are 2 routes from A to B. Or to be more precise there are 2 routes from "IP Address A" to "IP Address B".

With multipath, A has 2 different IP addresses: A0 and A1. A router knows the routes it has available to send a packet down, but it has no idea that A0 and A1 are different interfaces on the same device, and that it can send packets addressed to A0 to A1.

Indeed, packets arriving on the A1 interface addressed to A0 would be ignored unless the interface was in promiscuous mode.

Only the kernel (it has to set up "virtual" routers for wifi and mobile).

That doesn't solve the problem that the two interfaces have different IP addresses, in completely disparate networks.

Siri: Bad use case? (2)

bradgoodman (964302) | about a year ago | (#44893611)

It seems to me that Siri is a bad use case for Multipath TCP. Siri transactions seem to be fast and short-lived. i.e. You wouldn't need a persistent connection that could service transitions between Wifi and 3G. So why use MultipathTCP on it?

Re:Siri: Bad use case? (5, Insightful)

Tim12s (209786) | about a year ago | (#44893719)

But it is a great mass-market testcase.

Re:Siri: Bad use case? (5, Interesting)

Rude Turnip (49495) | about a year ago | (#44893847)

One of my everyday rituals is walking out of my office building and across the parking lot. During my walk across the parking lot, I ask Siri to call my wife. At some varying point, the building's Wifi cuts out and 3G kicks in. As soon as I read this headline, I knew exactly how it would apply to my life.

This would also be good for Pandora. My home's Wifi reaches almost to my street corner, so I can be several hundred feet away from my house using Pandora and still on Wifi. When I turn the corner, 3G goes on and Pandora cuts out because it lost Wifi. Again, another very practical use of this technology.

Re:Siri: Bad use case? (1, Redundant)

bradgoodman (964302) | about a year ago | (#44893897)

Pandora I can totally see. It's the antithesis of Siri. Very long, persistent, lots of data - a continuous stream. (Though other technologies, such as fragmentation at the application/asset level are often used here too - especially for video).

As for Siri - you have quite the edge case. It is an *extremely* small window between the transmission and then reception of the Siri transaction that you lose your Wifi.

Re:Siri: Bad use case? (1)

Anonymous Coward | about a year ago | (#44894437)

I think you basically nailed it. I bet that Siri is the beta test for multipath TCP before iTunes Radio starts to use it.

Re:Siri: Bad use case? (1)

immaterial (1520413) | about a year ago | (#44894767)

However, I've noticed I tend to use Siri on my way out of the house - getting directions somewhere, or setting up a reminder for the day, whatever. As such, the request tends to fall during the transition from my home wifi to the cellular network. I wouldn't be surprised if this is a common thing, since this would be a very common use case.

Re:Siri: Bad use case? (0)

Anonymous Coward | about a year ago | (#44894521)

That would be all great except this groundwork is not laid for that.

This is working up to a NSA mandated feature*. If you can segregate important data from bulk stupid data then the NSA doesn't need to process as much and can maybe finally run some queries on the data they already have and actually catch some terrorist.

It is all for your benefit, citizen, so they can listen in on the bad guys better while still listening to you. Think of the children.

*Mwahahaha

Re:Siri: Bad use case? (1)

Peter Kingsbury (3046159) | about a year ago | (#44894861)

>> I ask Siri to call my wife. At some varying point, the building's Wifi cuts out and 3G kicks in. As soon as I read this headline, I knew exactly how it would apply to my life. You and the couch are going to become BFFs?

The best thing I've heard about the new iPhone (4, Interesting)

timeOday (582209) | about a year ago | (#44893691)

This seems like a very fundamental improvement to the Internet for handling mobility, and a popular product like the iPhone should really boost adoption. Cellular communication is defined by the ability to pair with the best of several available routers, and switch from one to the other without dropping the connection - this is essentially what makes a cellphone different than a plain old cordless phone. But there has always been this annoying disconnect between the cellular network and the Internet, and this sounds like a big step in that direction. If we want super-mobile devices, like dick-tracy wristwatches, they will only have enough power for short-range communication so they will need super-dense infrastructure of some sort, like dynamically pairing with the nearest available wifi or smartphone - migrating connections to the Nth degree.

AT&T (0)

Anonymous Coward | about a year ago | (#44894095)

Theoretical at best. AT&T can't move from one tower to another without dropping a call, and that technology has been around forever.

Another hacker's dream (0)

Anonymous Coward | about a year ago | (#44894207)

I hope that this is implemented better than 99% of the software out there. This sounds like an excellent way of impersonating another device's connection. lol

IOS devices not very network friendly? (0)

Anonymous Coward | about a year ago | (#44894225)

I have run into issues with IOS devices appeared to be very "selfish" when trying to communicate. In one instance, the Netgear router at a vacation home was having problems and I traced it back to my iPad2 doing bunches of DHCP requests and exhausting the range. Another example is when we had issues with iPhones establishing, but not properly closing sessions when updating the mail client.

Wait, isn't this... (1)

bmo (77928) | about a year ago | (#44894239)

what UDP is for?

An example of an application that uses UDP is Mosh

http://mosh.mit.edu/ [mit.edu]

You can have various disconnections and reconnections (Since it's written by someone at MIT, say you're going in to the T @Davis and coming out at Kendall/MIT) and the connection with mosh looks like you never disconnected.

--
BMO

Re:Wait, isn't this... (1)

Richy_T (111409) | about a year ago | (#44894379)

And when you want a reliable connection?

Re:Wait, isn't this... (1)

bmo (77928) | about a year ago | (#44894431)

And when you want a reliable connection?

There is no such thing.

--
BMO

Protection against snooping? (1)

Anonymous Coward | about a year ago | (#44894289)

In cases where the NSA/five eyes hasn't compromised one of the two endpoints (or a spot close to an endpoint in the sense of multipath diversity), how much more difficult would multipathing make it to reconstruct the stream flowing through the connection?

Can I lock the screen orientation yet? (0)

Anonymous Coward | about a year ago | (#44894353)

The only thing I care about, WRT iOS, is whether I can lock the screen orientation. If I'm lying down while using my iPhone, I want to be in a position that I'm comfortable in, and not have to prop myself in one that will keep the screen oriented correctly.

Re:Can I lock the screen orientation yet? (0)

Anonymous Coward | about a year ago | (#44894877)

Good news! It's been in there for literally years. No longer must your ignorance prevent you from obtaining the iPhone of your dreams!

It's a good step, let's get that to VoIP. (1)

intermodal (534361) | about a year ago | (#44894375)

Smooth transitioning from 802.11abgn to mobile networks would sure be nice. Granted, it's not all VoIP, but that would be awesome.

More useful (0)

Anonymous Coward | about a year ago | (#44894533)

I hope they also enable an apps to run in the background for more than 10 minutes (i.e. for an ssh tunnel over wifi)

for(;;); (1)

Anonymous Coward | about a year ago | (#44894633)

Funny how old technology becomes new all over again. Multitasking, improved UI, and tcp protocol improvements? Sounds like it came straight out of the DOS era. :)

can't stand when terms like this get dumbed down (0)

Anonymous Coward | about a year ago | (#44894639)

"use case"? sure it's not a literally disruptive monetizing use case for early adopters with a steep learning curve?

Why not SCTP? (1)

TuringCheck (1989202) | about a year ago | (#44894803)

If a new protocol is needed at both ends of the connection why not use a less experimental and more capable one like SCTP? It is heavily used in telephony networks for SIGTRAN and is also supported by some servers for SIP and HTTP.
Wait, I know, because it's Apple!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>