From: Alan L. Liu (aliu@cs.washington.edu)
Date: Sun Oct 10 2004 - 21:43:46 PDT
One of the problems with multicast is that of deaing with lost packets,
because the source may not be able to handle all the retransmission
requests, and multicasting the duplicate packets is wasteful. One way of
dealing with this is to add duplicate information into the stream such
that any subset of packets of a certain minimum size can reconstruct the
original file.
The paper does a good job explaining the drawbacks to existing methods
for multicast distribution. Reed-Solomon codes aren't perfect for
multicast distribution because they are computationally expensive on
large blocks. By relaxing one of the constraints and allowing a subset
slightly bigger than the original file size, one can use a less
computationally expensive technique, tornado encoding, which is also
more tolerant to burst errors because packets can be sent out in any
random order.
Unfortunately, in comparing tornado encoding to using Reed-Solomon
codes with interleaving, the paper used what appears to be an extremely
small trace. Three distinct sites and only up to twenty simultaneous
connections? When compared against traces used by other research, this
seems tiny.
In addition, although they claim that tornado encoding could be used
for things like real-time video in parts of the paper, the paper
specifically counts that out as a feature when describing how tornado
encoding is resistant to burst errors. In order to make up for this
inconsistency, results for burst errors on tornado encoding without
randomization should also be included.
In general, there is not a whole lot of motivation behind creating a
digital fountain. Broadcast transmission of data sounds like it would
naturally fit a streaming multimedia type application, but nowhere does
it say how to tornado encode new bits as they arrive in a low-latency
fashion. In fact, all the tests suggest a static file is what is
transmitted. If that were the case, then it's interesting how the
assumption was that there was one source with the responsibility to send
the file out for as long as other hosts were interested in it, while in
a scheme like bittorrent, all hosts share partial responsibility for the
data as long as they are interested in it, and the initial provider can
go away as long as there is a full copy among the other hosts. While
this paper assumes the upload bandwidth and latency of non-source hosts
is virtual nil, bittorrent makes the assumption that there is a lot of
it, mostly wasted otherwise.
As far as future work for this digital fountain approach goes, I think
more thought should go into how to deal with distributing streaming data
efficiently. This is where solutions like distributed caching and
bittorrent are insufficient.
This archive was generated by hypermail 2.1.6 : Sun Oct 10 2004 - 21:43:48 PDT