[p2p-hackers] UDP file transfer protocol peer review

[Paul Campbell]

On Sat, Jul 23, 2005 at 11:43:49AM -0700, Serguei Osokine wrote:
> 	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.

Can't do that either. If you are less aggressive than TCP, then even if you
solve the local link problem, you'll fail to get fair bandwith on the
internal network connections.

The basic problem also rears its head in the multicast vs. unicast
protocols since there's obviously a tradeoff in fairness there as well...a
multicast should theoretically be given a different treatment from a unicast
since obviously the multicast affects a greater number of connections in spite
of the fact that multicasting network impact is smaller (more destinations
sharing the same stream).

One possible way around this is to manage the ENTIRE load as X number
of TCP links. An even better way would be to monitor internal and external
link bandwith limits for the purpose of deciding how to maintain fairness
at all levels. It can be done but the protocol is going to have to have a lot
more intelligence built in than just AIMD.

This somewhat reminds me of the cool process monitor tool that AmigaOS had.
It showed a process monitor similar to what is built-in to Windows, Linux, etc.
Except that then there were sliders on it where users could trivially tune
process load on their machines. It seems like at some point it would be really
handy to have this kind of capability built into a packet filtering application
where you could adjust the relative importance and/or load of various
applications to your desire. Then when you fire off that email client or
click on a web page, it would recognize POP traffic and correspondingly give
it more bandwidth vs. the P2P file transfer that is running in the background.
This can't be done at the P2P app level because it needs to be able to
differentiate traffic across the entire link. Obviously at the internal
network level, this is meaningless since those kinds of capabilities are
already built into the routers (where necessary) or not really capable of
being used since at that level, it's a user vs. user or machine vs. machine
question.