-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland wrote: > It seems like premature > optimization to me, lets get the basics right first.
Fair point - forget about calculating the receiver windows. Let's go back to the previous idea of incrementing one of the receiver windows (in round-robin or random order) whenever a request is forwarded or answered locally, which automatically matches the rate at which we accept requests to the rate at which we can process them. If we can't forward a request (because of the bandwidth limiter, the congestion window or the receiver window), we return a RejectedOverload and don't increment any of the receiver windows. There's no special reaction to local RejectedOverloads, because the congestion window and receiver window already control the speed of the link and ensure fairness. The only node that reacts to a RejectedOverload is the sender, which reduces its sending rate if it's well-behaved. It's too hot to think straight - does this sound sensible to you? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEjVDXyua14OQlJ3sRAhryAKDtOVrjGtK0QKdNPm6tpr0MFZ+0lgCg6w/+ T7b9ar6k7c4OImcCGNSuwuM= =ALtV -----END PGP SIGNATURE-----
