next up previous contents
Next: 4.3 The eXtended User Up: 4 Problem Documentation and Previous: 4.1 The Nature of

4.2 The Notion of Timed Obsolescence

Figure 4.6 shows a great way of visualizing the ``packaging'' of a typical internetworked datagram delivery service. The data to be sent over the network is wrapped by a layer that is recognized by the delivery service that will be used, and contains at least a ``To:'' address field for the destination and most likely a ``From:'' address field to let the recipient know who sent the package.

  
Figure 4.6: A typical datagram, from the post office point of view.

A reliable delivery service will keep attempting to deliver a package until the recipient successfully receives it. This can sometimes take a long time and use up quite a bit of system resources, especially if the receiving end has gone on vacation! Postal services have a number of ways of dealing with this situation, eventually resulting in the undeliverable package ending up in the dead letter office or back at the sender's door. The Internet Protocols, as they stand, don't have a happy medium between fully reliable delivery and unreliable delivery:

UDP
offers a best-effort delivery service. While the ``best effort'' of most parcel shipping services involves several attempts at delivery and very few lost or untraceable packages, UDP's best effort gives delivery one chance and upon failure, discards the data entirely.
TCP
employs a fully reliable delivery service. It ensures that all data is received at the destination, barring complete disconnection of service.

A semi-reliable data transmission system is needed fill the gap between the reliable and the unreliable. Much like the postal services, the system should know when to ``give up'' and stop trying to deliver certain packages. But, unlike the postal services, this transmission system could treat each parcel of data differently, rather than under a single policy that covers all packages.

What if data could expire if not successfully delivered within a certain amount of time?

Such would be the case for a parcel of fruit or other food - it would have an expiration or ``sell by'' date, as in Figure 4.7. If the recipient receives the fruit after the expiration date, the fruit is simply discarded. Better yet, if the sender knows that the fruit will not reach the recipient in time, the fruit will never be sent in the first place. Timed obsolescence lets applications label data with an expiration date, quantitatively assigning a time at which that data will become obsolete.

  
Figure 4.7: A datagram with a ``sell by'' date!

The earlier example of the ``bouncing ball'' video stream (reprinted in figure 4.8,) managed to preserve the time relationship of the video frames. It can now be seen that this behavior is congruent to what would be exhibited by a system implementing timed obsolescence. In this specific case, for whatever reason, frame four of the video stream could not be delivered in its entirety before its time to obsolescence or ``expiration date.'' Instead of sending now useless data in an attempt to fill in lost components of the parcel, the sending and receiving sides discard what data they have remaining and/or unacknowledged and continue on with the transfer.

  
Figure 4.8: Frames in a damaged but linear time relationship preserving video stream of a bouncing ball

In summary, an internetworked multimedia data transmission system with the ability to timestamp parcels of data with expiration dates could not only preserve the linear progression of timed sequential data at the user's end in the face of network congestion related data loss and delay, but could reduce network bandwidth significantly by not attempting to transmit or retransmit data that has outlived its usefulness.


next up previous contents
Next: 4.3 The eXtended User Up: 4 Problem Documentation and Previous: 4.1 The Nature of

Mike Andrews
Wed Mar 19 16:07:58 EST 1997