Subject: Re: [Rmt] small group replication service, application-level multicast etc.

From: Rick Boivie <[email-masked]>
Date: Wed, 19 Mar 2003 14:00:14 -0500

>Actually, the Swarmcast system that we developed in late 1999 utilized
>Forward Error Correction combined with peer-to-peer (end-system)
>multicast to overcome the first-mile bottleneck in systems like this.
>
>I'd be happy to discuss this approach off-line with anyone that is
>interested.
>

Justin,  Thanks.  Can you provide a reference?
Rick

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Justin Chapweske <[email-masked]>
Date: Wed, 19 Mar 2003 13:29:47 -0600

> Justin,  Thanks.  Can you provide a reference?

Swarmcast was a commercial endeavor, so no papers were published on it.

An old article at 
(http://www.openp2p.com/pub/a/p2p/2001/05/24/swarmcast_beta.html) 
provides an overview of the system and I'd be happy to answer any 
questions about it off-line.

-- 
Justin Chapweske, Onion Networks
http://onionnetworks.com/

---

From: IMAI Yuji <[email-masked]>
Date: Thu, 20 Mar 2003 17:20:16 +0900

Justin,

  Reading the article you pointed out, your P2P mechanism
  is very clever system to copy a immutable file from peer to
  peer. If one peer that provide some part of copy but have not
  enough up-link bandwidth to deliver, request side peer look for
  other peers who connect via broader up-link and can deliver
  more while receiving from first one. And to compile several
  part from several node, FEC is used.

  Is my understanding correct?

  It is very interesting idea because popular file will be
  duplicated on many hosts broadly on the Internet already,
  requester can ask several peers to send different part of
  files while encoding FEC.

  But your system seems to be focused on the goal different from
  ours. For real time datagram exchanging like VoIP and video
  meeting, source of original is only one node and it is not
  difficult, I think nearly impossible, for the listeners to
  require other several nodes to relay each part of real time
  streaming data depending of various unsettled bandwidth
  situation.

  For me, this looks the example of "There is no one-fits-all
  multicast transport protocol."
----
Yuji

From: Justin Chapweske <[email-masked]>
Subject: Re: [Rmt] small group replication service, application-level multicast etc.
Date: Wed, 19 Mar 2003 13:29:47 -0600

---

From: Justin Chapweske <[email-masked]>
Date: Thu, 20 Mar 2003 11:43:26 -0600

>   streaming data depending of various unsettled bandwidth

While Swarmcast-like systems are optimized for static content 
distribution, they can certainly be applied to near-realtime delivery as 
well.

The tradeoff of using something like Swarmcast is that by encoding data, 
and delivering data out-of-order from multiple locations, you increase 
the latency of the communication.

So, for a near-live broadcast, you can easily buffer up 30 seconds of 
audio/video of data, and encode/interleave that chunk data swarming 
technologies.  So while the individual packets of the feed will be 
delivered out-of-order and from multiple sources in parallel, the 
overall feed can be reconstructed in its original sequential form.

So, while this approach obviously wouldn't work for a conference call 
VoIP application where latency is very critical, it might work well for 
a near-live news or sports broadcast where latency can be traded off for 
better performance and reliability.

>   multicast transport protocol."

So true.