Slashdot Mirror


Vint Cerf on Why TCP/IP Was So Long in Coming

whitehartstag writes "TCP/IP is 25 years old this year. Vint Cerf says there was a long development cycle for both TCP/IP and for X.25, and we'd have been using TCP/IP much sooner if TCP/IP had been more marketable. 'Over the years, we can come up with many examples both of where the best technology did (or did not) win and of how marketing has defined a service. For example, many of the "best" features of frame relay, such as the ability to use Switched Virtual Circuits (SVC) in addition to Permanent Virtual Circuits (PVC) were never widely marketed because the pricing was too complex. Rather, the PVC was a simple replacement for a leased line at a fraction of the cost with better performance.'"

19 of 83 comments (clear)

  1. where's the content? by jessecurry · · Score: 4, Insightful

    I know that there isn't much real content on the web anymore, but that's not even an article. Where the hell is the content?

    --
    Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
    1. Re:where's the content? by jd · · Score: 4, Funny

      You need to run the article through a ROT13 filter, followed by the Bible Code decoder and finally the Redneck filter, to get the URL of the real article. This encryption technique was developed to prevent the real server being slashdotted.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    2. Re:where's the content? by Tablizer · · Score: 2, Funny

      I know that there isn't much real content on the web anymore, but that's not even an article. Where the hell is the content?

      It's split up. One packet went to Australia, another to Zimbabwe, and another to

  2. Seems normal. by jd · · Score: 4, Interesting
    Pricing complexities are why multicast is taking so long to reach the home, even though it has been enabled clear across the entire backbone up to the local ISP level for over a decade. The virtual circuits costing issue is presumably part of why MPLS is also somewhat of a rarity. Of course, this does raise some questions, one of which is why - when the early Internet and IPSS were Government-funded, mostly Government-run, intended to be fault-tolerent and suitable for military use - cost was a factor at all. Big business did not enter the X.25 or TCP/IP markets until very late in the game, and most initially used gateways off their own internal network protocol. The Internet's native protocols should have had no impact at that time.

    So why is it normal for the immaterial to matter more than the significant? It is normal, but it is also irrational and nonsensical.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:Seems normal. by techpawn · · Score: 3, Funny

      I guess this moderator thinks that 'troll' means "I didn't understand a word you just said".
      No no no! Didn't you get the memo? For the time being Moderators are to use Overrated, Flamebate, and Troll until the new options of -1 Unpopular, -1 Shut-up, and -1 I-just-don't-like-you are rolled out. It's just a workaround, so be patient.
      --
      Ask not what you can do for your country. Ask what your country did to you
    2. Re:Seems normal. by jd · · Score: 2, Funny

      Maybe he does. I've not seen 3Com for a while and Bay went belly-up. If he was the chief designer for those two, it would explain what happened to them.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  3. A little more here... by XanC · · Score: 4, Informative

    Apparently the "article" is a response to a comment (the only comment, mind you) attached to this "article", which is similarly content-free.

    1. Re:A little more here... by Megaweapon · · Score: 3, Informative

      Plus the submitter's name+link goes to the same site, so I'm guessing this is just more NetworkWorld clickbait for Slashdot.

      --
      I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
    2. Re:A little more here... by LMacG · · Score: 3, Funny

      NetworkWorld Accountant: Ad revenue seems to be off this week. Quick, somebody submit a story to Slashdot! (Before Computerworld does the same thing!)

      --
      Slightly disreputable, albeit gregarious
  4. TCP/IP still needs a rewrite by Anonymous Coward · · Score: 2, Interesting

    Unfortunately, for all of us, IPv6 is heading our way like some rusty old stream train. Its rickety and badly designed, but massive, and will squash anything in the way.

    IPv4 at least was designed well, and has lasted a long time. However, IPv6 has no firewall/NAT support (if you are in a company, you have to have a firewall, else you run afoul of a lot of corporate regs like SOX, HIPAA, and if doing credit cards, PCI). You can't tunnel or VPN (if you do, you pretty much do IPv4 routing as a kludge.) Finally, it doesn't support a person having their own permanent IP range. You are forced to use a subset of the range of whomever you are connecting to, and if you change ISPs or peers, you have to completely re-IP your servers.

    Of course, the opportunity was missed to have crypto at the IP level, rather than have it bolted/kludged on (like IPSec.)

    1. Re:TCP/IP still needs a rewrite by jd · · Score: 2, Informative

      IPv6-over-IPv6 seems to work ok. Some of the earliest routing protocols provided firewalling and NATting within the routing protocol itself (Telebit's router provided superb NAT and Firewall capabilities as an integrated facility). Permanent addresses lead to fragmented heirarchies and exploding routing tables, which is a major problem with IPv4.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    2. Re:TCP/IP still needs a rewrite by bendodge · · Score: 3, Insightful

      It seems to me like most of the things you listed as missing were things IPv6 was specifically designed to get rid of.

      --
      The government can't save you.
    3. Re:TCP/IP still needs a rewrite by gclef · · Score: 5, Informative
      So much misunderstanding crammed into such a small post. I'm impressed.

      However, IPv6 has no firewall/NAT support

      IPv6 partisans strongly discourage NAT, but there is nothing in IPv6 that will prevent it. Firewalling is still possible in IPv6, and is assumed to continue.

      You can't tunnel or VPN

      Where in the world did you get that from? There are several tunneling protocols supported as standard in IPv6. 6-in-6, IPSec, GRE...take your pick.

      Finally, it doesn't support a person having their own permanent IP range. You are forced to use a subset of the range of whomever you are connecting to, and if you change ISPs or peers, you have to completely re-IP your servers.

      This is untrue. ARIN (and most other RIRs) changed their allocation policy a year and a half ago. At present, if you qualify for Provider-Independent space in IPv4, you will also qualify for PI-space in IPv6.

    4. Re:TCP/IP still needs a rewrite by TheBracket · · Score: 5, Informative

      A lot of your "missing" features of IPv6 are exactly what it was meant to eliminate! You absolutely can firewall IPv6 (just as you can firewall a regular routed IPv4 space; a default stateful "outbound only" IPv6 firewall is every bit as secure as a similar IPv4/NAT setup). OpenBSD's pf has supported firewalling IPv6 for years; I'm pretty sure ipfw on FreeBSD has it, too. Iptables on Linux also seems to support it.

      NAT isn't something to be missed. The number of nasty kludges required to get protocols that require two peers each behind a NAT to communicate is ridiculous, and a lot of protocols (VOIP, P2P, most games, etc.) can be simplified quite a bit when you take out the various NAT-hole punch routines.

      Juniper already ship IPv6 capable VPN kit, you can do it on various open source platforms with things like tinc, and Windows Server 2008 supports it.

      In other words, IPv6 is taking a long time, but it's getting there - and support for essential features is developing decently well. I'd recommend getting familiar with it now; even if it never materializes in its current form, it's a good idea to play with lots of different setups and be ready for anything!

      --
      Lead developer, http://wisptools.net
    5. Re:TCP/IP still needs a rewrite by Watson+Ladd · · Score: 2, Informative

      You are just wrong half the time, and half wrong all the time. First off, a firewall is a piece of software that prevents packets from getting through. It can work with IPv6 just fine. Tunneling and VPN is what IPSec is for in tunnel mode. IPv6 mandates IPSec support, so I don't see how that is a kludge. Finally the mobility of IP addresses across ISPs leads to exploding routing tables. It's just not an option.

      --
      Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
  5. Argh! Typo! by jd · · Score: 2, Informative

    The translation list is here.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  6. Re:no by Tim+the+Gecko · · Score: 2

    Any ISP that uses RIPv2, OSPFv3 or ISIS on their internal network - or to connect to other networks - uses multicast for the routing protocol.
    True, but irrelevant in considering whether a customer might one day get IP multicast on an ISP connection. The routing protocols you mention (and OSPFv2 as well) use multicast packets with TTL=1 to exchange information across a LAN. Not at all the same thing - no multicast forwarding tree in sight!

    as of 2002.
    Which says everything you need to know about interdomain IP Multicast on the public internet. In contrast, it's doing pretty well on private VPNs (CEO "egocasts" and that kind of thing).
  7. Re:no by jd · · Score: 4, Insightful
    Customers are almost certain never to get IP Multicast, but (probably) not for technological reasons. It's easy to bill per stream, for unicast streams, but harder for multicast. And, let's face it, there are certain segments of the entertainment industry - not just the *AA's - that have a vested interest in providing heavily metered audio/video streams. Multicasting has the potential to slash revenue by an order or two of magnitude. It's also easier to guague interest (for advertising reasons) for unicast connections than for multicast. And since unicast demands more on the CPU and on the pipe, machine manufacturers and ISPs have financial incentives to encourage customers to use the least-efficient delivery format possible.

    If the customers are the only ones who could gain, and everyone else would lose, then who is going to be insane enough to switch on multicast routing to the home?

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  8. Re:no by Drishmung · · Score: 2, Insightful
    The benefit of multicast is to the network provider. Where the same stream needs to be sent to many (thousands) of customers, multicast has a huge benefit. In fact, for 'push' content delivery it is the only viable means of networking.

    And cable has been able to deal with the pricing issues for decades. The content is encrypted, with multiple keys---one for each subscriber. Anyone else can receive the multicast, but it does them no good without the key. When you join the stream, you not only join at an IP level, you authorise against the broadcaster and your key is enabled. For which you are sent a bill.

    So, content provider gets to sell content to consumer, and network provider reduces costs. Content provider also knows exactly who has received the content.

    For unencrypted content your points are valid, however even there a strong economic case can be made for multicast. Each consumer pays for bandwidth, so there is no direct cost benefit of multicast for them. But, it is in the network provider's interest to reduce costs, and by reducing bandwidth, multicast does this. Finally however, the content provider also has to buy bandwidth from somewhere, namely their upstream provider. They also have to serve that content. The economic benefits of a single server and 100Mbps (multicast) vs tens/hundreds of servers and 10Gbps (unicast) are fairly compelling to potential video content providers, if not to traditional text/web providers.

    --
    Protoplasm. Quiet Protoplasm. I like quiet protoplasm.