[p2p-hackers] UDP file transfer protocol peer review

[Serguei Osokine]

On Saturday, July 23, 2005 Matthew Kaufman wrote:
> The only hard and fast rule is that you *must* perform fairly against
> TCP. (Unless your stated goal is to use the "leftover bandwidth" after
> TCP is running...

	- which, as a matter of fact, is a perfectly reasonable goal to
have in the P2P system design.

	It is a very common user complaint among BitTorrent and other P2P
systems' users that their online experience suffers greatly when their
P2P application is running. E-mail is slow, web surfing slows down to a
crawl, and so on.

	The reason for that is fairly obvilus: a P2P application tends to
have multiple open connections at all times, and its target is to keep
them all constantly saturated, maximizing its network throughput. Swarm
downloading, multiple downloads, multiple uploads - you name it.

	More often than not all these streams are TCP, so if you wish to
get your mail or do some Web browsing, your new TCP connection becomes
just another one among 5, 10, or 20 already saturated P2P ones. Hence
its data transfer rate will be 6, 11, or 21 times slower than what you
used to have without P2P application running, and your user experience
will suffer accordingly.

	One way around this problem would be to have a UDP-based P2P data
transfer protocol that would be less aggressive than TCP by design - in
that case, its swarm links would still fully occupy the available
bandwidth when the user does not use the machine for ineractive tasks,
but would shrink back in the presence of the TCP streams, allowing them
to take the full bandwidth to themselves self and allowing the user to
have the same online experience with P2P as there was without it. Until
that goal is achieved, I don't see P2P applications running on every
user machine as a background task 24x7, which is where they belong to.
Today they are too intrusive for that.

	I don't remember the LimeWire/BearShare UDP protocol details right
away, but my recollection is that it was fairly naive - hopefully, naive
enough to send much less data than it possibly could if it would have
the "real" TCP-like AIMD mechanisms. This waste of bandwidth should not
really hurt anyone when you're running ten swarming streams - their
total throughput should be fairly close to the link capacity anyway.
But at the same time, this naive approach might make these streams
shrink in the presnece of the simultaneous TCP streams on the same 
link, thus achieving the "be invisible to the user" goal.

	It would be interesting to know whether LimeWire and BearShare 
did any experiments in that field - ideally, the long FTP transfer
should be unaffected by the parallel P2P transfers (which should not
make any progress in the meantime, of course). Greg, did you try
measuring something like that?

	Best wishes -
	S.Osokine.
	23 Jul 2005.


-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
Behalf Of Matthew Kaufman
Sent: Saturday, July 23, 2005 9:20 AM
To: 'Peer-to-peer development.'
Subject: RE: [p2p-hackers] UDP file transfer protocol peer review


David Barrett:
> Ahh, consecutive losses is a great idea.  2-3 consecutive 
> losses sounds like a good threshold for decreasing.  How many 
> consecutive successes would you recommend for increasing?

The only hard and fast rule is that you *must* perform fairly against TCP.
(Unless your stated goal is to use the "leftover bandwidth" after TCP is
running or to "crowd out" TCP deliberately. Since most TCP implementations
will drop the send rate in half on a single loss, if you wait for more
losses, you most likely need to drop more than half. The only way to know
for sure if you're doing the right thing is to compare in both simulations
and the real world, and see what happens when you compete with a big TCP
flow.

There's lots more details around doing better than TCP overall... True
selective ack, sharing the congestion window on multiple flows between the
same hosts, etc.

Matthew

_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences