On 4/1/06, Bob Harris <[EMAIL PROTECTED]> wrote: > ... > I can create hundreds of TCP (or TCP-like) flows in parallel, easily consume > more > than my fair share of bandwidth, and easily create congestion at the routers > by > closing and creating TCP connections (slow start, anyone?). Many p2p apps do > exactly that: open many connections to many other hosts. > > In fact, I'm cranky at the moment because some idiot's p2p download > is consuming > all the bandwidth at my current wireless hotspot. Maybe what we need is to > extend the TCP > ideas from the flow level to the host-level (and either embed them deep into > the OS > or enforce them via traffic shaping).
traffic shaping is an excellent idea and something i encourage and use routinely. implementing policy at the host/endpoint level is much better than trying to kludge it within an application (throttling TCP sockets in userspace, etc) that has a very limited view of network capability and status. regarding UDP: the reliable multicast charter has done a lot of work to couple congestion avoidance and reliable transmission for datagram transport without the full overhead of a TCP like mechanism. my personal preference when using UDP to many endpoints (although i admit i've focused mostly on signalling/control channels with UDP) is to limit overall throughput to a fixed fraction of available bandwidth. this way TCP and other transports can negotiate session capacity within the remaining bandwidth. _______________________________________________ p2p-hackers mailing list [email protected] http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
