Okay, here's our present algorithm: a = 0.875 (for packets) b = 4*(1-a*a)/3 = 0.3125
When a packet is successfully transmitted we increment the window size by b. When a packet is lost we multiply it by a. We send packets every (round trip time / window size). This is definitely TCP-friendly? For all possible a? TCP itself uses a=0.5 from what I've been able to gather. If this is the case, then we have to address the question of requests: a = 0.97. b is calculated as above. When we get a RejectedOverload (a node rejected a request due to overload; the node has been backed off by its direct peer, this was forwarded back to us, but the request continues), we multiply the window size by a - even if we have already had one in this request. When the request completes, unless it times out, even if it has had some RejectedOverload's, we increase the window size by b. We send a request every (round trip time / window size), where the round trip time is the average time taken for a completed, non-timed-out request (even if it has had some RejectedOverload's). The objective here is to stabilize the number of RejectedOverload's to a reasonable, low, level. We will have a single window for all types of requests (CHK/SSK insert/fetch), but separate round trip times for each. Does this seem reasonable? Is it likely to be stable? On Wed, Apr 12, 2006 at 04:32:05PM +0100, Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matthew Toseland wrote: > > "Every time a group of packets equivalent to the congestion window has > > been successfully acknowledged one packet is added to the congestion > > window (picture 1)." > > This is only true in congestion avoidance mode - the behaviour in slow > start mode is more aggressive and matches what you described for Dijjer. > > When the congestion window is less than the slow start threshold (slow > start mode), the congestion window is increased by one each time a > segment is acknowledged. This produces exponential growth as long as all > segments are acknowledged, because in the first RTT one segment is sent > and acked, in the next RTT two segments are sent and acked, etc. > > When the congestion window is greater than the slow start threshold > (congestion avoidance mode), the congestion window is increased by one > over its current size each time a segment is acknowledged. This produces > linear growth as long as all segments are acknowledged: the congestion > window increases by one each round trip time. > > The slow start threshold is calculated dynamically using the amount of > data in flight and the sender's maximum segment size; RFC 2581 has the > details. > > Cheers, > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQFEPR11yua14OQlJ3sRAhHEAJ9nOoe7bkTQcqllpRb3z8phy4IWMACg13CJ > JdVNMBA40QBX2qJaQZtZkLs= > =zgG6 > -----END PGP SIGNATURE----- > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060412/70102bcb/attachment.pgp>
