From: Daniel Lowd (lowd@cs.washington.edu)
Date: Sun Oct 10 2004 - 23:26:23 PDT
This paper described a new class of erasure codes, designed for
computational efficiency, and demonstrated their effectiveness for
multicast data distribution. An erasure code that offers great
computational speed-ups at only a limited size cost seems like an
excellent achievement. Software distribution seems like a natural
application for such a code, where this complexity/size tradeoff makes
sense.
I found it unfortunate, however, that they gave 3 full pages of background
before fully describing their contribution. I appreciate the
introduction, but found the emphasis on this "digital fountain" analogy to
be unnecessary, even misleading. It's really more about this "Tornado"
code than it is about fountains... and the fountain analogy does not fully
apply, since under the Tornado encoding you actually need a number of
drops that's (1 + \epsilon) * thirst, rather than just equal to your
thirst.
The end was stronger than the beginning: I think that their experiments
successfully showed the viability of their approach. I liked that they
compared both to Reed-Solomon codes (for speed) and interleaving (for
efficiency). I also liked that they included both simulated and
real-world tests, under a variety of scenarios. The experiments included
here seemed much better than most conference papers I've read. I don't
know if there are any other common multicast techniques or scenarios that
they should have included for completeness. The one change I would
request (had they time) would be to include some baseline, such as
interleaving, in the final experiment of distinctness/decoding/reception
inefficiencies.
I think that this work continues to be relevant as people seek to transfer
larger and larger files over the internet, such as disc images for new
Linux distributions, radio programs (e.g., the new Hitchhiker's Guide to
the Galaxy radio show), and even TV shows. Methods such as this one, if
not used already, could help reduce bandwidth requirements for these
applications and facilitate the birth of new applications.
-- Daniel
This archive was generated by hypermail 2.1.6 : Sun Oct 10 2004 - 23:26:24 PDT