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

From: Nicholas Weaver <[email-masked]>
Date: Thu, 20 Nov 2008 14:27:32 -0600

A network with only 128 Kbps uplink, >1.5 Mbps downlink (a 10-1  
download/upload ratio) is not suitable for P2P anyway, it really  
should be "leech only", as it contributes nothing to the P2P system in  
practice.

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

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 12:33:45 -0800

Can you say more about this?

On Thu, Nov 20, 2008 at 12:27 PM, Nicholas Weaver <[email-masked]
> wrote:

> download/upload ratio) is not suitable for P2P anyway, it really should be
> "leech only", as it contributes nothing to the P2P system in practice.
>

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 20 Nov 2008 14:48:54 -0600

> Can you say more about this?

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

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.

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.

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).

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 15:06:29 -0800

Replies inline...

On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver <[email-masked]

> 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?)

> 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

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 22 Nov 2008 19:41:08 -0800

My example was about running a single uploading TCP connection, not  
about running BitTorrent.  Running BitTorrent is somewhat harder to  
analyze because of multiple connections and an aggregate macro-scale  
rate limit.

On Nov 20, 2008, at 12:27 PM, Nicholas Weaver wrote:

> download/upload ratio) is not suitable for P2P anyway,

Incorrect.  The typical cheapest broadband connection is suitable for  
running P2P.  BitTorrent works fine on it, with the expected speeds.

The 10:1 down:up ratio is typical for home connections.  More  
expensive connections can often have even higher ratios.

> it really should be "leech only",

"Should"?  It clearly gets higher download rate for young swarms with  
uploading.  Even in the most selfish interpretation it shouldn't be  
leeching only.

> as it contributes nothing to the P2P system in practice.

Incorrect.  It contributes close to 128 kb/s, which is not nothing.

--
Stanislav Shalunov

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 23 Nov 2008 08:12:11 -0800

I know your example is about a single full-rate TCP flow, not  
BitTorrent.  But your all about the "bad queue" congestion problem,  
with occurs ALMOST exclusively for people in such situations when  
doing P2P activity over web-surfing.

I'd guess that part of the reason we have gotten away with such  
grossly asymmetric links is that, outside P2P usage, I'd guess that  
most users are grossly asymmetric in usage.  I know I was, the 3-s  
uplink buffer on my DSL line only bothered me when I was uploading  
photos or synchronizing work.

On Nov 22, 2008, at 7:41 PM, Stanislav Shalunov wrote:
> "Should"?  It clearly gets higher download rate for young swarms  
> with uploading.  Even in the most selfish interpretation it  
> shouldn't be leeching only.
>

Its Amdahl's law-related:  It really IS close to nothing, and enough  
that if you care about user performance because you are experiencing  
head of line blocking issues, that reducing it to 0 is fine.

EG.  You have 1/2 the peers behind cable-modems, with 1 Mbps uplinks.   
And you have 1/2 the peers behind slow DSL links, with 128 kbps uplinks.

The P2P performance becomes limited by the uplinks in aggregate.  And  
the cable modems contribute 8x the aggregate bandwidth that the DSL  
links do.

In this case, putting ALL the DSL links to 0 upload will have a  
remarkably low effect on aggregate performance: a degradation of total  
system upload bandwidth of only 11%.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 23 Nov 2008 08:25:53 -0800

> doing P2P activity over web-surfing.

Well, there is backup like applications and photo uploading, but  
backup/synchronization over the WAN still seems to be a niche market  
(iDisk I think is the biggest player).

But in those cases, the activity can easily be time-shifted away from  
usage, rather than an integral part of getting content.