[00:08:12] *** Miller` has joined #bittorrent
[00:19:00] <swolchok> re: uTorrent streaming, doesn't uTorrent have majority market share anyway?
[00:19:51] <K`Tetch> no
[00:20:15] <swolchok> http://torrentfreak.com/utorrent-dominates-bittorrent-client-market-share-090624/ ?
[00:20:20] <K`Tetch> http://torrentfreak.com/thunder-blasts-utorrents-market-share-away-091204/
[00:20:29] <K`Tetch> 6 months more recent
[00:20:51] <K`Tetch> we can only report the facts as we know em
[00:21:04] <swolchok> weird, and that study shows uT and Az neck and neck
[00:21:05] <swolchok> interesting
[00:21:09] <K`Tetch> 6 months ago, we thought ut was dominant, earlier this month, we knew better
[00:21:40] <swolchok> still think it's safe to say that on most non-China swarms, uT peers are going to be more than a third
[00:22:00] <K`Tetch> yes
[00:22:12] <swolchok> so there's nothing that can be done to prevent them from colluding to stream pieces unless you can reliably detect them and block them all together
[00:22:53] <swolchok> hmm, that may not be strictly true, but I bet some academics have either looked at it or will trip over themselves in their haste to look at it as soon as they find out
[00:23:11] <K`Tetch> I'm looking at it
[00:23:14] <K`Tetch> have been for 2 days
[00:23:19] <K`Tetch> as much as I can
[00:23:32] <K`Tetch> thankfully, schools fiished here, so I've now got a tea-slave
[00:24:02] <swolchok> well, assuming uT is willing to do anything to support their streaming feature, that's a Byzantine fault model and everyone else is hosed
[00:24:08] <swolchok> right?
[00:24:22] <K`Tetch> we'll see
[00:25:03] <swolchok> K`Tetch: are you ktetch.wordpress.com?
[00:25:33] <swolchok> heh, must be
[00:32:39] *** ajaya has quit IRC
[00:33:05] *** ajaya has joined #bittorrent
[00:36:48] *** Waldorf has quit IRC
[00:42:19] <K`Tetch> yes
[01:11:45] *** goussx has joined #bittorrent
[01:12:04] *** Miller` has quit IRC
[01:16:05] *** Miller` has joined #bittorrent
[01:25:43] *** Switeck has quit IRC
[02:07:44] *** bt42 has joined #BitTorrent
[02:10:54] *** kwinz2_ has joined #bittorrent
[02:13:14] *** Miller` has quit IRC
[02:15:37] *** bittwist has quit IRC
[02:20:27] *** kwinz__ has joined #bittorrent
[02:21:54] *** kwinz2_ has quit IRC
[02:22:35] *** Miller` has joined #bittorrent
[02:23:14] *** kwinz2 has quit IRC
[02:32:01] *** kwinz2_ has joined #bittorrent
[02:32:13] *** codas has joined #bittorrent
[02:36:19] <codas> hi,  the paper "Content Availability and Bundling in Swarming Systems" was awarded best paper in CONEXT'09!
[02:36:44] <codas> http://conferences.sigcomm.org/co-next/2009/papers/Menasche.pdf
[02:37:17] <The_8472> rofl
[02:37:32] <The_8472> the very first sentence in the paper is already misguided
[02:37:36] <The_8472> "BitTorrent, the immensely popular file swarming system,
[02:37:36] <The_8472> suffers a fundamental problem: content unavailability."
[02:37:50] <The_8472> bittorrent is about content distribution foremost
[02:37:56] <The_8472> retention is only a secondary goal
[02:38:04] <The_8472> you basically can't have both
[02:38:12] <The_8472> since available bandwidth is finite
[02:38:23] <codas> right
[02:38:34] <codas> but the amount of content is also finite
[02:38:45] <The_8472> yes, but new content arrives every day
[02:38:49] <The_8472> thus old content has to disappear
[02:38:53] <The_8472> to keep the pool constant
[02:39:08] <codas> i see your point
[02:39:47] <swolchok> Best Paper does not mean it is perfect :)
[02:39:52] <swolchok> or right
[02:39:55] <swolchok> necessarily
[02:40:22] <codas> content has to disappear if disk space is a  problem
[02:40:42] <codas> but bandwidth limitations does not imply that content has to disappear
[02:41:26] <The_8472> well, if the pool of available content would be growing and growing the bandwidth per torrent would decrease over time
[02:41:37] <The_8472> which would be contrary to the distribution aspect for new content
[02:41:52] <The_8472> in simple words: bittorrent is not emule
[02:42:32] <codas> yes, but possibly bundling brings some of the advantages of "emule" to the bittorrent world, no?
[02:42:32] <swolchok> it's turning into another classic p2p network though
[02:42:55] <swolchok> the entire "ecosystem" of bittorrent + trackers + torrent sites + DHT
[02:43:00] *** spoop has quit IRC
[02:43:10] <swolchok> http://cis.poly.edu/~ross/papers/PublicEcosystem.pdf is an interesting paper from that point of view
[02:43:12] <codas> another classic p2p network ?
[02:43:24] <The_8472> you don't share folders though
[02:43:27] <swolchok> the next napster/gnutella/fasttrack/emule/whatever else
[02:43:40] <The_8472> and only one/a few torrents at a time, at least in a well-behaving client
[02:43:45] <The_8472> while emule basically shares... everything
[02:44:14] <swolchok> that's fairly irrelevant
[02:44:33] <swolchok> no one cares about the details of client settings
[02:44:46] <The_8472> they are significant
[02:45:01] <codas> you mean, default client settings ?
[02:45:02] <swolchok> either way, I can get pretty much whatever content I please through the system, taken as a whole
[02:45:03] <The_8472> if you have hundreds of torrents and share all of them at once you basically have emule-like behavior
[02:45:06] *** kwinz__ has quit IRC
[02:45:20] <The_8472> if you only run one at a time then some torrents will never/rarely get their turn and die out
[02:45:33] <codas> well, but in emule if you help in the dissemination of a content u get credits that will help u to download others
[02:45:39] <swolchok> it's sort of interesting that bittorrent content has a lifecycle whereas in emule it theoretically doesn't
[02:45:58] <swolchok> but as you'll point out, emule etc. just ignores the reality of finite bandwidth
[02:46:05] <The_8472> yep
[02:46:12] <codas> i don't quite get this point
[02:46:43] <codas> peers should be free to decide how to split their finite bandwidth across all the available content
[02:46:50] <codas> the more content is available, the better
[02:46:57] <The_8472> swarms have a lifecycle. they start out with few seeds, many peers... then both the seeds and peer numbers grow until the seeds eclipse the peers
[02:47:16] <The_8472> and then it slowly dies off over the course of weeks to years, depending on size and popularity
[02:47:29] <DWKnight> bittorrent isn't about following the metrics of the traditional p2p networks
[02:47:33] <The_8472> bigger, more popular torrents (especially bundles) usually have a longer lifecycle
[02:47:58] <codas> what is the difference in terms of metrics?
[02:48:04] <DWKnight> and trying to run a bittorrent client as if it were a traditional p2p client
[02:48:14] <DWKnight> makes it perform like a rock trying to get up a hill without help
[02:48:16] <The_8472> codas, no. it's a content distribution system. designed to bring something you created NOW as fast as possible to many people.
[02:48:55] <codas> but there are many swarms disseminating classics on bittorrent
[02:49:02] <The_8472> if you want retention then back your torrents by a few seedboxes. otherwise they'll die to make room for someone else's content-of-the-day
[02:49:26] <codas> and one could argue that most of non-copyrighted material in bittorrent are classics
[02:49:46] <The_8472> codas yes. sufficiently popular content has a very long life-cycle. but even those will die eventually. e.g. when a DVD is replaced by a bluray ^^
[02:51:13] <codas> i see...
[02:52:19] <The_8472> the only design goals as far as retention goes is that client behavior does not shorten the lifecycle of a torrent due to suboptimal behavior
[02:52:59] <codas> what do you mean by seedboxes ?  keeping stable seeds ?  it would be nice if, after "dying out to make room for someone else's content-of-day" they could "rise again" when/if they become popular again
[02:53:43] <The_8472> seedboxes are basically colocated servers serving as seeds for specific content or a specific community
[02:53:52] <codas> i think that there is  a difference between  retention and dying out
[02:55:47] <codas> i think one of the problem of seedboxes is that if they serve many unpopular contents we end up having a "client server model" again
[02:55:54] <The_8472> consider torrents of your favorite creative commons tv show, first they're released episode by episode. at the end of the season someone makes a season-torrent. the season torrent is bigger, has a longer lifecycle and all. you want the old ones to die
[02:56:06] <The_8472> then after a few years somebody makes a multi-season torrent
[02:56:32] <codas> yes, i believe so
[02:58:11] <The_8472> anyway, bandwidth IS the issue. i have about 800 torrents in my seeding queue but only a puny uplink. to support new torrents i have setup my queue rules to seed torrents with many peers and few seeds
[02:58:21] <The_8472> thus the old stuff with few peers will rarely get seeded
[02:58:24] <The_8472> and most likely die out
[02:58:32] <The_8472> but at least new content won't be as slow as a snail
[02:59:08] <The_8472> (assuming everybody would do that)
[02:59:59] <The_8472> btw, my p2p panacea also solves this problem: multicast ^^
[03:00:09] <codas> multicast ?
[03:00:10] <The_8472> since then everyone could pretty much seed everything
[03:00:19] <The_8472> IP SSM multicast to be precise
[03:00:35] <The_8472> but i'll be an old man before that happens...
[03:00:57] <codas> there was a recent talk by Van Jacobson where he mentioned about Bittorrent to solve multicast
[03:00:59] <alus> right after flying cars
[03:01:27] <codas> http://video.google.com/videoplay?docid=-6972678839686672840
[03:01:28] <The_8472> codas, bittorrent is a poor emulation of true multicast
[03:01:41] <codas> (final part of talk)
[03:02:43] <K`Tetch> I like the idea of flying cars
[03:03:00] <K`Tetch> James May's had a flying caravan
[03:03:03] <codas> The_8472, i believe your strategy on how to split bandwidth between the 8000 swarms would in most cases not make unpopular contents to starve
[03:03:18] <K`Tetch> (and flew, accidentally, into restricted airspace
[03:03:21] <The_8472> 800, not 8000 ^^
[03:03:46] <codas> ok
[03:03:58] <codas> i still didnt get the panacea
[03:04:14] <The_8472> codas, my queue rules are designed to seed big (thus new/popular) swarms ^^
[03:04:23] <The_8472> so yeah, they do starve old stuff
[03:05:07] <codas> well... if in the new/popular there are many peers with lots of bandwidth
[03:05:16] <The_8472> about multicast. it's simple... onle one/few people need to upload any given data to allow a theoretically unbounded number of people to download it, thus freeing up tons of upload bandwidth for the long tail... the old content
[03:05:20] <codas> many peers will rapidly become seeds
[03:05:39] <codas> and the unpopular ones are the only ones that depend a lot on the seedbox
[03:07:05] <codas> yes, serving content with  popularity that has long tail is something that i had in mind
[03:07:42] *** rupertx has joined #bittorrent
[03:07:46] *** kwinz2_ has quit IRC
[03:08:08] <codas> so, one/few people upload any given data, and where is this data stored?  how would a theoretically unbounded number of people download it?
[03:08:20] *** kwinz2_ has joined #bittorrent
[03:08:23] <The_8472> the thing is, bittorrent works so well because the number of uploaders scales with the number of downloaders. in combination with asymmetric connections this means many uplinks get tied up distributing new content. and as they download the next new thing they again get tied up in new content
[03:08:25] <rupertx> Hey guys, I was wondering if you guys knew anything about TBSOURCE/TBDEV tracker software ? I cannot find any irc channel or person thats even somewhat familiar with this ...anyone ?
[03:08:31] <The_8472> leaving little capacity for old content
[03:08:50] <rupertx> The_8472: do you think BT will go 'trackerless' in the future? I mean is it the NEXT big thing in bittorrent ?
[03:09:24] <The_8472> rupertx, the feature is already there and has been for years. it has shortcomings, that's why it's not used that much
[03:09:30] <codas> leaving little capacity for old content ? so, how to solve this problem ? did u figure a panacea ?
[03:09:40] <The_8472> codas. yes. multicast.
[03:09:46] <rupertx> The_8472: so once its fixed do you think it will be the primary method ?
[03:09:52] <The_8472> but as i said
[03:09:53] <The_8472> <The_8472> but i'll be an old man before that happens...
[03:10:03] <K`Tetch> it's also had a lot of misinformation about it, rupertx. And of course, the 'private tracker' money-grubbers hate it
[03:10:14] <codas> application layer multicast + bittorrent
[03:10:19] <The_8472> no
[03:10:22] <The_8472> real multicast
[03:10:31] <codas> why not application layer ?
[03:10:38] *** spoop has joined #bittorrent
[03:10:49] <rupertx> K`Tetch: interesting. as for private trackers , what do you think is the next big thing for them ? without losing their business model of course
[03:10:51] <The_8472> because application layer multicast is constrained by the bytes uploaded = bytes downloaded equation
[03:10:55] <The_8472> IP multicast isn't
[03:11:15] <codas> hummmm
[03:11:44] <K`Tetch> rupertx - the next big thing for them, is death
[03:11:50] <The_8472> :]
[03:11:53] <codas> bytes uploaded = bytes downloaded ? in application layer multicast i'm assuming that trees would be built in the application layer
[03:11:55] <The_8472> music to my ears
[03:12:11] <rupertx> K`Tetch: are you joking or what ? I see nothing wrong with trying to make a buck...for risking something hehe
[03:12:52] <The_8472> codas. think about it. application layer multicast means that if you're sending to N nodes you have to upload it N times over your uplink.
[03:13:06] <codas> welll
[03:13:11] <The_8472> with IP multicast you send it once and the packets get forked within the internet infrastructure.
[03:13:15] <codas> im assuming that this would not be the case
[03:13:18] <swolchok> I'm surprised there aren't patches for all the major clients that disable private flag, just to make the point
[03:13:28] <swolchok> I still need to write those.If only I didn't have to grade...
[03:13:31] <codas> you send once in the overlay
[03:13:41] <The_8472> swolchok, i can write one up in 10 minutes or so
[03:13:45] <codas> and other nodes in the overlay replicate it
[03:13:55] <The_8472> codas, then the other nodes have to upload N times....
[03:14:29] <The_8472> seriously. anything happening at layer 7 means uploaded data = downloaded data. there's no way around that
[03:14:48] <codas> i see
[03:15:05] <codas> but how does it help to do it in a lower layer ?
[03:15:17] <GTHK> 1.7.7 has an "ignore private flag" patch, one byte change.
[03:15:25] <codas> the only difference is that the tree is built in a different layer, no?
[03:15:42] <The_8472> the tree sits within the internet infrastructure itself instead at the edges
[03:15:57] <GTHK> *Of uTorrent.
[03:16:05] <The_8472> (assuming widespread multicast router deployment)
[03:16:20] <codas> Van Jacobson discusses that in his talk
[03:16:26] <codas> (pointer above)
[03:16:30] *** kwinz2 has joined #bittorrent
[03:16:36] <The_8472> give me minutes and seconds
[03:16:54] <The_8472> i'm not willing to sit through the whole video just to get some possibly irrelevant quotes
[03:16:54] <codas> as far as i understood, he believes on applicatoin layer multicast
[03:17:07] <K`Tetch> brb, router just crashed
[03:17:21] <codas> sure, i'll have to mark the minutes and seconds
[03:17:22] <The_8472> http://www.scificool.com/images/2008/04/x-files-2-title-revealed-2.jpg <- so does mulder
[03:17:54] <codas> :]
[03:18:03] *** K`Tetch has quit IRC
[03:19:15] *** KyleK_ has joined #bittorrent
[03:19:54] <rupertx> The_8472: are you familiar with tbsource/tbdev by any chance ?
[03:20:00] <The_8472> no
[03:20:51] <codas> The_8472 : so, basically, you are saying that taking advantage of the broadcast nature of the ether is important for the success of multicast ?
[03:21:10] <rupertx> Interesting. Anyone in here familiar with TBSOURCE/TBDEV ?
[03:21:18] <rupertx> (IE: Torrent tracker software)
[03:21:40] <codas> that's why application layer multicast doesn't serve your purposes ?  and lower layer does?
[03:21:42] <The_8472> so to speak, yes. since it allows you to operate without the uploaded = downlaoded constraints
[03:22:19] <The_8472> freeing up lots of upload bandwidth to serve a wider variety of content
[03:22:30] <The_8472> and solving lots of other problems too
[03:22:43] <codas> ok, so let me see if i understand
[03:23:13] <codas> 1 ) worst case scenario :  client-server, the server needs to send one packet for each client that requests content
[03:23:45] <codas> 2 ) better : p2p, the server is not loaded anymore,  but still # of packets sent = # packets received
[03:24:52] <codas> 3 ) even better  :  p2p with multicast, so that if a packet is being sent by a node and reaches a network where multiple other nodes are interested in this packet, all the nodes receive the packet
[03:25:09] <The_8472> yes
[03:25:27] <codas> i think that 3 ) can, at least in part, be implemented in the application layer
[03:25:37] <The_8472> i do not see how
[03:25:46] <codas> for instance, tunels
[03:26:36] <The_8472> that doesn't duplicate packets along the path. so i still don't see how
[03:27:00] *** K`Tetch has joined #bittorrent
[03:27:08] <swolchok> isn't IP multicast just a way to externalize costs? the network operators will have to bill differently for the ability to send multicast packets because it would cost them more
[03:27:20] <codas> doesn't duplicate packets ?  in what sense ?
[03:27:53] <swolchok> sending 1 message to k destinations costs more than sending 1 message to 1 destination. trivial proof: electricity usage
[03:28:13] <codas> swolchok: not necessarily
[03:28:26] <swolchok> yes, but it *can*
[03:28:35] <codas> many nodes may be receiving the message but just filtering it
[03:28:48] <The_8472> if your multicast infrastructure is fine-grained enough then it actually saves them packets. at least if usage patterns wouldn't change (although they most definitely would)
[03:28:52] <codas> so, filtering messages when in reality they are interested in these messages
[03:29:01] <The_8472> since people only have to upload once now instead of uploading the same data several times
[03:29:18] *** kwinz2_ has quit IRC
[03:29:50] <codas> usage patterns ?
[03:29:58] <codas> you mean, popularity patterns ?
[03:30:02] <The_8472> no
[03:30:48] *** rupertx has quit IRC
[03:31:03] <swolchok> The_8472: let's say i'm being charged by the byte for upload bandwidth. I want to send a 1 KB packet to 1000 nodes, all on different ASNs. This costs my ISP a lot more than sending that 1 KB packet to 1 node on a different ASN, but the ISP's model has them charging the same price.
[03:31:41] <The_8472> swolchok, try the reverse case
[03:31:54] <swolchok> what, 1000 nodes want to send me a packet?
[03:32:03] <The_8472> you already ARE sending 1 packet to 1000 nodes each by sending it 1000 times.
[03:32:18] <The_8472> with multicast you would only send it once
[03:32:21] <swolchok> yes, but it costs me 1000 times more
[03:32:32] <swolchok> the cost is just shifted to the ISP
[03:32:40] <swolchok> there is some net gain, but the ISP gets fucked
[03:33:02] <The_8472> the thing is, bandwidth cost is fixed
[03:33:05] <The_8472> the line is there
[03:33:09] <The_8472> whether it's utilized or not
[03:33:18] <swolchok> the true cost does not matter. it complicates the pricing and billing models.
[03:33:30] <The_8472> probably, yes
[03:33:31] <swolchok> as a practical matter a multicast packet has to cost you more.
[03:33:41] <swolchok> stop thinking about this like an engineer ;)
[03:34:04] <The_8472> it makes already existing distribution systems only more efficient, not less
[03:34:11] <The_8472> thus given the same load it should cost less
[03:34:13] <swolchok> *yes* it's clearly more efficient from a global perspective, but it's a total pain in the ass for the business
[03:34:21] <The_8472> the only thing that would increase the price would be the increased usage
[03:34:37] <The_8472> and usage certainly would increase
[03:34:49] <codas> because more content would be available ?
[03:34:52] <swolchok> people would also do odd things like making bulk downloaders wait so that they could batch the transfer
[03:34:53] <The_8472> yes
[03:35:14] <codas> yes
[03:35:18] <codas> that  makes sense to me
[03:35:24] <codas> to wait for bulk transfers
[03:35:32] <codas> if multicast is supported
[03:35:33] <The_8472> well, those are implementation details... how you make use of multicast
[03:35:44] <The_8472> you could just loop through the content every few hours
[03:35:51] <codas> olala
[03:35:52] <The_8472> and either somebody listens in or they don't
[03:36:06] <codas> yes, and use fountain codes or something alike
[03:40:16] <codas> The_8472: what is IP SSM multicast ?
[03:41:01] <The_8472> http://en.wikipedia.org/wiki/Source_specific_multicast
[03:41:55] <The_8472> swolchok, you do have a point though. it suddenly would become possible to host a worldwide (ip)tv channel from a humble 10Mbit connection
[03:42:11] <The_8472> or 100Mbit if you want HD
[03:42:43] <swolchok> exactly. you wouldn't get multicast
[03:42:52] <swolchok> just big players
[03:43:09] <swolchok> putting the intelligence in the network just complicates things :)
[03:43:17] <swolchok> in the meantime, isn't this what akamai is for?
[03:43:44] <The_8472> it may complicate things, but it would also bring so many more opportunities to the edges
[03:44:44] <swolchok> check out slide 17 -- http://jon.oberheide.org/files/nanog47-observatory-pres.pdf
[03:44:52] <swolchok> not sure if they've actually gotten around to publishing the report or not
[03:45:08] <swolchok> contrast with slide 9
[03:45:44] <swolchok> comcast is already doing the edge thing, and you're not going to like it
[03:46:03] <swolchok> IIRC there was a NYT article a day or three ago; they're moving toward delivering their TV content via internet
[03:46:51] <The_8472> a big ISP here already does that
[03:47:05] <swolchok> and they sure don't want consumers having broadcast capability
[03:47:09] <The_8472> they have a separate vlan within their infrastructure to deliver IPTV to their customers via multicast
[03:47:16] <swolchok> you don't pay for that, you pay to *download* shit dammit
[03:47:24] <swolchok> nicht gut
[03:48:10] *** andar has quit IRC
[03:48:11] <codas> so, the vlan supports multicast, right?
[03:48:33] <The_8472> well, consider it a different way... if people actually would utilize their download bandwidth 24/7 ... would it matter if what they download is multicast or upload individually every time?
[03:48:53] <The_8472> codas, classical ASM, and probably filtered.
[03:49:16] <codas> filtered so that only iptv can make use of it?
[03:49:33] <The_8472> so that only their source can send to the multicast groups, yes
[03:49:40] *** andar has joined #bittorrent
[03:49:48] <codas> i see...
[03:49:57] <codas> so, that's new to me
[03:50:31] <codas> i used to think that the reason that multicast didn't work was that people "forgot" to activate it in their routers, or misconfiguration
[03:50:53] <codas> but in reality, it's really because they it's counter-economic to turn multicast on?
[03:51:52] *** The_8472 has quit IRC
[03:52:13] *** wadim has joined #bittorrent
[03:52:15] *** wadim is now known as The_8472
[03:53:15] <The_8472> but it's an interesting scenario.... would transit traffic actually increase or decrease with multicast. on one hand you only need 1 stream traversing the transit to serve many downloaders
[03:53:30] <The_8472> on the other hand... there probably would be many more streams, more diverse content
[03:54:09] <codas> more diverse content because people would be able to offer more diversity, right?
[03:54:11] <The_8472> but then again, bittorrent is no different. only that it now would be bounded by the aggregate download bandwidth instead of the aggregate upload bandwidth
[03:54:16] <The_8472> yes
[03:54:41] <codas> yes
[03:55:11] <codas> but the aggregate download bandwidth with multicast is much larger than the aggregate download bandwidth without it
[03:55:49] <codas> wait, the aggregate download bw doesn 't change
[03:56:02] <The_8472> only the utilization might
[03:56:13] <The_8472> s/might/probably would/
[03:56:40] <codas> probably would have more utilization since more people would find what they want?
[03:57:11] <The_8472> because they wouldn't have to seed/wait for tit-for-tat
[03:57:54] <codas> so, basically if the network supported multicast bittorrent incentive mechanism would have to change completely
[03:58:18] <swolchok> you wouldn't have all-you-can-eat multicast
[03:58:22] <swolchok> so it's a moot point
[03:58:55] <codas> i see
[03:59:00] <The_8472> well, nobody would have believed that we would have all-you-can-eat download speed back in the modem days :P
[03:59:03] <swolchok> I don't think there's a reasonable consumer application that requires it, so even if it *was* free for ISPs, they would charge for it
[03:59:11] <swolchok> at "business" rates
[03:59:18] *** CyrusYzGTt has joined #bittorrent
[03:59:28] <The_8472> uhm
[03:59:31] <The_8472> video conferencing
[03:59:35] <The_8472> gaming
[03:59:58] <swolchok> both specialized
[04:00:02] <The_8472> and of course filesharing
[04:00:04] <swolchok> "premium gaming" package
[04:00:14] <swolchok> "premium videoconf"
[04:00:34] <codas> The_8472:   filesharing  is very different from videoconf and gaming, no ?
[04:00:35] <swolchok> MBAs would cream their pants over that
[04:00:51] <The_8472> MBAs need to be shot. several times. with silver bullets
[04:00:58] <codas> fliesharing is not real time ...
[04:01:12] <The_8472> doesn't matter, all of them could use multicast
[04:01:23] <The_8472> and p2p with multicast would happen to provide realtime capabilities too
[04:01:37] <codas> yes, that is clear to me
[04:02:27] <codas> but p2p with multicast for non realtime apps is useful only if many users connected to the same "last hop" router are interested in the same content, no?
[04:02:59] <codas> otherwise, application layer multicast would be enough
[04:03:15] *** CyrusYzGTt has left #bittorrent
[04:03:31] <The_8472> well, not necessarily the last hop. they could share more of the transit paths too
[04:03:38] <codas> the only point where i can see a distinction between application layer multicast and lower layer mulicast is in the last hop
[04:04:38] <The_8472> e.g. if i'm uploading to a dozen of americans... via multicast only 1 packet could travel across the atlantic (though afaik multicast routing protocols don't work that way at the moment)
[04:05:03] <codas> yes, so that goes back to the tuneling idea
[04:05:07] <codas> application layer multicast
[04:05:49] <codas> if bittorrent is implemented in an overlay that implements app layer multicast
[04:06:03] <codas> i think we could make only 1 packet travel across atlantic
[04:06:58] <codas> the only point where app layer doesnt work in the last hop
[04:07:07] <The_8472> the problem is the edges know nothing about routing
[04:07:45] <codas> yes, routing would be implemented in an overlay
[04:07:59] <codas> bittorrent + application layer multicast
[04:08:35] <The_8472> i think PIM-SM can merge paths under some conditions, but i have no idea if in a real world deployment it would be possible to merge paths in a way that could save you the packets flowing through the atlantic for example
[04:09:00] <codas> PIM-SM ?
[04:09:02] * The_8472 doesn't know enough.
[04:09:17] <The_8472> the sparse mode multicast routing protocol
[04:09:35] <The_8472> wikipedia and cisco can tell you more
[04:09:43] <codas> thanks
[04:10:47] <codas> i think that waiting for multicast from the lower layer might be asking too much
[04:11:07] <The_8472> <The_8472> but i'll be an old man before that happens...
[04:11:10] <The_8472> i said so an hour ago
[04:11:24] <codas> maybe old man, but maybe it will never happen
[04:11:35] <codas> but it seems to me that in the same way that live stream p2p implements multicast in the app layer
[04:11:57] <codas> p2p for file sharing could take advantage of similar ideas
[04:12:08] <The_8472> i don't see why it should never happen. it's not physically impossible. so someone will find a way to do it
[04:12:30] <codas> i agree. it's physically possible, and the technology is available.
[04:12:42] <swolchok> you forgot "it's economically worthwhile"
[04:12:43] <codas> i thought the problem was that people "forgot" to configure the routers
[04:13:04] <codas> now i understand that the problem is that it's not economically worthwhile
[04:13:09] <The_8472> it's a bit more complicated than just flipping a switch
[04:13:34] <The_8472> e.g. almost all domesting routers don't speak IGMPv3/MLD
[04:13:44] <The_8472> *domestic
[04:13:59] <codas> i see
[04:14:39] <codas> so, the big picture is :
[04:14:50] <codas> * avoid sending redundant packets
[04:15:20] <codas> * if so, the bandwidth used for redundancy will then be used to increase diversity
[04:15:30] <The_8472> swolchok "uses available resources more efficiently" should always be economically worthwhile. if it isn't you end up with things like global warming. it wasn't economically wothwhile to cut down on resource consumption...
[04:16:03] <The_8472> yes, that's the idea
[04:16:53] <codas> i see
[04:17:48] <codas> this problem is strongly related to caching
[04:18:14] <codas> because if content is cached properly in the edges, redundancy in the core is mitigated
[04:18:50] <codas> (at least for p2p file sharing)
[04:19:14] <The_8472> except that caching is protocol-specific
[04:19:19] <The_8472> multicast works for everything
[04:19:32] <codas> (for gaming, teleconf, ... i agree that caching does not suffice)
[04:19:50] <The_8472> asking ISPs to roll out caches for the protocol of the day is probably even more expensive than rolling out multicast support
[04:20:01] <The_8472> on the long run at least
[04:20:11] <codas> right
[04:23:41] <codas> the multicast issue is really a key one in Van Jacobson talk
[04:24:06] <The_8472> i even would be happy with ISP-local SSM, that way they wouldn't have break their heads over all the transit stuff
[04:24:42] <codas> i see
[04:24:59] <codas> you mean, you would be happy if you could at least multicast to other guys using the same isp as you??
[04:25:07] <The_8472> yes
[04:25:12] <codas> i see
[04:25:51] <The_8472> different ISPs could be bridged by a single connection
[04:26:08] <codas> right
[04:26:08] <The_8472> or a few if the aggregate bandwidth exceeds that of a single upload
[04:26:17] <codas> i see
[04:26:48] <codas> the key idea behind multicast is the multicast tree
[04:27:02] <codas> i really don't get why the tree built in the upper layer can't help
[04:27:38] <codas> isn't this exactly what pplive et al are doing?
[04:28:29] <The_8472> because it doesn't solve any of our problems. builting a multicast tree at the application layer would only save transit bandwidth, but not last mile bandwidth since you just shift the N-times-uploading to other edge nodes
[04:29:06] <codas> yes, but it's already a save
[04:29:11] <codas> saving
[04:29:15] <The_8472> none that we care about basically
[04:29:32] <The_8472> saved transit is just a bonus for us and something ISPs might care about
[04:29:34] <codas> no?
[04:29:39] <The_8472> nope
[04:29:43] *** KyleK_ has quit IRC
[04:30:21] <codas> i see... you are saying that we still need the order of N transmissions
[04:31:02] <The_8472> perfect multicast would replicate packets only where the paths that would be taken if you would unicast to every destination would diverse
[04:31:25] <codas> yes
[04:31:33] <The_8472> due to efficiency reasons real world multicast doesn't work that way, but it still happens more or less along the path. not at the edges
[04:31:41] <codas> so, the big issue is in the end points
[04:31:49] <codas> as we already discussed
[04:31:58] <The_8472> application layer multicast happens at the endpoints
[04:32:16] <The_8472> which basically is what we're already doing.
[04:32:35] <The_8472> 1 seed uploads and the bittorrent swarm colludes to get the pieces to everyone who downloads
[04:32:46] <The_8472> but we pay the price in redundant upload bandwidth
[04:32:58] <codas> i see
[04:33:26] <codas> so, this dissemination should not happen in the level of leechers
[04:33:34] <codas> but in the level of "proxys-of-leechers"
[04:33:50] <codas> the leechers would then connect to the "proxys-of-leechers"
[04:34:28] <codas> and the "proxys-of-leechers" send 1 packet that is simultanously  received by all the leechers connected to it
[04:34:37] <The_8472> yes yes, same thing as caches, we already have been over this
[04:35:02] <codas> right
[04:36:10] <codas> not the same as caches
[04:36:46] <codas> since the proxys-of-leechers would use multicast to the leechers (e.g., all are inside the same isp)
[04:37:06] <codas> (assuming the isp supports multicast for its users)
[04:37:16] <The_8472> big assumption
[04:37:27] <codas> right
[04:38:11] <codas> well... wireless  is by nature broadcast
[04:39:30] <codas> if everything becomes wireless, maybe eventually multicast will come true :]
[04:39:50] <The_8472> unlikely
[04:40:10] <The_8472> a) wireless is actually a worse distribution model than dedicated lines
[04:40:23] <The_8472> b) wireless is separated into cells
[04:40:25] <codas> yeah ... i can't think about an "evolutionary path" that leads to less redundancy, as u suggest
[04:41:10] <codas> actually, bundling, which increases availability, goes in the other direction! it might INCREASE redundancy!
[04:41:37] <codas> (except if mixed with smart caching strategies)
[04:42:21] <The_8472> huh?
[04:43:04] <codas> well
[04:43:34] <codas> i can't think about any practical way to reduce the global (system-wide)  redundancy of transmitted packets
[04:44:17] <codas> what i can see, on the other hand, is a possible INCREASE in redundancy, if bundling is used more often
[04:45:04] *** indieross has joined #bittorrent
[04:45:04] <The_8472> you just said that, just in slightly different words
[04:45:11] <The_8472> which seems to happen a lot with you
[04:46:29] <codas> thanks, The_8472
[04:46:40] <codas> it was a nice discussion
[04:46:45] <The_8472> oO
[04:47:03] <The_8472> tbh, i was mildly annoyed by it
[04:47:37] <codas> it would be nice to find practical solutions to the redundancy problem
[04:47:44] <codas> i'll reflect about that
[04:48:10] <The_8472> can't think of one without support form ISPs
[04:48:13] <The_8472> *from
[04:59:08] <The_8472> hah
[04:59:13] <The_8472> i just scrolled through the paper
[04:59:18] <The_8472> mathematical proofs ^^
[05:00:11] <The_8472> that reads like there weren't engineers that work :P
[05:00:20] *** K`Tetch has quit IRC
[05:01:37] *** K`Tetch has joined #bittorrent
[05:14:43] *** bt42 is now known as bittwist
[05:42:30] *** chelz has joined #bittorrent
[05:52:14] *** burris has quit IRC
[05:52:40] *** burris has joined #bittorrent
[06:12:25] *** GTHK has quit IRC
[08:05:47] *** MassaRoddel has joined #bittorrent
[08:35:02] <chelz> a thought that struck me recently when i was reading over the transition of TPB to the DHT was that i totally missed a possible connection between TPB adding magnet links, then talking up the DHT shortly after
[08:35:24] <chelz> it may be part of a larger push to become magnet-link only
[08:36:53] <chelz> since, at least under US law, hosting torrents isn't all that legal. i'm not sure how legal linking to torrents is since i can't recall a case in the US where a pure index was forced out, plus sites like torrentz aren't hosted in the US anyway.
[08:37:54] <chelz> so it might be a way to force the issue of whether or not (magnet) linking counts as contributory infringement in countries that have ruled against hosting torrent files
[09:14:36] *** Andrius has joined #bittorrent
[09:41:27] *** KyleK_ has joined #bittorrent
[10:07:05] *** rrr_ has quit IRC
[10:22:12] *** burris has quit IRC
[10:29:26] *** burris has joined #bittorrent
[10:33:25] *** Andrius has quit IRC
[12:12:42] *** rrr_ has joined #bittorrent
[12:23:01] *** The_8472 has quit IRC
[12:23:22] *** wadim has joined #bittorrent
[12:23:24] *** wadim is now known as The_8472
[12:26:30] *** KyleK_ has quit IRC
[12:30:03] *** MassaRoddel has quit IRC
[12:30:08] *** ivan` has quit IRC
[12:30:18] *** ivan` has joined #bittorrent
[12:33:58] *** MassaRoddel has joined #bittorrent
[12:49:32] *** bt42 has joined #BitTorrent
[12:55:45] *** bittwist has quit IRC
[13:06:17] *** chelz has quit IRC
[13:32:58] *** burris has quit IRC
[13:45:58] *** burris has joined #bittorrent
[14:37:13] *** bt42 is now known as bittwist
[14:40:51] *** kwinz2 has quit IRC
[15:20:21] *** The_8472 has quit IRC
[15:20:32] *** ProperNoun has quit IRC
[15:20:42] *** wadim has joined #bittorrent
[15:20:44] *** wadim is now known as The_8472
[15:51:43] *** rrr_ has quit IRC
[16:10:56] *** init0_ has joined #bittorrent
[16:13:44] *** KyleK_ has joined #bittorrent
[16:22:09] *** init0 has quit IRC
[16:27:16] *** goussx has quit IRC
[16:57:10] *** rrr_ has joined #bittorrent
[17:18:53] *** burris has quit IRC
[17:27:16] *** ajaya has quit IRC
[17:28:16] *** ajaya has joined #bittorrent
[17:44:38] *** burris has joined #bittorrent
[18:28:59] *** ajaya has quit IRC
[18:30:06] *** GTHK has joined #bittorrent
[18:55:52] *** GTHK has quit IRC
[19:03:31] *** kwinz2 has joined #bittorrent
[20:40:47] *** Miller` has quit IRC
[21:07:50] *** Waldorf has joined #bittorrent
[21:30:52] *** Waldorf has quit IRC
[21:43:05] *** goussx has joined #bittorrent
[21:50:59] *** kwinz2 has quit IRC
[22:12:47] *** Waldorf has joined #bittorrent
[22:33:48] *** Waldorf has quit IRC
[22:43:54] *** Miller` has joined #bittorrent
[22:58:38] *** MassaRoddel has quit IRC
[23:08:01] *** dandon has joined #bittorrent
[23:18:08] *** Waldorf has joined #bittorrent
[23:26:52] *** Waldorf has quit IRC
[23:49:17] *** dandon has quit IRC
[23:50:00] *** burris has quit IRC
[23:50:12] *** burris has joined #bittorrent





top