On Wed, Mar 9, 2011 at 1:23 PM, Jeffrey Altman <[email protected]> wrote: > While I have no objections to discussions regarding extending the RX > abort packet format, I agree with Jeffrey Hutzelman that we need to > understand what we intend to do with it. I do not believe that > extending the packet format to describe "throttling" is a good idea. >
I think I agree, although for slightly nuanced reasons: I'm concerned that we will implement dynamic behavior on the client that is ostensibly correct, yet ultimately fails by virtue of being somewhat naive. We need to take careful note of the fact that a big distributed system is inherently a dynamics problem, and thus simplistic control solutions tend to cause oscillation. If we're going to do this, we need to think long and hard about how to approach distributed throttling from the perspective of control theory (e.g., is throttling information necessary and sufficient for clients to make good decisions?). Does anyone have the time and patience to start thinking about distributed systems control, load balancing, and throttling in terms of phase space and systems of differential equations? ;) That being said, I guess I'm not entirely opposed to encoding such information (in a very generic sense) on the wire, as I do think server-side throttling is a common-enough technique that most any non-trivial RPC server must implement it in some form or another. However, I think the I-D would need to explicitly warn implementors about the perils of using this information for purposes of implementing dynamic client behavior... Cheers, -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
