[p2p-hackers] avoiding uplink saturation / co-existing with other apps?

Adam Back adam at cypherspace.org
Mon May 8 00:19:09 UTC 2006


I believe this problem affects many p2p clients particularly on
asymmetric DSL links:

- the uplink becomes saturated

with the following negative implications:

- tcp ack flow-control packets acknowledging data coming down to the
the relatively unused downlink suffer congestion due to the saturated
downlink, consequently tcp performance for the downlink degrades even
though there is spare bandwidth.

- the link becomes unusable for the predominantly download focussed
(small requests large responses) other protocols the users apps are
using: http, pop etc.

Is this something one should be worrying about, or will tcp "take care
of it" gracefully?

It seemed to me that at least for a while bittorrent suffered from
this problem.

Anyone have a tried and tested algorithm/method to address this?

Like auto-detecting and backing off a bit?

Some p2p apps ask the user what bandwidth they'd like to allow and
then bandwidth limit to that rate.  However I think this is not ideal

- many users wont know what their uplink speed is

- if you are not using your link perhaps you'd like to let the p2p app
take over

- if you do what to use the link for other purposes (web browsing,
mail) you probably want this app to take precedence over the p2p app
-- providing services to other users.

I did see some earlier discussion of UDP based flow control protocols
"playing well with TCP" being discussed for non-TCP based apps --
where the hope was that the UDP flow control would be designed such
that TCP had precedence.

However for people who are using TCP for the p2p app that doesnt help.

Generally what you'd like I think is QoS and to give the p2p app
"bulk" precedence for other peoples traffic.

Comments, things others have tried, info about how well that worked?


More information about the P2p-hackers mailing list