Communications Triage


IEEE Spectrum Magazine, Jan. 2001


The speaker was talking about the first of about seven bullet points on the slide, but my eyes were captivated by the sixth point.  “Communications triage,” it said.  Now that sounded interesting.  While the speaker was describing the earlier points in some detail, I started to think about my email problem.  Communications triage was exactly what I needed.  This sounded like a great concept.  However, having failed at the use of various email filters in the past, I despaired of any solution to the love/hate relationship I have with my electronic correspondence.  Nevertheless, an idea began to grow on me.

Social solutions to the email problem have failed.  We’re all locked into this compulsion where we have to log in at midnight from some faraway hotel in order to download the hundred messages that await our action.  And heaven help us if we shirk this duty, because the next day there will be two hundred.  From there we descend to insanity.

So, I thought, why don’t I have this same problem with surface mail?  Well, the surface mail doesn’t find me at that hotel late at night.  The more I thought about this, the more I started the think about the virtues of surface mail.  Over the course of centuries we have evolved a workable relationship between the post office and ourselves.  The problem with email is that it happened too fast and we weren’t ready for it, and now we’ve painted ourselves into a corner where there is no escape.  So I’d like to propose a technological solution to this social quandary.  My thought is that we simply need to make email more like surface mail.  As technologists we can impose architectural changes that do this.

First we need deniability.  People are always asking me, “Did you see my email about the widget crisis?”  You can’t say no, because it obviously got to you, and the only reason you didn’t see it was because you didn’t handle your email like you’re supposed to.  Surface mail doesn’t have this problem, because the widget letter may have been lost or delayed.  Such mishaps don’t happen with email, but we can fix this.  The trouble with our current systems is that the address lookup in the DNS is too good, and the transmission via TCP is too reliable.  Some small changes in the protocols could fix this troublesome perfection.  But here is the key point: incorrect addresses, delays, and errors in transmission should be inserted randomly.  This gives everyone complete deniability.  Indeed, you may not have gotten that widget message.  They’ll never know for sure.

The BGP routing algorithms could be altered so as to misroute packets at some pre-determined rate, chosen for social optimization.  Additionally, the time-to-live fields in some packets could be made extremely large, so they could float for months in circular paths between routers.  There could be dead-letter queues of semi-infinite length, which could best be designed by the people who organize bank lobbies.  That urgent email may not have arrived, but you are blameless.  As an additional bonus, because of incorrect DNS translations you would occasionally get email addressed to someone else.  Sometimes these would be very interesting messages.

Torn envelopes and illegible text could be simulated by small changes in TCP.  Alteration of the packet number on an occasional basis would result in garbled reconstruction of the text, and ignoring the erroneous CRC in error-laden packets would simulate the effect of letters that had become sodden with rain.  You would be reading the email message, saying, “and therefore you must take the following immediate action: syzz&*q34qa.”  What follows would be complete garbage, and you could go to sleep in peaceful ignorance.  Your innocence would be preserved.  Instead of working on information assurance we should be creating information ambiguity.

We discovered long ago that it is best to have the post office take off weekends and many obscure holidays.  Of course, the routers could be instructed to do the same.  A simple “if” statement would suffice to stop forwarding of packets if the date coincided with the birthday of one of the fathers of the Internet.  On certain random dates a snow emergency could be declared on the Internet, in spite of a possible heat wave, and everyone would freed of electronic communication for the day.  Furthermore, email delivery could be optimized to once a day at a predictable time.  We would no longer need to work in the interrupt mode because of the capricious arrival of seemingly urgent messages.  Imagine how peaceful life could be!

Another problem with email is that it is too easy to generate.  In the paper world there are small, but significant, barriers to the writing and mailing of letters.  Things like stamps and envelopes and trips to the post office have served us well.  We could take a hint here and make it less easy to generate email.  For example, we could subcontract the design of the email GUI to the IRS (the US tax agency).  There would be small print at the bottom of the GUI indicating that the estimated time to complete the form would be 20 minutes, or something like that.  Instead of a subject line, email could have a graphical simulation of an envelope, so that you could see the “you may already have won $1 million dollars!” designating junk mail without having to open the envelope.

The length of email is also a fixable problem.  Again, a change to TCP might be the solution.  Currently, the TCP algorithms use a slow start, building up speed until they encounter a lost packet.  Maybe, instead of “slow start”, we could employ “slow finish”.  Packet transmission would start at a rapid rate and then continue to slow down until it was virtually stopped.  Long emails would be thus discouraged.

Of course, if all these measures were to be taken, then email and surface mail would be identical.  That would be undesirable too.  But perhaps there is a social optimum somewhere in between the instant perfection of email and the slow uncertainty of surface mail.  By backing off on perfection and instituting small amounts of randomness and uncertainty, the world might be a more pleasant place. 

In case anyone is tempted to take this advice seriously, please don’t.  My suggestions are but a passing, satirical dream, and, incidentally, I never did find out what the speaker meant by “information triage”.

 

Robert W. Lucky

rlucky@telcordia.com