Happy birthday TCP/IP

TCP/IP is frequently held up as a model for the type of lightweight standard that libraries and affiliated communities should aim to develop. But what goes into developing a “lightweight” standard? And how long does it take?

I heard a brief interview on NPR earlier this month that marked the 25th anniversary of TCP/IP. The interview was with Vinton “Vin” Cerf, one of the two creators of TCP/IP (the other was Robert Kahn). I was amazed to hear that this lightweight standard took 10 years to develop — the first five years were spent defining requirements, and the second five years were spent implementing on a variety of systems.

This interview got me thinking about what goes into lightweight standards development. Part of it might be “less than perfect, good enough.” TCP/IP makes a “best effort” for delivery — the standard does not guarantee delivery of packets (although it works pretty well, there are some very small number of failures). Another lightweight component is scope — the standard is scoped to do a small thing, not everything. Yet another aspect is design. Something small must be well designed, which takes time.

Hopefully as we are looking towards new standards being designed (or towards the retooling and redesign of existing standards), it will not take as long as 10 years. After all, we now have TCP/IP to speed our work along! But good standards specification and development does take time.

Vin Cerf is currently Vice President and “Chief Internet Evangelist” at Google.

Tweet about this on TwitterShare on TumblrShare on LinkedInShare on FacebookBuffer this pageShare on Google+Email this to someone

3 Comments

  1. You say ‘TCP/IP makes a “best effort” for delivery — the standard does not guarantee delivery of packets (although it works pretty well, there are some very small number of failures).’ I think that’s nearly but not quite right… if my memory serves me right, IP does not guarantee delivery, but the higher level TCP (transport control protocol?) does. TCP takes the packets that IP delivers and puts them in proper sequence (they could have come via different routes), plus requests re-transmission of any missing packets. It’s a brilliant idea: reliability built on unreliability. Sounds an essential lesson for those interested in long term preservation!

    BTW in this respect TCP/IP contrasts with UDP/IP, which delivers unreliable datagrams (as it says on the tin!).

  2. Chris,

    It is so nice to hear from you. I know very little about this, I’m only going by what I heard in the interview and what I (admit to having) read in a Wikipedia article on the topic. I defer to your knowledge. You are very kind of not having called me out on the difference between standards and protocols, but this is a conversation between friends, right?

  3. Since we’re amending and adding. Vinton really goes by ‘Vint’. He actually served on some RLG system development visiting committees in the early days.
    And one of the other reasons that TCP/IP may have taken so long to emerge is that it was widely criticized at the time and held up against the architectural demands of the Open Systems Interconnection (OSI) model (which it didn’t fit very well). IBM and others were big supporters of the OSI model and consequently there were competing transport mechanisms for awhile. Obviously I’m not a technical person but I sat at tables where this was discussed during that time and there were stunningly heated exchanges surrounding this.

Comments are closed.