| |||||||||||||
Fundamentally modifications to TCP are necessaryFundamentally modifications to TCP are necessaryPosted Apr 1, 2013 22:41 UTC (Mon) by marcH (subscriber, #57642)In reply to: Fundamentally modifications to TCP are necessary by paulj Parent article: Multipath TCP: an overview
> So, if you want to make use of multiple, disparate, network attachments, you need to do this above IP. Either you must modify TCP, or you must insert another protocol between IP and TCP (e.g. a shim, see shim6).
The original sin is actually quite simple: it's the lack of layering in TCP/IP. TCP should not "steal" and rely on IP addresses directly. Just like every other layer, the TCP layer should have a its own "host address" and some indirection logic to resolve it to IP layer address(es). This indirection logic would be the most natural place to implement mobility and all the other features Multipath TCP is offering. I'm sure there are a few good research papers explaining this.
Now of course it's way too late for such a dramatic change but keeping in mind the core shortcoming and the very theoretical but "correct" design helps understand all the numerous and more complex workarounds that keep being offered. I find.
(Log in to post comments)
Fundamentally modifications to TCP are necessary Posted Apr 1, 2013 23:14 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
In theory you could propagate routes for every host to the entire Internet and all hosts could move dynamically.
In practice it just doesn't scale, the overhead of letting the routing tables get that large just doesn't work at acceptable speeds.
Someday this may change.
It has changed for phones. It used to be that the area code and first three digits of the number routed you to specific buildings and then the last digits routed you out from that. so while there are still large chunks of landlines that mostly follow this model, phone number portability and cell phones make it so that any phone number can appear anywhere on the network.
now, the phone system only needs to find this to setup the conversation, not for each packet. This is the "smart network vs dumb network" discussion from above.
Given that the "smart network" of the phone system now tends to run on top of the "dumb network" of the Internet, I think it's pretty clear that the Internet has shows itself to be far superior
If you think about it, the Internet already has the layer of indirection you are talking about, DNS. The problem is that looking things up in DNS is far too slow and updates far too infrequently for it to be used in routing decisions for every packet.
Fundamentally modifications to TCP are necessary Posted Apr 2, 2013 2:44 UTC (Tue) by giraffedata (subscriber, #1954) [Link] Layering doesn't require TCP to have endpoint addressing that doesn't involve IP addresses, because it isn't that kind of layer. Now if TCP were a network topology layer, then it would need its own addressing and could easily do the kind of routing we're talking about. But I would not expect anyone to have designed TCP that way, because it would be redundant. The basic architecture of the Internet says routing packets to whatever ephemeral link happens to be up now is what the IP layer is for. A TCP driver is supposed to be blissfully ignorant of paths and concentrate on turning a blizzard of packets into an ordered, ungranular, reliable stream. The problem as I see it is just that IP hasn't evolved in a way that its routing protocols are sufficent for the needs of millions of handsets hopping from one wireless network to another. Considering that the original routing protocols were hardcoded files on each node, that's not surprising.
Fundamentally modifications to TCP are necessary Posted Apr 2, 2013 7:25 UTC (Tue) by marcH (subscriber, #57642) [Link]
An IP address conflates two things that should be separate: location (where) and identity (who). The latter should be in layer 4.
You don't ask the entire Post office to update ZIP codes when you move house.
It's not me saying it but the whole research community. Look at M-TCP, HIP, GTP (GPRS tunnelling), dynamic load balancing,... they are all try to somehow retrofit this separation in a backward, half-compatible way. Because it's too late it tends not to be pretty.
"As simple as possible, but not simpler" - too simple this time.
Fundamentally modifications to TCP are necessary Posted Apr 2, 2013 12:17 UTC (Tue) by paulj (subscriber, #341) [Link]
I don't think IP conflates these. It just wasn't an issue on the horizon in the design of IP. That said, the original designers of IP did envision that further addressing schemes (e.g the "associative addressing" Cerf & Kahn referred to in their '74 paper) might be layered over TCP.
Sadly, the designers and implementors that followed chose to prioritise short-term performance concerns over the long-term flexibility of IP. It became effectively impossible to insert new protocols between IP and TCP (in the sense of it having an IP protocol number != TCP).
It might still be possible to insert an identity layer. The lower 64 bits of the IPv6 address could be used for this. Unfortunately though:
a) There's no guarantee IPv6 will succeed
b) Even if it does, there are (as usual) short-sighted people out there pushing to abolish the split in IPv6 addresses between network and host ID portions ("Why should we limit the hierarchical network space to 64 bits? Why do we need 64 bits for a host?").
So we shall see if this is possible. Otherwise, it has to be done in TCP.
Identity is a very complex issue. It can mean different things to different people/processes at different times. Think about the identity for an email address, or an SSL cert, or a web page - you can surely think of many different scenarios and distinct issues for each. At the network layer, it is very hard to come up with a universal meaning of identity other than "the location in the network". Identity is an issue that really can't be solved at the network layer, other than equating it with location. Even a shim protocol between TCP and IP can't really say more than "these 2 network locations appear to be controlled by the same entity, around this time".
Anyway... :)
Fundamentally modifications to TCP are necessary Posted Apr 2, 2013 16:15 UTC (Tue) by giraffedata (subscriber, #1954) [Link] An IP address conflates two things that should be separate: location (where) and identity (who). The latter should be in layer 4. I'm with you on there being a need to separate location and identity, and to do it by layers, but it looks like all part of layer 3 (network layer) to me. One should be able to direct any IP packet to an identity, not just a TCP stream. That's just speaking of ideals, of course. I'm not saying that's the direction we should be going now. There is a layering issue between TCP and IP in that the TCP port address shouldn't be in the IP packet header. I wouldn't want to confuse that with this.
|
|||||||||||||