Plans for Multicast?

[movgp0]

Hi,
I've looked at how BitTorrent work. It is a very good protocol design.

But if I look at my Upload/Download-ratio from Bittorrent and from my
last-mile-ADSL I'm missing support for an parallel-existing and
cross-excanging[1] multicast deployment tree where possible.

In fact I think on an hybrid protocol between (Fat)Nemo[2] and
BitTorrent[3].

As an given Example see [4]. Distribute torrents over the Internet per
Unicast and within the (NAT-less) LAN over Multicast[5]. For End-Users
it is currently not really possible to distribute files in these
manner because of the lack of Applications doing so.

Are there any plans to implement such a feature?

Sincerly,
MovGP0

[1] Meaning that unicast-nodes exchange data with multicast-nodes over
unicast channels for backward compatibility.
[2] http://www.aqualab.cs.northwestern.edu/Nemo.html
[3] http://bittorrent.com/introduction.html
[4] http://groups.yahoo.com/group/BitTorrent/message/6065?threaded=1
[5] I think also on a kind of (auto-setup) streaming-proxy.
[6] http://groups.yahoo.com/group/BitTorrent_help/message/9656
?threaded=1






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Justin Cormack]

Post by movgp0
Hi,
I've looked at how BitTorrent work. It is a very good protocol design.
But if I look at my Upload/Download-ratio from Bittorrent and from my
last-mile-ADSL I'm missing support for an parallel-existing and
cross-excanging[1] multicast deployment tree where possible.
In fact I think on an hybrid protocol between (Fat)Nemo[2] and
BitTorrent[3].
As an given Example see [4]. Distribute torrents over the Internet per
Unicast and within the (NAT-less) LAN over Multicast[5]. For End-Users
it is currently not really possible to distribute files in these
manner because of the lack of Applications doing so.
Are there any plans to implement such a feature?

BT works best if peers have different blocks, and as peers that are on
networks that support multicast are normally on local lans where traffic is
cheap compared to offsite traffic, multicast does not offer much benefit.

If long haul routed multicast existed things might be different.

Justin

Post by movgp0
Sincerly,
MovGP0
[1] Meaning that unicast-nodes exchange data with multicast-nodes over
unicast channels for backward compatibility.
[2] http://www.aqualab.cs.northwestern.edu/Nemo.html
[3] http://bittorrent.com/introduction.html
[4] http://groups.yahoo.com/group/BitTorrent/message/6065?threaded=1
[5] I think also on a kind of (auto-setup) streaming-proxy.
[6] http://groups.yahoo.com/group/BitTorrent_help/message/9656
?threaded=1
Yahoo! Groups Links

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Cox]

Post by Justin Cormack

Post by movgp0
Hi,
I've looked at how BitTorrent work. It is a very good protocol design.
But if I look at my Upload/Download-ratio from Bittorrent and from my
last-mile-ADSL I'm missing support for an parallel-existing and
cross-excanging[1] multicast deployment tree where possible.
In fact I think on an hybrid protocol between (Fat)Nemo[2] and
BitTorrent[3].
As an given Example see [4]. Distribute torrents over the Internet per
Unicast and within the (NAT-less) LAN over Multicast[5]. For End-Users
it is currently not really possible to distribute files in these
manner because of the lack of Applications doing so.
Are there any plans to implement such a feature?

BT works best if peers have different blocks, and as peers that are on
networks that support multicast are normally on local lans where traffic is
cheap compared to offsite traffic, multicast does not offer much benefit.
If long haul routed multicast existed things might be different.
Justin

I took a quick tour of the multi-cast tutorial at:

http://www.networkmagazine.com/article/NMG20000727S0026

Post by Justin Cormack
From my point of view, it would be ideal if multicast simply allowed me

to specify multiple addresses for a message to be sent to. AFAIK, it
doesn't. Instead it is a very complex mechanism designed for
distributing real time video signals, rather than BitTorrent packets.
Also, since much of the core of the internet has multicast disabled, it
probably wouldn't help much in the near-term, except possibly on local
nets where it's value is less. The situation for multicast seems to me
to be the same for IPv4 and IPv6.

But what the heck, it's still fun to talk about how we might use it if
it were widely available... I'm not recommending we take action on any
of these ideas. There just ideas:

Trackers could define groups of peers that belong to a multicast group.
Let's call this a peer group. The tracker could mass broadcast peer
ids, rather that doing it one at a time. Also, HAVE messages could be
multi-cast to the peer group. This would eliminate a lot of
BitTorrent's overhead, although it's not very high now. The reduced
load on the trackers might interest the big torrent sites.

For distributing data, each peer might define his own multicast group.
They could announce to the peer group an order for broadcasting pieces,
and announce progress as pieces are sent. That way, peers could join in
just before a piece of interest was broadcast, and leave the group just
after.

There are lots of issues with this, other than the poor availablity of
multicast. For example, how do you reward peers for uploading to a
multicast group? Right now, if you don't upload, you don't get to
download very fast. AFAIK, you can't keep someone out of your multicast
group.

One way might be to accept piece requests from peers who've helped you
with their broadcasts, and try to optimize the download speed for those
who's broadcasts you've benefited from.

Another problem is bandwidth mismatch. What happens to a multicast
packet that is sent too fast for a client to download over his modem?
I'd guess the packets are simply lost. Perhaps the broadcast speed
could be selected by the requester of the piece, further providing
incentive to upload.

I keep trying to think of why multicast can't be used for the piece
transfer, but there seem to be ways... just not trivial ways.

Bill





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Nick Johnson]

Post by Bill Cox
http://www.networkmagazine.com/article/NMG20000727S0026

Post by Justin Cormack
From my point of view, it would be ideal if multicast simply allowed me

to specify multiple addresses for a message to be sent to. AFAIK, it
doesn't. Instead it is a very complex mechanism designed for
distributing real time video signals, rather than BitTorrent packets.
Also, since much of the core of the internet has multicast disabled, it
probably wouldn't help much in the near-term, except possibly on local
nets where it's value is less. The situation for multicast seems to me
to be the same for IPv4 and IPv6.
But what the heck, it's still fun to talk about how we might use it if
it were widely available... I'm not recommending we take action on any

If you're interested in this sort of thing, you might like to look into
Digital Fountain Algorithms and Tornado Codes. It's a very cool system
that allows one or more sources to distribute (multicast) files via
broadcast in such a way that listeners can reassemble the file after
recieving enough data, even with arbitary gaps (packetloss etc) in the
source data. The overhead for doing this is about 5% over the original
filesize.

Actually, I've been pondering its application to non-broadcast (BT like)
systems myself lately. I think it could alleviate problems
(particularaly at the start and end of getting a torrent) where two
connected peers can't both offer something of interest to each other.

-Nick Johnson



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Cox]

I see that BT use to have some encryption capability, and that it was
removed for various reasons.

In my proposed BT friends protocol extension, peers do an insecure
handshake the first time they meet, but later use their secret keys for
proper recognition of old friends. If I wanted to secure a socket with
an old friend, all I have to do is use something like BlowFish to
encrypt data on the socket, using the secret friendship keys. The
computational overhead is low, and the coding should be trivial.

Should it be done?

In general I do not support piracy, so that's not a good reason. I'm
based in the U.S. So far as I can tell, there are no restrictions on
open-source encryption algorithms. However, if I add encrypted streams
to the BT friends extension, will I upset anyone in the security
community? I'd prefer not to. Finally, would ISPs get upset? You
really wouldn't want that.

I'm leaning towards leaving it out. It just bugs me that the friendship
keys are just sitting there, begging to be used.

Thanks,
Bill
--
Bill Cox <***@viasic.com>
ViASIC




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/