Re: [ledbat] Note well on the BitTorrent problem on the example...

[Laird Popkin <[e-mail]>]

This is a good point. 

Keep in mind that tit-for-tat (i.e. sending as much as you receive with each peer) is only enforced between downloaders - anyone who has completed downloading contributes freely and does not get anything in return. Even between downloaders, tit-for-tat is not enforced absolutely, but only very approximately. 

Also keep in mind that not all p2p networks use tit-for-tat. So while it's certainly useful to think about the BitTorrent case, there are many other kinds of p2p network (e.g. live streaming) that care more about other attributes (e.g. latency) rather than fairness between peers. 

- Laird Popkin, CTO, Pando Networks 
mobile: [phone] 

----- Original Message ----- 
From: "Robb Topolski" <[e-mail]> 
To: "Nicholas Weaver" <[e-mail]> 
Cc: [e-mail] 
Sent: Thursday, November 20, 2008 6:06:29 PM (GMT-0500) America/New_York 
Subject: Re: [ledbat] Note well on the BitTorrent problem on the example... 

Replies inline... 


On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver < [e-mail] > wrote: 




In the aggregate, a bulk-data P2P system must upload as much as it downloads, and your performance becomes limited by uplink bandwidth. 

We can start here, although I know it's not the crux of your point. 

"In the aggregate," true, but "your performance" is not in that context -- its yours alone. 

I think the value of 1:1 up:down participation on an individual basis is overrated if not unhealthy (if not unattainable). There will always be some last downloader in a swarm -- who is he going to upload to? How many swarms that should have died stay alive (and perform poorly) in a futile effort for someone to reach their 1:1 goal? 

Such goals forget that some people value getting their own interests out there, and are motivated to spend their energy (and bandwidth) in doing that (quickly/broadly/efficiently etc) and that activity is further skewed based on their preferences (linux, anime, porn, first-run movies, software, old music, amateur documentaries). 




When you have a significant group of hosts with a near-zero uplink, these hosts contribute very little to the overall performance of the system. 



EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every single bit of uplink from the DSL lines, you get 8x the uplink from the cable modem lines. 

At such a point, you might as well, from an aggregate system viewpoint, reduce the upload of the DSL hosts to 0: they are contributing so little, but experiencing a huge degredation of performance that MUST occur because of the minimum buffer size of a few packets. 
. 


If two dial-up users are reciprocatively sharing chunks of files, that's two slots from the universe of other peer's uploading slots that they won't occupy. It's an efficient pairing. It would be inefficient for one of these dialup users to occupy the upload slot of a cablemodem user for any extended time. (Some clients will open an additional slot if this happens, but that enhanced behavior is optional, and an uploader still won't spend significant time servicing a slow downloader). 

Could those 128 Kb uploaders service ISDN or Satellite users? Or maybe pair up with a dial-up user (slow but better than 1 Mbps transferring to dial-up)? 






You can NEVER size a buffer for a DSL modem for normal TCP such that you will get good interactive behavior while a full rate upload occurs. 


This is the part that got my attention. These aren't like the old phone modems with flow control, so that's why they have this problem? (This isn't really a P2P-related problem, is it?) 



In contrast, you can use an effectivev 100-150ms buffer on the cable modems, so they can get full rate TCP but at the same time, not step on their interactive traffic (subequent message coming on that). 


I'll watch for it. I wasn't aware that one had less of a problem than the other. 

Thanks Nick! 

Robb 


-- 
Robb Topolski ( [e-mail] ) 
Hillsboro, Oregon USA 
http://www.funchords.com/ 

_______________________________________________ ledbat mailing list [e-mail] https://www.ietf.org/mailman/listinfo/ledbat 

_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat