VINT CERF: ADDING DELAY AND DISRUPTION TOLERANCE TO OUR LIST OF REQUIREMENTS

Dr. Vinton Cerf (NSF video, bio) continues to energize, as well as build, the Internet. One of the true fathers of the Internet, his first role (while a grad student) was to write some of the initial code to allow packets of information to move reliably from one computer to another. Now he serves as Google's Chief Internet Evangelist, as well as continuing to work with NASA and the world on the InterPlaNetary Internet (seriously).

cerf

I had the pleasure of attending Dr. Cerf's talk at the first Center for Work, Technology and Organization Distinguished Industry Research Lecture (I'll update with a link to the podcast when it's available). His presentation was wide-ranging, covering:
  1. History of the Internet and his role
  2. Possibilities for sensor nets (including how to better manage your wine cellar)
  3. Opportunities for the semantic web
  4. The opening of Internet addresses to non-Latin characters, and the complexities therein
  5. Bit Rot -- I'll try and address this one soon
  6. Delay and disruption tolerant networking (needed for the InterPlanetary Internet as satellites go behind planets, the Sun, deal with astronomical distances, etc.)
  7. Cargo Cults
He also provided thoughts on why members of younger demographics prefer communication with real-time updates (e.g., Twitter, IM, Facebook) over asynchronous modes (e.g., email). He argued that this preference is due to younger social/work groups being more local. He believes that as peoples' friendship and work become geographically dispersed (i.e., later in their careers), asynchronous communication becomes more valuable. I see an opportunity to connect Dr. Cerf's thoughts on human communication preferences and his research on delay and disruption tolerance in the InterPlanetary Internet.  Modern work settings are full of delays and disruptions: time-zones, multiple projects and demands, multiple sets of organizational boundaries. Delay and disruption tolerance is something we should all design for -- whether it be because we want to crash a sensor into a comet, or because we want a new product to make it to market. I'm going to add DaDT to my list of requirements for All of Us as Systems Designers. Slowly but surely I'm building a list, and this requirement seems critical in modern work environments.