Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Ghosts of Unix past, part 3: Unfixable designs
Posted Nov 17, 2010 4:28 UTC (Wed) by neilbrown (subscriber, #359)
I can tell you what I was thinking of in the "IP protocol suite" questions though, as no-one seems to have taken a stab that those in the comments.
The 'full exploitation' in IP relates to UDP. It is most nearly an application layer (layer 7) protocol (as applications can use it to communicate) yet it is used a multiple levels of the stack - particularly for routing (at least back when we used RIP. BGP uses TCP) which is a layer 3 concern. It is used for VPNs and other network management. And even sometimes for application level protocols.
The "conflated design" in IP is the fact that end-point addresses and rendezvous addresses are equivalent at the IP level. They aren't at higher levels. "lwn.net" is a rendezvous address, but the IP level you only see 18.104.22.168, which could (in a shared-hosting config) map from several rendezvous addresses. So upper level protocols (like http/1.1) need to communicate the *real* rendezvous address, because IP doesn't.
The "unfixable design" in IP is obviously the tiny address space, which we have attempted to fix by NAT and VPNs etc, but they aren't real fixes. Had IP used a distinct rendezvous address it would have only been needed in the first packet of a TCP connection, so it would have been cheap to make it variable-length and then we might not have needed IPv6 (though that doesn't really address UDP).
So those were my thoughts. I haven't spent as much time fighting with network protocols as I have with the Unix API so I'm a lot less confident of these ideas than of the ones I wrote formally about.
Posted Nov 17, 2010 4:40 UTC (Wed) by dlang (✭ supporter ✭, #313)
Posted Nov 17, 2010 10:00 UTC (Wed) by iq-0 (subscriber, #36655)
Posted Nov 17, 2010 23:23 UTC (Wed) by dlang (✭ supporter ✭, #313)
at the time it was designed, there were a lot of things that it did that were not possible in IPv4, but most (if not all) of the features that people really care about have been implemented in IPv4
Posted Nov 18, 2010 8:11 UTC (Thu) by Cato (subscriber, #7643)
However, Mobile IP is much better implemented in IPv6 so you don't get inefficient 'triangular routing' - http://www.usipv6.com/ppt/MobileIPv6_tutorial_SanDiegok.pdf
The biggest benefit of course is not having to use NAT for IPv6 traffic.
Posted Nov 18, 2010 13:19 UTC (Thu) by vonbrand (subscriber, #4458)
Yep, that's why people are clamoring for NATv6 ;-)
(Just as the idiotic firewalling going on has made everything run over HTTP.)
Posted Nov 18, 2010 4:27 UTC (Thu) by paulj (subscriber, #341)
So to look for conflation in networking addressing you probably need to stay within a layer. E.g. within IP, there is conflation in addressing because each address encodes both the identity of a node and its location in the network. Or perhaps more precisely: IP addressing lacks the notion of identity really, but an IP address is the closest you get and so many things use it for this. This may be fixed in the future with things like Shim6 or ILNP, which separate IP addressing into location and identity. This would allow upper-layer protocols like TCP to bind their state to a host identity, and so decouple them from network location.
Variable length addresses would have been nice. The ISO packet protocol CLNP uses variable length NSAP addresses. However, hardware people tend to dislike having to deal with VL address fields. The tiny address space of IPv4 perhaps needn't have been unfixable - it could perhaps have been extended in a semi-compatible way. However it was decided (for better or worse) a long time ago to create IPv6.
Possibly another problem with IP, though I don't know where it fits in your list, is multicast. This is an error of foresight, due to the fact that multicast still had to be researched and it depended on first understanding unicast - i.e. IP first had to be deployed. The basic problem is that multicast is bolted on to the side of IP. It generally doesn't work, except in very limited scopes. One case is where it can free-ride on existing underlying network multicast primitives, i.e. ones provided by local link technologies. Another is where a network provider has gone to relatively great additional trouble to configure multicast to work within some limited domain - needless to say this is both very rare and even when done is usually limited to certain applications (i.e. not available generally to network users). In any new network scheme one hopes that multicast services would be better integrated into the design and be a first-class service alongside unicast.
Another retrospectively clear error is IP fragmentation. It was originally decided that fragmentation was best done on a host by host basis, on the assumption that path MTU discovery could be done through path network control signalling and that fragmentation/reassembly was a reasonably expensive process that middle-boxes ought not to be obliged to do. IMO this was a mistake: path MTU signalling turned out to be very fragile in modern deployment (IP designers didnt anticipate securo-idiocy); it turned out fragmentation/reassembly was relatively cheap - routers routinely use links both for internal buses and external connections which require fragmenting packets into small fixed size cells. As a consequence of the IP fragmentation choices, the IP internet is effectively limited to a (outer) path MTU of 1500 for ever more, regardless of changes in hardware capability. This causes problems for any IP packet protocol which wants to encap itself or another. One imagines that any new network scheme would learn from the IP MTU mess, make different trade-offs and come up with something better and more robust.
We should of course be careful to not overly condemn errors of foresight. Anticipating the future can be hard, particularly where people are busy designing cutting-edge new technology that will define the future. ;)
Posted Nov 18, 2010 8:13 UTC (Thu) by Cato (subscriber, #7643)
http://en.wikipedia.org/wiki/IPv6#Features_and_difference... has a good summary of the benefits of IPv6 including this one.
Posted Nov 19, 2010 1:15 UTC (Fri) by dlang (✭ supporter ✭, #313)
this isn't just that clock speeds are higher, but that the ratio of clock speeds to the system bus speeds is no longer 1:1, this means that it's possible to execute far more steps without slowing the traffic down.
Posted Nov 19, 2010 11:15 UTC (Fri) by job (guest, #670)
Posted Nov 19, 2010 11:41 UTC (Fri) by Cato (subscriber, #7643)
You can probably manage to forward anything in hardware, but it helps somewhat that IPv6 has a regular header design.
IPV6 and hardware-parseable IP headers
Posted Nov 19, 2010 23:26 UTC (Fri) by giraffedata (subscriber, #1954)
And from what I've seen, as the cost of routing in a general purpose CPU has come down, so has the cost of doing it in a specialized network link processor (what we're calling "hardware" here) -- assuming the IP header structure is simple enough. So today, as ten years ago, people would rather do routing in an ASIC than allocate x86 capacity to it.
I think system designers balance system bus and CPU speed too, so it's not the case that there are lots of idle cycles in the CPU because the system bus can't keep up with it.
Posted Dec 3, 2010 9:05 UTC (Fri) by paulj (subscriber, #341)
Posted Nov 19, 2010 11:18 UTC (Fri) by job (guest, #670)
One thing I never really understood is why TCP MSS is a different setting from MTU. Given the belief that the MTU could be auto detected, MSS could be deduced from it.
Perhaps someone can enlighten me?
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds