On Mon, 2008-03-31 at 17:19 +0100, Will Morton wrote: > That's a great link, thanks! It seems that SST prioritizes different > streams within a session between two hosts, but cannot prioritize > between streams to different hosts, which is what I'm after. I'm > getting this from the spec document, which is marked as being > incomplete, so this may not be correct...?
That follows my understanding. I apparently scanned your message a little too quickly. :-) Cheers, Cyrus > > On 31/03/2008, Cyrus Hall <[EMAIL PROTECTED]> wrote: > > Have you checked out SST? > > > > http://pdos.csail.mit.edu/uia/sst/ > > > > I've worked with it a little bit, and using it's priority system would > > seem to accomplish what you've discussed. The implementation of SST is > > very solid, and is being used in a number of other projects, but they > > always love additional feedback. > > > > Cheers, > > Cyrus > > > > > > On Mon, 2008-03-31 at 16:32 +0100, Will Morton wrote: > > > 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 > > > > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
