On 07/01/2008, Spencer Dawkins <[EMAIL PROTECTED]> wrote: > > Good luck. >
Ho ho, yes, there are a few little gotchas in there, aren't there? :o) I've got SEON, my TCP-like protocol, working now and getting network speeds on a par with Linux/OSX TCP. I lose 8 bytes per packet for the UDP header, but I make most of that up by having SACK built in rather than being an option, and by not having a receive window. CPU load is higher than TCP (we're running in a JVM), but it's acceptable, and there should be some scope for reducing it when I get around to doing some profiling. Fairness-wise, SEON connections seem to compete equally with TCP. The code is all GPL; if anyone is interested in a Java TCP-over-UDP implementation (penetrates NAT if you feed it the port number from STUN or whatever), let me know. Now I can start on the interesting stuff. My goal is to extend the normal TCP-like behaviour to allow for connections to be ranked in order of preference by the sender. So, a sender node has a set of connections, C = (c1, c2, ... cn), ordered so that c1 is the 'most preferred' connection, and cn is the 'least preferred'. The goals of the protocol are as follows: * The 'most preferred' connection should be able to send data at the same rate as if there were no other connections * Each connection should use as much bandwidth as possible, once more-preferred connections have taken theirs * The sender's upstream bandwidth should be as maximally-used as possible Example: Take a sender node that has 1000Kbps of upstream bandwidth, sending data to three nodes, most-preferred first: Node 1 has 750Kbps available downstream bandwidth Node 2 has 500Kbps Node 3 has 500Kbps Under normal TCP and assuming equal RTTs and conditions, each receiver will receive 333Kbps. Under my desired system, Node 1 should receive 750Kbps, Node 2 should receive 250Kbps, and Node 3 should receive nothing. Having read around a bit, the protocol that comes closest to my goals seems to be TCP-LP (Low Priority), which is detailed here: http://www.ece.rice.edu/networks/TCP-LP/ Essentially, TCP-LP works by keeping track of the highest and lowest RTT on a connection. If SRTT > (MinRTT + D(MaxRTT-MinRTT)) where D is a constant s.t. 0 < D < 1, then there is assumed to be congestion, and the connection cuts its window in half, cutting the window to 1 if another congestion 'event' occurs within a certain time. This achieves effects similar to my desired goals, except that there are only two priority levels (TCP and TCP-LP), whereas I need to have N priority levels. So, I propose to extend TCP-LP as follows: * Every sender connection maintains an isCongested property, which is the TCP-LP RTT calculation above * On packet reception, the connection checks the isCongested property. If it is true, then the connection checks to see if there are any more-preferred connections who also have the isCongested property set to true. If there are, then the connection cuts its window as per TCP-LP; otherwise it maintains its window normally. This won't achieve my goals perfectly; for example, the window never drops below 1, so less-preferred connections will always take up some bandwidth. However, it seems quite clean and is building on a proven foundation. I'm going to start implementing this, I just thought I'd post it here in case anyone had any ideas, or knew of existing protocols/systems that do what I'm after. Thanks for reading :o) W _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
